УНИФИЦИРОВАННЫЙ ЯЗЫК МОДЕЛИРОВАНИЯ UML

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

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

Уточненное в UML 2 понятие вложенного автомата представляется нам настолько простым и естественным, что вместо дальнейших пояснений мы просто сошлемся на рис. ошибка! текст указанного стиля в документе отсутствует..24 и рис. ошибка! текст указанного стиля в документе отсутствует..25, где еще раз представлен пример, аналогичный примеру на рис. ошибка! текст указанного стиля в документе отсутствует..22 и рис. ошибка! текст указанного стиля в документе отсутствует..23.

Мы надеемся, что читатель оценит красоту и точность нотации

UML 2.

161

Рис. Ошибка! Текст указанного стиля в документе отсутствует..25. Составное состояние, раскрывающее вложенную машину состояний

162

4.2.7. События

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

В UML используются четыре типа событий:

-событие вызова,

-событие сигнала,

-событие таймера,

-событие изменения.

Событие вызова (call event) — это событие, возникающее при вызове метода класса.

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

Проиллюстрируем вышесказанное на примере информационной системы отдела кадров. Определим в классах Person и Position операции, приведенные на рис. ошибка! текст указанного стиля в документе отсутствует..26.

163

Person

+assign(newPos:Position):Boolean

+hasPosition():Boolean

Position

+occupy(person:Person):Boolean

+isFree():Boolean

Рис. Ошибка! Текст указанного стиля в документе отсутствует..26 Операции, определенные в классах Person и Position

assign()переводит сотрудника на новую должность newPos и возвращает значение true, если перевод успешно произведен.

Операция isFree() класса Position проверяет, свободна ли должность, и операция occupy() позволяет назначить сотрудника на должность и в случае успешного завершения возвращает значение true.

Тогда типичное поведение операции assign() можно описать диаграммой состояний, приведенной на рис. ошибка! текст указанного стиля в документе отсутствует..27.

Рис. Ошибка! Текст указанного стиля в документе отсутствует..27. Событие вызова

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

164

assign() данный переход возбуждается, но для того, чтобы этот переход завершился должно быть выполнено условие newPos.isFree(). Если должность свободна (newPos.isFree()

вернул true), то тогда осуществляется вызов метода newPos.occupy(self), а вызов метода assign(newPos)

возвращает true (1 на рис. ошибка! текст указанного стиля в документе отсутствует..27).

Событие сигнала (signal event)— это событие, возникающее при посылке сигнала.

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

Синтаксически сигнал (в UML 1) — это экземпляр класса со стереотипом «signal». В UML 2 сигнал — это самостоятельный классификатор.

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

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

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

165

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

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

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

В UML существует еще одно важное понятие, связанное с асинхронным взаимодействием — исключение (exception). В разных версиях UML исключение определены и используются по разному.

Исключения в UML 1 во всем подобны сигналам (на уровне метамодели исключение определено как подкласс сигнала), в то время как в UML 2 от исключения осталось только действие, которое генерирует исключение (RaiseExceptionAction) и элемент (ExceptionHandler), который описывает действия для обработки исключения. Как видно, в UML 2 более сильно выражен тот факт, что для поддержки исключений используется встроенный механизм обработки, который имеется в большинстве современных объектноориентированных систем программирования и состоит в том, что прерывается нормальный поток управления без помех для основной логики программы.

166

Событие таймера (time event)— это событие, которое возникает, когда истек заданный интервал времени с момента попадания автомата в данное состояние.

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

Если переход срабатывает, то автомат переходит в новое состояние.

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

И хотя мы уже привели несколько примеров использования события таймера на переходах в конечных автоматах (см. рис. 4.23– 4.27), приведем еще один (рис. ошибка! текст указанного стиля в документе отсутствует..28).

ИЗМЕНЕНИЯ В ТЕХНИЧЕСКОМ ЗАДАНИИ

Информационная система должна хранить информацию не только о работающих, но и об уволенных сотрудниках. По прошествии 10 лет после увольнения, если эта информация не нужна более, она уничтожается.

167

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

Unemployed

[else]/deleteDBrecord

Рис. Ошибка! Текст указанного стиля в документе отсутствует..28. Переход по событию таймера со сторожевым условием

В UML 2 появился очень полезный вариант события таймера, которое связано не с интервалом времени пребывания в локальном состоянии, а с глобальным временем — системными часами. Данное событие записывается с помощью ключевого слова at, за которым нужно указать некоторый момент абсолютного времени (год, месяц, день, час, минуту, секунду…). Когда заданный момент наступает, происходит событие таймера. Если указать момент в прошлом, событие at никогда не наступит.

Событие изменения (change event)— это событие, которое возникает, когда некоторое логическое условие становится истинным, будучи до этого ложным.

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

168

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

Рассмотрим элементарный пример из информационной системы отдела кадров.

ИЗМЕНЕНИЯ В ТЕХНИЧЕСКОМ ЗАДАНИИ

По достижении определенного возраста (55 лет для женщин и 60 лет для мужчин) сотрудник увольняется на пенсию.

Реализация данного требования приведена на рис. ошибка!

текст указанного стиля в документе отсутствует..29.

when self.age > 65 and self.gender=Male

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

сотрудников записано с помощью специального языка (OCL) и подразумевает, что класс Person (рис. ошибка! текст указанного стиля в документе отсутствует..29 — это часть диаграммы автомата именно этого класса) имеет атрибут с именем age.

169

4.3. ДИАГРАММЫ ДЕЯТЕЛЬНОСТИ

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

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

4.3.1. Действие и деятельность

Мы уже использовали понятие действия, постулировав, что

действие является атомарным, непрерываемым извне,

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

170