Диаграмма объектов,экземпляров (Objectdiagram)

 

Диаграммы объектов показывают множество объектов - экземпляров классов (изображенных на диаграмме классов) и отношений между ними в некоторый момент времени. То есть диаграмма объектов - это своего рода снимок состояния системы в определенный момент времени, показывающий множество объектов, их состояния и отношения между ними в данный момент.Диаграмму объектов можно использовать для отображения одного из вариантов конфигурации объектов.

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

Объект, как и класс, обозначается прямоугольником, но его имя подчеркивается. Под словом имя здесь мы понимаем название объекта и наименование его класса, разделенные двоеточием. Для указания значений атрибутов объекта в его обозначении может быть предусмотрена специальная секция. Еще один нюанс состоит в том, что объект может быть анонимным: это нужно в том случае, если в данный момент не важно, какой именно объект данного класса принимает участие во взаимодействии.

Рис. 2.8.

 

Приведем простейший пример такой диаграммы (рис. 2.9).

 

Рис. 2.9.

 

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

Другой пример (рис. 2.10).

Рис. 2.10.

 

Эта диаграмма тоже понятна в общих чертах даже без дополнительных объяснений. Здесь мы видим взаимосвязь объектов - организационных единиц в некоторой компании.

Диаграмма объектов учебной среды "Робот" для Turbo Pascal, в которой наше поколение школьников училось основам алгоритмизации.

Рис. 2.11.

 

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

 

Диаграммы кооперации,коллаборации, взаимодействия, коммуникации(collaboration diagram)

 

Назначение

Следует отметить, что здесь имеет место некоторая терминологическая путаница. В оригинале такие диаграммы называются Collaboration Diagram. Слово "collaboration", конечно же, синоним слова "cooperation", но в "русском" варианте звучит хуже. Поэтому в русскоязычных учебниках говорят "диаграмма кооперации", а не "коллаборации". Кроме этого, само это название немного устарело - в UML 2.x подобные диаграммы называются Communication Diagram. Впрочем, все три слова - "cooperation", "collaboration" и "communication" - являются синонимами, так что довольно часто используется "старое" название. Часто даже, говоря "диаграммы взаимодействия", подразумевают именно диаграммы кооперации.

Понятие кооперации (collaboration) служит для обозначения множества взаимодействующих с определенной целью объектов (выполняющих заданные роли) в общем контексте моделируемой системы, чтобы показать некую функциональность. Цель самой кооперации состоит в том, чтобы специфицировать (описать свойства объектов и связей) особенности реализации отдельных наиболее значимых операций в системе.

Выступают альтернативой диаграммы последовательности и диаграммы классов.Подобно диаграммам последовательности, диаграммы кооперации отображают поток событий в конкретном сценарии варианта использования, но здесьглавнымявляется показать не сколько последовательность взаимодействия, а все структурные отношения между объектами, участвующими в этом взаимодействии.На диаграмме кооперации последовательность взаимодействий и параллельных потоков определяется с помощью порядковых номеров их сообщений.В отличие от диаграммы классов не требуется указывать все свойства взаимодействующих объектов. Указываются только нужны для данной кооперации.

Кооперация часто реализует некоторый паттерн (шаблон проектирования).Таким образом, с помощью диаграммы кооперации можно описать полный контекст взаимодействий как своеобразный временной «срез» совокупности объектов, взаимодействующих между собой для выполнения определенной задачи или бизнес-цели программной системы.

 

Уровни диаграммы

Кооперация может быть представлена на двух уровнях:

· На уровне спецификации (Specification-Level) – показывает роли, которые играют участвующие во взаимодействии элементы (классы и ассоциации).

· На уровне экземпляров (Instance-Level) – указывает объекты (экземпляры классов) и связи(экземпляры ассоциаций), образующие отдельные роли в кооперации.При этом связи дополняются стрелками сообщений. На данном уровне показываются только релевантные объекты, т. е. имеющие непосредственное отношение к реализации операции или классификатора. Определяются свойства, которые должны иметь экземпляры для того, чтобы участвовать в кооперации. При этом вовсе не обязательно изображать все свойства или все ассоциации, поскольку на диаграмме кооперации присутствуют только роли,а не сами классы. Таким образом, в то время как класс требует полного описания, роль требует описания только тех свойств и ассоциаций, которые необходимы для участия в отдельной кооперации.Именно это отличает диаграмму кооперации от диаграммы классов, где должны быть указаны все свойства класса и все ассоциации.

 

