рис. 2 Компоненты справочной системы
А.Г. Никитин, А. М.Савин
Институт систем информатики СО РАН имени А. П. Ершова. 2002.
Программные системы управления электронной справочной документацией предназначены для автоматизации труда разработчиков электронных книг по организации информации в логическую структуру и снабжения ее средствами управления, навигации и поиска в содержимом. Непосредственные пользователи справочников при помощи программных средств, предоставляемых такой системой, применяют предусмотренные для них способы доступа к нужной информации.
В перечне функциональных возможностей справочных систем[1] можно выделить ряд ключевых пунктов, поддержка которых de facto обязательна в современных программных комплексах автоматизации управления электронной документацией.
Кроме того, в набор требований к базовой функциональности современной электронной справочной системы входит способность обеспечить сетевые издания (основанные на технологии WWW) характерными для справочных систем средствами навигации. Также важна возможность интеграции в программные комплексы и поддержка контекстно-зависимой справки.
На сегодняшний день можно выделить ряд справочных систем, нашедших широкую область применения, благодаря тем или иным удачным деталям своей архитектуры и реализации. На [рис. 1] приведена таблица, в которой для них проведено сравнение важных (в рамках решаемой задачи) функциональных возможностей. Ключевые детали этого анализа подробно освещены ниже.
| Man | AppleHelp | NetHelp2 | WinHelp | HtmlHelp | JavaHelp | |
|---|---|---|---|---|---|---|
| оглавление и предметный указатель | +/- | + | + | + | + | + |
| поиск по содержимому | - | + | + | + | + | + |
| базовый формат для представления содержимого | Текст | HTML | HTML | RTF | HTML | HTML |
| несколько различных языков в одном документе | - | - | - | - | +/- | + |
| поддержка сетевых WWW-изданий | - | + | + | - | + | + |
| встраиваемость в приложения и контекстно-зависимая справка | - | + | - | + | + | + |
| открытость системы[2] | + | - | - | - | - | +/- |
| возможность расширять по своему усмотрению | - | - | - | - | - | +/- |
| создание коллекций книг и средства управления ими | - | +/- | - | - | +/- | - |
| базовая программная платформа | Unix | MacOS | Communicator | Windows | Windows | Java |
рис. 1 Сравнение
функциональных возможностей известных
справочных систем
(+/- в клетке означает, что в данной системе
соответствующая возможность
поддерживается, но не в полной мере).
И таблицы видно, в частности, что Man (традиционная базовая справочная система для платформ семейства Unix) сильно уступает остальным в поддержке различных средств навигации: у нее они ограничены только предметным указателем. Зато несомненными плюсами Man являются компактность и отсутствие жестких требований к производительности, эти достоинства и позволили ей завоевать популярность в областях, где они играют важную роль. Впрочем, ввиду своей специфики, Man не интересует нас в рамках решаемой задачи и приведена в обзоре исключительно для полноты картины.
Практически все справочные системы, подлежащие рассмотрению, ограничены единственным, хоть и очень гибким, форматом для документов, составляющих справочник, для этого они используют такие технологии как Hypertext Markup Language (HTML) или Rich Text Format (RTF). Это позволяет им, не ограничиваясь простым текстом, снабжать книги сложно устроенными средствами оформления и пояснения информации, в том числе иллюстрациями и различной активностью (например, при помощи скриптовых языков). Кроме того, поскольку HTML является основой для WWW, то его использование влечет за собой естественную поддержку работы с электронной справочной документацией, доступ к которой осуществляется через WWW. RTF, в сравнении с HTML, лишен этих преимуществ.
Подавляющее большинство приведенных систем электронной справки (за исключением JavaHelp корпорации Sun являются закрытыми, то есть информация об их структуре, принципах функционирования и формате служебных данных не является открытой для публичного доступа и защищена авторским правом. Вся документация о таких системах, которую официально можно получить - это спецификация пользовательского интерфейса для набора предоставленных производителями программных приложений, которыми жестко ограничены возможности использования системы, поскольку применение этих приложений во многих случаях неудобно, а порой и вовсе невозможно.
Технология, при помощи которой построена система JavaHelp [1], здесь обладает несомненным преимуществом, поскольку обладает открытыми возможностями настройки и изменения функциональности. Эти возможности предполагают не только замену компонентов пользовательского интерфейса, но и средства, позволяющие встроить в систему модуль (класс в терминах языка Java, удовлетворяющий определенному интерфейсу, который бы осуществлял поддержку необходимого способа навигации (например, отличного от предопределенных, таких как оглавление, предметный указатель … т.д.). Информация о JavaHelp, доступная разработчикам, включает в себя развернутую спецификацию программного интерфейса системы, реализованной для программной платформы Java, с описанием базовых классов Java, которыми оперируют методы интерфейса, а также открытый формат хранения служебной информации. Подробности того, как с точки зрения архитектуры JavaHelp устроен внутри (то есть того, что стоит за гибкостью и красотами внешнего программного интерфейса), неизвестны, поэтому осуществление переноса с базовой программной платформы на другую теми разработчиками, у которых появляется такая необходимость, является трудоемкой задачей.
Использование нескольких различных языков для содержимого (подразумевается, что это должно поддерживаться всеми сервисами, в том числе механизмом текстового поиска) в пределах одного справочника и документа из всех рассмотренных систем возможно только в JavaHelp, которая использует для этих целей Unicode.
Поддержка объединения готовых книг в коллекции есть среди возможностей систем HtmlHelp [2] и AppleHelp [3]. AppleHelp ограничивается только созданием коллекций, но для непосредственных пользователей никаких средств управления составом готовых библиотек в этой системе не предусмотрено. HtmlHelp в том виде, в котором он доступен разработчикам электронных книг, создавать коллекций не позволяет. Но библиотека Microsoft Developer Network (MSDN), основанная на HtmlHelp, представляет собой организованный набор самостоятельных справочников, то есть в наших терминах как раз коллекцию, и имеет в арсенале мощный механизм управления составляющими элементами. Так HtmlHelp версии 1.3, которая на сегодняшний день является фактически стандартной системой электронной справки для платформы Windows, позволяет создавать подмножества в готовой коллекции из входящих в состав справочников, позволяя просто указывать отдельно для каждой книги в коллекции, входит она в данное подмножество или нет.
Подводя итоги обзора, следует отметить, что с точки зрения выдвинутых требований, JavaHelp благодаря своим способностям к расширению оказалась наиболее привлекательной в качестве основы для создания системы электронной справки. Но и она, несмотря на все преимущества перед остальными, обладает рядом существенных ограничений, которые делают невозможным ее использование для наших целей. Во-первых, это принципиальное ограничение формата документов HTML-ем, обойти которое средствами JavaHelp нельзя, поскольку большинство ее основных возможностей построено, опираясь на этот факт, а также отсутствие поддержки коллекций и средств управления ими.
Таким образом, поскольку с помощью существующих справочных систем невозможно найти удовлетворительное решение поставленной задачи, возникает необходимость в проектировании и реализации собственной системы.
Безусловно, невозможно создать единственную программную реализацию сервисов справочной системы, которая бы полностью удовлетворяла пожеланиям всех клиентов. Поскольку различные области применения хоть и предполагают использование общих принципов организации базовых средств навигации и логики управления ими, но требуют специфического и зачастую принципиально отличного от других подхода к реализации более сложных, комплексных возможностей доступа к актуальной информации, в том числе элементов пользовательского интерфейса. Поэтому при создании архитектуры универсальной системы необходимо предусмотреть способы гибкого изменения функциональности, чтобы разработчики могли легко подстраивать систему под нужды потребителей.
Перед авторами данной работы стояла задача разработки системы управления электронной справочной документацией, удовлетворяющей следующему ряду принципиальных требований, которые не являются традиционными для систем такого рода, но позволяют значительно расширить области их применения и возможности работы с большими объемами данных.
Основное требование заключается в организации системы таким образом, чтобы помимо реализации всех перечисленных выше обязательных для справочных систем функциональных возможностей, она обладала бы компактностью реализации, расширяемостью, настраиваемостью под любую область применения посредством динамической замены составляющих компонент без перекомпоновки системы в целом.
Еще один из необходимых аспектов расширяемости справочной системы заключается в поддержке возможности использовать для компоновки справочников документы в различных форматах представления. Поскольку в различных областях деятельности, связанных с вычислительной техникой, применяются различные форматы для хранения информации (это обусловлено не только их спецификой, но также историческими и экономическими факторами), то такая возможность позволит избежать необходимости хранить несколько копий одних и тех же документов в различных форматах, что при работе с большими объемами информации позволит не только экономить ресурсы, но и сильно упростит контроль версий. Кроме того, подобный подход позволил бы применять справочную систему как механизм для организации объемной совершенно разнородной информации в общую структуру и осуществлять доступ к ней, используя средства навигации из состава справочной системы.
Также ключевым пунктом в рамках задачи является предоставление справочной системой программных средств для объединения электронных книг в коллекции. А для непосредственных пользователей в качестве средств автоматизации управления уже готовыми коллекциями необходимо предусмотреть возможности выделения подмножеств их содержимого, что сделает более удобным применение обычных средств навигации в объемных коллекциях. Поддержка подобных сервисов позволяет организовать общую структуру издания , объединив несколько справочников меньшего объема, и получить, таким образом, электронный аналог библиотеки. Это не только значительно упрощает работу с большими объемами электронных документов различной тематики, но и дает возможность, комбинируя наборы готовых электронных книг, создавать различные справочные библиотеки, что является несомненным удобством, например, при организации тематических подборок материалов или же при создании справочной документации к приложениям, которые могут поставляться в различной комплектации.
Возможность построить решение на базе уже существующих программных комплексов электронной справки, безусловно, важна и требует тщательного анализа. Этому вопросу целиком посвящена следующая глава.
При проектировании системы управления электронной справочной документацией была использована так называемая компонентная модель, для которой характерно представление программного комплекса в виде совокупности динамически связываемых бинарных модулей (компонентов). Выбор такого подхода, как показано ниже, обуславливает гибкие возможности расширения системы, которые полностью удовлетворяют требованиям рассматриваемой задачи.
рис. 2 Компоненты справочной системы
На диаграмме [рис. 2] приведена схема разбиения системы электронной справки на компоненты в рамках предлагаемой архитектуры. Одной из важных особенностей этого решения является выделение в отдельную структурную составляющую так называемого ядра системы (HelpEngine), в котором сосредоточена логика по поддержке базовых сервисов системы. Ядро предоставляет программный интерфейс для доступа к набору объектов, представляющих структурную организацию функциональных возможностей системы.
Обозначенные на диаграмме как HelpView, компоненты внешнего управления играют роль элементов пользовательского интерфейса. HelpBroker – это управляющая компонента, предназначенная для динамического связывания и синхронизации состояний ядра и всех HelpView.
Далее подробно рассмотрены все указанные компоненты, их роли в архитектуре и логические схемы взаимодействия друг с другом.
Как уже было отмечено, актуальные действия по поддержке основных средств управления справочной документацией осуществляются в пределах ядра системы. Внешний интерфейс этой компоненты предоставляет ряд операций над набором объектов, составляющих структурную основу механизмов реализации функциональных возможностей.
Справочная информация доступна в виде статей. Статья – это минимальный с точки зрения средств навигации блок информации. Как часть внутреннего устройства ядра, она объединяет строку URL, указывающую местонахождение непосредственного содержимого документа, и соответствующую статье базу данных механизма текстового поиска. Использование URL добавляет дополнительную гибкость, поскольку стандарт URL предусматривает возможность использования для доступа к документу практически любого протокола (в том числе протокол file, то есть “путь” в файловой системе, или, например, http, являющийся основным протоколом передачи информации по WWW).
Набор статей объединен в книгу (HelpBook), в состав которой также входят разделы оглавления, предметного указателя и контекстно-зависимая справка.
Текстовый поиск. Для базового механизма поиска текста по справочнику была определена схема организации, при которой отдельная база данных поисковой машины создается для каждой статьи. Способ осуществления операции поиска был определен следующий: последовательный перебор всех статей и анализ поисковой базы данных каждой из них на предмет соответствия строке запроса. Не смотря на ряд ограничений, характерных для выбранного подхода, несомненными его достоинствами являются простота и отсутствие необходимости перегенерации служебной информации при слиянии нескольких справочников в один. А простота организации может явиться определяющим фактором при создании компактной и эффективной программной реализации механизма текстового поиска.
Оглавление (table of content). Логическая структура оглавления изображена на рис. 3]. Способ ее организации позаимствован у обычных бумажных изданий, где этот раздел традиционно составлен в иерархию. Элемент такой древообразной структуры может иметь вложенные элементы, тогда он представляет собой раздел, или не иметь их, тогда это подпункт. И раздел, и подпункт могут ссылаться не более чем на одну статью, и, если подпункт такую ссылку должен иметь обязательно, то раздел может на статью и не ссылаться.
рис. 3 Структура оглавления
Предметный указатель (index). Логическая структура предметного указателя, изображена на [рис. 5]. Она представляет собой дерево, узлами которого являются ключевые слова (keywords). Каждому ключевому слову может быть сопоставлен набор из нескольких статей (одной как минимум). Иерархическая структура предметного указателя служит для представления ключевых фраз, составленных из ключевых слов. Подобный подход характерен и для традиционных бумажных книг, пример такого иерархического предметного указателя вложенности 3 приведен на [рис. 4]. Ключевая фраза, соответствующая узлу такого дерева, составляется из ключевых слов, лежащих в узлах на пути от заданного узла к основанию. (например, ключевая фраза [рис. 4] “Длина последовательности” + “пути” + “взвешенная” + “общая” упоминается на стр. 288 ).
рис. 4 фрагмент предметного указателя из книги “Алгоритмы и структуры данных” Н. Вирт. Мир. 1989 г.
Каждый подуровень предметного указателя традиционно упорядочен в алфавитном порядке.
рис. 5 Предметный указатель
Контекстно-зависимая справка. Механизм поддержки возможности обращения к различным частям справочной информации, в зависимости от заданного контекста, основан на сопоставлении набора статей некоторому целочисленному идентификатору, представляющему логический контекст. Это общепринятый подход среди существующих систем электронной справки.
Ассоциативные связи (A-links). Так называются ссылки из содержимого одной статьи на другую из состава справочника. Механизм их реализации очень похож на механизм реализации контекстно-зависимой справки. Статьям, на которые возможны подобные ссылки, ставится в соответствие идентификатор, с помощью которого осуществляется и отсылка.
Организация справочника. Еще одна важная деталь в устройстве ядра заслуживает пристального внимания. Это способ добывания управляющей информации при составлении справочника из разрозненных документов. Делается это в ядре при помощи параметризации операции создания справочника загрузчиком (Loader) служебной информации. Внутреннее устройство загрузчика скрыто, а внешний интерфейс включает в себя методы получения уже скомпонованных предметного указателя, данные соответствия ID -> статьи для контекстно-зависимой справки и ассоциативных связей, а также всей текстовой информации из документа для создания базы данных механизма текстового поиска. Загрузчик, таким образом, представляет собой пример использования приема проектирования (design pattern) “строитель” (builder) [5]. По замыслу подстановка различных загрузчиков позволит использовать различные форматы для документов, помещаемых в состав справочника.
Для логической организации информации посредством структуры оглавления в API ядра предусмотрены специальные средства.
В рамках предлагаемой архитектуры коллекция (электронная библиотека) представляет собой объединенный набор книг (HelpBook) и обладает объединенными оглавлением, предметным указателем и остальными разделами, то есть выглядит, в свою очередь, как одна книга. Таким образом, при создании коллекций встает необходимость слияния соответствующей служебной информации входящих в нее книг.
Объединенное оглавление коллекции отражает ее логическую организацию. Оглавление каждой книги из состава коллекции становится его поддеревом и целиком помещается в указанное место. Механизм создания объединенного оглавления предполагает возможность делать одни справочники логически вложенными в другие. Данный подход обеспечивает наиболее гибкие возможности организации логической структуры коллекций, чем, например, простой линейных набор книжек.
Для поисковой службы проблема слияния имеет тривиальное решение, благодаря особенностям ее структуры (уже рассмотренным в соответствующем разделе), но для предметного указателя и механизма контекстно-зависимой справки предусмотрены специальные средства, позволяющие это делать.
И если созданием коллекций занимается разработчик, то для непосредственного пользователя (читателя) предусмотрены возможности управления содержимым готовых коллекций путем создания подмножеств их содержимого. Для этих целей используется механизм фильтров на основе тематических атрибутов.
В рамках коллекции каждой книге, входящей в ее состав, ставится в соответствие набор атрибутов. Атрибут имеет символьное имя, отражающее его тематическую принадлежность, и может быть общим для нескольких книг. Пользователь имеет возможность создавать новые атрибуты.
рис. 6 Пример фильтра и определяемого им подмножества
Создание подмножеств содержимого коллекции осуществляется при помощи фильтров. Фильтр представляет собой предикат, связывающий атрибуты с помощью логических операций. Результат вычисления предиката для каждой книги в составе топика означает, принадлежит ли она подмножеству, определяемому фильтром. При вычислении предиката, истинными полагают переменные, которым сопоставлен атрибут, имеющийся у рассматриваемой книги, остальные полагают ложными [рис. 6]. В коллекции есть выделенное так называемое активное подмножество (то есть то, с которым происходит работа в данный момент). Для каждой статьи в коллекции предусмотрена возможность узнать, принадлежит она активному подмножеству или нет. Службы навигации работают всегда только со статьями, принадлежащими активному подмножеству. В коллекции по умолчанию существует как минимум одно подмножество, соответствующее пустому фильтру и включающее в себя все статьи.
Предложенный способ создания подмножеств является, очевидно, более гибким, чем поддерживаемый системой HtmlHelp 1.3. (то есть простое включение-выключение каждой отдельной книги в коллекции). Достаточно сказать, что средства, предоставляемые HtmlHelp 1.3, можно легко реализовать при помощи предложенной в работе схемы.
В заключении разговора про коллекции, следует обратить внимание, что основными структурными единицами при работе системы являются не книги, которые в качестве логической структуры играют только вспомогательную роль, а коллекции, то есть книга не может существовать сама по себе и обязательно входит в состав коллекции.
Нужно отметить, что приведенная на [рис. 2] модель соответствует организации той части программной системы, которая предназначена для непосредственного пользователя справочников. Для строения программного приложения, ответственного за создание электронных книг и коллекций, в рамках предложенной архитектуры предусмотрен лишь открытый интерфейс ядра системы.
Введение такой сущности как управляющая компонента (HelpBroker) объясняется необходимостью осуществлять синхронизацию всех компонент внешнего управления и состояния ядра системы. Сосредоточив механизмы по такой синхронизации в пределах компоненты HelpBroker, в результате получаем возможности делать HelpView наиболее простыми, а именно, замена управляющих компонент пользовательского интерфейса - наиболее актуальный способ расширения системы.
Приведенная схема предусматривает для каждого из сервисов навигации механизм регистрации у HelpBroker соответствующей управляющей компоненты пользовательского интерфейса (HelpView). Также предусмотрен HelpView, служащий для просмотра непосредственно содержимого статей справки, и отдельный HelpView для отображения списка статей, являющихся результатом операции поиска.
По замыслу, действия по изменению справочной информации, с которой работает система, то есть загрузка или выгрузка коллекций и изменение активного подмножества (фильтра), выполняются посредством внешнего интерфейса компоненты HelpBroker. HelpBroker, выполнив соответствующие операции ядра, заботится о нотификации всех зарегистрированных HelpView.
Для обратной связи между HelpBroker и HelpView также предопределен ряд механизмов. Так, например, объекты HelpView, служащие для доступа к средствам навигации, извещают HelpBroker о том, что пользователь желает просмотреть одну из статей, HelpBroker дает соответствующую команду HelpView, ответственному за показ содержимого справки. Похожие действия осуществляются для операций поиска статей при помощи соответствующего HelpView.
Для HelpView предусмотрены дополнительные средства общения с HelpBroker, например, HelpView, демонстрирующий содержимое статей, имеет возможность сообщить управляющей компоненте о неудачном результате попытки показать документ. Для поддержки механизма ассоциативных связей во взаимоотношениях этих двух компонент предусмотрен ряд специальных вызовов.
Предложенная компонентная структура системы имеет большой потенциал для расширения. Поскольку внешний интерфейс каждой из составляющих полагается открыто опубликованным, то любую из них можно без труда заменить на другую, удовлетворяющую этому интерфейсу и, возможно, расширяющую его. Как уже было отмечено выше, наибольшее удобство и простоту предложенная модель обеспечивает для замены компонент пользовательского интерфейса.
Подмена HelpBroker-а позволяет добавить в систему ряд новых компонент пользовательского управления HelpView или добиться изменения политики управления существующими, например, расширив возможности нотификации или изменив их семантику.
Также возможно добиться изменения базовой функциональности системы заменой компоненты ядра (HelpEngine), например, добавить принципиально новые способы навигации.
Отдельного упоминания заслуживает возможность расширения системы посредством использования документов в различных форматах в составе справочника.
В качестве основного инструмента для программной реализации ядра системы был выбран язык C++ [6], поскольку он поддерживает широкий спектр механизмов объектно-ориентированного программирования и благодаря этому на сегодняшний день является стандартным промышленным инструментом при создании больших систем.
Одним из основных принципов, лежащих в основе реализации ядра системы, было использование методологии TestFirst [7, 8]. Ее принципиальной особенностью является подход, при котором написанию непосредственно участков программы предшествует написание тестов для них, которые, помимо собственно тестирования, являются своего рода спецификацией на необходимую функциональность. Важно, что подобная схема обеспечивает выявление ошибок программирования на самых ранних этапах разработки.
Ядро было реализовано в виде библиотеки, структура которой организована так, чтобы часть, зависящая от конкретной программной платформы, была локализована в пределах небольшого модуля, который без больших трудозатрат можно было бы подменить на другой при осуществлении переноса библиотеки на другую платформу.
Для управления ресурсами в пределах ядра и его API была использована методика подсчета ссылок, аналогичная принятой в COM [10]. Использование интеллектуальных указателей (smart pointers) языка С++ обеспечило ее применению изящество, удобство и безопасность в случае возникновения исключительных ситуаций при работе программы.
Для хранения внутренней текстовой информации был использован Unicode, благодаря чему система получила возможность корректно работать с документами, в содержимом которых использовано одновременно несколько языков (в том числе и неевропейских).
При реализации поискового механизма для поддержки возможности употреблять в строке запроса регулярные выражения была использована открытая библиотека Regex++ 3.31 (http://www.boost.org/libs/regex/).
В числе несомненных преимуществ данной реализации предложенной архитектуры – большая компактность по сравнению с известными системами электронной справки.
При помощи библиотеки ядра был создан базовый инструмент для разработчиков документации – компилятор, работающий на программной платформе Windows, который позволяет автоматически создать справочник из набора Html документов. Логическую организацию документов в оглавлении справочника, компилятор создает на основе файловой иерархии. Управление компилятором, а именно, указание, какие разделы следует включать в справочник, осуществляется при помощи ключей из командной строки.
В рамках компилятора был реализован Loader для Html-документов, использующий при работе COM-компоненту MsHtml из состава web-броузера Internet Explorer корпорации Microsoft.
В качестве развития системы планируется осуществить реализацию программного приложения с графическим интерфейсом пользователя, которое позволит сделать более удобным и наглядным процесс создания справочника.
Для реализации составляющих архитектуру модулей в рамках программной платформы Windows была выбрана технология COM (Component Object Model), поскольку она определяет стандартный механизм взаимодействия бинарных компонент программного обеспечения [9], который как нельзя лучше соответствует использованному при проектировании подходу. Так, при помощи средств COM, была повторена модель, описанная в разделе 2.4. Использование библиотеки ATL (Active Template Library), позволило значительно ускорить разработку компонент.
Посредством создания соответствующих COM-объектов и COM-интерфейсов был организован доступ к структурным составляющим внешнего API ядра. Компонента ядра была реализована как внутрипроцессный (inproc) сервер. Возможность его создания как внепроцессного (outproc) сервера, была рассмотрена и, в результате, отложена как возможность развития системы в будущем.
В качестве одной из особенностей следует указать то, что все объекты COM в реализации системы удовлетворяют интерфейсу IDispatch, благодаря чему допускают использование при написании программ на интерпретируемых языках. В частности ряд тестов для системы был написан с использованием VBScript.
Для реализации управляющих компонент пользовательского интерфейса, предусмотренных архитектурой системы, была использована технология ActiveX [12]. Управляющий элемент ActiveX является COM объектом, удовлетворяющим определенному набору интерфейсов. Технология ActiveX поддерживает не только входящие обращения (стандартные свойства и методы COM-объектов), но и исходящие события, позволяющие посылать приложению–клиенту сообщения или команды, возникающие, например, по нажатию кнопки в окне объекта. Эти возможности как раз необходимы (как было показано) для реализации компонентов внешнего управления в модели системы.
Таким образом, были созданы управляющие компоненты ActiveX, предоставляющие доступ к возможностям навигации по оглавлению, предметному указателю и осуществлению текстового поиска. ActiveX компонента, предназначенная для того, чтобы показывать содержимое документов, реализована при помощи элемента ActiveX WebBrowserControl из комплекта Internet Explorer.
По результатам анализа достоинств и недостатков существующих решений задачи построения программных систем работы с электронной справочной документацией, авторами предложена архитектура, обеспечивающая возможность замены составляющих ее компонентов и обладающая необходимой расширяемостью и настраиваемостью.
Предложенная архитектура позволяет поддерживать все необходимые базовые функциональные возможности электронной справочной системы и работать с практически любыми типами электронных документов в составе справочника. Также архитектурой системы предусмотрен механизм иерархической организации коллекций электронных книг и гибкий метод управления их содержимым при помощи тематических фильтров.
Авторами выполнена программная реализация предложенной архитектуры и представлен прототип системы для программной платформы Windows с набором инструментальных средств автоматизации процесса создания электронных справочных пособий. Основная ее часть – это переносимая реализация ядра системы в виде библиотеки классов на языке C++. На базе этой библиотеки с использованием технологии COM реализованы компоненты системы и открытый интерфейс взаимодействия между ними.
Упрощенная диаграмма взаимоотношений классов в реализации ядра системы управления электронной справочной документацией. В ней опущен ряд базовых сущностей, например, коллекция, атрибут, фильтр.
В диаграмме использованы элементы нотации UML (Universal Modeling Language).
[1] условимся далее использовать термин справочные системы (по аналогии с английским help system) для обозначения систем управления электронной справочной документацией.
[2] существование публично доступной информации о структуре системы и формате хранения служебных данных говорит об ее открытости