Формирование архитектурных уровней

В процессе анализа было принято предварительное решение о выделении архитектурных уровней (в случае системы регистра­ции — четырех уровней в соответствии с образцом «Уровни»). В процессе проектирования все элементы системы должны быть распределены по данным уровням.

Рис. 4.20. Контекст подсистемы CourseCatalogSystem

с точки зрения архитектора

С точки зрения модели это оз­начает распределение проектных классов по пакетам, соответ­ствующим архитектурным уровням (пакетам со стереотипом <<layer>>). В сложной системе архитектурные уровни могут раз­биваться на подуровни, количество и структура которых, как было сказано выше, зависят от сложности предметной области и среды реализации.

Рис. 4.21. Диаграмма классов подсистемы CourseCatalogSystem с точки зрения проектировщика

Подуровни могут формироваться, исходя из следующих критериев:

· группировка элементов с максимальной связанностью;

· распределение в соответствии со структурой организации (обычно это касается верхних уровней архитектуры);

· распределение в соответствии с различными областями компетенции разработчиков (предметная область, сети, коммуникации, базы данных, безопасность и др.);

· группировка отдельных компонентов распределенной сис­темы;

· распределение в соответствии с различной степенью безо­пасности и секретности.

Рис. 4.22. Кооперативная диаграмма, описывающая реализацию операции интерфейса getCourseOfferings

Пример выделения архитектурных уровней и объединения элементов модели в пакеты для системы регистрации приведен на рис. 4.23.

Данное представление отражает следующие решения, приня­тые архитектором:

· выделены три архитектурных уровня (созданы три пакета со стереотипом «layer»);

· в пакете Application создан пакет Registration, куда включе­ны граничные и управляющие классы;

· граничные классы BillingSystem и CourseCatalogSystem пре­образованы в подсистемы;

· в пакет Business Services, помимо подсистем, включены еще два пакета: пакет External System Interfaces включает интер­фейсы подсистем (классы со стереотипом <<Interface>>), а пакет University Artifacts — все классы-сущности.

Рис. 4.23. Представление структуры модели в процессе проектирования