Спонсор: Microsoft
Московский физико-технический институт
Опубликован: 24.09.2008 | Доступ: свободный | Студентов: 2634 / 769 | Оценка: 4.52 / 4.48 | Длительность: 25:15:00
Специальности: Системный архитектор
Лекция 5:

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

< Лекция 4 || Лекция 5: 12345 || Лекция 6 >

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). Для каждой пары языков взаимодействующих компонентов создаются интерфейсы типа Li, Ln по количеству пар ЯП системы, допускающих взаимодействие между собой.

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

Рис. 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. Назовите приемы переноса системы в другую среду.
< Лекция 4 || Лекция 5: 12345 || Лекция 6 >
Максим Цапко
Максим Цапко

Я наконец закончил курс "Управление ИТ-проектами". Как получить документ об окончании курса.

давайн Нкунда
давайн Нкунда
Владимир Карпенко
Владимир Карпенко
Украина, Киев, Национальный Авиационный Университет, 2009
Михаил Адигеев
Михаил Адигеев
Россия