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

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

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

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

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

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

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

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

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

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

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

Фокус управления (focus of control) – специальный символ на диаграмме последовательности, указывающий период времени, в течение которого объект выполняет некоторое действие, находясь в активном состоянии.

Фокус управления изображается в форме вытянутого узкого прямоугольника (объект а), верхняя сторона которого обозначает начало получения фокуса управления объекта (начало активности), а ее нижняя сторона – окончание фокуса управления (окончание активности). Этот прямоугольник располагается ниже обозначения соответствующего объекта и может заменять его линию жизни (объект a на предыдущем рисунке), если на всем ее протяжении он активен.

Периоды активности объекта могут чередоваться с периодами его пассивности или ожидания. В этом случае у такого объекта фокусы управления изменяют свое изображение на линию жизни и наоборот (объект «сирота» ob2). Важно понимать, что получить фокус управления может только объект, у которого в этот момент имеется линия жизни. Если же объект был уничтожен, то вновь возникнуть в системе он уже не может. Вместо него может быть создан лишь экземпляр этого же класса, который, строго говоря, будет другим объектом.

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

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

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

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

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

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

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

Хочется надеяться, что эту диаграмму внимательный слушатель «расшифрует» сравнительно быстро.

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

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

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

Пример диаграммы коммуникации показан на следующем рисунке (в первом приближении).

Приведем теперь диаграмму последовательностей для потока событий Добавить новый заказ для упомянутого выше варианта использования «Работа с заказом».

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

- объект класса OrderOptions (Параметры работы с заказом), отвечающий за выбор возможного действия с заказом в рассматриваемом прецеденте;

- объект класса AddNewOrder (Добавление нового заказа), отвечающий за добавление заказа;

- объект класса OrderManager (Менеджер по работе с заказами), отвечающий за обработку потока событий рассматриваемого прецедента;

- объект класса Order (Заказ);

- объект класса Client (Клиент);

- объект класса ComponentPart (Комплектующее изделие).

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

Номер сообщения	Объект - отправитель сообщения	Объект - получатель сообщения	Название
	Менеджер по работе с клиентами	OrderOptions	ввод пароля
	OrderOptions	OrderOptions	проверка пароля
	Менеджер по работе с клиентами	OrderOptions	выбор операции "добавить"
	OrderOptions	AddNewOrder	отображение полей ввода
	Менеджер по работе с клиентами	AddNewOrder	выбор типа компьютера
	AddNewOrder	OrderManager	получение списка клиентов
	OrderManager	Client	получение списка клиентов
	Client	AddNewOrder	список клиентов
	AddNewOrder	AddNewOrder	отображение списка клиентов
	Менеджер по работе с клиентами	AddNewOrder	выбор клиента
	AddNewOrder	OrderManager	получение списка комплектующих
	OrderManager	ComponentPart	получение списка комплектующих
	ComponentPart	AddNewOrder	список комплектующих
	AddNewOrder	AddNewOrder	отображение списка комплектующих
	Менеджер по работе с клиентами	AddNewOrder	выбор необходимых комплектующих
	Менеджер по работе с клиентами	AddNewOrder	сохранить заказ
	AddNewOrder	OrderManager	передача управления
	OrderManager	Order	сохранить

В качестве дополнительного упражнения рекомендуется построить для данной диаграммы эквивалентную ей диаграмму сотрудничества.

Дата добавления: 2014-01-11