На этом шаге рассмотрим типичные приемы моделирования различных представлений системы в UML.
Система – это набор подсистем, организованных для достижения определенной цели и описанных с помощью набора моделей (возможно, с различных точек зрения).
Подсистема – группа элементов, часть которых составляет спецификацию поведения, представленного другими ее составляющими.
Модель – семантически завершенная абстракция системы, которая создана по принципу полного и самодос-таточного упрощения реальности, ставящего целью лучшее понимание системы.
В контексте архитектуры представление – это проекция организации и структуры системной модели, сфокусированная на одном из ее аспектов.
При моделировании системы с разных точек зрения вы параллельно конструируете ее во многих измерениях. Выбирая правильный набор представлений, запускается процесс, который помогает ставить правильные вопросы о системе и выявлять риски, которым она будет подвергаться. Если подойти к выбору этих представлений неграмотно, то некоторые важные обстоятельства могут выпадать из поля зрения – таким образом, в будущем можно столкнуться с проблемами, которые серьезно повредят работе над проектом.
Чтобы смоделировать систему с разных точек зрения, необходимо:
- Решить, какие представления понадобятся для наилучшего выражения архитектуры вашей системы и для снижения технических рисков проекта.
- Определить, какие артефакты вам понадобятся для того, чтобы охватить наиболее существенные детали каждого выбранного представления. Чаще всего в качестве таких артефактов выступают разнообразные диаграммы UML.
- Отметить диаграммы, для которых следует предусмотреть формальный или полуформальный контроль (то есть те, которые требуют периодического пересмотра), и сохранить их в составе документации проекта.
- Оставить место для диаграмм, которые пока не задействованы. Эти временные диаграммы помогут исследовать реализацию ваших решений и продумать возможные изменения моделируемой системы.
К примеру, вы моделируете простое монолитное приложение, которое исполняется на одном компьютере. Для этого потребуется не так уж много диаграмм:
- представление вариантов использования - диаграммы вариантов использования,
- представление дизайна - диаграммы классов (для структурного моделирования),
- представление взаимодействий - диаграммы взаимодействия (для поведенческого моделирования),
- представление реализации - диаграммы составной структуры,
- представление развертывания - диаграммы развертывания.
Если ваша система реактивная или же сосредоточена на потоке процессов, не исключено, что для моделирования ее поведения вы захотите использовать соответственно диаграммы состояний и диаграммы деятельности.
Если же вы работаете над системой с архитектурой "клиент/сервер", вам, вероятно, понадобятся диаграммы компонентов и диаграммы развертывания, чтобы смоделировать ее физические особенности.
Наконец, при подготовке сложной распределенной системы вам придется задействовать полный набор диаграмм UML, чтобы выразить ее архитектуру и выявить технические риски проекта:
- представление вариантов использования - диаграммы вариантов использования, диаграммы последовательности,
- представление дизайна - диаграммы классов (для структурного моделирования), диаграммы взаимодействия (для поведенческого моделирования), диаграммы состояний для поведенческого моделирования), диаграммы деятельности,
- представление взаимодействий - диаграммы взаимодействия (для поведенческого моделирования),
- представление реализации - диаграммы классов, диаграммы составной структуры,
- представление развертывания - диаграммы развертывания.
На следующем шаге рассмотрим типичные приемы моделирования различных уровней абстракции.
