UML2 и унифицированный процесс. Джим арлоуайла нейштадтпрактический объектно ориентированныйанализ и проектированиеu
 Скачать 6.08 Mb.
|
|
• событие (event) – «описание заслуживающего внимания происше ствия, занимающего определенное положение во времени и про странстве» [Rumbaugh 1]; • переход (transition) – переход из одного состояния в другое в ответ на событие. Намного подробнее состояния, события и переходы будут рассмотрены в этой главе несколько позже. Реактивный объект – это объект, в широком смысле этого слова, кото рый предоставляет автомату контекст. Реактивные объекты: • отвечают на внешние события (т. е. события, происходящие вне контекста объекта); • могут генерировать и отвечать на внутренние события; • их жизненный цикл смоделирован как последовательность состоя ний, переходов и событий; • их текущее поведение может зависеть от предыдущего поведения. Реальный мир полон реактивных объектов, которые можно смодели ровать с помощью автоматов. В UML моделировании конечные авто маты обычно описываются в контексте конкретного классификатора. Затем конечный автомат моделирует поведение, общее для всех экзем пляров этого классификатора. Конечные автоматы могут использо ваться для моделирования динамического поведения таких классифи каторов, как: • классы; • прецеденты; • подсистемы; • целые системы. 21.2.1. Поведенческие и протокольные автоматы Спецификация UML 2 определяет два типа конечных автоматов, име ющих общий синтаксис: • поведенческие автоматы; • протокольные автоматы. Поведенческие автоматы определяют поведение. Поведенческие автоматы с помощью состояний, переходов и событий определяют поведение контекстного классификатора. Они могут ис пользоваться, только если у контекстного классификатора есть неко торое поведение, которое можно смоделировать. У некоторых класси 474 Глава 21. Конечные автоматы фикаторов, например интерфейсов и портов, такого поведения нет; они просто описывают протокол использования. Состояния поведенче ских автоматов могут определять одно или более действий, выполняе мых при входе в состояние, нахождении в нем или выходе из него (см. раздел 21.5.1). Протокольные автоматы определяют протокол. Протокольные автоматы используют состояния, переходы и события для определения протокола контекстного классификатора. Протокол включает: • условия, при которых могут вызываться операции классификатора и его экземпляров; • результаты вызовов операций; • порядок вызовов операций. Протокольные автоматы ничего не сообщают о реализации этого пове дения. Они только определяют, как оно представляется внешней сущ ности. Протокольные автоматы могут использоваться при описании протокола для всех классификаторов, включая те, которые не имеют реализации. Состояния протокольных автоматов не могут определять действия; это дело поведенческих автоматов. На практике разработчики моделей редко проводят различие между поведенческими и протокольными автоматами. Однако по желанию после имени протокольного автомата можно указывать ключевое слово {protocol}. 21.2.2. Конечные автоматы и классы Конечные автоматы чаще всего используются для моделирования ди намического поведения классов. На этом и сосредоточимся. У каждого класса может быть только один поведенческий автомат, мо делирующий все возможные состояния, события и переходы для всех экземпляров этого класса. У каждого класса также может быть один или более протокольных ав томатов, хотя чаще они используются с не имеющими состояния клас сификаторами, такими как интерфейсы и порты. Класс наследует про токольные автоматы своих родителей. Если у класса несколько конечных автоматов, все они должны быть совместимы друг с другом. Поведенческие и протокольные автоматы класса должны определять поведение и протокол, необходимые всем прецедентам, в которых при нимают участие экземпляры класса. Если обнаруживается, что преце денту требуется протокол или поведение, не описанное в конечном ав томате, это указывает на неполноту автоматов. 21.3. Конечные автоматы и UP 475 21.3. Конечные автоматы и UP Конечные автоматы используются преимущественно в рабочем потоке проектирования. Как и диаграммы деятельностей, автоматы в UP применяются в не скольких рабочих потоках. Они могут использоваться при анализе для моделирования жизненного цикла классов, у которых есть представ ляющие интерес состояния, например Order и BankAccount. При проек тировании с их помощью могут моделироваться такие вещи, как па раллелизм и имеющие состояние сеансовые компоненты Java. Мы да же применяли их при определении требований, когда пытались по нять сложный прецедент. Как всегда, главный вопрос: добавит ли что нибудь существенное в мо дель создание конечного автомата? Если конечный автомат помогает понять сложный жизненный цикл или поведение, его стоит создать. В противном случае не стоит тратить время на его разработку. Чаще всего конечные автоматы используются на завершающих этапах фазы Уточнение и в начале фазы Построение, когда осуществляется попытка настолько детально разобраться в классах системы, чтобы можно было их реализовать. Подчас конечные автоматы являются не оценимым подспорьем в детальной разработке системы. По нашему мнению, самой большой проблемой при использовании ко нечных автоматов является их тестирование. Рабочий поток тестиро вания в UP выходит за рамки рассмотрения этой книги. Но здесь все таки необходимо сказать несколько слов о тестировании конечных ав томатов, поскольку этим аспектом тестирования приходится зани маться аналитикам и проектировщикам. Как определить правиль ность создания конечного автомата? В большинстве инструменталь ных средств моделирования UML единственная возможность сделать это – вручную провести поэтапный анализ. При этом кто то должен выступать в роли автомата, чтобы можно было увидеть его реакцию при разных условиях. Обычно лучше всего работать в небольшой груп пе, где создатель автомата проводит остальных разработчиков модели и экспертов по алгоритму автомата. Однако лучший способ создания и тестирования автоматов – их имита ция. Существует несколько инструментов, позволяющих сделать это, например Real Time 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. A B событие1, событие2 [сторожевоеУсловие]/ действие Поведенческий автомат Рис. 21.5. Синтаксис переходов для поведенческих автоматов C D [предусловие] событие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 T erminated [after maximumDuration] returnBook простой узел слияния Loan returnBook FineDue payFine |