Диаграммы коопераций. 
Создание логического представления проектируемой системы. 
Диаграммы взаимодействия

Диаграмма коопераций, в отличие от диаграммы взаимодействий, акцентирует внимание на организации объектов, принимающих участие во взаимодействии. Она представляется в виде графа, вершины которого — объекты, участвующие во взаимодействии, а дуги — связи, соединяющие объекты. Связи дополняются сообщениями, которые объекты принимают и посылают. Таким образом, диаграмма коопераций даёт визуальное представление о потоке управления в контексте структурной организации кооперирующихся объектов.

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

• 1. Путь — для описания связи одного объекта с другим к дальней концевой точке этой связи можно присоединить стереотип пути:
  • — association — соответствующий объект виден на ассоциации;
  • — self — объект является диспетчером операции;
  • — global — объект находится в глобальной области действия;
  • — local — объект находится в локальной области действия;
  • — parameter — объект является параметром.
• 2. Порядковый номер сообщения — для обозначения временньй последовательности перед сообщением ставиться номер (нумерация начинается с единицы), который должен постепенно возрастать для каждого нового сообщения (2, 3 и т. д.). Для обозначения вложенности используется десятичная нотация Дьюи (1 — первое сообщение; 1.1 — первое сообщение, вложенное в сообщение 1; 1.2- второе сообщение, вложенное в сообщение 1 и т. д.). Уровень вложенности не ограничен. Для каждой связи можно показать несколько сообщений (вероятно, посылаемых разными отправителями), и каждое из них должно иметь уникальный порядковый номер.

Рекомендуется не показывать явно связи между объектами на диаграмме последовательностей — эта информация отражается на диаграмме взаимодействий, а также не указывать порядковые номер сообщения, поскольку они неявно определяются физическим расположением сообщений на диаграмме. Как правило, на диаграммах последовательностей показывают только простые ветвления, а более сложные изображаются на диаграмме коопераций.

Как правило, диаграммы коопераций и последовательности служат одной и той же цели, и представляют одну и ту же информацию, но с различных точек зрения. Поэтому, часто для какого-либо варианта использования создают диаграммы обоих типов.

Практическая часть:

1. Архитектурный анализ системы Следующий этап разработки проекта — анализ системы. Примем следующие соглашения по моделированию:

• 1. Имена вариантов использования должны быть короткими глагольными фразами.
• 2. Для каждого варианта использования должен быть создан пакет Use Case Realization, включающий:
  • — по крайней мере, одну реализацию варианта использования;
  • — диаграмму VOPC (View of Participating Classes).
• 3. Имена классов должны быть существительными, соответствующими понятиям предметной области, и начинаться с прописной буквы. Имена атрибутов и операций должны начинаться со строчной буквы, составные имена — сплошными, без подчёркиваний, каждой отдельное слово с прописной буквы.

Реализация варианта использования описывает конкретный вариант использования в терминах взаимодействующих объектов и представляется с помощью набора диаграмм — классов и взаимодействия (логического представления).

Сначала создайте структуру модели, аналогично рис. 2.

Затем, для построения логической модели, необходимо определить предварительные ключевые абстракции — классы анализа, добавить их в пакет Design Model, и поместить на диаграмму Key Abstractions (см. рис.3).

• 1. Граничные классы (стереотип boundary) — служат посредниками при взаимодействии внешних объектов с системой. Как правило, для каждой пары «актёр — вариант использования» определяется один такой класс. Типы граничных классов:
  • — пользовательский интерфейс (без деталей — кнопок, окон и т. п.);
  • — системный интерфейс (протоколы без деталей реализации);
  • — аппаратный интерфейс (протоколы без деталей реализации).
• 2. Классы сущности (стереотип entity) — ключевые абстракции (понятия) разрабатываемой системы. Выявляются в процессе архитектурного анализа, при составлении глоссария проекта, при описании потоков событий вариантов использования.
• 3. Управляющие классы (стереотип control) — обеспечивают координацию поведения объектов в системе. В вариантах использования, где производятся только простейшие манипуляции с данными, такие классы могут отсутствовать. Как правило, для каждого варианта использования определяется только один управляющий класс (менеджер транзакций, координатор ресурсов, обработчик ошибок и т. п.)

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