АРИС Текст 2. Водяхо А. И., Выговский Л. С., Дубенецкий В. А., Цехановский В. В. Архитектурные решения информационных систем
 Скачать 4.65 Mb.
|
ФреймворкФедеральнойАрхитектурыСША (Federal Enterprise Architecture Framework, FEAF). Данный фреймворк ориентирован на использования на уровне государства страны, в целом, прежде всего в контексте реализации концепции электронного правительства (e-governement).В основу данного фреймворка положена концепция Федеральной Архитектуры (ФА), который представляет собой концептуальную модель, которая описывает деятельность федерального правительства и государственных организаций с функциональной точки зрения, вне зависимости от организационных структур.ФА определяет функции государственных организаций, информацию и технологии, необходимые для реализации функций, а также процессы преобразований, необходимые для внедрения новых информационных технологий в ответ на изменения, происходящие во внешней среде. На базе ФА формируются архитектуры отдельных государственных организаций. В данном случая ФА выступает в качестве мета модели, на базе которой формируются модели отдельных государственных организаций. Основной целью ФА является обеспечение условий для совместной разработки процессов, стандартов совместимости и обмена информацией между государственными органами и организациями. FEAF состоит из следующих 8 основных компонентов (рис. 9.12: Двигатели архитектуры (Architecture Drivers), Стратегическое направление (Strategic Direction). Текущая архитектура (Current Architecture), Целевая архитектура (Target Architecture), Переходные процессы (Transitional Processes), Архитектурные сегменты (Architectural Segments), Архитектурные модели (Architectural Models), Стандарты (Standards). Двигатели архитектуры отражают внешние стимулы или источники изменения архитектуры- это бизнес-стимулы и технические стимулы. В качестве первых выступать новые законодательные акты, бюджетные ассигнования. Техническими двигателями могут быть новое программное обеспечение и новые аппаратные средства. Двигатели архитектуры являются источниками изменений ФА. Они делятся на бизнес-стимулы и технические стимулы. Бизнес-стимулы определяются федеральными бизнес-потребностями, а технические стимулы отражают использование новых средст удовлетворения федеральных бизнес-потребностей. Стратегическое направление представляют собой руководство для разработки целевой архитектуры, которая определяется в таких терминах как видение, принципы, цели.  Рис. 9.12. Структура FEAF Текущая архитектура определяет архитектуру "как есть" на данный момент времени и два основных элемента: Технические стимулы и Текущая ИТ архитектура. Технические стимулы определяют текущие потребности с точки зрения основной деятельности государственных организаций и как они обеспечиваются существующими ИС. Текущая ИТ-архитектура (т.е. архитектура данных, приложений и технологическая архитектура) – отображает текущее состояние возможностей технологий по обеспечению деятельности организаций и служит объектом для дальнейших изменений и описывается на 4 уровнях: Бизнес-архитектура (БА), Архитектура приложений (АП), Архитектура данных (АД) и Технологическая архитектура (ТА). Целевая архитектура определяет архитектуру "как должно быть". Она также включает 2 элемента: целевой бизнес-архитектуры и целевой ИТ- архитектуры информационных технологий. Переходные процессы – это процесс перехода от текущей архитектуры к целевой архитектуре. Этот процесс описывается в терминах планирования инвестиций в сферу ИТ, планирование изменений, управление конфигурациями, контроль и управление проектами. Архитектурные сегменты определяют разбиение ФА отдельные, существенные области деятельности, такие как общие административные системы, управление федеральными программами, электронная торговля для проведения закупок. Каждый архитектурный сегмент представляет собой часть ФА. Каждый сегмент также характеризуется текущей и целевой архитектурой. Соответствующая информация и модели помещаются в базу данных (репозиторий) единой ФА. Архитектурные модели определяют бизнес- и технологические модели, которые отражают все необходимые сегменты для полного описания архитектуры. Они определяют бизнес-архитектуру и ИТ архитектуру. При этом рассматриваются бизнес-модели и модели технической среды (данных, прикладных систем, технологий). Бизнес-модели отражают появление бизнес-потребностей, инициированных бизнес-двигателями. Модели технической среды (Design Models) включают модели данных, модели прикладных систем и технологические модели, которые требуются для того, чтобы поддержать реализацию бизнес-потребностей. Стандарты включают все стандарты, которые требуется выполнять. В рамках FEAF выделяются следующие представления (домены): бизнес-архитектура (функциональная архитектура деятельности правительства), архитектура данных, архитектура приложений, технологическая или системная архитектура. Для каждой из перечисленных областей имеются эталонные модели (Reference Models). Эти модели обеспечивают использование общих архитектурных принципов при реализации межведомственных проектов, обеспечивают всем государственным организациям единую методологию при разработке собственных корпоративных архитектур [137]. Более подробное описание FEAF можно найти, например в [138]. Контрольные вопросы 1. Дайте определение понятий фреймворк. 2. Приведите классификацию фреймворков. 3. В чем состоит различие между между паттернами и фреймворками? 4. Что такое фреймворки уровня приложения? 5. Охарактеризуйте JEE. 6. Сравните JEE и.NET. 7. Охарактеризуйте фреймворк Захмана. 8. Какое место занимает онтология в фреймворке Захмана? 9. Перечислите достоинства и недостатки фреймворка Захмана и укажите условия, при которых целесообразно использования фреймворка Захмана. 10. Охарактеризуйте фреймворк TOGAF. 11. Какое место занимает методика ADM в фреймворке TOGAF? 12. Перечислите достоинства и недостатки фреймворка TOGAF и укажите условия, при которых целесообразно использования данного фреймворка. 13. Охарактеризуйте фреймворк DoDAF. 14. Почему фреймворк DoDAF определяют как datacentric? 15. Перечислите достоинства и недостатки фреймворка DoDAF и укажите условия, при которых целесообразно использования данного фреймворка. 16. В чем состоит различие подходов, используемых в между фреймворках Захмана, TOGAF и DoDAF? 17. Охарактеризуйте фреймворк FEAF. Глава 10. КОМПОНЕНТНОЕ ПРОЕКТИРОВАНИЕ 10.1. Понятие компонента Термин компонент в ИТ-отрасли используется для обозначения различных понятий. Во-первых, можно выделить аппаратные (hardwarecomponents) и программные компоненты (softwarecomponents). Термин программный компонент (ПК) используется для обозначения 2-х связанных, но разных понятий. Если речь идет о программной архитектуре, то обычно под компонентом подразумевается программный модуль, реализующий некоторую функцию или набор функций и решает определенные подзадачи в рамках общих задач, решаемых системой. Это те компоненты, которые могут быть изображены на диаграммах компонентов (componentdiagram) в языке UML. Если речь идет о компонентных технологиях программирования или компонентно-ориентированной (componentbased) разработке ПО, то под ПК понимают объекты со специальными свойствами. В дальнейшем термин компонент будет употребляться во втором смысле. В этом случае понятие ПК выступает в качестве в качестве ключевого для определения понятия таких понятий как компонентно-ориентированное программирование и компонентно-ориентированный подход к проектированию ИС. Согласно [139], ПК представляет собой структурную единицу программной системы, обладающую четко определенным интерфейсом, который полностью описывает ее зависимости от контекста. ПК представляет собой откомпилированный автономный программный модуль, который можно объединять с другими модулями или кодом, организованным другим способом с целью создания приложений. ПК могут быть как простыми, таким как кнопка или сложным, таким как компонент, реализующий управление сетью. Чаще всего под ПК понимают откомпилированный «двоичный компонент», который можно интегрировать в приложение «на лету». При работе с компонентами исходный код обычно недоступен и поэтому компонент нельзя изменять. Под данное определение подпадают, в частности, динамические библиотеки. Компонентно-ориентированное приложение обычно состоит из множества компонентов. Само приложение представляет собой некоторую среду, включающую средства «склеивания» или скелетный код, в который можно встраивать ПК, которые могут взаимодействовать со средой и операционной системой и друг с другом. Изменение интерфейса ПК приводит к изменению его кода, но изменение способа реализации не обязательно приводит к изменению интерфейса. ПК можно рассматривать и как пакет, ориентированный на повторное использование кода, который можно приобрести у независимого производителя. У некоторых авторов ПК – это элемент системы, который обладает явно определенной функциональностью и может быть заменен на другой ПК, и, наконец, ПК можно определить как физическую реализацию некоторого набора интерфейсов. Из сказанного выше понятно, что не существует общепринятого определения понятие компонента, которое позволило бы определить, что является и что не является компонентом. ПК можно рассматривать с трех точек зрения: реализуемой функциональности; реализации; исполняемого кода. В первом случае речь идет об описании ПК в терминах реализуемых сервисов. Для этого обычно используются языки определения интерфейсов. Во втором случае описывается внутреннее устройство ПК. Для этого можно использовать, например, диаграммы классов. В третьем случае описывается функционирование ПК с учетом специфики платформы. Возникает естественный вопрос о том, как соотносятся понятия ПК и объект. На данный вопрос имеются разные точки зрения. Крайние точки зрения выглядят следующим образом. Одна точка зрения состоит в том, что ПК – это объект со специальными свойствами. Другая – в том, что ПК и объект – это разные сущности, компонент не является объектом и представляет собой самостоятельную сущность. Наличие различных точек зрения определяется, с одной стороны, отсутствием общепринятого определение понятия ПК, а, с другой стороны, наличием разных различных компонентных технологий, которые существенно отличаются друг от друга с точки зрения используемых моделей компонентов. Безусловно, ПК и объекты имеют много общего, но имеются и отличия. Концептуальнообъект представляет собой элемент модели реального мира, который имеет уникальный идентификатор и описывает некоторый класс сущностей. Объект имеет состояние, которое хранится во внутренних переменных. Поведение объекта описывается через множество доступных методов. Состояние объекта может изменяться только посредством вызова его методов. На базе конкретного класса можно создавать произвольное число объектов. Объект может взаимодействовать другими объектами посредством вызова методов объекта-сервера, причем один и тот же объект может выступать как в качестве клиента, так и в качестве сервера. Как ПК, так и объекты, поддерживают инкапсуляцию и доступ через «хорошо определенные интерфейсы». Обычно как объекты, так и ПК поддерживают «сильную» инкапсуляцию, при которой доступ к переменным (атрибутам) возможно только с использованием методов объектов. Как объекты, так и компоненты являются моделями объектов реального мира. Очевидно, что для моделирования объектов могут использоваться как объекты, так и ПК. Часто принято считать, ПК – это большие объекты, однако с этим трудно согласиться, поскольку объекты могут быть большими, а компоненты маленькими. Типовой ПКобладает следующими свойствами: представляет собой фрагмент самодостаточного кода, т. е. для его функционирования не требуется наличия дополнительные библиотек; является самоустановливаемым модулем, который может быть включен в состав системы, исключен из ее состава или заменен на другой модуль, например, принадлежащий другому производителю, при минимальном участии пользователя; может повторно использоваться в различных контекста; при работе с ПК используются механизмы динамического связывания; можно объединять с другими ПК с целью создания более крупных ПК; пользователи используют ПК преимущественно по принципу черного ящика, т.е. пользователю известны только интерфейсы, но не внутренняя структура системы. ПК может быть независимо поставлен или не поставлен, добавлен в состав некоторой системы или удален из нее, в том числе, может включаться в состав систем других поставщиков. ПК можно определить как фрагмент самодостаточного, самоустанавливаемого кода, обладающий хорошо определенной функциональностью и имеющий четко определенные интерфейсы. ПК могут агрегатироваться с другими компонентами в более сложные системы. Компоненты и системы компонентов могут повторно использоваться в различных контекста. Пользователи используют компоненты преимущественно по принципу черного ящика, т.е. пользователю известны только интерфейсы, но не внутренняя структура ПК. На основе выше изложенного можно говорить о следующих основных различиях между компонентами и объектами: как ПК, так и объекты ориентированы на повторное использование кода, однако объекты ориентировано преимущественно на повторное использование на низком уровне, а ПК – на высокоуровневое повторное использование кода; ПК в большей степени ориентированы на интерфейсы, чем объекты; ПК разрабатываются в рамках конкретного фреймворка, а объекты в рамках конкретного языка программирования; объекты тесно связаны с конкретным языком программирования, в то время как ПК в явном виде не связаны с конкретным языком программирования, но связаны с платформой, а платформа может быть связана с конкретным языком, например, JEE связана с Java. Обычно объекты не являются автономными модулями, которые можно легко заменить на другие объекты, поскольку они, как правило, имеют вложенные объекты, для выполнения процедуры замены объекта обычно требуется перекомпилировать приложение, а для замены компонента часто оказывается достаточным поместить файл, в котором находится исполняемый код, в заданное место и отредактировать конфигурационный файл [140]. Для функционирования ПК, как правило, необходимо наличие соответствующей инфраструктуры, которая позволяет компонентам находить друг друга и взаимодействовать по определенным правилам. Набор правил, определяющих интерфейсы ПК и их реализаций, а также правил, по которым ПК работают в системе и взаимодействуют друг с другом, называют компонентной моделью (componentmodel)[141]. В компонентную модель входят также правила, регламентирующие жизненный цикл ПК. Взаимодействовать друг с другом могут только ПК, построенные в рамках одной модели. Для работы ПК необходим некоторый набор базовых служб (basicservices), которые обеспечивают, например, нахождение компонентов, в распределенной среде, обеспечение обмена данными через сеть. Набор таких базовых, необходимых для функционирования большинства компонентов служб, вместе с поддерживаемой с их помощью компонентной моделью называется компонентной средой(или компонентным фрейворком, componentframework). Известно достаточно много различных компонентных технология. Некоторые из них остались на уровне теоретических исследования, однако ряд технологий активны используются на практике в течение уже многих лет. К последней группе можно отнести такие компонентно-ориентированные (component based) технологии как JavaBeans, EJB, CORBA, ActiveX, VBA, COM, DCOM, .Net компоненты. Принципиально мультиагентные технологии также можно рассматривать как разновидность компонентных технологий. 10.2. CORBA Основы CORBA. CORBA (ComponentObjectRequestBrokerArchitecture) – это стандарт, определенный группой компаний OMG (ObjectManagementGroup), который позволяет различным программным компонентам, написанным на разных языках программирования и работающих на разных машинах, взаимодействовать друг с другом. Спецификация СОRВА лежит в основе всех стандартов, разработанных ОМG и определяют механизмы взаимодействие приложений в распределенной системе. Ключевыми компонентами данного стандарта являются объектный брокер запросов и язык определения интерфейсов IDL. Следующими по важности элементами являются сервис динамического формирования запросов, репозиторий интерфейсов, сервис динамической обработки запросов и сервис, обеспечивающий взаимодействие различных брокеров запросов. Ключевая идея состоит в том, что приложение представляется в виде множества объектов. Каждый из объектов содержащих информацию о возможностях кода и способах его вызова. Объект может быть вызван локально или через сеть из других приложений или объектов CORBA.  Рис. 4.12. Обобщенная структура системы, построенной с использованием CORBAОбобщенная структура системы, построенной с использованием CORBA, показана на рис. 10.1. Основу CORBA-системы составляет «системная шина», которая позволяет компонентам, реализованным на разных языках и работающих на разных платформах находить друг друга и взаимодействовать. Эту шину называют брокером объектных запросов (Common Object Request Broker Architecture) или просто ORB. Интерфейсы в CORBA определяются средствами языка IDL (InterfaceDefinitionLanguage – язык описания интерфейса). IDL описание используется для генерации кода заглушек для поддерживаемых языков программирования (Java, C++, C, COBOL, Lisp, PL/I, Smalltalk, Python). Сгенерированный код используется как основа для доступа к объекту в определенной программной среде. Данные вызова преобразуются в сетевой формат, сериализуются с помощью сгенерированных для объекта заглушек (Stubs) и передаются клиентским ORB (ObjectRequestBroker – посредник вызова объектов) серверному ORB. На сервере данные вызова десериализуются с помощью сгенерированных для объекта скелетонов (Skeletons), где вызов выполняется. Данные, полученные при обработке вызова, передаются по цепочке обратно клиентскому коду. История CORBA. Стандарт CORBA 1.0 был представлен в октябре 1991 году группой компаний OMG. OMG – это международная открытая независимая организация, основанная в 1989 году одиннадцатью компаниями, включая, American Airlines, Canon Inc., Hewlett-Packard, Philips Telecommunications N.V., Sun Microsystems и др. с целью создания общей среды для разработки объектно-ориентированных приложений через разработку рекомендаций и детализированных спецификаций для объектно-ориентированного управления процессами. Первые версии стандарта CORBA включили в себя базовые определения объектной модели CORBA, языка IDL, API для динамичного управления вызовами объектов (DII, Dynamic Interface Invocation) и репозитория интерфейсов (Interface Repository), а также представили концепцию базового адаптера объектов (BOA, Basic Object Adapter) – посредника между объектом и ORB. Единственным языком, официально поддерживаемым первыми версиями стандарта, стал язык программирования C. Одним из ограничений первых версий спецификации было отсутствие определения стандартного протокола взаимодействия различных ORB, что часто делало невозможным взаимодействие ORB от разных производителей. В 1996 году появился стандарт CORBA 2.0, который устранил данный недостаток, представив протоколы GIOP (General Inter-ORB Protocol – общий протокол взаимодействия ORB) и IIOP (Internet Inter-ORB Protocol – протокол взаимодействия ORB через сеть Internet). Появилась возможность работы с языками C++ и Smalltalk, и многое другое. В 1997 – 2001 годы была добавлена поддержка языков Cobol, Ada и Java, концепция пeреносимого адаптера объектов (POA, Portable Object Adapter) – еще одного шага на пути к стандартизации взаимодействия между различными реализациями CORBA, поддержку взаимодействия с DCOM, службу сообщений (Messaging specification), минимальный стандарт CORBA (Minimum CORBA), систему CORBA реального времени (Real-time CORBA) и ряд других служб. Фактически, это последняя выпущенная версия. С современным состоянием развития технологии CORBA можно познакомиться, посетив официальный сайт www.corba.org. Область применения. Наибольшая популярность технологии CORBA пришлась на последние годы прошлого века и первые годы текущего века. CORBA всегда рассматривалась как «тяжелая» технология, ориентированная на решение сложных задач, преимущественно в сфере крупных корпоративных систем. Однако CORBA далеко не всегда используется исключительно в крупных приложениях. Специализированные версии CORBA до сих пор работают в системах реального времени и малых встраиваемых системах. Реализации. CORBA является спецификацией; она предоставляет описание для реализации конкретных продуктов. Существует множество компаний и сообществ, поставляющих продукты CORBA для различных языков программирования. Список поставщиков можно найти на сайте CORBA.  Рис. 10.2. Группы архитектурных элементов CORBA Архитектура CORBA. Глобальная архитектура CORBA восходит к модели OMG, в рамках которой выделяется четыре группы архитектурных элементов (рис. 10.2): брокер объектных запросов; сервисы CORBA; средства CORBA; прикладные объекты и приложения. Брокер Объектных Запросов (Object Request Broker — ORB) определяет объектную шину CORBA, Сервисы CORBA (CORBA Services) определяют системный уровень объектной структуры, и могут рассматриваться как расширение объектной шины, Общие Средства CORBA (CORBA Facilities) определяют сервисы, которые непосредственно используются приложениями (бизнес-объектами), Application Objects представляют прикладные объекты и приложения, то есть конечных потребителей инфраструктуры CORBA. Каждый ниже лежащий уровень выступает как сервер для выше лежащего. Объектная модель CORBA. В основе CORBA лежит понятие объектной модели. Объектная модель описывает объектные концепции и терминологию, применимые к клиентскому коду и реализации объектов. Объектная модель CORBA являет собой пример классической объектной модели, в которой клиенты посылают сообщения объектам, а объекты интерпретируют сообщения и выполняют соответствующие им действия. В основе объектной системы лежит понятие объекта (object). Объект – идентифицируемая, инкапсулированная сущность, предоставляющая один или более сервисов, которые могут быть запрошены клиентами. Клиенты запрашивают службы объектов через специальные запросы (request). Информация, содержащаяся в запросе, включает в себя объект, название операции, параметры и необязательный контекст запроса. Параметры могут быть входящими (input), выходящими (output) и двунаправленными (input-output), а необязательный контекст представляет собой маппинг из строк в строки. Результатом запроса является выполнение сервиса для клиента, а также возвращение результирующего значения (если таковое определено для операции) и значений в output и input-output параметрах. При ошибочном выполнении вызова клиенту возвращается исключение (exception). Объекты создаются и уничтожаются. Создание и уничтожение объектов происходит вследствие выполнения запросов. Клиент получают доступ к созданным объектам через ссылки (reference). CORBA разграничивает понятие реализации объекта и ссылки на объект. Реализация объекта представляет собой серверный код объекта с определенными операциями, в то время как ссылка идентифицирует объект для клиента и используется для осуществления вызовов. Множество различных ссылок может обозначать один объект. Типы (type) в CORBA определяются предикатной логикой. Сущность, которая удовлетворяет предикату, определенному для типа, считается членом (member) данного типа. Объектные типы (objecttype) – типы, чьими членами являются объектные ссылки. Объектные типы образуют единую иерархию с типом Object в качестве корня, при этом любой тип может использоваться везде, где используются его предки. Объектные типы могут использоваться в качестве параметров и результирующих типов операций, и также в качестве компонентов других структурированных типов. Необъектные типы также определены в CORBA и описываются через конструкции IDL. В качестве базовых типов (basictypes) определены булевой тип, различные числовые и строковые типы, а также тип any, обозначающий любой базовый тип. Базовые типы, как и объектные, могут использоваться в качестве компонентов для множества различных структурированных типов, включая структуры, массивы, последовательности и объединения. Одним из ключевых понятий в объектной модели CORBA является понятии интерфейса (interface). Интерфейс представляет собой описание операций, предоставляемых объектом для вызова клиенту, а также может содержать определение типов, используемых для данных операций. Интерфейсы в CORBA образуют иерархию и соответствуют иерархии объектных типов. Объекты в CORBA могут реализовывать более одного интерфейса. Язык описания интерфейсов (IDL), определяет типы объектов посредством спецификации их интерфейсов. Интерфейс состоит из множества именованных операций и их параметров. Описание на IDL обеспечивает ORB всей необходимой информацией о типе объекта. Язык описания интерфейсов рассматривается как средство, с помощью которого реализация объекта сообщает своим потенциальным клиентам о том, какие операции доступны и каким образом их следует вызывать. Описание на языке IDL транслируется в код на конкретном языке программирования. |