В процессе анализа было принято предварительное решение о выделении архитектурных уровней (в случае системы регистрации — четырех уровней в соответствии с образцом «Уровни»). В процессе проектирования все элементы системы должны быть распределены по данным уровням.
Рис. 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. Представление структуры модели в процессе проектирования