Методы объектного анализа и построения моделей предметных областей

4.2.2. Общесистемный подход к проектированию архитектуры

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

1. Системные компоненты, устанавливающие интерфейс с оборудованием и аппаратурой;
2. Общесистемные компоненты, устанавливающие интерфейс с универсальными системами компьютеров;
3. Специфические бизнес-компоненты;
4. Прикладные программные системы.

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

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

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

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

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

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

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

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

Архитектурная схема может быть: распределенная, клиент-серверная и многоуровневая.

Распределенная схема обеспечивает взаимодействие компонентов системы, расположенных на разных компьютерах через стандартные механизмы вызова RPC (Remote Procedure Calls), RMI (Remote Method Invocation), которые реализуются промежуточными средами (COM/DCOM, CORBA, Java и др.) [4.15, 4.16]. Взаимодействующие компоненты могут быть неоднородными, на разных языках программирования (С, С++, Паскаль, Java, Basic, Smalltalk и др.), которые допускаются в промежуточной среде системы CORBA (рис. 4.6). Для каждой пары языков взаимодействующих компонентов создаются интерфейсы типа L_i, L_n по количеству пар ЯП системы, допускающих взаимодействие между собой.

Рис. 4.6. Связь между языками L1, L2, …, Ln через интерфейсы

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

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

В качестве инструмента проектирования объектов применяется UML или унифицированный процесс RUP [4.17, 4.18]. Связи между объектами и их типами (операции и атрибуты) сервера и клиента задаются диаграммами классов. Взаимодействие объектов моделируется с помощью сценариев взаимодействия или диаграмм последовательности. Диаграммы состояний задают ограничения на операции к объектам сервера, преобразуются (генерируются) в интерфейсы (стабы), определяющие структуру и поведение объектов сервера (рис. 4.7).

Рис. 4.7. Процесс разработки распределенных объектов

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

Сущность стиля проектирования в рамках унифицированного процесса RUP состоит в предоставлении всех видов деятельности, выполняемых на моделях (анализа, проектирования, разработки и тестирования) процесса ЖЦ.

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

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

1. каждая подсистема должна отражать требования и способ их реализации (сценарий, прецедент, актер и т.п.);
2. изменяемые функции выделятся в подсистемы так, чтобы для них прогнозировались изменения требований и отдельные объекты, связанные с актером;
3. связь объектов осуществляется через интерфейс;
4. каждая подсистема должна выполнять минимум услуг или функций и иметь фиксированное множество параметров интерфейса.

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

Выделенные в модели анализа объекты объединяются в систему путем:

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

Если во вновь создаваемой системе используется унаследованная система, то она снимает проблему дублирования и сокращает объем работ при проектировании архитектуры системы.

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

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

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

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

Контрольные вопросы и задания

1. Определите задачи анализа предметной области.
2. Сформулируйте задачи концептуального проектирования моделей ПрО.
3. Назовите продукты анализа домена в методе Шлеера и Меллора.
4. Назовите модели метода Шлеера и Меллора и их суть.
5. Какие еще модели ПрО существуют?
6. Перечислите ключевые факторы, влияющие на проектирование интерфейсов.
7. Назовите примеры нефункциональных требований, которые требуется учитывать на стадии проектирования архитектуры.
8. Какие уровни выделяются в архитектуре системы?
9. Какие известны способы объединения объектов в подсистемы?
10. Назовите приемы переноса системы в другую среду.