Обзор паттернов проектирования

2005 г.

Обзор паттернов проектирования

Ольга Дубина

5 ПАТТЕРНЫ ИНТЕГРАЦИИ КОРПОРАТИВНЫХ ИНФОРМАЦИОННЫХ СИСТЕМ

Паттерны интеграции информационных систем представляют собой , как это описано в разделе 2, верхний уровень классификации паттернов проектирования. Аналогично паттернам более низких уровней классификации, среди паттернов интеграции выделена группа структурных паттернов, см. раздел 5.1. Структурные паттерны описывают основные компоненты единой интегрированной метасистемы. В свою очередь, для описания взаимодействия отдельных корпоративных систем, включенных в интегрированную метасистему, организована группа паттернов, объединенных в соответствии с тем или иным методом интеграции, см. раздел 5.2. Далее, интеграция корпоративных информационных систем подразумевает тем или иным способом организованный обмен данными между системами. Для организации обмена информацией между отдельными системами, включенными в интегрированную метасистему, служит раздел 5.3. Следует отметить, что в отличие от паттернов проектирования классов/обьектов и архитектурных системных паттернов, отнесение отдельного паттерна интеграции к тому или иному виду является менее условным.

5.1 Структурные паттерны интеграции

5.1.1 Взаимодействие "точка - точка"

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

5.1.2 Взаимодействие "звезда" (интегрирующая среда)

Описание

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

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

5.1.3 Смешанный способ взаимодействия

Описание

В данном способе совмещены 5.1.1 и 5.1.2 подходы к взаимодействию систем. При этом интерфейсы частично могут использоваться непосредственно напрямую в обход интегрирующей среды. Указанный способ сочетает в себе преимущества централизации управления процессами взаимодействия систем, унификации интерфейсов, а также возможность использовать прямые интерфейсы между системами. Необходимость использования прямых интерфейсов в обход интегрирующей среды может диктоваться, например, специфическими требованиями безопасности.

5.2 Паттерны по методу интеграции

5.2.1 Интеграция систем по данным (data-centric).

Описание

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

Недостатки

Необходимость передачи больших объемов данных.

5.2.2 Функционально-центрический (function-centric) подход.

Описание

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

5.2.3 Объектно-центрический (object-centric).

Описание

Объектно-центрический подход, основанный на стандартах объектного взаимодействия CORBA, COM/DCOM, .NET и пр. и является композицией типов объединения систем по данным и обьектно - центрического. Концепция интеграции в состоит в том, что системы объединяются вокруг общедоступных распределенных объектов со стандартными интерфейсами. Характерными особенностями данного подхода являются: " унифицированный язык спецификации интерфейсов объектов (например IDL); " отделение реализации компонентов от спецификации их интерфейсов; " общий механизм поддержки взаимодействия объектов (брокер объектных запросов, играющий роль "общей шины", поддерживающей взаимодействие объектов). Интегрирующей средой является брокер объектных запросов с интерфейсом в стандарте CORBA или DCOM. Общая архитектура системы формируется на основе распределенных объектов и является n-звенной.

5.2.4 Интеграция на основе единой понятийной модели предметной области (concept-centric).

Задача

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

Решение

Средством решения проблемы интеграции второго уровня является разработка ОЯВ компонентов, основанного на единой понятийной модели, описывающей объекты предметной области, их взаимосвязи и поведение. Как правило, ОЯВ является языком сообщений высокого уровня и имеет достаточно простой синтаксис и естественно-языковую лексику на основе бизнес-объектов. Единая понятийная модель представляет собой базу метаданных, хранящую описания интерфейсных бизнес-объектов каждого из компонентов и отношения (связи) между этими объектами. Между интегрируемыми компонентами и их описаниями в базе метаданных должно поддерживаться постоянное соответствие. Хранящиеся в базе метаданных описания и сам язык взаимодействия строятся как независимые от конкретного интегрирующего программного обеспечения. Преобразование сообщений на ОЯВ в вызовы функций той или иной интегрирующей среды обеспечивается дополнительной интегрирующей оболочкой с единым интерфейсом, который предназначен только для обмена сообщениями на ОЯВ. Единицей информационного обмена в рассматриваемом подходе являются сообщения, поэтому целесообразно строить такое программное обеспечение на основе программных продуктов класса MOM.

5.3 Паттерны интеграции по типу обмена данными

5.3.1 Файловый обмен

Описание

