Анализ возможностей организации 6 страница

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

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

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

 

3.4.4. ОПЕРАЦИИ

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

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

<признак-видимости> <имя> (<список-параметров>): <тип-выражения-возвращающего-значение> {<строка-свойств>}

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

строка-свойств показывает значения свойств, которые применяются к данной операции.

Пример записи операции: кредитныйРейтинг(): Строка.

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

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

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

 

3.4.5. ОБОБЩЕНИЕ

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

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

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

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

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

 

3.4.6. ОГРАНИЧЕНИЯ

При построении диаграмм классов на них отображаются различные ограничения.

На рис. 3.3 показано, что Заказ может быть сделан одним-единственным Клиентом. Диаграмма также подразумевает, что каждая Позиция Заказа рассматривается отдельно: можно заказать 40 коричневых штук, 40 голубых штук и 40 красных штук, а не 40 коричневых, голубых и красных штук. Далее, диаграмма говорит, что Корпоративный клиент располагает кредитным лимитом, а Частный клиент — нет.

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

 

3.4.7. БОЛЕЕ СЛОЖНЫЕ ПОНЯТИЯ

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

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

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

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

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

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

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

Множественная и динамическая классификация.Понятие "классификация" касается связи между объектом и его типом.

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

Отметим, что множественная классификация отличается от множественного наследования. При множественном наследовании тип может иметь много супертипов, но для каждого объекта должен быть

определен только один тип. Множественная классификация допускает принадлежность объекта многим типам без определения для этих целей какого-либо специального типа.

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

Если используется множественная классификация, то необходимо четко определить, какие сочетания являются допустимыми. Это делается с помощью дискриминатора, который помечает ассоциацию-обобщение и характеризует сущность подтипов. Несколько подтипов могут характеризоваться одним и тем же дискриминатором. Все подтипы с одним и тем же дискриминатором являются непересекающимися. Это означает, что любой экземпляр супертипа может быть экземпляром только одного из подтипов, описываемых данным дискриминатором. Удачный способ изобразить такое обобщение графически — это свести ассоциации всех подклассов к одной треугольной стрелке с одним дискриминатором, как показано на рис. 3.4. Альтернативный способ изобразить несколько стрелок с одинаковыми текстовыми метками.

Рис. 3.4.Множественная классификация

 

Дискриминатор может быть помечен как {полный} (что является дополнительным ограничением). Это означает, что любой экземпляр суперкласса должен быть экземпляром одного из подклассов в данной группе. (Суперкласс в этом случае является абстрактным.)

В качестве иллюстрации отметим следующие допустимые сочетания подтипов на диаграмме: (Женщина, Пациент, Медсестра); (Мужчина, Физиотерапевт); (Женщина, Пациент) и (Женщина, Доктор, Хирург). Отметим также, что такие сочетания, как (Пациент, Доктор) и (Мужчина, Доктор, Медсестра), являются недопустимыми: первое не включает типа, определенного {полным} дискриминатором "Пол", а второе включает сразу два типа, определенных одним и тем же дискриминатором "Роль". Однозначной классификации соответствует (по определению) единственный, непомеченный дискриминатор.

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

Динамическая классификация допускает изменение типа объектов в рамках структуры подтипов, а статическая классификация этого не допускает. Статическая классификация проводит границу между типами и состояниями, а динамическая классификация объединяет эти понятия.

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

Рис. 3.5. Динамическая классификация

 

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

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

Такое каскадное удаление нередко рассматривается как часть определения агрегации, однако оно всегда подразумевается в том случае, когда множественность роли составляет 1..1; например, если необходимо удалить Клиента, то это удаление должно распространиться и на Заказы (и, в свою очередь, на Строки заказа).

На рис. 3.6 показаны примеры агрегации и композиции. Согласно данной диаграмме Многоугольник состоит из упорядоченной совокупности Вершин. Эти Вершины могут изменяться при изменении Многоугольника, вследствие чего применяется агрегация. Композиция применяется для связи между Многоугольником и Графическим объектом.

Рис. 3.6. Агрегация и композиция

 

Графический объект содержит такие атрибуты, как цвет и текстура. Он рассматривается отдельно от Многоугольника, поскольку многие графические элементы могут использовать такой набор атрибутов. Связь между Многоугольником и Графическим объектом определяется как композиция. Таким образом, показывается, что данный Графический объект создается и уничтожается вместе с данным Многоугольником и не может быть изменен. Разумеется, можно изменить атрибуты Графического объекта, но невозможно заменить один Графический объект другим.

Класс ассоциаций. Он позволяет определять для ассоциаций атрибуты, операции и другие свойства, как это показано на рис. 3.7.

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

 

Рис.3.7. Класс ассоциаций

 

Это можно сделать, дополнив ассоциацию атрибутом типа "интервал Времени". Можно включить этот атрибут в класс Личность, однако на самом деле он характеризует не Личность, а ее связь с Компанией, которая будет меняться при смене работодателя.

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

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

Рис. 3.8.Преобразование класса ассоциаций в обычный класс

 

3.4.8. МЕХАНИЗМ ПАКЕТОВ

Один из подходов к решению проблемы сложности систем ПО, о которой говорилось в начале главы 2, заключается в группировке классов в компоненты более высокого уровня. Эта идея проявляется во многих объектно-ориентированных методах. В UML такой способ группировки носит название механизма пакетов (package).

Механизм пакетов применим к любым элементам модели, а не только к классам. Если для группировки классов не использовать некоторые эвристики, то она становится весьма произвольной. Одна из них, которая в основном используется в UML, — это зависимость. Таким образом, диаграмма пакетов представляет собой диаграмму, содержащую пакеты классов и зависимости между ними. Строго говоря, пакеты и зависимости являются элементами диаграммы классов, т. е. диаграмма пакетов — это всего лишь форма диаграммы классов.

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

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

