Geum.ru

Научно-учебный комплекс "Институт прикладного системного анализа" Кафедра

Вид материалаУчебный комплекс

Содержание


3. МОДЕЛИ И ИНСТРУМЕНТАЛЬНЫЕ СРЕДСТВА ПОСТРОЕНИЯ АБИС/ЭБ В КОНТЕКСТЕ ОНОИП 3.1. АБИС/ЭБ как открытая система
3.2. Базовые функции АБИС
Подобный материал:
1   2   3   4   5   6   7   8   9   10   ...   14

3. МОДЕЛИ И ИНСТРУМЕНТАЛЬНЫЕ СРЕДСТВА ПОСТРОЕНИЯ АБИС/ЭБ В КОНТЕКСТЕ ОНОИП

3.1. АБИС/ЭБ как открытая система


АБИС/ЭБ являются сложным высокотехнологичным ПО/ИС, и естественно, должны удовлетворять свойствам открытости. В [17] анализируется понятие открытая система, которое сформулированно специалистами IEEE и подчеркивает аспект среды.

Открытая АБИС/ЭБ должна реализовывать определенный набор функций, который, имеет многоуровневую структуру. Идеальной представляется такая ситуация, когда существует открытая архитектура АБИС/ЭБ. Под открытостью здесь подразумевается в первую очередь “общепринятость”, основанная на стандартах, минимальных требованиях к реализации, рекомендациях и т. п. Если бы все разработчики АБИС,ЭБ создавали свои системы на базе открытой архитектуры, то проблем с открытостью не было бы. Однако в целом такая ситуация пока что реально не достижима и приведение существующих АБИС/ЭБ к базису такой открытой архитектуры (которой пока нет), скорее всего, будет коммерчески нецелесообразно. Следует отметить, что такие работы стоят очень дорого, а рынок АБИС/ЭБ гораздо меньше, чем рынок другого ПО (операционные системы, офисные системы, бизнес системы и пр.), где затраты на развитие быстро окупаются. Несмотря на вышесказанное, создавать открытую архитектуру имеет смысл, но не как некоторую вещь в себе, оторванную от практики, а как реализацию концепции развития АБИС/ЭБ, не навязывающую конкретных сиюминутных решений. Необходимо обеспечить участие в разработке такой концепции производителей АБИС/ЭБ.

Можно выделить следующие основные задачи построения концепции развития АБИС/ЭБ:
  • Разработка общих спецификаций построения стандартов взаимодействия компонент (модулей) АБИС/ЭБ, как автономных (имеющих самостоятельное значение), так и зависимых (интегрирующихся). Имеется ввиду не только сетевое взаимодействие, но и обычное межпрограммное.
  • Обеспечение высокой динамики и гибкости (расширяемости с сохранением совместимости) развития стандартов взаимодействия, сокращение сроков их внедрения. Для этого при разработке или модификации стандартов необходимо учитывать существующее положение вещей, возможности различных АБИС/ЭБ. Также необходимо, с одной стороны, в максимально возможной мере следовать международным и государственным стандартам, а, с другой стороны, не превращать эти стандарты в идолы, не допускать, чтобы они мешали реальной работе и развитию. В последнем случае лучше отдавать предпочтение отраслевым стандартам, нежели международным, которые, как известно, неповоротливы и опаздывают (если за ними не стоит крупная компания).
  • Выработка гибкой политики взаимодействия производителей АБИС/ЭБ, которая обеспечивала бы не только взаимодействие между различными АБИС/ЭБ как автономными системами, но и программную интегрируемость модулей разных производителей. Например, чтобы, имея некоторую АБИС/ЭБ, можно было использовать модуль анализа и представления статистики (или, например, модуль книгообеспеченности) от другой системы или такой модуль от производителя, который специализируется именно на таком ПО (не занимаясь разработкой собственно БС). «Хорошую» АБИС/ЭБ сделать трудно, но еще труднее сделать такую систему, которая бы превосходила все другие по всей функциональности и ее качеству. И производители, которые разрабатывают не АБИС/ЭБ целиком, а некоторые ее компоненты, могут добиться лучших результатов. Например, несмотря на развитие систем управления базами данных, продолжает существовать ПО сторонних производителей для генерации отчетов. Кроме того, у разных пользователей разные представления о качестве, удобстве. С этой точки зрения создание идеальной АБИС практически невозможно.

