Приложение

(Client)

Реализация объекта

Динамический вызов

IDL Stub Суррогат

Интерфейс ORB

Статический IDL-скелетон

Динамический скелетон IDL

Адаптер объекта

Я д р о

Рис.6. Структура интерфейсов ORB

Для определения интерфейсов объектов имеется специальный язык - язык определения интерфейсов Interfase Definition Language (IDL) и отображения этого языка во многие реальные языки программирования (например С++). Самый простой случай – это обращение через статический интерфейс, когда клиент, ORB и реализация объекта находятся в одном адресном пространстве. В этом случае ORB и реализация объекта могут представлять собой набор библиотек, компонуемых с приложением, а связи устанавливаются на этапе компиляции и компоновки. Интерфейс объекта при этом описывается на языке IDL, после чего из этого описания генерируется IDL Stub (stub - локальная процедура вызова заданной операции при обращении к ней) – отображение интерфейса в язык программирования, на котором написано приложение. Для более сложных случаев предусмотрены динамические вызовы. Здесь для конкретной реализации используется объектный адаптер.

Skeleton – интерфейс обращения к реализации объекта в конкретной вычислительной среде. Для обеспечения динамических обращений стандарт CORBA предусматривает наличие специальной службы, интегрированной в ORB, - хранилища интерфейсов (Interface Repository – IR), которая обеспечивает хранение IDL интерфейсов объектов в форме, пригодной для использования во время исполнения программ.

• переиспользуемые динамически связываемые библиотеки с интерфейсами доступных функций на С, С++, Pascal;

• Java- и C++-классы.

Структурная декомпозиция ЭИС на основе oбъектнo-oриен­тированного подхода отличается от функционально-oриентированного подхода лучшей способностью отражать динамическое поведение системы в зависимости от возникших событий.

Модель проблемной области предстает как совокупность взаимодействующих во времени объектов. Процесс обработки информации формируется в виде последовательности взаимодействий объектов. Одна операция обработки данных может рассматриваться как результат одного взаимодействия объектов.

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

Если в функциональном подходе модели данных и операций разрабатываются относительно независимо друг от друга и только координируются между собой, то объектно-ориентированный подход предполага­ет совместное моделирование данных и процессов. При этом модели проблемной области в репозитории постепенно уточняются.

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

Объектная модель

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

Например. Предположим, что система А содержит информацию об экологической обстановке и декларирует сервис «получить процент содержания окиси углерода в атмосфере», а в качестве параметров используются географические координаты места и дата. Система В, в свою очередь, содержит статистику по легочным заболеваниям и декларирует сервис «получить число людей, заболевших астмой», а в качестве параметров используются название города и интервал дат. Далее, система С декларирует сервис «получить географические координаты», в качестве параметра используется название населенного пункта. Система D, не обладая никакими собственными информационными ресурсами может, тем не менее, вычислить влияние содержания окиси углерода в атмосфере на заболеваемость астмой, пользуясь сервисами, предоставленными системами А, В, и С. Если представить, что существуют системы, которые декларируют сервиса ориентированные на статистическую обработку и визуализацию информации, разработчики системы D могут воспользоваться и ими, сводя к минимуму затраты на реализацию.

Следовательно, процесс проектирования нового приложения сводится к анализу применимости уже существующих объектов для реализации требуемой функциональности и интеграции их в законченный программный продукт. Недостающие компоненты могут быть разработаны и включены в проект как локальные или, по желанию разработчика, они могут быть оформлены как объекты, доступные для использования в других приложениях. Существует несколько идеологий подобного «объектного» подхода, наиболее известна и проработана идеология, предложенная консорциумом Objekt Managament Group – стандарт Common Object Reguest Broker Architecture (CORBA).