CC BY
33
3/2007 МГСУНИК
ИНТЕРОПЕРАБЕЛЬНОСТЬ МНОГОУРОВНЕВЫ1Х ИНФОРМАЦИОННЫХ ПРИЛОЖЕНИЙ В СТРОИТЕЛЬНОЙ
ОТРАСЛИ
Пихтерев Д.В., к.т.н., доцент, кафедра СИ МГСУ
Рубцов И.В., к.т.н., профессор, кафедра ТМ МГСУ
Куликова Е.Н., к.т.н., доцент, кафедра ИСТУС МГСУ
Волков А.А.,
д.т.н., профессор, кафедра ИСТУС МГСУ
Особенности проектирования многоуровневых распределенных открытых информационных приложений в строительной отрасли предполагают широкое использование технологий объектно-ориентированного подхода и интероперабельности при создании всего спектра информационного обеспечения процессов и результатов архитектурно-строительного проектирования, производства и управления.
Рассмотрим основы проектирования информационных потоков в составе функциональных систем гомеостатического управления [1,3,4] на примере акцентов специального предметно-ориентированного обзора [2]. Этот процесс должен начинаться с анализа требований, которым должна будет удовлетворять система. Такой анализ проводится с целью понять назначение и условия эксплуатации системы настолько, чтобы суметь составить ее предварительный проект.
При объектно-ориентированном подходе анализ требований к системе сводится к разработке моделей этой системы. Моделью системы (или какого-либо другого объекта или явления) мы называем формальное описание системы, в котором выделены основные объекты, составляющие систему, и отношения между этими объектами.
Построение модели функциональной системы гомеостатического управления помогает:
■ проверить работоспособность разрабатываемой системы на ранних этапах ее разработки;
■ общаться с заинтересованными лицами, уточняя их требования к системе;
■ вносить (в случае необходимости) изменения в проект системы (как в начале ее проектирования, так и на других фазах ее жизненного цикла).
В настоящее время существует несколько технологий объектно-ориентированной разработки прикладных программных систем, в основе которых лежит построение и интерпретация на компьютере моделей этих систем. Наиболее подходящей из них для решения поставленных задач является Object Modeling Techniques (OMT).
В технологии OMT проектируемая программная система представляется в виде трех взаимосвязанных моделей:
■ объектной модели, которая представляет статические, структурные аспекты системы, в основном связанные с данными;
■ динамической модели, которая описывает работу отдельных частей системы;
■ функциональной модели, в которой рассматривается взаимодействие отдельных частей системы (как по данным, так и по управлению) в процессе ее работы.
Эти три вида моделей позволяют получить три взаимно-ортогональных представления системы в одной системе обозначений. Совокупность моделей системы может быть проинтерпретирована на компьютере (с помощью инструментального программного обеспечения), что позволяет получить представление о характере работы с будущей системой, что существенно упрощает согласование предварительного проекта системы.
Модели, разработанные и отлаженные на первой фазе жизненного цикла системы, продолжают использоваться на всех последующих его фазах, облегчая программирование системы, ее отладку и тестирование, сопровождение и дальнейшую модификацию. Модели системы не связаны с языком программирования, на котором будет реализована система.
Объектная модель описывает структуру объектов, составляющих систему, их атрибуты, операции, взаимосвязи с другими объектами. В объектной модели должны быть отражены те понятия и объекты реального мира, которые важны для разрабатываемой системы. В объектной модели отражается, прежде всего, прагматика разрабатываемой системы, что выражается в использовании терминологии прикладной области, связанной с использованием разрабатываемой системы [2].
Объектно-ориентированные приложения на платформах Microsoft Windows используют технологии распределенных объектных систем Object Linking and Embedding (OLE, Microsoft Corp.), обеспечивающие возможность обмена объектами между приложениями, поддерживающими эту технологию, а также их совместное использование при формировании новых составных информационных ресурсов.
Открытые интерфейсы объектно-ориентированного информационного обеспечения функциональных систем гомеостатического управления создаются в соответствие со спецификациями последних версий OLE, использующих коммуникационную модель Component Object Model (COM).
В СОМ любая часть программного обеспечения реализует свои сервисы как один или несколько объектов СОМ. Каждый такой объект поддерживает один или несколько интерфейсов, состоящих из методов. Метод - это функция или процедура, которая выполняет некоторое действие и может быть вызвана программным обеспечением, использующим данный объект (клиентом объекта). Методы, составляющие каждый из интерфейсов, обычно определенным образом взаимосвязаны. Клиенты могут получить доступ к сервисам объекта СОМ только через вызовы методов интерфейсов объекта - у них нет непосредственного доступа к данным объекта.
Следует отметить, что в большинстве объектных технологий объект поддерживает только единственный интерфейс с одним набором методов. В отличие от них, СОМ-объекты могут поддерживать более одного интерфейса.
Объекты СОМ можно собрать в библиотеки или исполняемые файлы и затем распространять в двоичном виде (без исходных текстов). Так как СОМ определяет стандартный доступ к этим двоичным объектам, то СОМ-объекты, написанные на одном языке, можно использовать на другом [2].
Сказанное подтверждает перспективы предложенных решений.
Составными частями функциональных систем гомеостатического управления системы являются произвольные информационные ресурсы - программные компоненты, базы данных, базы знаний, файлы данных (включая мультимедийную информацию), компоненты существующих информационных систем, и др. независимо от аппаратно-программных платформ их реализации и размещения в пространстве. Этот слой расположен обычно над сетевой архитектурой, являющейся необходимой предпосылкой такой совместной деятельности компонентов, обеспечивающей их взаимосвязь.
При проектировании функциональных систем гомеостатического управления рассматриваются насущные потребности применений, определяющие существенную мотивацию для перехода к интероперабельным информационным системам и разработки соответствующей технологии. Подтвердим сказанное общим анализом проектирования интероперабельных информационных систем, изложенном в [2].
Функционирование систем гомеостатического управления происходит в условиях информационной и реализационной неоднородности, распределенности и автономности информационных ресурсов системы. Информационная неоднородность ресурсов заключается в разнообразии их прикладных контекстов (используемых онтологических средств - понятий, словарей; отображаемых реальных объектов, составляющих "поверхность соприкосновения" различных реальных миров и их (объектов) абстракций в информационных системах; семантических правил, определяющих адекватность совокупностей моделируемых объектов реальности; моделируемых деятельностей; видов данных, способов их сбора и обработки; интерфейсов пользователей и т.д.). Реализационная
неоднородность источников проявляется в использовании разнообразных компьютерных платформ, средств управления базами данных, моделей данных и знаний, средств программирования, операционных систем и т.п.
Процесс создания функциональных систем гомеостатического управления, а равно и использования таких систем предполагает ориентацию на следующие немаловажные факторы.
Интеграция систем. Системы эволюционируют от простых, автономных подсистем к более сложным, интегрированным системам, основанным на интероперабельном взаимодействии компонентов.
Реинжениринг систем. Эволюция функциональных процессов - это непрерывный процесс, который является неотъемлемой составляющей проектируемых функциональных систем. Соответственно, создание системы и ее реконструкция (реинжениринг) - непрерывный процесс формирования, уточнения требований и конструирования. Реконструкция систем осуществляется постепенно. Система должна быть сконструирована так, чтобы произвольные ее составляющие могли быть реконструированы при сохранении целостности системы.
Миграция унаследованных систем. Любая система после создания противодействует изменениям и имеет тенденцию быстрого превращения в устойчивую структуру (т.н. legacy systems - унаследованные системы, использующие "уставшие" технологии, архитектуры, платформы, а также собственно программное и информационное обеспечение, при проектировании которых не были предусмотрены нужные меры для их пошаговой миграции в новые системы, соответствующие новым требованиям деловых процессов и технологии). Существенно, что в процессе миграции необходимо, чтобы мигрировавшие составляющие системы и оставшиеся компоненты унаследованных систем сохраняли ин-тероперабельность.
Повторное использование неоднородных информационных ресурсов. Технология разработки информационных систем должна позволять крупномасштабно применять технологию повторного использования информационных ресурсов, переходя от технологии программирования, основанной на интенсивном индивидуальном труде по созданию вручную изделий, удовлетворяющих специфическим требованиям одного конкретного применения, к технологии, основанной на планируемых капиталовложениях в разработку повторно-используемых компонентов, которые могут быть "соединены" (т.е., образованы их интероперабельные сообщества) для производства серий стандартизованных продуктов в определенной прикладной области.
Продление жизненного цикла систем. В условиях исключительно быстрого технологического развития требуются специальные меры, обеспечивающие необходимую продолжительность жизненного цикла.
Существенно, что свойство интероперабельности информационных ресурсов функциональных систем гомеостатического управления является необходимой предпосылкой удовлетворения перечисленных требований.
Основу информационной архитектуры функциональных систем гомеостатического управления составляет концепция промежуточного слоя (middleware) - сосредоточение родовых служб в специальном слое архитектуры, расположенном между операционной системой и средствами управления компьютерными сетями и прикладными системами, специфическими для конкретных областей применения. Традиционно к такому промежуточному слою относились средства управления и доступа к данным, средства разработки программ, средства управления распределенными вычислениями (включая поддержку необходимых протоколов взаимодействия), средства поддержки пользовательского интерфейса и др. Такие инфраструктуры использовались как отдельными компаниями (IBM), так и в международных проектах (например, UNIX - ориентированная интеграционная среда). Применяемые идеи и технологии не позволяли до сих пор решить радикально архитектуру промежуточного слоя.
OMG на основе объектной технологии и идеи интероперабельности вводит концепцию промежуточного слоя последовательно, радикально и до конца. Технически интероперабельность компонентов (представляемых объектами) решена введением базовой объектной модели, унифицированного языка спецификации интерфейсов объ-
ектов, отделением реализации компонентов от спецификации их интерфейсов, введением общего механизма поддержки интероперабельности объектов (брокера объектных заявок, играющего роль "общей шины", поддерживающей взаимодействие объектов). Тем самым достигается однородность представления компонентов и их взаимодействия. Далее, для формирования информационной архитектуры вводится слой унифицированных (ортогональных) служб, которые используются как при конструировании прикладных систем, так и для формирования функционально законченных средств промежуточного слоя, предлагающих конкретные виды услуг. Существенно, что и службы, и средства представляются однородно своими объектными интерфейсами, что позволяет обеспечить их интероперабельность посредством брокера объектных заявок.
Одним из интересных следствий этого подхода, иллюстрирующим его радикальность, является реализация в информационной архитектуре функций СУБД совокупностью объектных служб.
Объектная модель OMG определяет общую объектную семантику для спецификации базовых характеристик объектов стандартным, независимым от реализации образом. Объектная модель OMG определяется в виде объектной модели - ядра (Core Object Model - COM) и совокупности расширений. Объектная модель - ядро - специфицирует некоторый набор базовых понятий. Примерами понятий COM являются объекты, операции, типы, отношение тип/подтип, наследование, интерфейс типа. Каждое расширение вводит дополнительный набор понятий. Расширяться может либо COM, либо уже существующие и согласованные расширения. При этом вводится понятие "профиля", как некоторой комбинации COM, и одного или нескольких расширений, вместе поддерживающих определенную целевую архитектуру.
Эталонная модель архитектуры OMG определяет концептуальную схему для поддержки технологии, удовлетворяющей техническим требованиям OMG. Она идентифицирует и характеризует компоненты, интерфейсы и протоколы, составляющие архитектуру управления объектами OMG (Object Management Architecture - OMA), не определяя, впрочем, их детально. Согласованная с OMA прикладная система состоит из совокупности классов и экземпляров, взаимодействующих при помощи брокера объектных заявок (Object Request Broker - ORB).
Объектные службы (Object Services) представляют собой коллекцию служб, снабженных объектными интерфейсами и обеспечивающих поддержку базовых функций объектов. Общие средства (Common Facilities) образуют набор классов и объектов, поддерживающих полезные во многих прикладных системах функции. Прикладные объекты представляют прикладные системы конечных пользователей и обеспечивают функции, уникальные для данной прикладной системы.
Брокер объектных заявок обеспечивает механизмы, позволяющие объектам посылать или принимать заявки, отвечать на них и получать результаты, не заботясь о положении в распределенной среде и способе реализации взаимодействующих с ними объектов. ORB отвечает за поиск реализации объекта, участвующего в заявке, подготовку объектной реализации к приему заявки и передачу данных, являющихся результатом заявки. Интерфейс клиента полностью независим от расположения вызываемого объекта, языка программирования, на котором он реализован, и любых других аспектов, не отраженных в интерфейсе вызываемого объекта.
На основании совместных предложений ряда ведущих компаний (таких, как DEC, HP, HyperDesk, NCR, Object Design, SunSoft) OMG был разработан стандарт общей архитектуры брокера объектных заявок (Common Object Request Broker Architecture -CORBA). CORBA определяет среду для различных реализаций ORB, поддерживающих общие сервисы и интерфейсы. Это обеспечивает переносимость клиентов и реализаций объектов между различными ORB.
Интерфейсы объектов могут быть определены и помещены в репозиторий интерфейсов (Interface Repository) двумя способами: статически, т.е. описываются на языке определения интерфейсов CORBA (Interface Definition Language - IDL), или динамически. Ре-позиторий представляет компоненты интерфейса как объекты и обеспечивает доступ к ним во время выполнения.
При формировании заявки, клиент может использовать интерфейс динамического вызова или генерируемый компилятором IDL стаб (stub - корешок, локальная процедура вызова заданной операции при обращении к ней).
Клиент может также непосредственно взаимодействовать с ORB. ORB ищет соответствующий код, пересылает параметры заявки и передает управление реализации объекта (Object Implementation). Реализация объекта принимает заявку через сгенерированный компилятором IDL скелетон (skeleton) и при этом может обращаться к объектному адаптеру (Object Adapter) и ORB. Когда обработка заявки завершена, управление и выходные значения возвращаются клиенту.
Различные ORB могут иметь разную реализацию и поддерживать различные объектные механизмы. В структуре ORB выделяется ядро, обеспечивающее внутреннее представление объектов и передачу заявок, и набор надстраиваемых компонентов, интерфейсы которых маскируют различия в реализации ORB.
Клиенты максимально мобильны и должны работать без изменения исходного кода в среде любого ORB, который поддерживает отображение IDL в соответствующий язык программирования. Мобильны также и реализации объектов для разных ORB при условии, что последние поддерживают заданное языковое отображение и имеют требуемые объектные адаптеры.
Языковое отображение включает определение характерных для языка программирования типов данных и интерфейсов доступа к объектам при помощи ORB. Отображение определяет структуру интерфейса стаба клиента, интерфейса динамического вызова, скелетона объектной реализации, объектных адаптеров и прямые интерфейсы ORB.
Объектный адаптер является основным средством доступа к услугам ORB со стороны объектной реализации. Эти услуги обычно включают: генерацию и интерпретацию объектных ссылок, вызов методов, активизацию/деактивизацию реализации и объекта, регистрацию реализаций. Предполагается наличие нескольких широко доступных объектных адаптеров с интерфейсами, соответствующими определенным видам объектов.
В настоящее время существует ряд промышленных реализаций ORB, соответствующих стандарту CORBA. CORBA непрерывно совершенствуется OMG. Идеи CORBA начинают проникать в архитектурные слои ниже промежуточного. Так, в проекте Spring, посвященном архитектуре операционной системы, рассчитанной на распределенные среды и на многопроцессорные платформы, основополагающими являются понятия строгих интерфейсов, открытости и расширяемости. Следуя этому, интерфейсы объектов Spring определены средствами IDL, не зависящими от языков программирования. Такой подход позволяет достичь распределенности системы, соответствия типов, безопасности (при необходимости от самой слабой до самой сильной) и унифицируемости при вызове операций, независимо от того, размещаются ли объект и обратившийся к нему клиент в одном адресном пространстве, на одной машине, или удалены друг от друга.
Spring организована как микроядерная система. Она почти полностью реализована в виде набора менеджеров объектов (например, файловая система, поддерживающая объекты-файлы), выполняющихся в непривилегированном режиме и часто в различных адресных пространствах. Как следствие, добавить новую функцию к системе столь же легко, как и написать прикладную программу в Spring, причем каждая такая функция становится неотъемлемой частью распределенной системы. Все сервисы и объекты, доступные в одном узле, также доступны и в других узлах данной распределенной среды.
Реальным примером расширяемости системы может служить реализация эмуляции UNIX. Подсистема эмуляции будет целиком реализована на пользовательском уровне, не будет использовать "реальный" код UNIX и обеспечит совместимость на уровне исполняемого кода для большого набора программ Solaris. Подсистема использует сервисы, предоставляемые базовой системой Spring, и реализует только специфические для операционной системы UNIX средства, которые в Spring не имеют эквивалентов (например сигналы). Для того, чтобы реализовать эмуляцию Solaris, не требуется никакой модификации в самой системе Spring.
Архитектура объектных служб обеспечивает базис для спецификации структуры и функций отдельных объектных служб. Предлагаемая архитектура будет уточняться по мере принятия OMG спецификаций объектных служб и должна быть согласована с общей архитектурой OMG.
В настоящее время OMG приняты или находятся в процессе формирования спецификации следующих служб [2], использование которых оправдано при создании информационных компонент функциональных систем гомеостатического управления:
■ служба уведомления объектов о событии (Event Notification Service). Служба обеспечивает извещение заинтересованных объектов о происходящих в системе событиях;
■ служба жизненного цикла объектов (Object Lifecycle Service). Служба поддерживает создание, удаление, копирование и перемещение объектов;
■ служба именования объектов (Name Service). Служба обеспечивает отображение между именами и объектами (связывание имен);
■ служба долговременного хранения объектов (Persistent Object Service). Служба обеспечивает сохранение объекта независимо от времени жизни клиентов, осуществляющих доступ к объекту, и от реализации, обеспечивающей выполнение методов объекта;
■ служба управления конкурентным доступом (Concurrency Control Service). Поддерживает конкурентный доступ к одному или более объектам со стороны одного или более объектов;
■ служба внешнего представления объектов (Externalization Service). Спецификация службы определяет протоколы и соглашения по внешнему и внутреннему представлению объектов;
■ служба объектных связей (Relationships Service). Служба обеспечивает средства для создания, удаления, навигации и управления связями между объектами;
■ служба транзакций (Transaction Service). Служба предоставляет гарантию того, что вычисления поддерживают некоторые, или все присущие транзакциям ACID свойства (атомарность, непротиворечивость, изолированность, постоянство);
■ служба изменения объектов (Change Management Service). Поддерживает идентификацию и согласованную эволюцию объектов;
■ служба лицензирования (Licensing Service). Служба обеспечивает среду для спецификации и управления лицензионной политикой;
■ служба объектных свойств (Properties Service). Позволяет связывать с объектом динамически создаваемые атрибуты;
■ служба объектных запросов (Object Query Service). Осуществляет операции над наборами объектов;
■ служба безопасности объектов (Object Security Service). Контролирует доступ к объектам;
■ служба объектного времени (Time Service). Поддерживает механизм синхронизации в распределенной системе.
Помимо рассмотренных выше, имеется также ряд служб, которые впоследствии были связаны с другими компонентами OMA.
Рассмотренные выше службы далеко не исчерпывают возможностей OMA. В ходе дальнейшей работы OMG, вероятно, будут выделены и приняты дополнительные объектные службы [1—4].
Библиографический список
1. Волков А.А. Гомеостат зданий и сооружений: кибернетика объектов и процессов // В кн. "Информационные модели функциональных систем" / Под ред. К.В. Судакова, А.А. Гусакова. - М.: Фонд "Новое тысячелетие", 2004. - с. 133-160.
2. Центр информационных технологий МГУ:
3. Волков А.А. Функциональное управление зданиями. Гомеостат. Практика. Часть
1. Концепция "устойчивости" // Сборник докладов XIII словацко-польско-российского семинара "Теоретические основы строительства". - Xilina.: University of Xilina, 2005. -с. 375-382.
4. Волков А.А. Функциональное управление зданиями. Гомеостат. Практика. Часть
2. Концепция "функционального управления"// Сборник докладов XIII словацко-польско-российского семинара "Теоретические основы строительства". - Warszawa: Warsaw University of Technology, 2006. - с. 415-420.