На рис. 3.9 показаны классы предметной области, сгруппированные в два пакета: Заказы и Клиенты. Оба пакета, в свою очередь, являются частью общего пакета предметной области. Приложение Сбора Заказов имеет зависимости с обоими пакетами предметной области. Пользовательский интерфейс Сбора Заказов имеет зависимости с Приложением Сбора Заказов и AWT (средством разработки графического интерфейса пользователя (GUI) в языке Java).

 

Рис. 3.9.Диаграмма пакетов

 

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

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

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

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

Если показывается содержимое пакета, то имя пакета помещается в "этикетку", а содержимое — внутрь основного прямоугольника. Это содержимое может быть перечнем классов (как в пакете Общий), другой диаграммой пакетов (как в пакете Предметная область) или диаграммой классов (этот вариант не показан, однако идея вполне очевидна).

В большинстве случаев достаточно перечисления основных классов, однако иногда дополнительная диаграмма оказывается полезной. В данном случае (см. рис. 3.10) показано, что, в то время как Приложение Сбора Заказов связано зависимостью со всем пакетом Предметная область, Приложение Списка Рассылки зависит только от пакета Клиенты.

На рис. 3.10 имеется пакет Общий, помеченный как {глобальный}. Это означает, что все пакеты в системе связаны зависимостью с данным пакетом. Разумеется, такую конструкцию следует применять очень расчетливо, однако общие классы (такие, как Деньги) используются во всей системе.

Рис. 3.10.Усовершенствованная диаграмма пакетов

 

По отношению к пакетам можно использовать механизм обобщения. Это означает, что конкретный пакет должен соответствовать интерфейсу общего пакета. Такое определение можно сравнить с аспектом спецификации относительно механизма подклассов в диаграммах классов. Следовательно, в соответствии с рис. 3.10 Интерфейс Базы данных может использовать либо Интерфейс Oracle, либо Интерфейс Sybase. Когда обобщение применяется таким образом, общий пакет может быть помечен как {абстрактный}, чтобы показать, что он всего лишь определяет интерфейс, реализуемый конкретным пакетом.

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

Механизм обобщения позволяет поместить необходимый интерфейс триггера (различные операции загрузки и сохранения) в пакет интерфейса с базой данных. Эти операции впоследствии реализуются классами в рамках пакетов-подтипов. Нам не нужна какая-либо I зависимость между пакетом интерфейса с базой данных и пакетом интерфейса с Oracle, поскольку во время выполнения и так будет вызываться именно тот пакет-подтип, который необходим. При этом пакет Предметная область имеет дело только с простым пакетом интерфейса с базой данных. В существующей системе зависимости могут быть выведены на основании анализа классов. Эта задача является крайне полезной для реализации с помощью любого инструментального средства. В качестве самого первого шага желательно разделить классы на пакеты и проанализировать зависимости между пакетами. Затем следует уменьшить количество зависимостей. Пакеты являются жизненно необходимым средством для больших проектов. Их следует использовать в тех случаях, когда диаграмма классов, охватывающая всю систему в целом и размещенная на единственном листе бумаги формата А4, становится нечитаемой.

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

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

 

3.5. ДИАГРАММЫ ВЗАИМОДЕЙСТВИЯ

Диаграммы взаимодействия (interaction diagrams) являются моделями, описывающими поведение взаимодействующих групп объектов.

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

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

· Окно Ввода Заказа посылает Заказу сообщение "приготовиться".

· Заказ посылает данное сообщение каждой Строке заказа в данном Заказе.

· Каждая Строка заказа проверяет состояние определенного Запаса товара:

Если данная проверка удовлетворяется (результат — true), то Строка заказа удаляет соответствующее количество товара из Запаса.

В противном случае количество Запаса снижается до уровня повторного заказа, и Запас запрашивает новую поставку товара.

Существуют два вида диаграмм взаимодействия: диаграммы последовательности (sequence diagrams) и кооперативные диаграммы (collaboration diagrams).

 

3.5.1

ДИАГРАММЫ ПОСЛЕДОВАТЕЛЬНОСТИ

На диаграмме последовательности объект изображается в виде прямоугольника на вершине пунктирной вертикальной линии (рис. 3.11).

Эта вертикальная линия называется линией жизни (lifeline) объекта. Она представляет собой фрагмент жизненного цикла объекта в процессе взаимодействия. Такую форму представления впервые ввел Ивар Якобсон.

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

Из всей возможной управляющей информации два ее вида имеют существенное значение. Во-первых, это условие, показывающее, когда посылается сообщение (например, [нуженПовторныйЗаказ = "true"]). Сообщение посылается только при выполнении данного условия. Другой полезный управляющий маркер — это маркер итерации, показывающий, что сообщение посылается много раз для множества объектов-адресатов (например,* приготовиться).

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

Диаграмма (см. рис. 3.11) содержит возврат, означающий не новое сообщение, а возврат из сообщения. На диаграмме возврат отличается от обычных сообщений тем, что его стрелка не сплошная, а имеет вид пары линий.

Диаграммы последовательности можно также использовать для представления параллельных процессов.

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

 

Рис. 3.12.Параллельные процессы и активизации

 

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

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

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

· создавать новую ветвь процесса (в этом случае оно связано с самой верхней частью активизации);

· создавать новый объект;

· устанавливать связь с уже выполняющейся ветвью процесса. Удаление объекта показано с помощью большого знака "X".

Объекты могут выполнить самоуничтожение или могут быть уничтожены посредством еще одного сообщения.

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

 

3.5.2. КООПЕРАТИВНЫЕ ДИАГРАММЫ

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