Данный тип интеграции основывается на концепции "Точка - Точка", 5.1.1, системы экспортируют общие данные в формате пригодном для импорта в другие системы. В последнее время в качестве единого формата файлов обмена все чаще выбирают XML, как наиболее распространенный и поддерживаемый в мире, большинство систем позволяют производить экспорт-импорт данных в формате XML, на рынке программного обеспечения существует большое количество программ, позволяющих в удобной форме создавать так называемые "преобразователи" XML данных на основе технологии XSLT.

Недостатки

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

5.3.2 Общая база данных

Описание

Является реализацией подхода 5.2.1. Данный тип интеграции позволяет получить полностью интегрированную систему приложений, работающую с едиными данными в любой момент времени. Изменения, произведенные в одном из приложений, автоматически отражаются в другом. За корректность данных отвечает многопользовательская СУБД.

Затруднительно интегрировать существующие системы, удобно использовать для вновь создаваемых.

систем.

5.3.3 Удаленный вызов процедур

Описание

Данный тип интеграции является реализацией объектно-центрического подхода, 5.2.3. При таком подходе приложения интегрированы на уровне функций. Изменение данных в другой системе происходит также посредством вызова функций.

Недостатки

Каждая из систем самостоятельно заботится о поддержке данных в корректном состоянии, что является довольно сложно задачей

5.3.4 Обмен сообщениями

Описание

Данный тип интеграции приложений основан на асинхронном обмене сообщениям посредством шины данных и предназначен для интеграции независимых приложений без или с минимальными доработками существующих систем. Он является реализацией подхода 5.2.4. При этом за логику интеграции отвечает интеграционная шина в отличие от других типов интеграции, где за логику интеграции отвечала одна из интегрируемых систем. Такой подход позволяет легко интегрировать новые системы, а также изменять логику интеграции, легко приводя ее в соответствие с бизнес логикой процесса.

6 ЗАКЛЮЧЕНИЕ

Данная работа представляет собой единый словарь - справочник паттернов проектирования информационных систем, сформированный на основе обобщения и реструктурирования материала наиболее значительных монографий в этой области. Описания паттернов структурированы таким образом, чтобы обеспечить максимальное удобство в их освоении и использовании. Для этой цели выделены и систематически, на единых принципах описаны три группы паттернов проектирования, обсуждаемые в порядке возрастания "масштаба" решаемых задач.

Каждая из этих групп описывает паттерны для решения задач определенного уровня - от взаимодействия отдельных классов/обьектов системы до интеграции нескольких информационных систем в единое целое. В соответствии с этим в работе описаны паттерны проектирования взаимодействия обьектов информационных систем, архитектурные системные паттерны и паттерны интеграции. Следует подчеркнуть, что, по крайней мере в русскоязычной литературе, предложенная унифицированное обсуждение разнородных паттернов до сих пор отсутствовало.

Внутри вышеописанных групп паттернов проектирования проведена своя структуризация, упрощающая поиск и понимание назначения паттернов проектирования. Например, внутри группы паттернов проектирования классов/обьектов выделены паттерны для организации классов/обьектов в более крупные структуры, паттерны для распределения обязанностей между классами/объектами и паттерны для создания классов или обьектов. Аналогично, архитектурные паттерны разделены на структурные паттерны, служащие для разделения отдельной системы на несколько взаимодействующих подсистем и, кроме того, паттерны управления. для обеспечения взаимодействия этих подсистем.

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

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

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

7 ПРИЛОЖЕНИЕ: СЛОВАРЬ ТЕРМИНОВ

7.1 Общие термины

Rational Rose - инструмент для визуального моделирования объектно-ориентированных информационных систем компании Rational Software. Продукт использует UML.

API (Application Programming Interface) - интерфейс программирования прикладных систем.

UML (Unified Modeling Language) - унифицированный язык моделирования обьектно - ориентированных программных систем.

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

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

Диаграмма - графическое представление набора элементов разрабатываемой системы или предметной области, в вершинах данного представления находятся сущности, а дуги представляют собой отношения этих сущностей. Диаграммы строятся в рамках определенной модели. Например, в рамках UML строятся следующие диаграммы: - прецедентов (описывает функциональное назначение системы), - концептуальных классов (описывает предметную область), - состояний (описывает поведения зависимых от состояний обьектов системы), - деятельности (используется для алгоритмического описания поведения системы) - программных классов, - взаимодействия (описывает взаимодействие обьектов системы).

Проектирование - выработка концептуальных решений, обеспечивающих выполнение основных требований и разработка системной спецификации.

Модель - представление разрабатываемой системы или предметной области в рамках определенного стандарта, например, модель данных системы, выполненная c использованием стандарта IDEF1X.

