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

Детали структурной модели

Компоненты UserDriver и Main реализуют интерфейсы UD и Main соответственно, которые подсоединяются к ним через порты. Чтобы корректно функционировать, каждая из этих компонент нуждается в интерфейсе, определяемом другой компонентой. Все это можно видеть на рис. 7.2.

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

Рис. 7.4. Описание интерфейсов UD и Main

И, наконец, определим необходимые внутренние операции и атрибуты компоненты Main (см. рис. 7.5). Данные свойства компоненты, разумеется, являются private, т. е. не видны "наружу".

Рис. 7.5. Внутренние свойства компоненты Main

Выше было представлено целых три диаграммы (рис. 7.2, рис. 7.4, рис. 7.5), где описываются одни и те же сущности - компоненты Main и UserDriver, а также их интерфейсы. Конечно, это же самое можно было сделать, используя одну-единственную диаграмму, но получилось бы громоздко и существенно менее понятно.

Состояние

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

"Стабильность" состояния понимается в одном из следующих смыслов:

• ожидание компонентой внешних событий - обращений к ней других компонент, поступление сигналов к системе извне и пр.;
• выполнение компонентой некоторой фоновой деятельности, которая может быть прервана при получении компонентой какого-либо события, требующего обработки (эта деятельность может определяться, например, с помощью деятельности в состоянии - см. ниже);
• выполнение компонентой определенного связного "куска" штатной работы - например, прохождение определенного этапа алгоритма^{4Правда, в этом случае может не идти речи о состоянии как об отрезке жизни компоненты, прерываемом внешними событиями. Но такое понятие состояния часто используется, например, при спецификации сложных математических алгоритмов. Изучив раздел про состояние до конца, подумайте, как можно определить такое состояние с помощью UML .}.

Важно не только то, что компонента очередной раз перешла в стабильное положение, даже если сама стабильность по качеству одна и та же - например, простое ожидание. Существенно также то, что было до этого момента, т. е. история поведения компоненты. Пусть, например, компонента Main ожидает события срабатывания таймера в состояниях PLMNSearch и VPLMN. Закроем глаза на то, что она при этом выполняет различную "фоновую" деятельность. Реакция компоненты на сообщение timeout в этих состояниях будет разной (см. рис. 7.12).

Каждый миг жизни неповторим. В том числе, во многом, и для сложной программной компоненты - иначе, например, тестировщики так бы не мучались, воспроизводя ошибки системы. Однако в случае реактивных систем линии жизни программных компонент из бесконечных или очень длинных делаются относительно небольшими. Различные состояния компоненты факторизуют ее поведение, отбрасывая несущественные отличия и "склеивая", отождествляя, разные отрезки жизни, делая множество состояний из бесконечного конечным и обозримым. Например, пользователь мобильной трубки ввел правильный PUK и тогда он снова начинает вводить PIN. Компонента Main "не помнит", что все идет по второму кругу. Или по третьему, и так далее. Для нее все происходит так, как будто трубку только что включили.

В UML 2.0 у состояния возможны следующие атрибуты:

• имя;
• деятельность по входу ;
• деятельность по выходу ;
• деятельность в состоянии ;
• внутренний переход.

Примеры имен состояний можно увидеть на рис. 7.6 - PLMNSearch (поиск мобильной трубкой своей сети) и WaitingForPIN (ожидание мобильной станцией ввода пользователем PIN ). Если генерировать по диаграмме конечных автоматов программный код, то в диаграммах лучше использовать англоязычные идентификаторы, допустимые в целевом языке программирования.

Рис. 7.6. Примеры состояний

Деятельность по входу (entry activity) - это работа, выполняемая компонентой в данном состоянии сразу после входа, независимо от того перехода, посредством которого компонента попала в это состояние. Здесь может быть выполнено одно или несколько действий, но деятельность по входу не должна быть длительной, так как она не может быть прервана внешним событием. Пример деятельности по входу представлен на рис. 7.6. Там при входе в состояние PLMNSearch запускается таймер T, ограничивающий максимальное пребывание компоненты в этом состоянии временным интервалом 0.5 секунд (именно на этот временной интервал таймер T установлен, как будет рассказано ниже, при подробном обсуждении поведения компоненты Main ).

Деятельность по выходу (exit activity) - это работа, выполняемая в данном состоянии непосредственно перед выходом из него, независимо от того перехода, посредством которого компонента покидает это состояние. Здесь может быть выполнено одно или несколько действий, но пребывание компоненты здесь не должно быть длительным, так как деятельность по выходу не может быть прервана внешним событием. Пример деятельности по выходу представлен на рис. 7.6. Там при выходе из состояния PLMNSearch происходит остановка таймера T, так как этот таймер нужен для ограничения времени пребываний компоненты только в данном состоянии.

Деятельность в состоянии (do activity) - это работа, выполняемая компонентой, когда она находится в данном состоянии. Деятельность в состоянии может быть прервана событием, которое компонента обрабатывает в данном состоянии. С помощью данной конструкции удобно моделировать фоновую деятельность в состоянии. Деятельность в состоянии, как правило, выражается с помощью вызова операции компоненты. Она не прерывается внутренним переходом. Пример представлен на рис. 7.6. Там в состоянии PLNMSearch запускается операция PLMN_Search(), которая осуществляет поиск своей сети для данной мобильной трубки.

Внутренний переход (internal transition) - это переход, который происходит внутри состояния: компонента обрабатывает событие, не выходя из состояния. В результате выполнения такого перехода не выполняется деятельность по входу/выходу. Этот переход определяется в виде текста внутри состояния, а не в виде линии со стрелкой, т. к., собственно, перехода никуда не происходит. Пример представлен на рис. 7.6. В состоянии WaitingForPIN, после ввода владельцем трубки PIN и при условии, что этот PIN неверен и число сделанных попыток не превосходит трех, компонента остается в этом же состоянии. Если бы произошел выход и повторный вход в состояние WatingForPIN, то счетчик попыток (переменная n ) был бы обнулен.