Полная версия

Главная arrow Информатика arrow Архитектура и проектирование программных систем

  • Увеличить шрифт
  • Уменьшить шрифт


<<   СОДЕРЖАНИЕ   >>

Архитектуры, основанные на потоках данных

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

Метамодель диаграммы потоков данных

Рис. 2.15. Метамодель диаграммы потоков данных

Как разновидность таких архитектур рассматриваются архитектуры типа «каналы и фильтры», в которых процессы называются фильтрами, а потоки направляются через каналы.

Архитектуры независимых компонентов

Программные системы такой архитектуры состоят из независимо работающих компонентов, время от времени общающихся друг с другом. Компонент, называемый клиентом, выдает запрос для выполнения какого-либо действия другому компоненту, называемому сервером. Такое отношение называется клиент-серверным. Интерфейс сервера должен быть собран в одном месте и четко определен. Преобладание таких отношений характерно для клиент-серверной архитектуры. Классическая двухуровневая архитектура «клиент - сервер» постоянно усложнялась добавлением новых уровней. Отдельный уровень может управлять процедурами (сервер приложений), другой - данными (сервер баз данных в трехуровневой архитектуре).

Значительную роль в разработке систем на основе архитектуры независимых компонентов сыграл международный консорциум OMG (Object Management Group) [5]. Дело в том, что в мире существует громадное количество готовых к использованию информационно-вычислительных ресурсов. Они создавались в разное время, для их разработки использовались разные подходы. Почти всегда при разработке новой информационной системы можно найти подходящие по своим функциям уже работающие, готовые компоненты. Проблема состоит в том, что

при их создании не учитывались требования интероперабельности. Эти компоненты не понимают один другого, они не могут работать совместно. Желательно иметь механизм или набор механизмов, которые позволят сделать такие независимо разработанные информационно-вычислительные ресурсы интероперабельными.

Одно из наиболее признанных решений проблемы унаследованных систем основывается также на объектно ориентированном подходе. Основной задачей OMG является разработка архитектуры и методов реализации программного обеспечения, которое в объектно ориентированном стиле позволило бы выполнить интеграцию существующих и заново разрабатываемых (не обязательно объектно ориентированных) информационно-вычислительных ресурсов. OMG регулярно выпускает спецификационные документы, которые становятся фактическими промышленными стандартами. Основными составляющими подхода OMG являются базовая объектная модель (Core Object Model), эталонная модель архитектуры ОМА (Object Management Architecture) и более приближенная к реализации общая архитектура брокера объектных заявок CORBA.

На рис. 2.16 приведена эталонная модель метаобъектного средства OMG. На нижнем уровне находятся отдельные объекты. Объектные типы определяют общие свойства схожих объектов. Объектные типы, в свою очередь, являются экземплярами метаобъектной модели. С помощью этой метамодели описываются архитектуры OMG/CORBA, Microsoft/COM и Java/RMl [25].

Эталонная модель метаобъектного средства OMG

Рис. 2.16. Эталонная модель метаобъектного средства OMG

Идея CORBA заключается в следующем. Во-первых, в каждый объект, который должен быть включен в интегрированную объектную систему, добавляется специальный программный код, обеспечивающий принципиальную возможность взаимодействия объектов. Этот код генерируется автоматически за счет использования определенного OMG-языка определения объектных интерфейсов IDL (Interface Definition Language). В исходный текст программы включаются спецификации интерфейса на языке IDL. Затем этот текст должен быть обработан специальным прекомпилятором, который и генерирует дополнительный программный код. Заметим, что на сегодняшний день в документах OMG определены правила встраивания конструкций IDL в далеко не все языки программирования, но, по крайней мере, определены правила встраивания для таких популярных языков, как С и C++.

Во-вторых, для реального взаимодействия должным образом настроенных объектов предполагается наличие специального программного обеспечения, называемого в документах OMG брокером объектных заявок ORB (Object Request Broker). Брокер объектных заявок должен существовать и на стороне вызывающего объекта, и на стороне вызываемого объекта. Основная задача ORB состоит в том, чтобы доставить заявку на вызов метода вызываемого объекта и возвратить результаты выполнения метода вызываемому объекту.

В настоящее время CORBA является индустриальным стандартом, описывающим высокоуровневые средства поддержки взаимодействия объектов в распределенных гетерогенных средах. Этот стандарт специфицирует инфраструктуру взаимодействия компонентов на представительском уровне и уровне приложений модели OSI, позволяя рассматривать все приложения в распределенной системе как объекты. Практика показывает, что большинство объектов одновременно исполняет роль и клиентов, и серверов, позволяя тем самым с помощью CORBA строить гораздо более гибкие системы, чем системы «клиент - сервер», основанные на двухуровневой и трехуровневой архитектуре.

 
<<   СОДЕРЖАНИЕ   >>