Модуль - компонент системы (подсистемы), который предоставляет один или несколько сервисов. Модуль может использовать сервисы, поддерживаемые другими модулями. Модуль не может рассматриваться как независимая система.

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

Предметная область - область знаний или деятельности, характеризующаяся специальной терминологией, используемой экспертами предметной области, и набором бизнес - правил.

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

Система - совокупность взаимодействующих компонентов, работающих совместно для достижения определенных целей.

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

Требования к системе - условия или возможности, которые система должна выполнять или предоставлять, и, кроме того, соглашение между заказчиком системы и ее разработчиком об этих условиях или возможностях.

Паттерн проектирования представляет собой именованное описание проблемы и ее решения, кроме того, содержит рекомендации по применению в различных ситуациях, описание достоинств и недостатков.

паттерн проектирования объектов - GoF - паттерны, разработанные четырьмя авторами [ 4], GRASP (General Responsibility Assignment Software Patterns) - паттерны распределения обязанностей между объектами [ 2];
архитектурный системный паттерн - крупномасштабное проектное решение при разработке системы, обычно формируется на ранних итерациях [ 5];
паттерн интеграции систем - используется при интеграции нескольких систем [ 6].

7.2 Термины паттернов проектирования объектов

Зацепление (cohesion) - мера "сфокусированности" обязанностей класса. Класс с низкой степенью зацепления выполняет много разнородных функций и несвязанных между собой обязанностей. Создавать такие классы нежелательно.

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

Инстанцирование - создание экземпляра класса.

Интерфейс объекта (системы) - совокупность сигнатур всех определенных для объекта (системы) операций.

Класс специфицирует внутренние данные объекта и его представление, а также операции, которые объект может выполнять. Класс в языке UML (программный или концептуальный) -это описание набора элементов, имеющих одинаковые атрибуты, операции и отношения. Абстрактный класс делегирует свою реализацию подклассам, его единственным назначением является спецификация интерфейса.

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

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

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

Связанность (coupling) - зависимость между классами, вызываемая взаимодействием между ними при выполнении определенной задачи. Класс с высокой степенью связанности зависит от множества других классов, что нежелательно.

Сигнатура операции - имя операции, передаваемые параметры и возвращаемые значения.

Системное событие - событие, генерируемое внешним исполнителем.

7.3 Термины архитектурных системных паттернов

Реляционная база данных - база данных, построенная на реляционной модели. Информация в реляционной базе данных хранится в виде связанных таблиц, состоящих из столбцов и строк.

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

СУБД - система управления базами данных, комплекс программных и семантических средств, реализующий поддержку создания баз данных, централизованного управления и организации доступа к ним различных пользователей в условиях принятой технологии обработки данных.

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

7.4 Термины паттернов интеграции

Активная система - система, использующая интерфейс другой системы.

Пассивная система - система, предоставляющая интерфейсы для пользования другим системам и не использующая напрямую интерфейсы других систем.

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

ОЯВ - общесистемный язык взаимодействия.

EAI (Enterprise Application Integration) - Интеграция корпоративных систем.

IDL (Interface Definition Language) - язык спецификации интерфейсов.

MOM (Message Oriented Middleware) - системное программное обеспечение промежуточного слоя, ориентированное на обмен сообщениями.

XML (eXtensile Markup Language)- расширяемый язык гипертекстовой разметки, используемый в интернете. Язык XML использует структуру тегов и определяет содержание гипертекстового документа. XML позволяет автоматизировать обмен данными, при этом обьем программирования будет незначительным.

XSLT (eXtensible Stylesheet Language for Transformations) - предназначен для преобразования XML документов. С его помощью можно описать правила преобразования, которые позволят преобразовать документ в другую форму (структуру) или формат, например, в текстовый или HTML.

ЛИТЕРАТУРА

[1] K. Alexander et al. Pattern Language. Oxford 1977.

[2] К. Ларман. Применение UML и паттернов проектирования. М. , Вильямс, 2002.

[3] Г. Буч, Дж. Рамбо, А. Джекобсон. Язык UML. Руководство пользователя. М. LVR Пресс, 2001.

[4] Э. Гамма, Р. Хелм, Р. Джонсон, Дж. Влиссидес. Приемы обьектно - ориентированного проектирования Паттерны Проектирования. СПб., Питер, 2003.

[5] М. Фаулер. Архитектура корпоративных программных приложений. М. , Вильямс, 2004.

[6] G. Hohpe, B. Woolf. Enterprise Integration Patterns : Designing, Building, and Deploying Messaging Solutions. Addison-Wesley, 2004.

Оглавление Назад