Арлоу Д., Нейштадт А. UML2 и Унифицированный процесс. Практический объектно-ориентированный анализ и проектирование
Подождите немного. Документ загружается.
474 Глава 21. Конечные автоматы
фикаторов, например интерфейсов и портов, такого поведения нет;
они просто описывают протокол использования. Состояния поведенче
ских автоматов могут определять одно или более действий, выполняе
мых при входе в состояние, нахождении в нем или выходе из него (см.
раздел 21.5.1).
Протокольные автоматы определяют протокол.
Протокольные автоматы используют состояния, переходы и события
для определения протокола контекстного классификатора. Протокол
включает:
• условия, при которых могут вызываться операции классификатора
и его экземпляров;
• результаты вызовов операций;
• порядок вызовов операций.
Протокольные автоматы ничего не сообщают о реализации этого пове
дения. Они только определяют, как оно представляется внешней сущ
ности. Протокольные автоматы могут использоваться при описании
протокола для всех классификаторов, включая те, которые не имеют
реализации. Состояния протокольных автоматов не могут определять
действия; это дело поведенческих автоматов.
На практике разработчики моделей редко проводят различие между
поведенческими и протокольными автоматами. Однако по желанию
после имени протокольного автомата можно указывать ключевое слово
{protocol}.
21.2.2. Конечные автоматы и классы
Конечные автоматы чаще всего используются для моделирования ди
намического поведения классов. На этом и сосредоточимся.
У каждого класса может быть только один поведенческий автомат, мо
делирующий все возможные состояния, события и переходы для всех
экземпляров этого класса.
У каждого класса также может быть один или более протокольных ав
томатов, хотя чаще они используются с не имеющими состояния клас
сификаторами, такими как интерфейсы и порты. Класс наследует про
токольные автоматы своих родителей.
Если у класса несколько конечных автоматов, все они должны быть
совместимы друг с другом.
Поведенческие и протокольные автоматы класса должны определять
поведение и протокол, необходимые всем прецедентам, в которых при
нимают участие экземпляры класса. Если обнаруживается, что преце
денту требуется протокол или поведение, не описанное в конечном ав
томате, это указывает на неполноту автоматов.
21.3. Конечные автоматы и UP 475
21.3. Конечные автоматы и UP
Конечные автоматы используются преимущественно в рабочем потоке
проектирования.
Как и диаграммы деятельностей, автоматы в UP применяются в не
скольких рабочих потоках. Они могут использоваться при анализе для
моделирования жизненного цикла классов, у которых есть представ
ляющие интерес состояния, например Order и BankAccount. При проек
тировании с их помощью могут моделироваться такие вещи, как па
раллелизм и имеющие состояние сеансовые компоненты Java. Мы да
же применяли их при определении требований, когда пытались по
нять сложный прецедент.
Как всегда, главный вопрос: добавит ли чтонибудь существенное в мо
дель создание конечного автомата? Если конечный автомат помогает
понять сложный жизненный цикл или поведение, его стоит создать.
В противном случае не стоит тратить время на его разработку.
Чаще всего конечные автоматы используются на завершающих этапах
фазы Уточнение и в начале фазы Построение, когда осуществляется
попытка настолько детально разобраться в классах системы, чтобы
можно было их реализовать. Подчас конечные автоматы являются не
оценимым подспорьем в детальной разработке системы.
По нашему мнению, самой большой проблемой при использовании ко
нечных автоматов является их тестирование. Рабочий поток тестиро
вания в UP выходит за рамки рассмотрения этой книги. Но здесь все
таки необходимо сказать несколько слов о тестировании конечных ав
томатов, поскольку этим аспектом тестирования приходится зани
маться аналитикам и проектировщикам. Как определить правиль
ность создания конечного автомата? В большинстве инструменталь
ных средств моделирования UML единственная возможность сделать
это – вручную провести поэтапный анализ. При этом ктото должен
выступать в роли автомата, чтобы можно было увидеть его реакцию
при разных условиях. Обычно лучше всего работать в небольшой груп
пе, где создатель автомата проводит остальных разработчиков модели
и экспертов по алгоритму автомата.
Однако лучший способ создания и тестирования автоматов – их имита
ция. Существует несколько инструментов, позволяющих сделать это,
например RealTime Studio от компании Artisan Software (www.arti+
sansw.com). С помощью имитации можно выполнить автомат и уви
деть его поведение. Некоторые инструментальные средства также по
зволяют генерировать из автоматов код и тесты. Для моделирования
бизнессистем подобные инструменты излишни, а вот для встроенных
систем реального времени, где у объектов могут быть сложное поведе
ние и жизненные циклы, они очень полезны.
476 Глава 21. Конечные автоматы
21.4. Диаграммы состояний
Для иллюстрации диаграмм состояний (state machine diagrams) давай
те рассмотрим простой пример. Один из самых наглядных объектов
реального мира, который постоянно переходит из состояния в состоя
ние, – электрическая лампочка. На рис. 21.2 показана передача собы
тий от переключателя к лампочке. Могут быть посланы два события:
turnOn (включить) (это событие моделирует подключение лампы в элект
рическую сеть) и turnOff (выключить) (выключает ток).
Диаграмма состояний содержит только один конечный автомат для
единственного реактивного объекта. В данном случае реактивный объ
ект – это система, состоящая из лампочки, переключателя и электро
питания. Диаграмма состояний может изображаться в явно обозна
ченной рамке, как показано на рис. 21.2, или существовать в неявных
рамках, предоставляемых средством моделирования.
По желанию имя конечного автомата можно начинать со слов State Ma
chine, но необходимость в этом возникает редко, поскольку автоматы
имеют легко опознаваемый синтаксис.
• Состояния обозначаются прямоугольниками со скругленными уг
лами, за исключением начального состояния (закрашенный кру
жок) и конечного состояния (бычий глаз).
• Переходы указывают на возможные пути между состояниями и мо
делируются с помощью стрелок.
• События записываются над инициируемыми ими переходами.
Базовая семантика также довольно проста. Когда реактивный объект,
находящийся в состоянии А, получает событие anEvent (какоето собы
тие), он может перейти в состояние В.
У каждого конечного автомата должно быть начальное состояние (за
крашенный кружок), обозначающее первое состояние последователь
ности. Если смена состояний не бесконечна, должно присутствовать
и конечное состояние (бычий глаз), которое завершает последователь
ность переходов. Обычно переход от начального псевдосостояния
к первому «настоящему» состоянию происходит автоматически. На
чальное псевдосостояние используется просто как удобный маркер
для обозначения начала ряда переходов состояний.
Light bulb {protocol}
On
turnOn
turnOff
состояние = Off
Off On
состояние
событие
переход
Off
burnOut
Рис. 21.2. Диаграмма состояний электрической лампочки
21.5. Состояния 477
Когда переключатель устанавливается в положение «On» (включен),
лампочке посылается событие turnOn (рис. 21.2). В диаграммах состоя
ний события считаются мгновенными, т. е. от переключателя к лам
почке событие доходит мгновенно. Мгновенные события существенно
упрощают теорию автоматов. Если бы события не были мгновенными,
возникали бы условия состязания, когда два события наперегонки
устремляются от источника к одному и тому же реактивному объекту.
Это состязание пришлось бы моделировать как некую разновидность
автомата!
События обуславливают переходы состояний.
Лампочка получает событие turnOn и в ответ на него меняет свое состоя
ние на On. В этом суть автоматов – объекты могут менять состояние
при получении события. Лампочка переходит в состояние Off при по
лучении события turnOff. В некоторый момент может произойти собы
тие burnOut (лампочка перегорает). Оно завершает конечный автомат.
Все элементы конечного автомата подробно рассматриваются в следу
ющих разделах.
21.5. Состояния
В книге «UML Reference Manual» [Rumbaugh 1] состояние определяет
ся как «условие или ситуация в жизни объекта, при которых он удов
летворяет некоторому условию, осуществляет некоторую деятель
ность или ожидает некоторого события». Состояние объекта меняется
со временем, но в любой отдельный момент оно определяется:
• значениями атрибутов объекта;
• отношениями с другими объектами;
• осуществляемыми деятельностями.
Состояние – это семантически значимое состояние объекта.
С течением времени объекты обмениваются сообщениями. Эти сооб
щения и являются событиями, которые могут привести к изменению
состояния объекта. Важно очень точно осознать, что мы понимаем под
«состоянием». В случае электрической лампочки можно было бы
предположить (если бы мы были специалистами в квантовой физике),
что каждое изменение любого атома или мельчайшей частицы лам
почки образует новое состояние. Строго говоря, это верно, но привело
бы нас к несметному числу состояний, по большей части, идентичных.
Должны быть выявлены значимые состояния системы.
478 Глава 21. Конечные автоматы
Однако с точки зрения пользователя значимыми состояниями лампоч
ки являются On, Off и конечное состояние, когда она перегорает. Выяв
ление значимых состояний системы – ключ к успешному моделирова
нию состояний.
В качестве другого примера рассмотрим простой класс Color, приведен
ный на рис. 21.3.
Если предположить, что атрибуты red (красный), green (зеленый) и blue
(синий) могут принимать значения от 0 до 255, тогда на основании толь
ко этих значений у объектов данного класса может быть 256
× 256 × 256 =
= 16777216 возможных состояний. Вот это была бы диаграмма состоя
ний! Однако мы должны задать себе вопрос: в чем основная семантиче
ская разница между каждым из этих состояний? Ответ: никакой раз
ницы. Каждое из 16777216 возможных состояний представляет цвет
и только. В сущности, автомат этого класса совсем неинтересен, по
скольку все возможные состояния могут быть смоделированы одним
единственным состоянием.
То есть предпосылкой моделирования в виде автомата должно быть
наличие семантики «отличия, которое различает» состояния. Конеч
ные автоматы должны повышать ценность модели. Примеры таких
автоматов будут даны в этой и следующей главах.
21.5.1. Синтаксис состояния
UMLсинтаксис состояния представлен на рис. 21.4.
Каждое состояние поведенческого автомата может содержать нуль
или более действий и деятельностей. У состояний протокольных авто
матов нет действий или деятельностей.
Действия являются мгновенными и непрерывными.
Действия считаются мгновенными и непрерываемыми, тогда как дея
тельности занимают конечное время и могут быть прерваны. Каждое
действие в состоянии ассоциируется с внутренним переходом, ини
циируемым событием. В состоянии может быть любое число действий
и внутренних переходов.
Внутренний переход позволяет зафиксировать тот факт, что произош
ло чтото, заслуживающее отражения в модели, но не обуславливаю
Color
red : int
green : int
blue : int
Рис. 21.3. Класс Color
21.6. Переходы 479
щее (или не настолько важное, чтобы моделировать это как) переход
в новое состояние. Например, на рис. 21.4 нажатие одной из клавиш
клавиатуры, конечно, является заслуживающим внимания событием,
но оно не приводит к переходу из состояния EnteringPassword (ввод паро
ля). Мы моделируем это как внутреннее событие keypress (нажатие кла
виши), которое обусловливает внутренний переход, инициирующий
действие отобразить “*“.
Два специальных действия – вход и выход – ассоциированы со специ
альными событиями entry и exit. У этих двух событий особая семанти
ка. Событие entry происходит мгновенно и автоматически при входе
в состояние. Это первое, что происходит, когда осуществляется вход
в состояние. Это событие обусловливает выполнение ассоциированно
го с ним действия на входе. Событие exit – самое последнее, что проис
ходит мгновенно и автоматически при выходе из состояния. Обуслов
ливает выполнение ассоциированного действия на выходе.
Деятельности длятся конечный промежуток времени и могут быть пре
рваны.
Деятельности, с другой стороны, длятся конечный промежуток време
ни и могут быть прерваны по получении события. Деятельность обо
значается ключевым словом do (делать). В отличие от действий, кото
рые всегда завершаются, потому что они атомарны, деятельность мож
но прервать до того, как завершилось ее выполнение.
21.6. Переходы
UMLсинтаксис переходов для поведенческих автоматов представлен
на рис. 21.5.
Переходы показывают движение между состояниями.
EnteringPassword
entry/ показать диалог для ввода пароля
exit/ проверить пароль
keypress/ отобразить “*”
help/ вывести подсказку
do/ принять пароль
входное и выходное
действия
внутренние
переходы
внутренняя
имя состояния
синтаксис действия: имяСобытия/некотороеДействие
синтаксис деятельности: do/некотораяДеятельность
деятельность
Рис. 21.4. Синтаксис состояния
480 Глава 21. Конечные автоматы
Синтаксис переходов в поведенческом автомате прост и может исполь
зоваться для внешних переходов (изображаются стрелками) или внут
ренних переходов (изображаются вложенными в состояние). Каждый
переход имеет три необязательных элемента.
1. Нуль или более событий – определяют внешнее или внутреннее
происшествие, которое может инициировать переход.
2. Нуль или одно сторожевое условие – логическое выражение, кото
рое должно быть выполнено (иметь значение true), прежде чем мо
жет произойти переход. Условие указывают после событий.
3. Нуль или более действий – часть работы, ассоциированная с пере
ходом и выполняемая при срабатывании перехода.
Рисунок 21.5 можно прочитать так: «При возникновении (события1
ИЛИ события2), если (сторожевоеУсловие является истинным), выполнить
действие и немедленно перейти в состояние B».
В действиях могут использоваться переменные, область действия ко
торых – конечный автомат. Например:
actionPerformed( actionEvent )/ command = actionEvent.getActionCommand()
В приведенном примере actionPerformed( actionEvent ) – событие, генери
руемое нажатием кнопки в Java GUI. При получении этого события
выполняется действие по сохранению имени кнопки в переменной
command.
Синтаксис переходов протокольных автоматов немного другой, как
показано на рис. 21.6.
AB
событие1, событие2 [сторожевоеУсловие]/ действие
Поведенческий автомат
Рис. 21.5. Синтаксис переходов для поведенческих автоматов
CD
[предусловие] событие1, событие2/ [постусловие]
Протокольный автомат {protocol}
Рис. 21.6. Синтаксис переходов для протокольных автоматов
21.6. Переходы 481
• Здесь нет действия, поскольку задается протокол, а не реализация.
• Сторожевое условие заменено предусловиями и постусловиями. Об
ратите внимание, что предусловие указывается перед событиями,
а постусловие – после слэша.
Как в поведенческих, так и в протокольных автоматах переход, осуще
ствляемый без события, называют автоматическим переходом (auto+
matic transition). Автоматический переход не ожидает события и сраба
тывает при выполнении его сторожевого условия или предусловия.
21.6.1. Соединение переходов – переходное
псевдосостояние
Переходные псевдосостояния объединяют или разветвляют переходы.
Переходы могут быть соединены переходными псевдосостояниями
(junction pseudo+states). Это точки слияния или ветвления переходов.
Они изображаются в виде закрашенных кружков с одним или более
входными переходами и одним или более исходящими переходами.
Пример на рис. 21.7 показывает конечный автомат для класса Loan,
который был представлен в разделе 18.12.2. Loan моделирует получе
ние книги в библиотеке. Конечный автомат Loan имеет простой узел
слияния. Это наиболее распространенное использование переходных
псевдосостояний.
У переходного псевдосостояния может быть несколько выходных пе
реходов. В этом случае каждый исходящий переход должен быть за
щищен взаимоисключающим сторожевым условием, обеспечиваю
щим возможность срабатывания только одного перехода. Пример
представлен на рис. 21.8. Здесь конечный автомат для класса Loan был
расширен, чтобы обработать случай, когда выдача книги может быть
продлена. Бизнесправило состоит в том, что для продления срока воз
врата выданная книга должна быть предъявлена библиотеке. Таким
образом, события returnBook попрежнему действительны.
OnLoan
Overdue
Terminated
[after maximumDuration]
returnBook
простой узел слияния
Loan
returnBook
FineDue
payFine
Рис. 21.7. Конечный автомат класса Loan имеет простой узел слияния
482 Глава 21. Конечные автоматы
21.6.2. Ветвление переходов – псевдосостояние выбора
Для представления простого ветвления без слияния необходимо ис
пользовать псевдосостояние выбора (choice pseudo+state), как показано
на рис. 21.9.
Псевдосостояние выбора направляет поток конечного автомата соглас
но заданным условиям.
Псевдосостояние выбора позволяет направлять поток конечного авто
мата согласно условиям, заданным для исходящих переходов. Напри
OnLoan
Overdue
Terminated
[after maximumDuration]
returnBook
узел слияния
и ветвления
Loan
returnBook
FineDue
payFine
[extend]
[!extend]
Рис. 21.8. Конечный автомат класса Loan имеет узел слияния и ветвления
Unpaid
FullyPaid PartiallyPaidOverPaid
[payment > balance] [payment < balance]
acceptPayment
acceptPayment
makeRefund
BankLoan
псевдосостояние выбора
[payment = balance]
Рис. 21.9. Реализация ветвления без слияния с помощью псевдосостояния
выбора
21.7. События 483
мер, на рис. 21.9 показан поведенческий автомат простого класса Bank
Loan (банковская ссуда). При получении события acceptPayment (принят
платеж) объект BankLoan переходит из состояния Unpaid (не оплачен)
в одно из трех состояний – FullyPaid (полностью оплачен), OverPaid (пере
плачен) или PartiallyPaid (частично оплачен) – в зависимости от соотно
шения объема платежа (payment) и неоплаченного баланса BankLoan.
Условия, налагаемые на исходящие переходы псевдосостояния выбо
ра, должны быть взаимоисключающими, чтобы гарантировать в лю
бой момент времени срабатывание только одного из них.
21.7. События
События инициируют переходы.
UML определяет событие как «описание заслуживающего внимания
происшествия, занимающего определенное положение во времени
и пространстве». События инициируют переходы в автоматах. События
могут быть указаны вне состояний на переходах, как на рис. 21.10, или
внутри состояний, как на рис. 21.11.
Существует четыре семантически различных типа событий:
• событие вызова;
• сигнал;
• событие изменения;
• событие времени.
21.7.1. События вызова
Событие вызова (call event) – это запрос на вызов конкретной операции
экземпляра контекстного класса.
Событие вызова – это запрос на вызов конкретной операции.
Сигнатура события вызова должна быть аналогичной сигнатуре опера
ции контекстного класса автомата. Получение события вызова – это
Off
On
событие
turnOff turnOn
Рис. 21.10. События указаны вне состояний на переходах