Элементы

 

Объекты (классы)

Прежде всего, на диаграмме кооперации в виде прямоугольников изображаются участвующие во взаимодействии объекты или классы. Простой класс на диаграмме кооперации обозначается прямоугольником класса, внутри которого записывается строка текста. Эта строка текста называется ролью классификатора (classifier role). Роль классификатора показывает особенность использования объектов данного класса. Обычно в прямоугольнике показывается только секция имени класса, хотя не исключается возможность указания секций атрибутов и операций (подробней смотреть в диаграммах последовательности, они одинаковые).

В контексте языка UML все объекты делятся на две категории: пассивные и активные. Пассивный объект оперирует только данными и не может инициировать деятельность по управлению другими объектами. В тоже время пассивные объекты могут посылать сигналы в процессе выполнения запросов, которые они получают. Активный объект имеет свою собственную нить управления и может инициировать деятельность по управлению другими объектами. При этом под нитью понимается поток управления, который может выполняться параллельно с другими вычислительными нитями или нитями управления в пределах одного вычислительного процесса. На диаграмме обводиться толстой рамкой.

В приведенном фрагменте диаграммы кооперации (рис. 38) активный объект “а: Вызывающий абонент” является инициатором процесса установления соединения для обмена информацией с другим абонентом.

 

Рис. 38. Активный объект (слева) на диаграмме кооперации

 

Дополнительно к обычным объектам существует мультиобъект (multiobject) – представляет собой целое множество объектов на одном из концов ассоциации (рис. 37, а). На диаграмме кооперации мультиобъект используется чтобы показать операции и сигналы, адресованные всему множеству объектов, а не только одному. При этом стрелка сообщения относится ко всему множеству объектов, которые обозначают данный мультиобъект. На диаграмме кооперации может быть явно указано отношение композиции между мультиобъектом и отдельным объектом из его множества (рис. 37, б).

 

Рис. 37. Графическое изображение мультиобъектов на диаграмме кооперации

 

В следующем примере рассматривается ситуация с вызовом функции печати из текстового редактора (рис. 39). Анонимный активный объект класса текстовый редактор вначале посылает сообщение анонимному мультиобъекту класса принтер. Это сообщение инициирует выбор единственного объекта класса принтер, возможно, удовлетворяющего некоторым дополнительным условиям. После этого выбранному объекту посылается сообщение о необходимости напечатать документ, загруженный в текстовый редактор.

 

Рис. 39. Фрагмент диаграммы кооперации для вызова функции печати из текстового редактора

 

Составной объект (composite object) или объект-контейнер предназначен для представления объекта, имеющего собственную структуру и внутренние потоки (нити) управления. Составной объект является экземпляром составного класса (класса-контейнера), который связан отношением агрегации или композиции со своими частями. Аналогичные отношения связывают между собой и соответствующие объекты. Это пример использования паттерна фасад.

На диаграммах кооперации составной объект состоит из двух секций: верхней и нижней. В верхней секции записывается имя составного объекта, а в нижней – его элементы (рис. 40), которые могут быть составными объектами.

 

Рис. 40. Составной объект на диаграмме кооперации

 

Интерфейс. Интерфейс (interface) в контексте языка UML является специальным случаем класса, у которого имеются только операции и отсутствуют атрибуты. Для обозначения интерфейса используется специальный графический символ окружность или стандартный способ - прямоугольник класса со стереотипом <<interface>> (рис. 44)

Рис. 44. Примеры графического изображения интерфейсов на диаграмме классов

 

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

 

 

Кооперации

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

Рис. 9.1. Общее представление кооперации на диаграммах уровня спецификации

 

Если кооперация допускает обобщенное представление, то на диаграммах могут быть указаны отношения обобщения соответствующих элементов. Этот способ может быть использован для определения отдельных коопераций, которые являются, в свою очередь, частным случаем или специализацией другой кооперации. Такая ситуация изображается обычной стрелкой обобщения, направленной от символа дочерней кооперации к символу кооперации-предка (рис. 9.2). При этом роли дочерних коопераций могут быть специализациями ролей коопераций-предков.

