Design patterns of information systems (part I).pdf Введем несколько определений. Под информационнойсистемой (ИС) будем понимать совокупность программных,аппаратных и людских ресурсов, задействованных в управ-лении бизнес-процессами и/или в обеспечении информаци-онной поддержки бизнес-процессов предприятия или орга-низации. Если такое воздействие затрагивает все или боль-шую часть бизнес-процессов предприятия или организации,информационную систему можно называть корпоративной(КИС).Под паттерном будем понимать классическое определе-ние К. Александра: паттерн - это описание задачи, котораямногократно возникает в нашей работе, а также принципаее решения, причем так, что это решение можно потом ис-пользовать всякий раз, когда это необходимо, ничего неизобретая заново [1]. Хотя сам классик имел в виду паттер-ны, возникающие при проектировании зданий и городов,его слова применимы и в отношении паттернов программ-ной инженерии.ИС КАК МОДЕЛЬ ОКРУЖАЮЩЕЙ ДЕЙСТВИ-ТЕЛЬНОСТИКак и любая программа, ИС представляет собоймодель деловой среды, для которой она создается.Действительно, все, что происходит в бизнесе, долж-но находить свое отражение в ИС: принят ли на рабо-ту новый сотрудник или в учебный план поставленновый курс - все эти данные, раз они появились в ре-альном мире, должны появиться и в ИС в виде доку-ментов, элементов справочников, фотографий и т.д.Если этого не происходит, ИС не является адекватноймоделью бизнеса и, следовательно, не может исполь-зоваться как инструмент для достижения успеха.Говоря об ИС как о модели бизнеса, мы должныотдавать себе отчет в том, что бизнес постоянно ме-няется. Изменения бизнеса, в свою очередь, незамед-лительно приводят к изменению требований, нала-гаемых на ИС. Помимо изменения требований к ИС,порожденных изменением бизнеса, возможны такжеизменения требований, порожденные изменившимсявосприятием системы со стороны заинтересованныхлиц и/или пользователей.Хотя проблемы, связанные с изменением требова-ний, относятся к области системного анализа, их по-следствия носят в том числе и инженерный характер -кому, как не инженерам, переписывать систему в ре-зультате изменившихся требований. Поэтому совер-шенно понятно стремление создавать системы, устой-чивые к изменениям, то есть системы, позволяющиевносить изменения максимально быстро и дешево.Чтобы говорить о создании устойчивых к измене-ниям систем, необходимо понять, что может изме-няться в бизнесе и что не может изменяться в бизнесе.Авторы считают, что на стратегическом уровне неиз-менными в любом бизнесе являются факт существо-вания организационной структуры бизнеса и фактсуществования бизнес-процессов в контексте этой ор-ганизационной структуры. Все остальное: состав ор-ганизационной структуры, содержание бизнес-про-цессов и т.д. - может изменяться.В данной работе рассматривается два паттерна:«Организационная структура», «Бизнес-процесс».При описании паттернов используется шаблон,принятый в [1].ПАТТЕРН«ОРГАНИЗАЦИОННАЯ СТРУКТУРА»НазначениеПредоставляет возможность задавать произволь-ную иерархию подчинения при описании организаци-онной структуры предприятия или организации.РешениеДля описания организационной структуры в мо-дель данных предлагается ввести 3 сущности (табли-цы). Первая из них - это тип подразделения (subdivision_type). Таблица хранит информацию о типах под-разделений, присутствующих в организации. Приме-рами записей в такой таблице могут быть: факультет,кафедра, лаборатория, склад, цех и т.д.;- правила подчинения (subordination_rule). Таблицахранит пары ключей {идентификатор родительскоготипа (parent_type_id), идентификатор дочернего типа(child_type_id)}. Записи в данной таблице показыва-ют, как типы подразделений могут подчиняться другдругу. Например, пусть 1 - номер типа Факультет, 2 -номер типа Кафедра, 3 - номер типа Лаборатория. То-гда пары {1,2}, {1,3} задают возможность подчинениякафедры факультету и лаборатории факультету.- подразделение (subdivision). В данной таблицехранится информация о конкретных подразделенияхпредприятия или организации; например: ФПМК,РФФ, кафедра программирования, лаборатория вакцини сывороток. Пара {subdivision_type_id, parent_type_id}формирует внешний ключ на таблицу subordination_rule. Пара {parent_type_id,parent_id} формируетвнешний ключ к таблице subdivision. Наконец, поля{subdivision_type_id} и {parent_type_id} являютсявнешними ключами на таблицу subdivision_type.Описанные сущности представлены на ER-диа-грамме (рис. 1).РезультатыОсновными результатами применения данногопаттерна являются:- возможность описывать произвольные организа-ционные структуры;- контроль над целостностью данных, касающихсяорганизационной структуры, осуществляется на дек-subdivision_typesubdivision_type_idsubdivision_type_namesubordination_ruleparent_type_id (FK)child_type_id (FK)Рис. 1. Модель данных организационной структурыларативном уровне, что делает паттерн независимымот используемой системы управления базами данных.Прежде чем начать рассмотрение паттерна «Биз-нес-процесс», рассмотрим используемый в нем пат-терн Рефлексия, так как для паттерна «Бизнес-процесс» возможность создавать объекты по именикласса является необходимой.ПАТТЕРН «РЕФЛЕКСИЯ»НазначениеОбеспечить возможность создания объектов поимени класса для языков программирования, не под-держивающих рефлексию явно.РешениеObjectFactoryObjectFactory()ObjectFactory( : ObjectFactory) getInstance() : ObjectFactoryregisterClass(class_name : string, object : Object) : voidcreateObjectByName(class_name : string) : ObjectObjectcreateInstance() : Object-objectsLibrarClient yConcreteClass1createInstance() : ObjectConcreteClass1::createInstance(){return new ConcreteClass1();}Рис. 2. Структура паттерна РефлексияУчастникиObject − базовый класс для тех классов системы,для которых необходимо создание объектов по имени.В простейшем случае Object объявляет интерфейс содним абстрактным методом createInstance().ConcreteClass1 - конкретный подкласс Object. Реа-лизует метод createInstance(). Наиболее простой реа-лизацией этого метода в конкретных подклассах Objectявляется создание самого себя (рис. 2).ObjectFactory - фабрика объектов. ObjectFactoryреализуется в соответствии с шаблоном Singleton [1].Данный класс предоставляет интерфейс для регистра-ции классов (метод registerClass()) и для созданияобъектов (метод createObjectByName()) (рис. 2).Library предоставляет интерфейс для модулей сис-темы. Конкретными подклассами Library могут являть-ся классы, инкапсулирующие загрузку динамическихбиблиотек, таких, как Dynamic Load Library (DLL) вWin32-системах или Shared Library в Unix-системах. Взадачу данного класса входит регистрация содержа-щихся в них классов у ObjectFactory (рис. 3)Client. Описывает классы, объекты которых явля-ются клиентами относительно ObjectFactory. Клиентыиспользуют ObjectFactory для создания объектов, вы-зывая у последней createObjectByName() (рис. 4)Взаимодействие: Library: ObjectFactory: Object1: new Object2: getInstance( )3: registerClass(string, Object)Рис. 3. Регистрация класса1: getInstance( )2: createObjectByName(string) 3: createInstance( )Рис. 4. Создание объектаРезультатыОсновным результатом применения данного пат-терна является возможность создавать объекты клас-сов по имени, что, в свою очередь, повышает гибкостьпрограммного решения. С другой стороны, паттернподразумевает организацию программы как наборадинамически подгружаемых библиотек, что можетоказаться неприемлемым. Так, например, динамиче-ски загружаемые библиотеки могут не поддерживать-ся целевой операционной системой.ПАТТЕРН «БИЗНЕС-ПРОЦЕСС»Назначение- Упрощает прямую трассировку артефактов пото-ка работ Требования [3,4] в артефакты потока работАнализ и проектирование [4].- Упрощает процесс внесения в систему измене-ний.РешениеСледуя рекомендациям, приведенным в [4], разо-бьем классы анализа на 3 категории:- Бизнес-объекты (BusinessObject) - классы, пред-ставляющие понятия деловой среды.- Граничные классы (BoundaryClass) - классы, от-вечающие за взаимодействие системы с ее акторами(Actor, [4]).- Классы управления - классы, отвечающие за ко-ординацию взаимодействия в контексте прецедентов[2,4]В соответствии с паттерном MVC [1] все комму-никации между граничными классами и бизнес-объектами будем осуществлять через классы управ-ления.Для каждого прецедента, выявленного на этапеТребования, введем один класс управления, которыйбудем называть контроллер прецедента (UseCase-Controller) или просто контроллер. Будем считать,что i-й контроллер в каждый момент времени можетнаходиться в одном состоянии из множества{Si1,Si2,…,SiN}. Переход из состояния Sij в состояниеSik происходит при получении контроллером сооб-щения M. Сообщение M может быть послано кон-троллеру любым объектом системы. Правила пере-хода из состояния в состояние инкапсулированы вконтроллере (каждый контроллер хранит у себя таб-лицу состояний и переходов).Таким образом, мы получим архитектуру, в кото-рой для каждого прецедента деловой среды, описы-ваемого конечным автоматом, явно выделяется своягруппа классов, реализующая или поддерживающаяэтот прецедент в ИС. Это положение решает первуюзадачу паттерна - упрощение прямой трассировкимежду артефактами потоков работ. Действительно,для каждого прецедента явно выделяется по одномуконтроллеру и несколько классов, с которыми выде-ленный контроллер состоит в отношении ассоциации[4]. Для того чтобы решить вторую задачу, упроститьпроцесс внесения изменений в систему, необходиморазобраться с характером изменений программныхартефактов, наступающих в ответ на изменения тре-бований. Изменения программных артефактов могутзаключаться:- в изменении набора состояний контроллеров,правил перехода из состояния в состояние, а также визменении логики обработки сообщений. К таким из-менениям может привести, например, изменение по-следовательности действий внутри некоторого биз-нес-процесса;- в изменении внешнего представления бизнес-объектов, т.е. в изменении граничных классов. К та-ким изменениям могут привести изменение воспри-ятия системы со стороны заинтересованных лиц илиизменение структуры самих бизнес-объектов;- в изменении структуры и поведения бизнес-объектов, обусловленных, например, изменениемвнешней среды (изменение законодательства, реин-жиниринг и т.д.).Для устойчивости к такого рода изменениям необ-ходимо:- вынести из контроллеров описание состоянийпрецедентов и правила перехода из состояния в со-стояние, в некоторое внешнееСтруктураBusinessObjectBoundaryClassMessageResultConcreteBoundaryConcreteObjectConcreteHandler1processMessage( : Message)UseCaseControllerprocessMessage( : Message)MessageHandlerprocessMessage( : Message)MacroConcreteHandler2processMessage( : Message)1-handlers0..* -handlersUseCaseController::processMessage(Message message){ foreach MessageHandler iin handlers {i.processMessage(message)}// Далее с ледует код,// обес печивающий переход// из сос тояния в с ос тояние}ConcreteHandler::processMessage(Messagemessage){// обработка с ообщения...foreach MessageHandler i in handlers {i.processMessage(message)}}Рис. 5. Структура паттерна Бизнес-процессУчастникиBusinessObject. Базовый класс бизнес-объектов де-ловой среды.UseCaseController. Контроллер прецедента. Отве-чает за координацию объектов в контексте прецеден-та. В простейшем случае содержит один-единствен-ный метод processMessage(). Метод предназначен дляобработки посылаемых контроллеру сообщений. Ре-ально данный метод большинство сообщений не об-рабатывает, а делегирует их обработку объектамкласса MessageHandler. Исключением являются со-общения, инициирующие переход контроллера из со-стояния в состояние.BoundaryClass. Базовый класс граничных классов.Подклассы граничного класса отвечают за организа-цию взаимодействия системы с внешней средой.Message. Представляет собой абстракцию сообще-ния. Так, если некоторый объект (клиент) системыхочет инициировать поведение другого объекта (сер-вера), он создает объект Message и посылает его сер-веру.Result. Представляет собой абстракцию результатаобработки сообщения. Объекты данного класса пред-назначены для того, чтобы сервер мог вернуть резуль-тат своей работы клиенту. MessageHandler. Базовыйкласс обработчиков сообщений.MessageHandler. Обработчик сообщений. В под-классах данного класса содержится практически всябизнес-логика работы системы. Именно объектыMessageHandler заставляют другие объекты сохра-няться, изменяться, удаляться, что-либо рассчитыватьили показывать и т.д. Конкретные подклассыMessageHandler могут иметь связи с конкретнымибизнес-объектами и граничными классами, необходи-мыми им для обеспечения своей ответственности.ConcreteObject. Конкретный подклассBuisinessObject, например Факультет или Документ.ConcreteBoundary1. Конкретный граничный класс,например форма для внесения личных дел сотрудни-ков.ConcreteHandler1, MacroConcreteHandler2. Кон-кретные обработчики сообщений.ВзаимодействиеПри старте системы для каждого прецедента соз-дается контроллер (объект класса UseCaseConttoller).Контроллер загружает свою таблицу состояний и пе-реходов, создает необходимые для работы объекты(обработчики сообщений, возможно, бизнес-объектыи объекты граничных классов) и переходит в некото-рое начальное состояние. Далее, контроллеру посред-ством вызова processMessage() может быть посланонекоторое сообщение. Контроллер, получив сообще-ние, пересылает его всем ассоциированнымСхема данныхclassclass_idclass_nameclass_for_createclass_id (FK)use_case_state_id (FK)use_case_id (FK)jump_state_tablenew _use_case_state_id (FK)use_case_state_id (FK)use_case_id (FK)message_type_id (FK)message_typemessage_type_iduse_caseuse_case_iduse_case_extendextend_use_case_id (FK)use_case_id (FK)use_case_state_id (FK)numberparent_extend_use_case_id (FK)use_case_stateuse_case_state_iduse_case_id (FK)Рис. 5. Структура паттерна Бизнес-процессclass. Хранит информацию о классах системы.class_for_create. Хранит информацию о том, какиеклассы должны создаваться при переходе контролле-ра прецедента в некоторое состояние.use_case. Хранит информацию о прецедентах, при-сутствующих в системе прецедентах.use_case_state. Хранит информацию о возможныхсостояниях контроллеров.message. Хранит информацию о сообщениях.use_case_extend. Хранит информацию о расшире-ниях (extent) прецедентов [4], позволяя тем самым за-давать условия вида [Если прецедент UCi находится всостоянии Sk, необходимо запустить выполнение пре-цедента UCj].jump_state_table. Таблица состояний и переходов.Хранит информацию о том, в какое состояние долженперейти контроллер прецедента, если он находится всостоянии Si и получил сообщение Mj.РезультатыПаттерн Бизнес-процесс фактически представляетсобой архитектурное ядро ИС. Архитектура, постро-енная на базе паттерна Бизнес-процесс, обладает сле-дующими характеристиками:- Классы ядра обладают низкой степенью связно-сти (см. описание паттерна Low Coupling [2]), что по-зитивно сказывается на возможности повторного ис-пользования.- Позволяет легко наращивать функциональностьсистемы

Скачать электронную версию публикации