Диаграммы взаимодействия объектов в UML

Диаграммы взаимодействия объектов в UML
В данной статье рассматриваются во всех подробностях диаграммы сотрудничества (collaboration
diagram) и диаграммы последовательности взаимодействия (sequence diagram) объектов.
В хорошо спроектированных программных системах для реализации многих задач взаимодействуют
мощные бизнес-объекты. Поэтому, для документирования потока сообщений между объектами и создания
при этом уникального представления отношений между взаимодействующими объектами применяются
UML-диаграммы сотрудничества объектов.
Бизнес-объекты находятся в основе любого сложного программного обеспечения. Когда пользователь
взаимодействует с программным обеспечением, бизнес-объекты реагируют на это, выполняя требуемые
действия, например, вычисления, получение, подтверждение и управление данными.
Зачастую для выполнения определенной задачи бизнес-объектам следует обратиться к сервисам других
бизнес-объектов. В унифицированном языке моделирования (Unified Modeling Language (UML))
существуют два вида диаграмм, которые помогают документировать и описывать эти взаимодействия:
диаграмма последовательности взаимодействия (Sequence diagram) и диаграмма сотрудничества объектов
(Collaboration diagram). Обе они известны как диаграммы взаимодействия (Interaction diagrams).
Оба типа диаграмм описывают взаимодействие между объектами, но при этом диаграммы
последовательности действий показывают, в каком порядке посылаются сообщения между объектами, а
диаграммы сотрудничества иллюстрируют отношения между взаимодействующими объектами.
1. Для чего применяются диаграммы сотрудничества?
Из двух типов диаграмм взаимодействия, диаграммы последовательности используются чаще, чем
диаграммы сотрудничества объектов. Зачем же использовать диаграммы сотрудничества?
Прежде всего, они очень полезны, чтобы визуализировать отношения между объектами,
взаимодействующими при выполнении определенной задачи, что сложно определить из диаграммы
последовательности. Кроме того, диаграммы сотрудничества помогают определить точность вашей
статической модели (то есть, диаграммы класса). Некоторые разработчики создают статические модели
своих бизнес-объектов, но не подтверждают их построением соответствующих динамических моделей.
Если же рассматривать классы в действии (или взаимодействии), можно сразу увидеть недостатки
статической модели, ранее не обнаруженные.
2. От диаграммы последовательности к диаграмме сотрудничества объектов
В действительности, диаграммы последовательности действий и диаграммы сотрудничества объектов
отображают одну и ту же информацию, только представляют ее по-разному. Более того, диаграммы
сотрудничества настолько близко связаны с диаграммами последовательности, что некоторые средства
моделирования, например, Rational Rose, могут автоматически создавать один тип диаграммы из другого.
Чтобы продемонстрировать это, возьмем диаграмму последовательности взаимодействия и покажем, как
преобразовать ее в диаграмму сотрудничества объектов. Наша диаграмма последовательности - один из
документов, спроектированных для научно-исследовательской библиотеки. Последовательность,
показанная на Рисунке 1, документирует взаимодействие, происходящее между бизнес-объектами при
определении количества книг, которые читатель может получить в библиотеке.
Рисунок 1: Диаграмма последовательности идеальна для демонстрации упорядоченной передачи
сообщений во время взаимодействия объектов.
Если открыть эту диаграмму последовательности в Rational Rose, а затем нажать клавишу F5, Rose
автоматически сгенерирует диаграмму сотрудничества объектов, показанную на Рисунке 2. При сравнении
диаграмм видно, что обе они содержат объекты и сообщения. При этом намного проще определить
порядок сообщений из диаграммы последовательности, а увидеть отношения между объектами - в
диаграмме сотрудничества объектов.
Рисунок 2: Диаграмма сотрудничества объектов лучше демонстрирует отношения между
взаимодействующими объектами.
Однако, для полного понимания этого различия, следует определить основные элементы диаграммы
сотрудничества.
3. Элементы диаграммы сотрудничества
Основные элементы диаграммы сотрудничества это:
l
l
l
Объекты (Objects)
Связи (Links)
Сообщения (Messages).
3.1 Объекты
Объекты, участвующие во взаимодействии, имеют две разновидности - Поставщики и Клиенты. Объекты-
поставщики – это объекты, которые предоставляют метод, который вызывается, и поэтому они получают
сообщение. Объекты-клиенты вызывают методы на объектах-поставщиках, и поэтому посылают
сообщения.
На Рисунке 2, объект Transaction действует как Поставщик для объекта-клиента UI (User interface). В свою
очередь, объект Fine - Поставщик для объекта-клиента Transaction.
3.2 Связи
Линии соединения между объектами в диаграмме сотрудничества – это связи. Они, как раз, и отображают
отличие диаграммы сотрудничества от диаграммы последовательности действий. Связи дают возможность
видеть отношения между объектами. Каждая связь представляет отношения между объектами и
символизирует способность объектов посылать сообщения друг другу. Связь может поддерживать одно
или более сообщений, посылаемых между объектами. В этом заключается отличие от диаграммы
последовательности действий, где линии, проведенные между объектами, представляют сообщения,
посланные от одного объекта к другому.
Как видно на Рисунке 2, визуальное представление связи - прямая линия между двумя объектами. Если
объект посылает сообщения себе, связь, относящаяся к этим сообщениям, представляется как значок
цикла. Такой цикл имеется у объектов UI и Transaction.
Связи в диаграмме сотрудничества напрямую соотносятся с ассоциациями между классами в диаграмме
класса. Например, Рисунок 3 показывает ассоциацию между объектом Transaction и объектом Fine, как это
видно на диаграмме класса. Под ассоциацией видна соответствующая связь между двумя объектами.
Ассоциация в диаграмме класса преобразуется в связь в диаграмме сотрудничества.
Рисунок 3: Ассоциации, определенные в диаграмме класса, могут быть представлены как связи в
диаграмме сотрудничества.
Если Вы не определили иначе, связь представляет ассоциацию между объектами. Однако чтобы указать,
каким образом ассоциированы объекты, можно определить следующие дополнения для связей:
l global (объект видим как глобальная переменная)
l local (объект видим как локальная переменная)
l parameters (объект видим как параметр)
l self (представляет способность объекта посылать сообщение себе)
3.3 Сообщения
Сообщения в диаграммах сотрудничества изображаются стрелками, ведущими от объекта-клиента к
объекту-поставщику. Как правило, сообщения представляют вызов клиентом операции на объектепоставщике.
Стрелки, обозначающие вызов операции, могут иметь одно или более связанных с ними сообщений.
Сообщение состоит из текста сообщения и предшествующей последовательности чисел, которая
обозначает порядок следования данного сообщения во времени. Например, в диаграмме сотрудничества на
Рисунке 2, чтобы определить порядок сообщений между объектами, можно следовать порядку чисел:
1. Enter Borrower ID
1.1 CalcAmtCanBorrow
1.1.1 <<create>>
1.1.2 CalcBorrowerFines
1.1.3 GetBorrowersCheckedOutMedia
1.1.4 IsMediaOverdue
1.1.5 Amt Can Borrow
1.2 Display Invalid User Msg
Первое сообщение в диаграмме сотрудничества всегда нумеруется 1, второе - 2, и так далее. Можно
указать, что сообщение вложено в родительское сообщение, добавляя десятичную точку и
дополнительные разряды к родительской последовательности чисел. Например, "CalcAmtCanBorrow"
сообщение - первое вложенное сообщение под "Enter Borrower ID" и ему дается последовательный номер
1.1. Второе вложенное сообщение под "Enter Borrower ID" является "Display Invalid User Msg", поэтому
ему присвоен порядковый номер 1.2. Как видно, есть несколько сообщений, вложенных в
"CalcAmtCanBorrow", и они нумеруются от 1.1.1 до 1.1.5.
В диаграммах последовательности каждый значок сообщения представляет отдельное сообщение. В
диаграммах сотрудничества значок сообщения может представлять одно или более сообщений. Например,
взгляните на изображение сообщения на Рисунке 2 между объектами Transaction и Fine. Значок всего один,
однако, имеется два относящихся к нему сообщения (1.1.1 и 1.1.2).
3.4 Повторяющиеся и условные сообщения
Для описания того, что сообщение итерируется (используется много раз) или выполняется условно,
диаграммы сотрудничества используют синтаксис, сходный с синтаксисом диаграмм последовательности
действий.
Чтобы указать, что сообщение повторяется, следует задать перед порядковым номером сообщения
итеративное выражение. Можно просто использовать звездочку (*) для указания того, что сообщение
посылается более чем один раз, или явно задать количество раз повторения сообщения (например, 1.. 5).
Чтобы указать, что сообщение выполняется при условии, можно поставить перед последовательностью
чисел сообщения условный пункт, типа [x = true]. Это указывает, что сообщение будет послано только,
если условие выполнено. UML поддерживает открытым синтаксис условных пунктов, так что можно
свободно создавать выражения в контексте ваших приложений.
4. Создание и удаление объектов
В отличие от диаграмм последовательности, в диаграмме сотрудничества не указывается длительность
существования объекта. Если нужно показать продолжительность жизни объекта в диаграмме
сотрудничества, можно использовать сообщения создания и удаления объекта (create, destroy).
Например, на рисунке 2, есть сообщение 1.1.1 <<create>> перед 1.1.2 - вызовом сообщения к объекту Fine.
Это означает, что объект Transaction создает объект Fine перед вызовом его метода CalcBorrowerFines.
5. Диаграммы сотрудничества против диаграмм последовательности
Рассматривая последовательность сообщений на Рисунке 2, становится понятно, почему временной
порядок сообщений не является сильным звеном диаграмм сотрудничества! В то же время, сообщениям в
диаграммах последовательности не нужно присваивать порядковые номера, потому что порядок
сообщений задается фактическим расположением сообщений сверху книзу в диаграмме.
Следовательно, диаграммы сотрудничества имеют существенное преимущество по отношению к
диаграммам последовательности в том, что позволяют делать более сложное ветвление, а также
осуществлять многократный параллельный контроль. Напротив, формат и характер диаграмм
последовательности позволяют показывать только простое ветвление.
6. Создание диаграммы сотрудничества
Создавая диаграмму сотрудничества, наиболее важные объекты, участвующие во взаимодействии, следует
помещать в середину диаграммы. Это способствует более точному представлению отношений между
взаимодействующими объектами.
При проектировании диаграмм сотрудничества с нуля (в отличие от генерирования их автоматически из
диаграмм последовательности), следует придерживаться такого пошагового порядка:
l Определите область диаграммы. Как с диаграммами последовательности, область диаграммы
сотрудничества может быть делом пользователя.
l Разместите на диаграмме объекты, которые участвуют во взаимодействии. Не забывайте о том, что
наиболее важные объекты следует размещать ближе к центру диаграммы.
l Если
определенный объект имеет свойства или поддерживает состояние, важные для
взаимодействия, установите начальные значения этих свойств или состояния.
l Создайте связи между объектами.
l Создайте сообщения, соответствующие каждой связи.
l Добавьте порядковые номера к каждому сообщению в соответствии с их временным порядком во
взаимодействии.
7. Измененное состояние объектов
Как упомянуто выше, можно дополнять объекты свойствами, задающими начальное состояние объектов, а
также любым изменением в этом состоянии. Однако, если объект значительно изменяется во время
взаимодействия, в диаграмму можно внести новый экземпляр объекта, изображая связь между ними и
добавляя сообщение со стереотипом <<become>>.
Наглядный пример показан на Рисунке 4. Объект Contract имеет в начале состояние “pending”, и, в
конечном счете, переходит в состояние "accepted". Заметьте, что есть порядковый номер,
соответствующий этому сообщению. Если затруднительно применить Rational Rose для простой
демонстрации изменения в состоянии на диаграмме сотрудничества, можно использовать Visual UML, как
было сделано для создания диаграммы на рисунке 4. Visual UML позволяет явно установить состояние
объекта, что не возможно в Rational Rose.
Рисунок 4: Если объект значительно изменяется при взаимодействии, можно ввести новый
экземпляр класса к диаграмме и показать его измененное состояние.
Хотя диаграммы сотрудничества не так часто применяются, как диаграммы последовательности, они
очень полезная часть UML. Если вы постоянно мечетесь между диаграммой последовательности
(динамическим представлением) и соответствующей диаграммой класса (статическим представлением),
пытаясь понять ассоциации между бизнес-объектами, попробуйте вместо этого использовать диаграмму
сотрудничества. Она позволяет на одном листе увидеть как динамические аспекты взаимодействия, так и
взаимоотношения между объектами.
Статью подготовила Татьяна Полякова