Рис. 9.2. Графическое изображение отношения обобщения между отдельными кооперациями уровня спецификации

 

В отдельных случаях возникает необходимость явно указать тот факт, что кооперация является реализацией некоторой операции или классификатора. Это можно представить одним из двух способов.

Во-первых, можно соединить символ кооперации пунктирной линией со стрелкой обобщения с символом класса, реализацию операции которого специфицирует данная кооперация (рис. 9.3, а). Так, если в качестве класса рассмотреть «Заказ на покупку товара», у которого имеется операция "оформить_заказ (), то ее реализация может быть специфицирована в форме кооперации.

Рис. 9.3. Способы представления кооперации, которая реализует операцию класса

 

Во-вторых, можно просто изобразить символ кооперации, внутри которого указать всю необходимую информацию, записанную по определенным правилам (рис. 9.3, б). Эти правила определяют формат записи имени кооперации, после которого записывают двоеточие и имя класса. За именем класса следует двойное двоеточие и имя операции.

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

 

 

Связи

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

Связь (link) является экземпляром или примером произвольной ассоциации. Связь как элемент языка UML может иметь место между двумя и более объектами. Связь на диаграмме кооперации изображается отрезком прямой линии, соединяющей два прямоугольника объектов, стрелка отсутствует. На каждом из концов этой линии могут быть явно указаны имена ролей данной ассоциации. Рядом с линией в ее средней части может записываться имя соответствующей ассоциации. Связи не имеют собственных имен, поскольку полностью идентичны как экземпляры ассоциации. Для связей не указывается также и кратность.

Связь обеспечивает канал для направленной передачи сообщений между объектами от объекта-источника к объекту-получателю.

Стереотипы связей. Связь может иметь некоторый стереотип, который записывается рядом с одним из её концов и указывает на особенность реализации данной связи. В языке UML для этой цели могут использоваться следующие стереотипы:

• «association» — связь-ассоциация – показывает, что элементы взаимодействуют друг с другом. Предполагается по умолчанию, поэтому этот стереотип можно не указывать.
• «parameter» — параметр операции или метода. Соответствующий объект может быть только параметром некоторой операции.
• «local» — локальная переменная. Её область видимости ограничена только соседним объектом.
• «global» — глобальная переменная. Её область видимости распространяется на всю диаграмму кооперации.
• «self» — рефлексивная связь объекта с самим собой, которая допускает передачу объектом сообщения самому себе. Изображается петлёй в верхней части прямоугольника объекта.

Некоторые примеры связей с различными стереотипами изображены на рис. 41. Здесь представлена обобщенная схема некоторой конкретной компании с именем с, которая состоит из отделов (анонимный мультиобъект класса отдел). Последние, в свою очередь, состоят из сотрудников (анонимный мультиобъект класса сотрудник). Рефлексивная связь указывает на тот факт, что менеджер отдела является в то же время и его сотрудником.

Рис. 41. Графическое изображение связей с различными стереотипами

Сообщения.

Сообщение (message) на диаграмме кооперации специфицирует коммуникацию между двумя объектами, один из которых передаёт другому некоторую информацию. При этом первый объект предполагает, что после получения сообщения вторым объектом последует выполнение некоторого действия. Таким образом, сообщение является причиной или стимулом для начала выполнения операций, отправки сигналов, создания и уничтожения отдельных объектов. Сообщение представляет собой законченный фрагмент информации, содержащей например параметры для операции, которую нужно выполнить.

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

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

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

 

Рис. 42. Графическое изображение различных типов сообщений на диаграмме кооперации

 

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

· Сплошная линия с V-образной стрелкой (рис. 42, б) обозначает простой поток управления. Каждая такая стрелка изображает один этап в последовательности потока управления. Обычно все такие сообщения являются асинхронными.

· Сплошная линия с полустрелкой (рис. 42, в) используется для обозначения асинхронного потока управления. Соответствующие сообщения формируются в произвольные, заранее не известные моменты времени, как правило, активными объектами. Обычно сообщения этого типа являются начальными в последовательности потока управления и чаще всего инициируются актерами.

