Различные уровни абстракции

Разработчикам необходимо рассматривать систему не только с различных то­чек зрения, но и на разных уровнях абстракции. Например, если есть набор клас­сов, охватывающих словарь предметной области, то программист захочет изучить свойства каждого из них, вплоть до атрибутов, операций и отношений. С другой стороны, аналитику, который обсуждает с конечным пользователем многочислен­ные варианты использования системы, те же самые классы готовой системы пона­добятся в максимально упрощенном виде. Таким образом, можно сказать, что про­граммист работает на более низком, а аналитик и пользователь - на более высоком уровне абстракции, но и в том, и в другом случае приходится иметь дело с одной и той же моделью. Так как диаграммы, по сути, являются графическим изображе­нием составляющих модель элементов, вы можете нарисовать несколько диаграмм одной модели, каждая из которых прячет или, наоборот, раскрывает некоторые элементы и, следовательно, показывает разные уровни детализации.

Существует два основных способа моделировать различные уровни абстрак­ции системы: можно, во-первых, строить диаграммы одной и той же модели, ха­рактеризующиеся различными уровнями детализации, а во-вторых, создавать раз­ные модели с различными степенями абстракции и диаграммы трассировки от одной модели к другой.

Моделирование системы на разных уровнях абстракции с применением диа­грамм разной степени детализации осуществляется следующим образом:

1. Изучите потребности ваших читателей и приступайте к созданию модели.

2. Если читатель будет использовать модель для создания реализации, то по­надобятся диаграммы самого низкого уровня, содержащие много деталей. Если же он рассчитывает применять модель для изложения основных кон­цепций конечному пользователю, то нужны высокоуровневые диаграммы, где большая часть деталей скрыта.

3. В зависимости от того, какие потребности читателя вам предстоит учесть, создайте диаграмму на подходящем уровне абстракции, скрыв или показав четыре категории сущностей, составляющих модель:

- строительные блоки и отношения. Скройте те из них, которые не соответ­ствуют предполагаемому уровню диаграммы или запросам читателя;

- дополнения. Оставьте только те дополнения к показанным строительным блокам и отношениям, которые существенны для понимания ваших наме­рений;

- поток управления. В диаграммах поведения раскрывайте только те сооб­щения (см. главу 15) или переходы (см. главу 21), которые имеют значе­ние для понимания читателем ваших намерений;

- стереотипы (см. главу 6). Если они используются для классификации пе­речней таких сущностей, как атрибуты и операции, показывайте только те из них, что необходимы для понимания вашего замысла.

Основное преимущество данного подхода состоит в том, что в процессе моде­лирования всегда используется общий набор семантических понятий. Основной

недостаток в следующем: изменения в диаграмме на одном уровне абстракции могут привести к тому, что диаграммы на другом уровне утратят актуальность.

Проектирование системы на различных уровнях абстракции с применением разноуровневых моделей производится так:

1. Рассмотрите потребности читателей и выберите необходимый уровень абст­ракции для каждого из них, после чего создайте для каждого уровня свою модель.

2. Модели, находящиеся на более высоком уровне, должны содержать по воз­можности простые абстракции, а на более низком - детализированные. Уста­новите отношения трассировки (Trace dependencies) между связанными эле­ментами различных моделей (см. главу 31).

3. Если вы следуете в своей работе идеологии пяти архитектурных видов систе­мы, то возможны четыре типовые ситуации, с которыми предстоит столкнуть­ся в процессе моделирования системы на различных уровнях абстракции:

- прецеденты и их реализация. В модели с точки зрения прецедентов ис­пользования (см. главу 16) прецеденты трассируются к кооперациям моде­ли с точки зрения проектирования;

- кооперации и их реализация. Кооперации (см. главу 27) трассируются к со­обществу классов, совместно функционирующих для осуществления дан­ной кооперации;

- компоненты и их проектирование. Компоненты (см. главу 25) модели реали­зации трассируются к элементам модели с точки зрения проектирования;

- узлы и их компоненты. Узлы (см. главу 26) модели с точки зрения развер­тывания трассируются к компонентам модели с точки зрения реализации.

Главное преимущество такого подхода в том, что диаграммы различных уров­ней абстракции менее тесно связаны друг с другом. Изменение в одной модели пе окажет слишком сильного влияния на остальные. Главный недостаток заключа­ется в необходимости затрачивать дополнительные усилия на синхронизацию моделей и их диаграмм. Он становится наиболее очевидным, если ваши модели соответствуют различным фазам жизненного цикла разработки приложения, на­пример, когда аналитическая модель отделена от проектной.

В качестве примера рассмотрим процесс моделирования системы электронной торговли. Одним из основных прецедентов такой системы является размещение заказа. Аналитику или конечному пользователю понадобятся диаграммы взаимо­действия (см. главу 18) на высоком уровне абстракции, которые схематично изоб­ражают этот процесс, как на рис. 7.1.

С другой стороны, программист, отвечающий за реализацию такого сценария, Должен воспользоваться более проработанной диаграммой, в которой следует рас­ширить некоторые сообщения и добавить новые действующие лица. Такой при­мер показан на рис. 7.2.

Обе диаграммы относятся к одной и той же модели, но демонстрируют раз­личные уровни детализации. Представляется разумным создать большое число

подобных диаграмм, особенно если ваши инструментальные средства позволяют легко осуществлять навигацию между ними.