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

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

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

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

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

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

Не все действия связаны с передачей информации и отправкой сообщений. В UML таковыми считаются:

• вызов операции;

• создание объекта;

• уничтожение объекта;

• возврат значения;

• посылка сигнала.

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

переменные:= ИМЯ (аргументы)

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

Поскольку получение сообщения является событием, то получатель сообщения вместе с информацией получает и управление (для того, чтобы иметь возможность выполнить действия, инициируемые полученным сообщением). В UML различается несколько типов тип передачи управления с помощью сообщения. Чтобы отличить тип передачи сообщения, в UML применяется специальная графическая нотация, а именно, различаются виды стрелок, которыми обозначаются сообщения. Хотя на диаграммах кооперации и последовательности сообщения обозначаются различным образом, принципы изображения одинаковы и перечислены в табл. 13.

Таблица 13. Типы передачи сообщений

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

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

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

• На диаграмме последовательности порядок сообщений определяется временем их отправки, а время считается текущим на диаграмме сверху вниз. Таким образом, сообщения, изображенные выше, предшествуют сообщениям, изображенным ниже.^[19]

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

• Наконец, порядок можно указать, перечислив (через запятую) номера сообщений, предшествующих данному.

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

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

предшественники / повторность номер: переменные:= ИМЯ (аргументы)

На рисунке 4.35 приведена метамодель сообщений.

Рисунок 4.35. Метамодель сообщений

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

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

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

• Состав сообщений (а тем самым операций и сигналов) определяется назначением данного взаимодействия; в других взаимодействиях эти же объекты могут обмениваться другими сообщениями.

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

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

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

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

В направлении оси времени от всех участвующих во взаимодействии объектов отходит прямая пунктирная линия, которая называется линией жизни. Линия жизни представляет объект во взаимодействии: если стрелка отходит от линии жизни объекта, то это означает, что данный объект отправляет сообщение, а если стрелка сообщения входит в линию жизни, то это означает, что данный объект получает сообщение. Если же стрелка пересекает линию жизни объекта, то это ничего не значит — сообщение пролетело мимо.^[20] Если в процессе взаимодействия объект заканчивает свое существование, то линия жизни обрывается и в этом месте ставится жирный косой крест.

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

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

Рисунок 4.36. Диаграмма последовательности

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

Метка времени — это именованная точка на оси времени.

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

Рисунок 4.37. Метки времени и задержанная доставка сообщения

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

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

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

Рисунок 4.38. Активации и возвраты

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

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

Рассмотрим пример (он получился немного искусственным и был создан вопреки возможностям используемого инструмента — все-таки диаграммы состояний больше приспособлены для показа протоколов чисто линейных программ). Допустим, мы хотим отобразить два сценария создания подразделения: "под начальника" и исходя из потребностей организации. В обоих случаях при создании подразделения создается должность начальника, но в первом случае она немедленно заполняется имеющимся "нужным" человеком (операция occupy), а во втором объявляется вакантной (операция setVacant). Чтобы не перегружать диаграмму, мы включили описание только части взаимодействия, а именно, часть, соответствующую выполнению операции createDpt класса Company (Рисунок 4.39).

Рисунок 4.39. Сообщения со сторожевыми условиями и альтернативные линии жизни

Графических ухищрений на диаграмме кооперации^[21] значительно меньше — данный тип диаграмм графически очень лаконичен и, тем не менее, чрезвычайно выразителен. Поэтому при рассмотрении элементов диаграмм кооперации мы больше внимания уделяем семантике, оставляя самоочевидную нотацию для примеров. В частности, описания некоторых семантических тонкостей, относящиеся также и к диаграммам последовательности и опущенные в двух предыдущих разделах, здесь восполнены. Для начала мы остановимся на трех важных семантических понятиях, присущих диаграммам кооперации, которые не имеют броского графического выражения, но являются важным аспектом прагматики диаграмм взаимодействия и могут быть просто не замечены и пропущены читателем, если он знакомится с языком, глядя только на картинки. Поскольку данные понятия относятся к сфере семантики и прагматики, с ними не связано громких ключевых слов и броских графических символов, а потому возникает терминологическая путаница, особенно в русских переводах. Читателю не следует пугаться необычных слов в следующих абзацах. Итак, первые три понятия этого раздела:

• роль классификатора;

• роль ассоциации;

• контекст взаимодействия.

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

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

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

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

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

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

Номер сообщения определяется в соответствии с положением сообщения в последовательности сообщений данного взаимодействия. Если во взаимодействии используются только простые или асинхронные сообщения, то сообщения просто нумеруются, обычно подряд: 1, 2, 3 и т. д. Сообщения с меньшими номерами предшествуют сообщениям с большими номерами. Если же используются вложенные потоки управления, т. е. сообщения типа вызова операции, то сообщения нумеруются более сложным образом. Допустим сообщение вызова операции имеет номер х. Тогда сообщения, отправляемые при выполнении этой операции будут иметь номера х.1, х.2 х.3 и т. д. Первое сообщение, отправляемое при выполнении вызова х.1 будет иметь номер х.1.1 и т. д. Количество точек в номер соответствует уровню вложенности потока управления, т. е. глубине стека вызовов. Таким образом, например, сообщение с номером 1.2 предшествует сообщению с номером 1.2.3, а сообщение 2.1, напротив, следует за сообщением 1.2.3. Если первым во взаимодействии является сообщение вызова, то его номер часто не указывают (такое сообщение как бы имеет неявный номер 0), чтобы не загромождать диаграмму повторяющимся всюду номером первого сообщения и ненужной точкой.