· Пунктирная линия с V-образной стрелкой (рис. 42, г) обозначает возврат из вызова процедуры. Стрелки этого типа зачастую отсутствуют на диаграммах кооперации, поскольку неявно предполагается их автоматическое создание после окончания некоторой деятельности.

Формат записи сообщений. Каждое сообщение имеет номер, который показывает его очередь выполнения, после которого ставиться двоеточие и следует имя сообщения, поясняющее, какая информация передаётся. Номер может состоять из нескольких частей разделённых точкой (см. ниже выражение последовательности). Данная информация обычно записывается в треугольных скобках. Например:

< 2.3: отобразить сообщение>

Каждое сообщение может быть дополнительно помечено строкой текста, которая имеет следующий формат:

· <Предшествующие сообщения> – есть разделенные запятыми номера сообщений, записанные перед наклонной черточкой, после наклонной идёт именование текущего сообщения – номер и название:

<Номер сообщения,>< Номер сообщения,> /

Если список номеров сообщений пуст, то вся запись, включая наклонную черточку (слэш), опускается. Выражение должно определять номер другого сообщения в этой же последовательности. Смысл указания предшествующих сообщений заключается в том, что данное сообщение не может быть передано, пока не будут переданы своим адресатам все сообщения, номера которых записаны в данном списке. Пример записи предшествующих сообщений: <1, 4/ 5: ошибка записи (сектор)>.

· < [Сторожевое условие] > является обычным булевским выражением и предназначено для синхронизации отдельных нитей потока управления. Записывается в квадратных скобках и может быть опущено, если оно отсутствует у данного сообщения. Семантика сторожевого условия обеспечивает передачу сообщения только в том случае, если это условие принимает значение «истина».Пример записи сторожевых условий:

[(х>=0)&(х<=255)] 2: отобразить_на_экране_цвет(х)

[количество цифр номера = 7] 1: набрать_телефонный_номер()

· < Выражение последовательности > – есть разделенный точками список отдельных термов последовательностей, после которого записывается двоеточие:

<Терм последовательности.><Терм последовательности.>:

Каждый из термов представляет отдельный уровень процедурной вложенности в форме законченной итерации. Наиболее верхний уровень соответствует самому левому терму последовательности. Если все потоки управления параллельные, то вложенность отсутствует. Каждый из термов последовательности имеет следующий синтаксис:

[Целое число| Имя] [Символ рекуррентности].

Целое число указывает на порядковый номер сообщения в процедурной последовательности верхнего уровня. Сообщения, номера которых отличаются на единицу, следуют подряд один за другим.Например, сообщение с номером «3.1.4» следует за сообщением с номером «3.1.3» в процедурной последовательности «3.1».Имя используется для спецификации параллельных нитей управления. Сообщения, которые отличаются только именем, являются параллельными на этом уровне вложенности. На одном уровне вложенности все нити управления эквивалентны в смысле приоритета передачи сообщений.

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

1. *[ Предложение-итерация ] для записи итеративного выполнения соответствующего выражения.Итерация представляет последовательность сообщений одного уровня вложенности. Предложение-итерация может быть опущено, если условия итерации никак не специфицируются. Наиболее часто предложение-итерация записывается на некотором псевдокоде или языке программирования. В языке UML формат записи этого предложения не определен. Например, <*[i:=1..n]: НаборЦифры(i)>, что означает последовательную передачу сообщения с параметром i, который изменяется от 1 до некоторого целого числа n с шагом 1.

2. [Предложение-условие ] для записи ветвления. Это условие представляет такое сообщение, передача которого по данной ветви возможна только при истинности этого условия. Чаще всего предложение-условие записывают на некотором псевдокоде или языке программирования, поскольку в языке UML формат записи этого предложения не определен. Например, [х>у] означает, что сообщение по некоторой ветви будет передано только в том случае, если значение х больше значения у.

· < Возвращаемое значение > - Возвращаемое значение представляется в форме списка имен значений, возвращаемых по окончании коммуникации или взаимодействия в полной итерации данной процедурной последовательности. Эти идентификаторы могут выступать в качестве аргументов в последующих сообщениях. Если сообщение не возвращает никакого значения, то ни значение, ни оператор присваивания на диаграмме кооперации не указываются.Например, сообщение

