logo
A03_Doc

3.4. Диаграмма последовательности (sequence diagram)

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

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

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

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

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

Различные графические примитивы диаграммы последовательности

Рис. 3.23

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

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

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

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

Графическое изображение различных вариантов линий жизни и фокусов управления объектов

Рис. 3.24

Фокус управления. Как было рассмотрено в главе 1, в процессе функционирования объектно-ориентированных систем одни объекты могут находиться постоянно в активном состоянии (актер), воздействуя на другие объекты, или в состоянии пассивного ожидания сообщений от других объектов (сервер). Чтобы явно выделить подобную активность объектов, в языке UML применяется специальное понятие, получившее название фокуса управления (focus of control). Фокус управления изображается в форме вытянутого узкого прямоугольника (см. объект 1 на рис. 3.23), верхняя сторона которого обозначает начало получения фокуса управления объекта (начало активности), а ее нижняя сторона - окончание фокуса управления (окончание активности). Этот прямоугольник располагается ниже обозначения соответствующего объекта и может заменять его линию жизни (объект 4 на рис. 3.24), если на всем ее протяжении он является активным.

Графическое изображение актера, рекурсии и рефлексивного сообщения на диаграмме последовательности

Рис. 3.25

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

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

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

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

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

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

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

Рис. 3.26

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

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

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

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

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

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

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

Ниже представлена диаграмма последовательности для рассмотренного выше случая ветвления, дополненная стереотипными значениями (рис. 3.27).

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

Диаграмма последовательности со стереотипными значениями сообщений

Рис. 3.27

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

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

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

Начальный фрагмент диаграммы последовательности для моделирования телефонного разговора

Рис. 3.28

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

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

  3.4.3. Пример построения диаграммы последовательности. В качестве примера рассмотрим построение диаграммы последовательности для моделирования процесса телефонного разговора с использованием обычной телефонной сети. Объектами в этом примере являются: два абонента А и В, два телефонных аппарата C и D, коммутатор и сам разговор как объект моделирования. При этом как коммутатор, так и разговор в нашей задаче являются анонимными объектами.

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

Процесс взаимодействия в этой системе начинается с поднятия трубки телефонного аппарата абонентом A. Тем самым он посылает сообщение телефонному аппарату C, которое переводит этот аппарат в активное состояние и вызывает действие - подачу тонового сигнала в телефонную трубку для первого абонента. Следующее действие также инициируется абонентом A: набор цифр телефонного номера. Это представлено в форме итеративного сообщения со знаком «*» слева от имени сообщения.

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

После создания анонимный объект «разговор» сразу получает фокус активности и посылает сообщение телефонному аппарату D на выполнение действия - звонка вызова. При этом второй абонент снимает трубку (асинхронное сообщение), тем самым устанавливается прямое соединение между абонентами A и B. После того как абоненты опустят трубки, разговор заканчивается. Тем самым объект «разговор» уничтожается. Окончательный вариант диаграммы последовательности может содержать некоторые временные ограничения и комментарии (рис. 3.30). Назначение отдельных сообщений соответствуют рассмотренным действиям.

Дополненный фрагмент диаграммы последовательности для моделирования телефонного разговора

Рис. 3.29

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

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

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

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

Окончательный вариант диаграммы последовательности для моделирования телефонного разговора

Рис. 3.30

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

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