Остановимся на болем детельном рассмотрении некоторых технических свойств открытых систем:

– Расширяемость/масштабируемость. Обычно под этим понимают возможность исполнения ПО в распределенном режиме, т. е. на нескольких процессорах, на нескольких компьютерах, а также возможность наращивания нагрузки при соответствующем наращивании мощности аппаратуры (от тривиальной до создания кластеров), увеличения количества рабочих станций в сетевом аспекте.

– Мобильность/переносимость. Это свойство, без сомнения, является важным для конечного пользователя. Однако в том виде, как оно пояснено выше, при существующем уровне программных технологий, оно выполняется практически само собой. И здесь гораздо важнее возможность переноса при замене программной платформы.. Реализовать платформо-независимую АБИС/ЭБ возможно, но требует значительных усилий, причем с самого начала процесса разработки. В дальнейшем, при неправильном выборе среды разработки или выборе используемого ПО сторонних фирм, потребуется на порядок большие усилия для реализации переносимости. А ресурсы производителей АБИС/ЭБ, как уже говорилось, ограничены в связи с специфичностью рынка.

— Интероперабельность. Этому свойству АБИС/ЭБ в последнее время уделялось особое внимание. Под взаимодействием обычно понимают сетевое взаимодействие. Однако сюда можно и отнести и опосредованное взаимодействие через внешние файлы данных. И здесь, на основании опыта, полученного в процессе как эксплуатации АБИС/ЭБ, так и в процессе перехода с одной АБИС/ЭБ на другую, можно констатировать, что важнейшей функцией, с которой начинается открытость — это возможность экспорта/импорта всех (возможно, за исключением служебной информации) данных из/в АБИС/ЭБ в формате, стандартном для данной области (напрнмер, MARC и ISO2709 для библиографических записей или DC) или, для “нестандартных” (не библиографических) данных, в формате с открытом описанием, позволяющем в полной мере отразить структуру данных. Перейдем теперь к сетевому взаимодействию. В области АБИС сетевое взаимодействие в основном связывают с протоколом Z39. 50, который является международным стандартом. Следует заметить, что этот протокол не предназначался для организации взаимодействия АБИС. Он предназначен для организации взаимодействия клиентского ПО с серверным ПО, хотя и то и другое могут принадлежать различным АБИС. При этом основной причиной, сдерживающей его распространение, является его сложность. Можно сказать, что для той функциональности, которую обеспечивает этот протокол, он не является сложным. Другое дело, что большая часть этой функциональности в большинстве случаев не будет востребована на практике, а для того чтобы реализовать собственно межсистемное взаимодействие потребуется реализовывать и клиент и сервер.

Если поставить задачу организации межсистемного взаимодействия наиболее простым и открытым способом (в рамках рассматриваемой выше концепции развития), то наилучшим решением в ряде случаев (зависит от требуемой функциональности) будет разработка специализированного прикладного протокола (типа SOAP). Появление языка описания структурированной информации XML и соответствующего ПО для работы с ним практически до предела упрощает работу с содержательной частью протокола (протокольными блоками данных). XML не создает открытость, это лишь удобное (для решения определенных задач) средство. Более того, в ряде случаев с простой функциональностью можно решить задачу сетевого взаимодействия гораздо проще без использования XML.

3.2. Базовые функции АБИС

Функции системы складываются из переосмысленных и переложенных на автоматизированную платформу традиционных библиотечных технологий. Существенным моментом здесь является осмысление того, что автоматизированная технология может, сохраняя основную идеологию, существенно отличаться от традиционной. Ярким примером здесь является, например, “безбумажная” технология, т. е. такая технология при которой не существует традиционных каталожных карточек, читательских требований и многих бумажных форм отчета и выходных форм. Однако совершенно понятно, что не каждая библиотека сможет быстро отказаться от производства, например, каталожных карточек и ведения традиционных картотек, а это значит, что в функции системы обязательно должна входить возможность напечатать весь существующий набор каталожных карточек. Таких примеров можно привести множество.