Такая иерархическая десятичная нумерация удобна, поскольку задает относительный порядок сообщений на данном уровне вложенности вызовов и позволяет описывать взаимодействие с нужной степенью детальности. Например, если требуется раскрыть детали выполнения операции, вызванной сообщением с номером х, т. е. показать, какие сообщения отправляются в процессе выполнения данной операции, то достаточно добавить на диаграмму сообщения с номерами x.1, x.2 и т. д. (а также соответствующие целевые объекты — роли классификаторов). Если же детали не нужны на данной диаграмме, то сообщения можно удалить, при этом номера других сообщений не меняются. Другими словами, в последовательности сообщений, образующей взаимодействие, можно показывать больше или меньше элементов, и при этом перенумерации элементов не требуется. На диаграмме последовательности время жизни объекта относительно данного взаимодействия показывается графически, с помощью смещения вниз символа объекта, создаваемого в процессе взаимодействия и с помощью символа уничтожения объекта (косой крест) на линии жизни уничтожаемого объекта. На диаграмме кооперации для этой цели используются специальные ключевые слова, которые указываются для ролей классификаторов в форме стандартных стереотипов и/или в форме стандартных ограничений для сообщений (табл. 14).

Таблица 14. Ключевые слова для описания времени жизни объектов во взаимодействии на диаграмме кооперации

Ключевое слово	Способ использования	Описание
create	стереотип операции в сообщении	Операция создает объект, т. е. данное сообщение является вызовом конструктора
destroy	стереотип операции в сообщении	Операция уничтожает объект, т. е. данное сообщение является вызовом деструктора
destroyed	ограничение роли классификатора	Объект уничтожается в процессе описываемого взаимодействия
New	ограничение роли классификатора	Объект создается в процессе описываемого взаимодействия
transient	ограничение роли классификатора	Объект создается и уничтожается в процессе описываемого взаимодействия. Такой объект называется временным. Данное ограничение эквивалентно одновременному указанию ограничений new и destroyed

Рассмотрим пример из информационной системы отдела кадров, уже разобранный нами на рисунке 4.36. Рисунок 4.40 семантически эквивалентен рисунку 4.36 — эти диаграммы описывают одно и то же взаимодействие и поведение.

Рисунок 4.40. Диаграмма кооперации

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

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

Таблица 15. Стереотипы полюса роли ассоциации на диаграмме кооперации

Стереотип	Описание
«association»	Объект на полюсе роли ассоциации связан с объектом на противоположном полюсе фактической связью, реализующей ассоциацию
«global»	Объект на полюсе роли ассоциации имеет глобальную область определения относительно объекта на противоположном полюсе
«local»	Объект на полюсе роли ассоциации имеет локальную область определения относительно объекта на противоположном полюсе, т. е. является временным объектом для выполнения операции
«parameter»	Объект на полюсе роли ассоциации является параметром операции объекта на противоположном полюсе
«self»	Роль ассоциации является фиктивной связью, введенной для моделирования вызова операции данного объекта

Рассмотрим в качестве примера реализацию операции рисования многоугольника. Подробно прокомментируем обозначения на рисунке 4.41, чтобы объяснить все детали нотации на диаграмме сообщений. Взаимодействие, описывающее поведение операции, инициируется сообщением draw. Для этого сообщения номер не задан (обычная для UML практика опускания очевидных вещей), а посылающий сообщение объект изображен в виде анонимного действующего лица, символизирующего источник вызова операции. Для выполнения операции draw вызывает операция drawSegment (n-1 раз, где n — количество вершин многоугольника). Соответствующее сообщение (оно имеет номер 1) нагружено на связь со стереотипом «self», которая не является реальным экземпляром ассоциации, а введена в модель только для того, чтобы послать сообщение объекту из операции этого же объекта. При каждом вызове операции drawSegment определяются две вершины, которые являются началом и концом стороны многоугольника. При этом в модели не показаны никакие сообщения: подразумевается, что нужную информацию можно получить, указывая значение квалификатора (i и i +1, соответственно). После этого с помощью сообщения с номером 1.1 создается временный объект line и затем вызывается его операция draw (сообщение с номером 1.2). То обстоятельство, что объект line временный (существует только на время выполнения операции drawSegment), указывать с помощью стандартного ограничения transient не обязательно: достаточно стереотипа «local», указанного для имени полюса роли ассоциации segment.

Рисунок 4.41. Структурные связи и стереотипы полюса роли ассоциации на диаграмме кооперации

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

• «become» — зависимость с данным стереотипом проводится от объекта в исходном состоянии к тому же самому объекту, но в измененном состоянии. Имя состояния, как обычно, указывают в квадратных скобках.

• «copy» — данный стереотип означает, что создается новый объект — копия исходного. После создания копия объекта существует как новый независимый объект.

Рассмотрим еще раз пример из информационной системы отдела кадров, относящийся к созданию подразделения. Допустим, что кадровая политика организации требует немедленного назначения начальника при создании подразделения (что вполне разумно, по нашему мнению). В терминах нашей модели это означает, что при создании новый объект boss класса Position находится в состоянии vacant, но ему сразу же посылается сообщение occupy, в результате чего объект boss переходит в состоянии occupied. Описание данного взаимодействия может быть представлено диаграммой на рисунке 4.42 (полезно сопоставить эту диаграмму с диаграммой на рисунке 4.38). Иногда для зависимости указывают номер (как у сообщения), чтобы показать, при выполнении какой именно операции происходит изменение состояния объекта.^[22]

Рисунок 4.42. Использование зависимости на диаграмме кооперации