1.2.3: р:= найти_документ (спецификация_документа)

означает передачу вложенного сообщения с запросом поиска в базе данных нужного документа по его спецификации, причем источнику сообщения должен быть возвращен найденный документ.Имя сообщения, записанное в сигнатуре после возвращаемого значения, означает имя события, которое инициируется объектом-получателем сообщения после его приема. Наиболее часто таким событием является вызов операции объекта. Это может быть реализовано различными способами, один из которых – вызов операции. Тогда соответствующая операция должна быть определена в том классе, которому принадлежит объект-получатель.

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

1.2.3: р:= найти_документ (спецификация_документа)

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

 

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

· «call» (вызвать) — сообщение, требующее вызова операции или процедуры объекта-получателя. Если сообщение с этим стереотипом рефлексивное, то оно инициирует локальный вызов операции у самого пославшего это сообщение объекта;

· «return» (возвратить) — сообщение, возвращающее значение выполненной операции или процедуры вызвавшему ее объекту. Значение результата может инициировать ветвление потока управления;

· «create» (создать) — сообщение, требующее создания другого объекта для выполнения определенных действий. Созданный объект может стать активным (ему передается поток управления), а может остаться пассивным;

· «destroy» (уничтожить) — сообщение с явным требованием уничтожить соответствующий объект. Посылается в том случае, когда необходимо прекратить нежелательные действия со стороны существующего в системе объекта либо когда объект больше не нужен и должен освободить задействованные им системные ресурсы;

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

 

 

Примеры

 

В качестве примера рассмотрим построение диаграммы кооперации для моделирования процесса телефонного разговора с использованием обычной телефонной сети (см. главу ф. Напомним, что объектами в этом примере являются два абонента а и b, два телефонных аппарата с и коммутатор и сам разговор как объект моделирования. При этом как коммутатор, так и разговор являются анонимными объектами.

На начальном этапе изобразим все объекты и связи между ними на диаграмме кооперации при помощи соответствующих обозначений (рис. 9.11). Заметим, что первый телефонный аппарат изображен как активный объект, а второй – как пассивный.

Рис. 9.11. Начальный фрагмент диаграммы кооперации для примера моделирования обычного телефонного разговора

В последующем необходимо специфицировать все связи на этой диаграмме, указав на их концах необходимую информацию в форме ролей связей. Дополненный таким образом вариант диаграммы кооперации изображен ниже (рис. 9.12). Заметим, что для объекта «Разговор» указано помеченное значение {transient}, которое означает, что этот объект создается в процессе выполнения объемлющего процесса и уничтожается до его завершения. Напомним, что помеченные значения (tagged values) являются стандартными элементами языка UML.

 

При разработке диаграмм кооперации вначале изображаются объекты и связи между ними. Далее на диаграмму кооперации уровня примеров необходимо нанести все сообщения, указав их порядок и другие семантические особенности. Окончательный фрагмент диаграммы кооперации модели телефонного разговора изображен на рис. 43. Заметим, что для объекта класса коммутатор указано стандартное помеченное значение {persistent}, которое означает, что этот объект создается (существует) в момент начала выполнения основного процесса и уничтожается вместе с ним. Для объекта класса Разговор указано стандартное ограничение {transient}, которое означает, что этот объект создается в ходе выполнения основного процесса и уничтожается до его завершения. Напомним, что помеченные значения и ограничения являются стандартными элементами механизма расширения языка UML.

Рис. 43. Диаграмма кооперации для представления модели телефонного разговора

 

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

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

 

На рис. 49 приведена кооперативная диаграмма, описывающая систему управления банкоматом.

Рис. 49. Диаграмма кооперации системы управления банкоматом

 

Данная диаграмма уровня примеров содержит 5 объектов, два из которых представлены в форме активных объектов, а три — в форме пассивных. При этом все объекты диаграммы являются анонимными. В качестве имен сообщений указаны имена операций, которые специфицированы у соответствующих классов. Предложения-условия сообщений с номерами 3, 6 и 8 записаны на обычном тексте. Эти условия отражают возможность ветвления процесса снятия наличных по кредитной карточке и выполнения исключений сценария соответствующего варианта использования.

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