Лабораторная работа № 3 Разработка структуры состояний

ЛАБОРАТОРНАЯ РАБОТА № 3
РАЗРАБОТКА СТРУКТУРЫ СОСТОЯНИЙ И ДИНАМИЧЕСКОЙ МОДЕЛИ
ПРОГРАММНОГО СРЕДСТВА С ИСПОЛЬЗОВАНИЕМ UML
1 Цель занятия
Научиться формировать диаграммы состояний, диаграммы деятельности и
диаграммы последовательности для отдельных классов, вариантов использования,
операций или подсистем.
2 Теоретические сведения о диаграмме состояний
Главное предназначение диаграммы состояний – описание возможных
состояний и переходов, которые в совокупности характеризуют поведение элемента
модели в течение его жизненного цикла. Диаграмма состояний представляет
динамическое поведение сущностей, на основе спецификации их реакции на
восприятие некоторых конкретных событий. Системы, которые реагируют на
внешние действия от других систем или от пользователей, иногда называют
реактивными. Если такие действия инициируются в произвольные случайные
моменты времени, то говорят об асинхронном поведении модели.
Рис. 1 Простейший пример диаграммы состояний
При проектировании следует выявить все возможные состояния и варианты их
возникновения, а также построить диаграмму состояний для жизненного цикла
одного из разрабатываемых объектов.
Рис. 2 Пример диаграммы состояний жизненного цикла объекта «телефона»
Диаграмма строится для отдельного класса, варианта использования, отдельной
операции класса или целой подсистемы. В рамках данного проекта необходимо
построить диаграмму состояний для всех выбранных объектов, для которых будет
описано поведение.
2.1 Состояние
Понятие состояния (state) является фундаментальным не только в метамодели
языка UML, но и в прикладном системном анализе. Концепция динамической
системы основывается на понятии состояния системы. Однако семантика состояния в
языке UML имеет целый ряд специфических особенностей.
В языке UML под состоянием понимается абстрактный метакласс,
используемый для моделирования отдельной ситуации, в течение которой имеет
место выполнение некоторого условия. Состояние может быть задано в виде набора
конкретных значений атрибутов класса или объекта, при этом изменение их
отдельных значений будет отражать изменение состояния моделируемого класса или
объекта.
Следует заметить, что не каждый атрибут класса может характеризовать его
состояние. Как правило, имеют значение только такие свойства элементов системы,
которые отражают динамический или функциональный аспект ее поведения. В этом
случае состояние будет характеризоваться некоторым инвариантным условием,
включающим в себя только значимые для поведения класса атрибуты и их значения.
Рис. 3 Графическое изображение состояний на диаграмме состояний
Состояние на диаграмме изображается прямоугольником со скругленными
вершинами (рис. 3). Этот прямоугольник, в свою очередь, может быть разделен на
две секции горизонтальной линией. Если указана лишь одна секция, то в ней
записывается только имя состояния (рис. 3, а). В противном случае в первой из них
записывается имя состояния, а во второй — список некоторых внутренних действий
или переходов в данном состоянии (рис. 3, б). При этом под действием в языке UML
понимают некоторую атомарную операцию, выполнение которой приводит к
изменению состояния или возврату некоторого значения (например, "истина" или
"ложь").
Имя состояния представляет собой строку текста, которая раскрывает
содержательный смысл данного состояния. Имя всегда записывается с заглавной
буквы. Поскольку состояние системы является составной частью процесса ее
функционирования, рекомендуется в качестве имени использовать глаголы в
настоящем времени (звенит, печатает, ожидает) или соответствующие причастия
(занят, свободен, передано, получено). Имя у состояния может отсутствовать, т. е.
оно является необязательным для некоторых состояний. В этом случае состояние
является анонимным, и если на диаграмме состояний их несколько, то все они
должны различаться между собой.
Секция «Список внутренних действий» содержит перечень внутренних
действий или деятельностей, которые выполняются в процессе нахождения
моделируемого элемента в данном состоянии. Каждое из действий записывается в
виде отдельной строки и имеет следующий формат:
<метка-дёйствия '/' выражение-действия>
Метка действия указывает на обстоятельства или условия, при которых будет
выполняться деятельность, определенная выражением действия. При этом выражение
действия может использовать любые атрибуты и связи, которые принадлежат области
имен или контексту моделируемого объекта. Если список выражений действия
пустой, то разделитель в виде наклонной черты '/' может не указываться.
Перечень меток действия имеет фиксированные значения в языке UML,
которые не могут быть использованы в качестве имен событий. Эти значения
следующие:
entry – эта метка указывает на действие, специфицированное следующим за ней
выражением действия, которое выполняется в момент входа в данное состояние
(входное действие);
exit – эта метка указывает на действие, специфицированное следующим за ней
выражением действия, которое выполняется в момент выхода из данного состояния
(выходное действие);
do – эта метка специфицирует выполняющуюся деятельность ("do activity"),
которая выполняется в течение всего времени, пока объект находится в данном
состоянии, или до тех пор, пока не закончится вычисление, специфицированное
следующим за ней выражением действия.
include – эта метка используется для обращения к подавтомату, при этом
следующее за ней выражение действия содержит имя этого подавтомата.
Во всех остальных случаях метка действия идентифицирует событие, которое
запускает соответствующее выражение действия. Эти события называются
внутренними переходами и семантически эквивалентны переходам в само это
состояние, за исключением той особенности, что выход из этого состояния или
повторный вход в него не происходит. Это означает, что действия входа и выхода не
выполняются.
Начальное состояние представляет собой частный случай состояния, которое не
содержит никаких внутренних действий (псевдосостояния). В этом состоянии
находится объект по умолчанию в начальный момент времени. Оно служит для
указания на диаграмме состояний графической области, от которой начинается
процесс изменения состояний. Графически начальное состояние в языке UML
обозначается в виде закрашенного кружка (рис. 4, а), из которого может только
выходить стрелка, соответствующая переходу.
Рис. 4 Графическое изображение начального и конечного состояний на
диаграмме состояний
На самом верхнем уровне представления объекта переход из начального
состояния может быть помечен событием создания (инициализации) данного
объекта. В противном случае переход никак не помечается. Если этот переход не
помечен, то он является первым переходом в следующее за ним состояние.
Конечное (финальное) состояние представляет собой частный случай
состояния, которое также не содержит никаких внутренних действий
(псевдосостояния). В этом состоянии будет находиться объект по умолчанию после
завершения работы автомата в конечный момент времени. Оно служит для указания
на диаграмме состояний графической области, в которой завершается процесс
изменения состояний или жизненный цикл данного объекта. Графически конечное
состояние в языке UML обозначается в виде закрашенного кружка, помещенного в
окружность (рис. 4, б), в которую может только входить стрелка, соответствующая
переходу.
2.2.2. Переход
Простой переход (simple transition) представляет собой отношение между двумя
последовательными состояниями, которое указывает на факт смены одного состояния
другим. Пребывание моделируемого объекта в первом состоянии может
сопровождаться выполнением некоторых действий, а переход во второе состояние
будет возможен после завершения этих действий, а также после удовлетворения
некоторых дополнительных условий. В этом случае говорят, что переход
срабатывает, Или происходит срабатывание перехода. До срабатывания перехода
объект находится в предыдущем от него состоянии, называемым исходным
состоянием, или в источнике (не путать с начальным состоянием — это разные
понятия), а после его срабатывания объект находится в последующем от него
состоянии (целевом состоянии).
Переход осуществляется при наступлении некоторого события: окончания
выполнения деятельности (do activity), получении объектом сообщения или приемом
сигнала. На переходе указывается имя события Кроме того, на переходе могут
указываться действия, производимые объектом в ответ на внешние события при
переходе из одного состояния в другое. Срабатывание перехода может зависеть не
только от наступления некоторого события, но и от выполнения определенного
условия, называемого сторожевым условием. Объект перейдет из одного состояния в
другое в том случае, если произошло указанное событие и сторожевое условие
приняло значение "истина".
На диаграмме состояний переход изображается сплошной линией со стрелкой,
которая направлена в целевое состояние (например, "выход из строя" на рис. 1).
Каждый переход может помечен строкой текста, которая имеет следующий общий
формат:
<сигнатура события>'['<сторожевое условие>']' <выражение действия>.
При этом сигнатура события описывает некоторое событие с необходимыми
аргументами:
<имя события>'('<список параметров, разделенных запятыми>')'.
2.2.3 Событие
Термин событие (event) требует отдельного пояснения, поскольку является
самостоятельным элементом языка UML. Формально, событие представляет собой
спецификацию некоторого факта, имеющего место в пространстве и во времени. Про
события говорят, что они "происходят", при этом отдельные события должны быть
упорядочены во времени. После наступления некоторого события нельзя уже
вернуться к предыдущим событиям, если такая возможность не предусмотрена явно в
модели.
Семантика понятия события фиксирует внимание на внешних проявлениях
качественных изменений, происходящих при переходе моделируемого объекта из
состояния в состояние. Например, при включении электрического переключателя
происходит некоторое событие, в результате которого комната становится
освещенной. После успешного ремонта компьютера также происходит немаловажное
событие — восстановление его работоспособности. Если поднять трубку обычного
телефона, то, в случае его исправности, мы ожидаем услышать тоновый сигнал. И
этот факт тоже является событием.
В языке UML события играют роль стимулов, которые инициируют переходы
из одних состояний в другие. В качестве событий можно рассматривать сигналы,
вызовы, окончание фиксированных промежутков времени или моменты окончания
выполнения определенных действий. Имя события идентифицирует каждый
отдельный переход на диаграмме состояний и может содержать строку текста,
начинающуюся со строчной буквы.
Если рядом со стрелкой перехода не указана никакая строка текста, то
соответствующий переход является нетриггерным, и в этом случае из контекста
диаграммы состояний должно быть ясно, после окончания какой деятельности он
срабатывает. После имени события могут следовать круглые скобки для явного
задания параметров соответствующего события-триггера. Если таких параметров нет,
то список параметров со скобками может отсутствовать.
Сторожевое условие (guard condition), если оно есть, всегда записывается в
прямых скобках после события-триггера и представляет собой некоторое булевское
выражение. Введение для перехода сторожевого условия позволяет явно
специфицировать семантику его срабатывания. Если сторожевое условие принимает
значение "истина", то соответствующий переход может сработать, в результате чего
объект перейдет в целевое состояние. Если же сторожевое условие принимает
значение "ложь", то переход не может сработать, и при отсутствии других переходов
объект не может перейти в целевое состояние по этому переходу. Однако вычисление
истинности сторожевого условия происходит только после возникновения
ассоциированного с ним события-триггера, инициирующего соответствующий
переход.
В общем случае из одного состояния может быть несколько переходов с одним
и тем же событием-триггером. При этом никакие два сторожевых условия не должны
одновременно принимать значение "истина". Каждое из сторожевых условий
необходимо вычислять всякий раз при наступлении соответствующего событиятриггера.
Примером события-триггера может служить разрыв телефонного соединения с
провайдером Интернет-услуг после окончания загрузки электронной почты
клиентской почтовой программой (при удаленном доступе к Интернету). В этом
случае сторожевое условие есть не что иное, как ответ на вопрос: "Пуст ли почтовый
ящик клиента на сервере провайдера?". В случае положительного ответа "истина",
следует отключить соединение с провайдером, что и делает автоматически почтовая
программа-клиент. В случае отрицательного ответа "ложь", следует оставаться в
состоянии загрузки почты и не разрывать телефонное соединение.
2.2.4 Выражение действия
Выражение действия (action expression) выполняется в том и только в том
случае, когда переход срабатывает. Представляет собой атомарную операцию
(достаточно простое вычисление), выполняемую сразу после срабатывания
соответствующего перехода до начала каких бы то ни было действий в целевом
состоянии. Атомарность действия означает, что оно не может быть прервано никаким
другим действием до тех пор, пока не закончится его выполнение. Данное действие
может оказывать влияние, как на сам объект, так и на его окружение, если это с
очевидностью следует из контекста модели. Выражение записывается после знака "/"
в строке текста, присоединенной к соответствующему переходу.
В общем случае, выражение действия может содержать целый список
отдельных действий, разделенных символом ";". Обязательное требование – все
действия из списка должны четко различаться между собой и следовать в порядке их
записи. На синтаксис записи выражений действия не накладывается никаких
ограничений. Главное – их запись должна быть понятна разработчикам модели и
программистам. Поэтому чаще всего выражения записывают на одном из языков
программирования, который предполагается использовать для реализации модели.
В качестве примера выражения действия может служить "разорвать телефонное
соединение (телефонный номер), которое должно быть выполнено сразу после
установления истинности ("истина") сторожевого условия "почтовый ящик на
сервере пуст".
2.2.5. Составное состояние и подсостояние
Составное состояние (composite state) – такое сложное состояние, которое
состоит из других вложенных в него состояний. Последние будут выступать по
отношению к первому как подсостояния (substate). Хотя между ними имеет место
отношение композиции, графически все вершины диаграммы, которые
соответствуют вложенным состояниям, изображаются внутри символа составного
состояния (рис. 5). В этом случае размеры графического символа составного
состояния увеличиваются, так чтобы вместить в себя все подсостояния.
Рис. 5 Графическое представление составного состояния с двумя вложенными в
него последовательными подсостояниями
Составное состояние может содержать два или более параллельных
подавтомата или несколько последовательных подсостояний. Каждое сложное
состояние может уточняться только одним из указанных способов. При этом любое
из подсостояний, в свою очередь, может являться составным состоянием и содержать
внутри себя другие вложенные подсостояния. Количество уровней вложенности
составных состояний не фиксировано в языке UML.
Последовательные подсостояния (sequential substates) используются для
моделирования такого поведения объекта, во время которого в каждый момент
времени объект может находиться в одном и только одном подсостояний. Поведение
объекта в этом случае представляет собой последовательную смену подсостояний.
Параллельные подсостояния (concurrent substates) позволяют специфицировать
два и более подавтомата, которые могут выполняться параллельно внутри составного
события. Каждый из подавтоматов занимает некоторую область (регион) внутри
составного состояния, которая отделяется от остальных горизонтальной пунктирной
линией. Если на диаграмме состояний имеется составное состояние с вложенными
параллельными подсостояниями, то объект может одновременно находиться в
каждом из этих подсостояний.
Однако отдельные параллельные подсостояния могут, в свою очередь, состоять
из нескольких последовательных подсостояний. В этом случае по определению
объект может находиться только в одном из последовательных подсостояний
подавтомата.
Рис. 6 Графическое изображение составного состояния с вложенными
параллельными подсостояниями
Поскольку каждый регион вложенного состояния специфицирует некоторый
подавтомат, то для каждого из вложенных подавтоматов могут быть определены
собственные начальное и конечные подсостояния. При переходе в данное составное
состояние каждый из подавтоматов оказывается в своем начальном подсостояний.
Далее происходит параллельное выполнение каждого из этих подавтоматов, причем
выход из составного состояния будет возможен лишь в том случае, когда все
подавтоматы будут находиться в своих конечных подсостояниях.
Если какой-либо из подавтоматов пришел в свое конечное состояние раньше
других, то он должен ожидать, пока и другие подавтоматы не придут в свои конечные
состояния.
В некоторых случаях бывает желательно скрыть внутреннюю структуру
составного состояния. Если отдельный подавтомат, специфицирующий составное
состояние, может быть настолько большим по масштабу, что его визуализация
затруднит общее представление диаграммы состояний. В подобной ситуации
допускается не раскрывать на исходной диаграмме состояний данное составное
состояние, а указать в правом нижнем углу специальный символ-пиктограмму (рис.
7). В последующем диаграмма состояний для соответствующего подавтомата может
быть изображена отдельно от основной с необходимыми комментариями.
Рис. 7 Составное состояние со скрытой внутренней структурой и специальной
пиктограммой
2.2.6. Сложные переходы
Рассмотренное выше понятие перехода является вполне достаточным для
большинства типичных расчетно-вычислительных задач. Однако современные
программные системы могут реализовывать очень сложную логику поведения
отдельных своих компонентов. Может оказаться, что для адекватного представления
процесса изменения состояний семантика обычного перехода для них недостаточна.
С этой целью в языке UML специфицированы дополнительные обозначения и
свойства, которыми могут обладать отдельные переходы на диаграмме состояний.
В отдельных случаях переход может иметь несколько состояний-источников и
несколько целевых состояний. Такой переход получил специальное название —
параллельный переход. Введение в рассмотрение параллельного перехода
обусловлено необходимостью синхронизировать и/или разделить отдельные
подпроцессы на параллельные нити без спецификации дополнительной
синхронизации в параллельных подавтоматах.
Графически такой переход изображается вертикальной черточкой, аналогично
обозначению перехода в известном формализме сетей Петри. Если параллельный
переход имеет две или более входящих дуг (рис. 8, а), то его называют соединением
(join). Если же он имеет две или более исходящих из него дуг (рис. 8, б), то его
называют ветвлением (fork). Текстовая строка спецификации параллельного перехода
записывается рядом с черточкой и относится ко всем входящим (исходящим) дугам.
Рис. 8 Графическое изображение параллельного перехода из параллельных
состояний (а) и параллельного перехода в параллельные состояния (б)
Срабатывание параллельного перехода происходит следующим образом. В
первом случае (переход-соединение) переход срабатывает, если имеет место событиетриггер для всех исходных состояний этого перехода, и выполнено (при его наличии)
сторожевое условие. При срабатывании перехода-соединения одновременно
покидаются все исходные состояния перехода (состояния 1 и 2) и происходит
переход в целевое состояние. При этом каждое из исходных состояний перехода
должно принадлежать отдельному подавтомату, входящему в состав автомата
(процессу 1).
Во втором случае (ветвление) происходит расщепление автомата на два
подавтомата, образующих параллельные ветви вложенных подсостояний. При этом
после срабатывания перехода моделируемый объект одновременно будет находиться
во всех целевых состояниях этого перехода (состояния 3 и 4). Далее процесс
изменения состояний будет протекать согласно ранее рассмотренным правилам для
составных состояний.
Переход, стрелка которого соединена с границей некоторого составного
состояния, обозначает переход в составное состояние (переход b на рис. 9). Он
эквивалентен переходу в начальное состояние каждого из подавтоматов (возможно,
единственному), входящих в состав данного суперсостояния. Переход, выходящий из
составного состояния (переходы f и g на рис. 9), относится к каждому из вложенных
подсостояний. Это означает, что объект может покинуть составное суперсостояние,
находясь в любом из его подсостояний. Для этого вполне достаточно выполнения
события и сторожевого условия.
Рис. 9 Различные варианты переходов в (из) составное состояние
Иногда желательно реализовать ситуацию, когда выход из отдельного
вложенного состояния соответствовал бы выходу и из составного состояния тоже. В
этом случае изображают переход, который непосредственно выходит из вложенного
подсостояния за границу суперсостояния (переход с на рис. 9). Аналогично,
допускается изображение переходов, входящих извне составного состояния в
отдельное вложенное состояние (переход а на рис. 9).
Как уже было отмечено, поведение параллельных подавтоматов независимо
друг от друга, что позволяет реализовать многозадачность в программных системах.
Однако в отдельных случаях может возникнуть необходимость учесть в модели
синхронизацию наступления отдельных событий. Для этой цели в языке UML
имеется специальное псевдосостояние, которое называется синхронизирующим
состоянием.
Синхронизирующее состояние (synch state) обозначается небольшой
окружностью, внутри которой помещен символ звездочки "*". Оно используется
совместно с переходом-соединением или переходом-ветвлением для того, чтобы явно
указать события в других подавтоматах, оказывающие непосредственное влияние на
поведение данного подавтомата.
Для иллюстрации использования синхронизирующих состояний рассмотрим
упрощенную ситуацию с моделированием процесса постройки дома. Предположим,
что постройка дома включает в себя строительные работы (возведение фундамента и
стен, возведение крыши и отделочные работы) и работы по электрификации дома
(подведение электрической линии, прокладка скрытой электропроводки и установка
осветительных ламп). Очевидно, два этих комплекса работ могут выполняться
параллельно, однако между ними есть некоторая взаимосвязь.
В частности, прокладка скрытой электропроводки может начаться лишь после
того, как будет завершено возведение фундамента и стен. А отделочные работы
следует начать лишь после того, как будет закончена прокладка скрытой
электропроводки. В противном случае отделочные работы придется проводить
повторно. Рассмотренные особенности синхронизации этих параллельных процессов
учтены на соответствующей диаграмме состояний с помощью двух
синхронизирующих состояний (рис. 10).
Рис. 10 Диаграмма состояний для примера со строительством дома
2.2.7 Пример моделирования поведения конкретного объекта – процесса
функционирования телефонного аппарата
Кратко прокомментируем основные особенности этого примера. Данная
диаграмма состояний представляет единственный автомат с одним составным
состоянием. Вне этого составного состояния имеется только одно состояние
"ожидание", которое характеризует исправный и подключенный к телефонной сети
телефонный аппарат. Переход в следующее состояние происходит при поднятии
телефонной трубки. Переход с атомарным действием "подать тоновый сигнал"
переводит аппарат в составное состояние, а точнее – в начальное его подсостояние.
Далее телефонный аппарат будет находиться в состоянии "тоновый сигнал".
При этом будет непрерывно издавать этот сигнал до тех пор, пока не произойдет
событие-триггер "набор цифры (п)", либо не истечет 15 секунд с момента поднятия
трубки. В первом случае аппарат перейдет в состояние "набор номера", а во втором
— в состояние "истечение времени ожидания". Последняя ситуация может быть
результатом сомнений по поводу "звонить — не звонить?", следствием чего могут
стать гудки в трубке. При этом нам ничего не остается делать, как опустить ее на
рычаг.
При наборе номера выполняется событие-триггер "набор цифры (п) со
сторожевым условием "номер неполный". Это означает, что если набранный
телефонный номер не содержит необходимого количества цифр, то нам следует
продолжать набор очередной цифры, оставаясь в состоянии "набор номера".
Если же набранный номер полный, то можно перейти в состояние "неверный
номер" или "соединение". В случае неверного номера (сторожевое условие
"неверный" истинно) ничего не остается, как покинуть составное состояние, опустив
трубку на рычаг. Если же номер верный, то происходит соединение по этому номеру.
Однако в результате соединения может оказаться, что аппарат абонента занят
(переход в состояние "занято") либо свободен (переход в состояние "звонок у
абонента"). В первом случае можно повторить дозвон, предварительно опустив
трубку на рычаг (выход из составного состояния). Во втором случае происходит
проверка сторожевого условия "разговор доступен". Если оно истинно, что
соответствует снятию трубки абонентом, начинается телефонный разговор. В
противном случае (это условие не выполняется, т. е. оно ложно) телефон абонента
будет продолжать звонить, извещая нас об отсутствии последнего либо о
невозможности по какой-либо причине вести разговор по телефону. При этом нам
ничего не остается, как опустить трубку на рычаг.
Если же разговор состоялся, то после слов прощания и выполнения
сторожевого условия "подтверждение" на окончание разговора мы снова опускаем
трубку. При этом телефонный аппарат переходит в состояние "ожидание", в котором
может находиться неопределенно долго.
Рис. 11 Диаграмма состояний процесса функционирования телефонного
аппарата
3 Теоретические сведения о диаграмме деятельности
При моделировании поведения проектируемой или анализируемой системы
возникает необходимость не только представить процесс изменения ее состояний, но
и детализировать особенности алгоритмической и логической реализации
выполняемых системой операций. Традиционно для этой цели использовались схемы
алгоритмов, акцентирующие внимание на последовательности выполнения
определенных действий или элементарных операций, которые в совокупности
приводят к получению желаемого результата.
Для моделирования процесса выполнения операций в языке UML используются
так называемые диаграммы деятельности. Применяемая в них графическая нотация
во многом похожа на нотацию диаграммы состояний, поскольку на диаграммах
деятельности также присутствуют обозначения состояний и переходов. Отличие
заключается в семантике состояний, которые используются для представления не
деятельностей, а действий, и в отсутствии на переходах сигнатуры событий. Каждое
состояние на диаграмме деятельности соответствует выполнению некоторой
элементарной операции, а переход в следующее состояние срабатывает только при
завершении этой, операции в предыдущем состоянии. Графически диаграмма
деятельности представляется в форме графа деятельности, вершинами которого
являются состояния действия, а дугами — переходы от одного состояния действия к
другому.
3.1 Состояние действия
Состояние действия (action state) является специальным случаем состояния с
некоторым входным действием и по крайней мере одним выходящим из состояния
переходом. Этот переход неявно предполагает, что входное действие уже
завершилось. Состояние действия не может иметь внутренних переходов, поскольку
оно является элементарным. Обычное использование состояния действия
заключается в моделировании одного шага выполнения алгоритма (процедуры) или
потока управления.
Графически состояние действия изображается фигурой, напоминающей
прямоугольник, боковые стороны которого заменены выпуклыми дугами (рис. 12).
Внутри этой фигуры записывается выражение действия (action-expression), которое
должно быть уникальным в пределах одной диаграммы деятельности.
Рис. 12 Графическое изображение состояния действия
Иногда возникает необходимость представить на диаграмме деятельности
некоторое сложное действие, которое, в свою очередь, состоит из нескольких более
простых действий. В этом случае можно использовать специальное обозначение так
называемого состояния под-деятельности (subactivity state). Такое состояние является
графом деятельности и обозначается специальной пиктограммой в правом нижнем
углу символа состояния действия (рис. 7.2). Эта конструкция может применяться к
любому элементу языка UML, который поддерживает "вложенность" своей
структуры. При этом пиктограмма может быть дополнительно помечена типом
вложенной структуры.
Рис. 13 Графическое изображение состояния под-деятельности
3.2. Переходы
При построении диаграммы деятельности используются только нетриггерные
переходы, т. е. такие, которые срабатывают сразу после завершения деятельности или
выполнения соответствующего действия. Этот переход переводит деятельность в
последующее состояние сразу, как только закончится действие в предыдущем
состоянии. На диаграмме такой переход изображается сплошной линией со стрелкой.
Если из состояния действия выходит единственный переход, то он может быть
никак не помечен. Если же таких переходов несколько, то сработать может только
один из них. Именно в этом случае для каждого из таких переходов должно быть
явно записано сторожевое условие в прямых скобках. При этом для всех выходящих
из некоторого состояния переходов должно выполняться требование истинности
только одного из них. Подобный случай встречается тогда, когда последовательно
выполняемая деятельность должна разделиться на альтернативные ветви в
зависимости от значения некоторого промежуточного результата. Такая ситуация
получила название ветвления, а для ее обозначения применяется специальный
символ.
Графически ветвление на диаграмме деятельности обозначается небольшим
ромбом, внутри которого нет никакого текста (рис. 14). В этот ромб может входить
только одна стрелка от того состояния действия, после выполнения которого поток
управления должен быть продолжен по одной из взаимно исключающих ветвей.
Принято входящую стрелку присоединять к верхней или левой вершине символа
ветвления. Выходящих стрелок может быть две или более, но для каждой из них явно
указывается соответствующее сторожевое условие в форме булевского выражения.
В качестве примера рассмотрим фрагмент известного алгоритма нахождения
корней квадратного уравнения. Графически фрагмент процедуры вычисления корней
квадратного уравнения может быть представлен в виде диаграммы деятельности с
тремя состояниями действия и ветвлением (рис. 14). Каждый из переходов,
выходящих из состояния "Вычислить дискриминант", имеет сторожевое условие,
определяющее единственную ветвь, по которой может быть продолжен процесс
вычисления корней в зависимости от знака дискриминанта. Очевидно, что в случае
его отрицательности, мы сразу попадаем в конечное состояние, тем самым завершая
выполнение алгоритма в целом.
Рис. 14 Фрагмент диаграммы деятельности для алгоритма нахождения корней
квадратного уравнения
3.3. Дорожки
Диаграммы деятельности могут быть использованы для моделирования бизнеспроцессов. Применительно к бизнес-процессам желательно выполнение каждого
действия ассоциировать с конкретным подразделением компании. В этом случае
подразделение несет ответственность за реализацию отдельных действий, а сам
бизнес-процесс представляется в виде переходов действий из одного подразделения к
другому.
Для моделирования этих особенностей в языке UML используется специальная
конструкция, получившее название дорожки (swimlanes) по аналогии с
плавательными дорожками в бассейне. При этом все состояния действия на
диаграмме деятельности делятся на отдельные группы, которые отделяются друг от
друга вертикальными линиями. Две соседние линии и образуют дорожку, а группа
состояний между этими линиями выполняется отдельным подразделением (отделом,
группой, отделением, филиалом) компании (рис. 15).
Названия подразделений явно указываются в верхней части дорожки.
Пересекать линию дорожки могут только переходы, которые в этом случае
обозначают выход или вход потока управления в соответствующее подразделение
компании. Порядок следования дорожек не несет какой-либо семантической
информации и определяется соображениями удобства.
Рис. 15 Фрагмент диаграммы деятельности для торговой компании
4 Теоретические сведения о диаграмме последовательности
В языке UML взаимодействие элементов рассматривается в информационном
аспекте их коммуникации, т. е. взаимодействующие объекты обмениваются между
собой некоторой информацией. При этом информация принимает форму
законченных сообщений. Другими словами, хотя сообщение и имеет
информационное содержание, оно приобретает дополнительное свойство оказывать
направленное влияние на своего получателя. Это полностью согласуется с
принципами ООАП, когда любые виды информационного взаимодействия между
элементами системы должны быть сведены к отправке и приему сообщений между
ними.
Для моделирования взаимодействия объектов в языке UML используются
соответствующие диаграммы взаимодействия. Говоря об этих диаграммах, имеют в
виду два аспекта взаимодействия. Во-первых, взаимодействия объектов можно
рассматривать во времени, и тогда для представления временных особенностей
передачи и приема сообщений между объектами используется диаграмма
последовательности.
4.1. Объекты
На диаграмме последовательности изображаются исключительно те объекты,
которые непосредственно участвуют во взаимодействии и не показываются
возможные статические ассоциации с другими объектами. Для диаграммы
последовательности ключевым моментом является именно динамика взаимодействия
объектов во времени. При этом диаграмма последовательности имеет как бы два
измерения. Одно — слева направо в виде вертикальных линий, каждая из которых
изображает линию жизни отдельного объекта, участвующего во взаимодействии.
Графически каждый объект изображается прямоугольником и располагается в
верхней части своей линии жизни (рис. 16). Внутри прямоугольника записываются
имя объекта и имя класса, разделенные двоеточием. При этом вся запись
подчеркивается, что является признаком объекта, который, как известно,
представляет собой экземпляр класса.
Рис. 16 Различные графические примитивы диаграммы последовательности
Линия жизни объекта (object lifeline) изображается пунктирной вертикальной
линией,
ассоциированной
с
единственным
объектом
на
диаграмме
последовательности. Линия жизни служит для обозначения периода времени, в
течение которого объект существует в системе и, следовательно, может потенциально
участвовать во всех ее взаимодействиях. Если объект существует в системе
постоянно, то и его линия жизни должна продолжаться по всей плоскости диаграммы
последовательности от самой верхней ее части до самой нижней (объекты 1 и 2 на
рис. 16).
Отдельные объекты, выполнив свою роль в системе, могут быть уничтожены
(разрушены), чтобы освободить занимаемые ими ресурсы. Для таких объектов линия
жизни обрывается в момент его уничтожения. Для обозначения момента
уничтожения объекта в языке UML используется специальный символ в форме
латинской буквы "X" (объект 3 на рис. 16). Ниже этого символа пунктирная линия не
изображается, поскольку соответствующего объекта в системе уже нет, и этот объект
должен быть исключен из всех последующих взаимодействий.
В процессе функционирования объектно-ориентированных систем одни
объекты могут находиться в активном состоянии, непосредственно выполняя
определенные действия или в состоянии пассивного ожидания сообщений от других
объектов. Чтобы явно выделить подобную активность объектов, в языке UML
применяется специальное понятие, получившее название фокуса управления (focus of
control). Фокус управления изображается в форме вытянутого узкого прямоугольника
(см. объект 1 на рис. 16), верхняя сторона которого обозначает начало получения
фокуса управления объекта (начало активности), а ее нижняя сторона — окончание
фокуса управления (окончание активности). Этот прямоугольник располагается ниже
обозначения соответствующего объекта и может заменять его линию жизни, если на
всем ее протяжении он является активным.
4.2. Сообщения
Цель взаимодействия в контексте языка UML заключается в том, чтобы описать
связи между множеством взаимодействующих объектов. Каждое взаимодействие
описывается совокупностью сообщений, которыми участвующие в нем объекты
обмениваются между собой. В этом смысле сообщение (message) представляет собой
законченный фрагмент информации, который отправляется одним объектом другому.
При этом прием сообщения инициирует выполнение определенных действий,
направленных на решение отдельной задачи тем объектом, которому это сообщение
отправлено.
Таким образом, сообщения не только передают некоторую информацию, но и
требуют от принимающего объекта выполнения ожидаемых действий. Сообщения
могут инициировать выполнение операций объектом соответствующего класса, а
параметры этих операций передаются вместе с сообщением. На диаграмме
последовательности все сообщения упорядочены по времени своего возникновения в
моделируемой системе.
В таком контексте каждое сообщение имеет направление от объекта, который
инициирует и отправляет сообщение, к объекту, который его получает. Иногда
отправителя сообщения называют клиентом, а получателя — сервером. Сообщение
от клиента имеет форму запроса некоторого сервиса, а реакция сервера на запрос
может быть связана с выполнением определенных действий или передачи клиенту
необходимой информации тоже в форме сообщения.
Рис. 17 Графическое изображение различных видов сообщений между
объектами на диаграмме последовательности
В языке UML могут встречаться несколько разновидностей сообщений, каждое
из которых имеет свое графическое изображение (рис. 17).
 Первая разновидность сообщения (рис. 17, а) является наиболее
распространенной и используется для вызова процедур, выполнения операций или
обозначения отдельных вложенных потоков управления. Начало этой стрелки всегда
соприкасается с фокусом управления или линией жизни того объекта-клиента,
который инициирует это сообщение. Конец стрелки соприкасается с линией жизни
того объекта, который принимает это сообщение и выполняет в ответ определенные
действия. При этом принимающий объект зачастую получает и фокус управления,
становясь активным.
 Вторая разновидность сообщения (рис. 17, б) используется для обозначения
простого (не вложенного) потока управления. Каждая такая стрелка указывает на
прогресс одного шага потока. При этом соответствующие сообщения обычно
являются асинхронными, т. е. могут возникать в произвольные моменты времени.
Передача такого сообщения обычно сопровождается получением фокуса управления
объектом, его принявшим.
 Третья разновидность (рис. 17, в) явно обозначает асинхронное сообщение
между двумя объектами в некоторой процедурной последовательности. Примером
такого сообщения может служить прерывание операции при возникновении
исключительной ситуации. В этом случае информация о такой ситуации передается
вызывающему объекту для продолжения процесса дальнейшего взаимодействия.
 Наконец, последняя разновидность сообщения (рис. 17, г) используется для
возврата из вызова процедуры. Примером может служить простое сообщение о
завершении некоторых вычислений без предоставления результата расчетов объектуклиенту. В процедурных потоках управления эта стрелка может быть опущена,
поскольку ее наличие неявно предполагается в конце активизации объекта. В то же
время считается, что каждый вызов процедуры имеет свою пару — возврат вызова.
Для непроцедурных потоков управления, включая параллельные и асинхронные
сообщения, стрелка возврата должна указываться явным образом.
В языке UML предусмотрены некоторые стандартные действия, выполняемые в
ответ на получение соответствующего сообщения. Они могут быть явно указаны на
диаграмме последовательности в форме стереотипа рядом с сообщением, к которому
они относятся. В этом случае они записываются в кавычках. Используются
следующие обозначения для моделирования действий:
 «call» (вызвать) – сообщение, требующее вызова операции или процедуры
принимающего объекта. Если сообщение с этим стереотипом рефлексивное, то оно
инициирует локальный вызов операции у самого пославшего это сообщение объекта;
 «return» (возвратить) – сообщение, возвращающее значение выполненной
операции или процедуры вызвавшему ее объекту. Значение результата может
инициировать ветвление потока управления;
 «create» (создать) – сообщение, требующее создания другого объекта для
выполнения определенных действий. Созданный объект может получить фокус
управления, а может и не получить его;
 «destroy» (уничтожить) – сообщение с явным требованием уничтожить
соответствующий объект. Посылается в том случае, когда необходимо прекратить
нежелательные действия со стороны существующего в системе объекта, либо когда
объект больше не нужен и должен освободить задействованные им системные
ресурсы;
 «send» (послать) – обозначает посылку другому объекту некоторого сигнала,
который
асинхронно
инициируется
одним
объектом
и
принимается
(перехватывается) другим. Отличие сигнала от сообщения заключается в том, что
сигнал должен быть явно описан в том классе, объект которого инициирует его
передачу.
Рис. 18 Окончательный вариант
моделирования телефонного разговора
диаграммы
последовательности
для
5 Задачи для самостоятельного решения студентами
5.1 Для диаграммы вариантов использования и диаграммы классов,
построенных на предыдущих лабораторных работах выбрать не менее 2 вариантов
использования и 2-х классов, имеющих динамические характеристики.
5.2 Внимательно изучить текст теоретической части настоящих методических
указаний.
5.3 Сформировать для каждого выбранного варианта использования и класса
диаграммы состояний, описав в них все состояния, события, переходы и условия. В
одной или более диаграмм должны содержаться сложные переходы.
5.4 Сформировать диаграмму деятельности с дорожками для самого сложного
варианта использования.
5.5 Сформировать
диаграмму
последовательности
для
варианта
использования, для которого не строилась диаграмма деятельности.