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