Часть IV

4.4. Принципы разработки OSE-профилей

    Рассмотрим пример применения OSE-профиля и на основе этого примера продемонстрируем методику разработки OSE-профилей.

    Для примера выберем класс распределенных офисных систем, содержащих в качестве своих компонент (подсистем) системы трех типов: A, B, C. Их назначение следующее:

• Система типа A представляет собой систему-клиента базы данных с некоторым прикладным программным обеспечением (например, ориентированным на поддержку бухгалтерской деятельности).
• Система типа В - сервер баз данных, обслуживающий запросы клиентов к базе данных.
• Система типа С - терминальный сервер, выполняющий семантику функций человеко-машинного интерфейса на клиентских машинах.

    Зададимся целью разработать офисную систему рассмотренного класса, обладающую свойством переносимости прикладного программного обеспечения клиентской части и, возможно, интероперабельности.

    Методологической основой создания такой системы является разработка соответствующего OSE-профиля, специфицирующего поведение системы типа А на всех ее интерфейсах. При этом специфицируемое профилем окружение должно определяться некоторым набором стандартизованных спецификаций (стандартов и ISPs), чтобы обеспечить разработку приложений клиентской системы А на основе принципов открытости, в частности, переносимости программного обеспечения. Присвоим данному профилю рабочее наименование DOT (Distributed Office Technology).

    Для разработки профиля DOT будем применять некоторый систематический подход, который можно представить в виде последовательности шагов. Основными шагами данного подхода являются:

• 1. Идентификация области применения систем ИТ, соответствующих данному профилю, а также определения конечных целей и общих ограничений задачи проектирования профиля.

      В нашем случае область применения разрабатываемого профиля ограничена конкретным классом информационных систем и конкретной функциональной компонентой таких систем (прикладным программным обеспечением клиентских систем). Также определены цели проектирования - переносимость и интероперабельность клиентского программного обеспечения.

• 2. Разработка сценария (типовой ситуации применения системы ИТ, соответствующей разрабатываемому профилю). Такой сценарий, как правило, представляет собой графическое представление информационной модели систем данного класса, включающей:
  • Основные функциональные элементы (системы/подсистемы) описываемой реализации;
  • Взаимосвязи между элементами (физические каналы, логические взаимодействия или протоколы);
  • Распределение функций ИТ по элементам модели.

      Для рассматриваемого примера в качестве такого сценария могла бы служить модель, показанная на рис. 4.2.

  
  Рис.4.2. Сценарий для OSE-профиля прикладного программного обеспечения клиентской части А офисной системы

• 3. Определение функциональности профиля в виде набора ссылок на актуальные стандарты и ISPs и формирование, таким образом, раздела нормативных ссылок.

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

  
  
  Рис. 4.3. Нормативные ссылки профиля DOT

      Дадим краткую мотивацию принятым решениям.

      Описанный выше профиль определяет OSE для прикладных программ клиентских систем распределенных офисных технологий со следующими возможностями:

  • В качестве средств API, обязательными для разработки прикладных программ систем типа А, принимаются стандарты языков С и SQL. Язык С++ вводится как дополнительная возможность для программирования приложений. Доступ к удаленным базам данных должен осуществляться посредством интерфейса и протокола ODBC, являющегося стандартом де-факто. Доступность базовых возможностей операционной системы и встроенных в нее языковых средств (оболочки) реализуется на основе спецификаций POSIX (IEEE Std 1003.1, IEEE Std 1003.2).
  • Для реализации интерфейса сетевого взаимодействия (CSI) предполагается использовать стек протоколов TCP/IP. В качестве базовой сетевой архитектуры канального уровня принимается структура локальных сетей, например, с методом доступа IEEE Std 802.3 (сети типа Ethernet).
  • Для реализации HCI в профиле DOT выбираются две оконные системы: OSF/MOTIF и X Window.
  • ISI в профиле DOT не специфицируется. Здесь считается, что соответствующих возможностей, предоставляемых базовой операционной системой должно быть достаточно для переносимости информации с внешних носителей.
• 4. Анализ спецификаций на совместимость. На этом шаге производится тщательный анализ непротиворечивости спецификаций, входящих в состав профиля. В результате этого шага могут быть определены дополнительные требования конформности реализаций профилю, исключающие случаи потенциального конфликта между спецификациями.
• 5. Определение концептуальной части профиля - введение новых понятий в раздел Definitions, дополняющих систему понятий цитируемых базовых спецификаций, а также введение используемых в профиле сокращений (раздел Abbreviations).
• 6. Анализ требуемой функциональности для каждого цитируемого базового стандарта или ISPs, обоснование и выбор классов сервиса, тестовых поднаборов, опций, диапазонов значений параметров.
• 7. Разработка требований конформности, учитывающих специфику применения профиля для каждой спецификации, упомянутой в разделе нормативных ссылок (раздел Conformance).
• 8. Разработка списка требований конформности, например, в табличной форме, как это будет рассмотрено далее.
• 9. Разработка информативных приложений.