Самоучитель UML
Шрифт:
Событие
Термин событие (event) требует отдельного пояснения, поскольку является самостоятельным элементом языка UML. Формально, событие представляет собой спецификацию некоторого факта, имеющего место в пространстве и во времени. Про события говорят, что они «происходят», при этом отдельные события должны быть упорядочены во времени. После наступления некоторого события нельзя уже вернуться к предыдущим событиям, если такая возможность не предусмотрена явно в модели.
Семантика понятия события фиксирует внимание на внешних проявлениях качественных изменений, происходящих при переходе моделируемого объекта из состояния в состояние. Например, при включении электрического переключателя происходит некоторое событие, в результате которого комната становится освещенной.
В языке UML события играют роль стимулов, которые инициируют переходы из одних состояний в другие. В качестве событий можно рассматривать сигналы, вызовы, окончание фиксированных промежутков времени или моменты окончания выполнения определенных действий. Имя события идентифицирует каждый отдельный переход на диаграмме состояний и может содержать строку текста, начинающуюся со строчной буквы. В этом случае принято считать переход триггерным, т. е. таким, который специфицирует событие-триггер. Например, переходы на рис. 6.1 являются триггерными, поскольку с каждым из них связано некоторое событие-триггер, происходящее асинхронно в момент выхода из строя технического устройства или в момент окончания его ремонта.
Если рядом со стрелкой перехода не указана никакая строка текста, то соответствующий переход является нетриггерным, и в этом случае из контекста диаграммы состояний должно быть ясно, после окончания какой деятельности он срабатывает. После имени события могут следовать круглые скобки для явного задания параметров соответствующего события-триггера. Если таких параметров нет, то список параметров со скобками может отсутствовать.
Сторожевое условие
Сторожевое условие (guard condition), если оно есть, всегда записывается в прямых скобках после события-триггера и представляет собой некоторое булевское выражение. Напомним, что булевское выражение должно принимать одно их двух взаимно исключающих значений: «истина» или «ложь». Из контекста диаграммы состояний должна явно следовать семантика этого выражения, а для записи выражения может использоваться синтаксис языка объектных ограничений, основы которого изложены в приложении.
Введение для перехода сторожевого условия позволяет явно специфицировать семантику его срабатывания. Если сторожевое условие принимает значение «истина», то соответствующий переход может сработать, в результате чего объект перейдет в целевое состояние. Если же сторожевое условие принимает значение «ложь», то переход не может сработать, и при отсутствии других переходов объект не может перейти в целевое состояние по этому переходу. Однако вычисление истинности сторожевого условия происходит только после возникновения ассоциированного с ним события-триггера, инициирующего соответствующий переход.
В общем случае из одного состояния может быть несколько переходов с одним и тем же событием-триггером. При этом никакие два сторожевых условия не должны одновременно принимать значение «истина». Каждое из сторожевых условий необходимо вычислять всякий раз при наступлении соответствующего события-триггера.
Примером события-триггера может служить разрыв телефонного соединения с провайдером Интернет-услуг после окончания загрузки электронной почты клиентской почтовой программой (при удаленном доступе к Интернету). В этом случае сторожевое условие есть не что иное, как ответ на вопрос: «Пуст ли почтовый ящик клиента на сервере провайдера?». В случае положительного ответа «истина», следует отключить соединение с провайдером, что и делает автоматически почтовая программа-клиент. В случае отрицательного ответа «ложь», следует оставаться в состоянии загрузки почты и не разрывать телефонное соединение.
Графически фрагмент логики моделирования почтовой программы может быть представлен в виде следующей диаграммы состояний (рис. 6.5). Как можно заключить из контекста, в начальном состоянии программа не выполняется, хотя и имеется на компьютере пользователя. В момент ее включения происходит ее активизация. В этом состоянии программа может находиться неопределенно долго, пока пользователь ее не закроет, т. е. не выгрузит из оперативной памяти компьютера. После окончания активизации программа переходит в конечное состояние. В активном состоянии программы пользователь может читать сообщения электронной почты, создавать собственные послания и выполнять другие действия, не указанные явно на диаграмме.
Однако при необходимости получить новую почту, пользователь должен установить телефонное соединение с провайдером, что и показано явно на диаграмме верхним переходом. Другими словами, пользователь инициирует событие-триггер «установить телефонное соединение». В качестве параметра этого события выступает конкретный телефонный номер модемного пула провайдера. Далее следует проверка сторожевого условия «телефонное соединение установлено», которое следует понимать как вопрос. Только в случае положительного ответа «да», т. е. «истина», происходит переход почтовой программы-клиента из состояния «активизация почтовой программы» в состояние «загрузка почты с сервера провайдера». В противном случае (линия занята, неверный ввод пароля, отключенный логин) никакой загрузки почты не произойдет, и программа останется в прежнем своем состоянии.
Рис. 6.5. Диаграмма состояний для моделирования почтовой программы-клиента
Второй триггерный переход на диаграмме инициирует автоматический разрыв телефонного соединения с провайдером после окончания загрузки почты на компьютер пользователя. В' этом случае событие-триггер «закончить загрузку почты» происходит после проверки сторожевого условия «почтовый ящик на сервере пуст», которое также следует понимать в форме вопроса. При положительном ответе на этот вопрос (вся почта загружена или ее просто нет в ящике) почтовая программа прекращает загрузку почты и переходит в состояние активизации. В случае же отрицательного ответа загрузка почты будет продолжена.
Речь идет о том, что в отдельных случаях может произойти редкое, но весьма неприятное событие, получившее название «залипание модема». Это характерно для ситуации, когда вся почта загружена, а автоматический разрыв соединения не происходит. Тем не менее и этот случай можно предусмотреть в нашей модели, дополнив диаграмму еще одним переходом с аналогичным событием-триггером «закончить загрузку почты» и с новым сторожевым условием. Это сторожевое условие должно проверять максимально
Примечание 54
Конечно, рассмотренный пример имеет методический характер и иллюстрирует лишь основные особенности поведения почтовой программы-клиента в одном из ее аспектов. И даже этот аспект загрузки почты во многом условный, поскольку не учитывает реакцию программы на такие сообщения, как «линия занята» или самопроизвольный разрыв соединения.
допустимое время соединения для загрузки почты (например, 600 секунд) и может быть сформулировано в виде «время загрузки почты превышает 600 секунд». Модифицировать диаграмму состояний для этого случая предлагается самостоятельно в качестве упражнения.
Выражение действия
Выражение действия (action expression) выполняется в том и только в том случае, когда переход срабатывает. Представляет собой атомарную операцию (достаточно простое вычисление), выполняемую сразу после срабатывания соответствующего перехода до начала каких бы то ни было действий в целевом состоянии. Атомарность действия означает, что оно не может быть прервано никаким другим действием до тех пор, пока не закончится его выполнение. Данное действие может оказывать влияние как на сам объект, так и на его окружение, если это с очевидностью следует из контекста модели. Выражение записывается после знака "/" в строке текста, присоединенной к соответствующему переходу.