Общее правило. АБИС должна разрабатываться на основах классического структурного программирования, в котором модульный принцип построения системы является основным. При этом количество разработанных модулей – программ, конечно, отличается и значительно превышает количество функциональных модулей АРМов. Количество и функциональное назначение АРМов может быть разнообразным, но основными, т. е. такими, без которых нельзя обойтись в современной системе, должны быть АРМы, выполняющие следующие функции:
  • администрирование, включающее в себя функции настройки системы и ее модификации;
  • комплектование фонда;
  • ввод данных и создание библиографического описания;
  • информационный поиск и заказ изданий;
  • обслуживание читателя;
  • создание Интернет/Интранет серверов и обеспечение удаленных функций поиска, заказа и каталогизации;
  • обеспечение корпоративных технологий;
  • блок регистрации читателей, модуль МБА и ЭДД и др.

Конечно в современной системе все эти функции должны присутствовать, но будут они выделены в отдельные модули – АРМы или будут функционально скрыты в основных блоках – непринципиально.

1) Система работает только в локальном режиме, точнее только в локальной вычислительной сети библиотеки, т. к. на каких бы современных средствах не разрабатывалась система, практически все они поддерживают сетевые режимы работы. При этом набор модулей – АРМов может варьироваться. ЭБ должна иметь возможность, наращивая мощность вычислительной техники, одновременно наращивать мощность автоматизированной системы, последовательно осваивая новые для себя автоматизированные функции.

2) Система работает в глобальных сетях, в таких как например, Интернет. АБИС такой структуры хорошо подходят для библиотек, имеющих разветвленную сеть отделений и филиалов, так как в центральной библиотеке устанавливается собственно система, а в отделениях и филиалах находятся только терминалы. В этом случае все структурные подразделения связаны в единую сеть единой автоматизированной технологией, подчиненной центральной библиотеке. На мой взгляд, нельзя связывать в такую сеть разнородные библиотеки и даже библиотеки одного назначения, но имеющие собственный юридический статус. Тому только одна причина – эти библиотеки заведомо потеряют собственное лицо, так как их функции в конечном итоге будут сведены к созданию сводного электронного каталога в центральной библиотеке, а остальные автоматизированные технологии будут диктоваться. Нельзя так же отметать тот факт, что для надежной, бесперебойной работы автоматизированной системы необходимо иметь хорошие высокоскоростные каналы связи (лучше оптико-волоконной), так как любой перебой в связи неминуемо приведет к останову одной или нескольких библиотек.

3) Система работает как в локальной вычислительной сети, так и в глобальных сетях. Такая структура позволяет библиотекам творчески подходить к создаваемым ею технологическим процессам и просто выходить на такие масштабные задачи, как создание сводных ЭК и систем корпоративной каталогизации и др., так же как и в предыдущем случае, но сохраняя собственное лицо каждой библиотеки.

Для того, чтобы эти функции стали достаточными следует рассмотреть дополнительные возможности систем, без которых их сегодня невозможно представить. Отнесем к ним следующие:
  • Поддержка произвольного количества баз данных, составляющих ЭК или представляющих собой проблемно-ориентированные библиографические БД;
  • Технология автоматического формирования словарей, на основе которых реализуется быстрый поиск по любым элементам описания и их сочетаниям;
  • Средства для ведения и использования Авторитетных файлов;
  • Поддержка традиционных “бумажных” технологий: от печати листов заказа и книги суммарного учета до печати всех видов каталожных карточек;
  • Технологии, ориентированные на использование штрих–кодов на экземплярах изданий и читательских билетах;
  • Поддержка полных текстов, графических данных и других внешних объектов (включая ресурсы Internet);
  • Средства для перевода пользовательских интерфейсов на другие языки;
  • Широкий набор сервисных средств, обеспечивающих удобство и наглядность пользовательских интерфейсов, упрощающих процесс ввода, исключающих ошибки и дублирование информации;
  • Широкие возможности для адаптации к условиям работы конкретной ЭБ в соответствии с профилем организации;
  • Соблюдение ДСТУ, и в первую очередь ДСТУ на библиографическое описание;
  • Правильная трактовка международных и отечественных коммуникативных форматов;
  • Возможность экспорта и импорта как в различных коммуникативных форматах, так и в “договорных” форматах (структурированном текстовом, вариантах ISO 2709 и др.);
  • Возможность использования тезаурусов и словарных БД;
  • Возможность использования БД классификаций и рубрикаторов.

Разработка полного перечня необходимых и достаточных функций систем требует специальной, серьезной проработки и классификации.