Визуальное моделирование систем реального времени, часть II

Cобытие

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

• изменение значения некоторого булевского выражения (change event);
• срабатывание некоторого таймера, то есть прием специального сообщения (timeout);
• получение компонентой сообщения (signal event);
• вызов операции компоненты извне через ее интерфейс (call event);
• обращение извне к переменным компоненты через ее интерфейс.

Переход

Конструкция конечного автомата, которая определяет переход компоненты из одного состояния в другое в связи с возникновением определенного события, так и называется - переход (transition). Он инициируется событием, представляет собой цепочку действий (actions) по обработке данного события и завершается новым состоянием компоненты. Пример показан на рис. 7.7.

Рис. 7.7. Пример перехода

После того как компонента Main, находясь в состоянии WaitingForPIN, получила сообщение PIN, она переходит в состояние PLMNSearch (поиск сети), совершая в переходе единственное действие - посылку сообщения Search_for_PLMN компоненте UserDriver, чтобы та могла показать соответствующую картинку на дисплее телефона.

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

Выход компоненты из состояния может зависеть не только от события, но и от значения охраняющего условия (guarded condition) - логического выражения, которое связано с переходом и проверяется перед тем, как компонента войдет в переход. Если охраняющее условие не выполнено (имеет значение "ложь"), то перехода не происходит. Так, например, на рис. 7.8 показано, что переход в состояние PLMNSearch выполняется не просто после получения PIN, а только после его проверки и в случае, когда он правильный. Вызов функции CheckPIN(), возвращающей булевское значение, выступает здесь в роли охраняющего условия.

Рис. 7.8. Пример охраняющего условия

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

• посылка сообщения;
• вызов операции другой компоненты;
• вызов операции этой же компоненты;
• таймерная операция;
• произвольное выражение на языке реализации (например, присваивание);
• логическое ветвление потока управления.

Последний вид действия авторы UML все-таки "вытянули" на модельный уровень, назвав эту конструкцию выбор (choice). Пример показан на рис. 7.9.

Рис. 7.9. Пример конструкции выбор

После того, как пользователь мобильного телефона ввел PIN, возможно три ситуации: (i) PIN введен правильно; (ii) PIN введен неправильно и число попыток не превышает трех; (iii) PIN введен неправильно и число попыток равно трем. Первая и третья ситуация специфицированы с применением конструкции выбора, а вторая определена с помощью внутреннего перехода (и поэтому в конструкции "выбор" всего две ветки).

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

Таймер

При моделировании систем реального времени очень важной является конструкция таймер (timer). Она позволяет наложить временные ограничения на исполнение тех или иных действий, ожидание тех или иных событий и пр. При получении сообщения timeout (срабатывание таймера) компонента "понимает", что время какого-то ограничения истекло и надо соответствующим образом действовать, прервав предыдущую активность (или неактивность, если компонента ожидала какого-то события).

У таймера есть следующие операции:

• установить - позволяет установить конкретный таймер на определенное время, например, на 0,5 секунд;
• запустить - таймер начинает "тикать";
• остановить - запущенный таймер останавливается; это нужно, когда ожидаемое событие или выполняемые действия уложились в заданный временной интервал и поэтому теперь нет необходимости дожидаться события timeout; при следующем после остановки запуске таймер стартует с нулевой временной отметки.

Событие "таймер Т истек" (получение компонентой сообщения timeout с именем истекшего таймера Т ) означает, что с момента старта Т времени прошло ровно столько, на какое он был установлен. Обработчики события timeout должны быть описаны в поведении компоненты.

На рис. 7.10 приводится пример работы с таймером. При входе в состояние VPLMN (мобильной трубке доступен ограниченный сервис некоторой чужой станции, так как своя не найдена) таймер T стартует (установлен на временной интервал в 0,5 секунд он был когда-то раньше). Пробыв в этом состоянии положенное время (то есть те самые 0,5 секунд), трубка снова начинает поиск своей сети - а вдруг абонент, передвигаясь, снова оказался в зоне ее доступа? При выходе из данного состояния таймер останавливается - это сделано для обработки ситуаций, когда выход из данного состояния происходит не по timeout, а по другому событию. Будем считать, что остановка истекшего таймера также является корректной - при этом ничего не происходит, но такая возможность позволяет уменьшить сложность спецификации.

Рис. 7.10. Пример работы с таймером

Групповые состояния

Рассмотрим один интересный вид состояния, который не вошел в UML, но был в языке SDL - групповые состояния.

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

На рис. 7.11, а показано, что компонента Main в состояниях WaitingForPIN, WaitingForPUK, ServiceBlocked, VPLMN, Idle одинаково реагирует на запрос по обработке экстренного вызова. При получении сообщения EmergencyCall она переходит в состояние ECProcessing, где происходит обработка этого вызова. После этого происходит возврат в исходное состояние. Этот возврат - не вполне обычный переход, так как, фактически, групповое состояние - это псевдосостояние. Перейти в него, как в обычное состояние, нельзя, в него можно лишь вернуться, как показано в нашем примере. Этот возврат означает, что компонента оказывается в том же состоянии, из которого она перешла в состояние ECProcessing. Реализация всего этого в программном коде будет представлена ниже.

На рис. 7.11, б представлен переход из группового состояния-звездочки: в любом состоянии компонента Main должна обработать сообщение о выключении трубки (пользователь нажал на кнопку "выключить").

Рис. 7.11. Переход из группового состояния

Групповые состояния - это еще один вид "синтаксического сахара": они могут быть выражены другими конструкциями языка (подумайте, как) и вводятся исключительно для удобства, а не для увеличения выразительной силы UML.

Реализационная диаграмма конечных автоматов

На рис. 7.12 представлен формальный вариант спецификации поведения компоненты Main, по которому осуществляется генерация исполняемого кода.

Рис. 7.12. Полная спецификация поведения компоненты Main

Эта диаграмма получается из диаграммы, представленной на рис. 7.3, путем выполнения следующих действий:

• замена всех русских идентификаторов на английские; в частности, термин "сеть" заменен на стандартное сокращение PLMN (Public Land Mobile Network)^{5PLMN - это мобильная сеть, коммутация абонентов внутри которой не требует роуминга. Например, cеть компании "МегаФон" в Санкт-Петербурге и Ленинградской области образует одну PLMN.} ;
• усложнен переход - вместо неформальной подписи на русском языке используются следующие модельные конструкции: получение сообщения, охраняющие условия, посылка сообщений, а также выбор;
• в состояния введена (разумеется, там, где нужно) деятельность по входу/выходу и в состоянии, внутренние переходы ;
• введен таймер с именем T ;
• синтаксис выражений, вызовов процедур и пр. текстовых вставок приведен к формату целевого языка, в который будет производиться генерация - языку С