Джим Арлоу, Айла Нейштадт - UML 2 и Унифицированный процесс. Практический объектно-ориентированный анализ и проектирование (1037782), страница 86

Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла (страница 86)

Протоколвключает:• условия, при которых могут вызываться операции классификатораи его экземпляров;• результаты вызовов операций;• порядок вызовов операций.Протокольные автоматы ничего не сообщают о реализации этого поведения. Они только определяют, как оно представляется внешней сущности. Протокольные автоматы могут использоваться при описаниипротокола для всех классификаторов, включая те, которые не имеютреализации. Состояния протокольных автоматов не могут определятьдействия; это дело поведенческих автоматов.На практике разработчики моделей редко проводят различие междуповеденческими и протокольными автоматами. Однако по желаниюпосле имени протокольного автомата можно указывать ключевое слово{protocol}.21.2.2.

Конечные автоматы и классыКонечные автоматы чаще всего используются для моделирования динамического поведения классов. На этом и сосредоточимся.У каждого класса может быть только один поведенческий автомат, моделирующий все возможные состояния, события и переходы для всехэкземпляров этого класса.У каждого класса также может быть один или более протокольных автоматов, хотя чаще они используются с не имеющими состояния классификаторами, такими как интерфейсы и порты.

Класс наследует протокольные автоматы своих родителей.Если у класса несколько конечных автоматов, все они должны бытьсовместимы друг с другом.Поведенческие и протокольные автоматы класса должны определятьповедение и протокол, необходимые всем прецедентам, в которых принимают участие экземпляры класса. Если обнаруживается, что прецеденту требуется протокол или поведение, не описанное в конечном автомате, это указывает на неполноту автоматов.21.3. Конечные автоматы и UP47521.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 Machine, но необходимость в этом возникает редко, поскольку автоматыимеют легко опознаваемый синтаксис.• Состояния обозначаются прямоугольниками со скругленными углами, за исключением начального состояния (закрашенный кружок) и конечного состояния (бычий глаз).• Переходы указывают на возможные пути между состояниями и моделируются с помощью стрелок.• События записываются над инициируемыми ими переходами.Базовая семантика также довольно проста.

Когда реактивный объект,находящийся в состоянии А, получает событие anEvent (какоето событие), он может перейти в состояние В.У каждого конечного автомата должно быть начальное состояние (закрашенный кружок), обозначающее первое состояние последовательности. Если смена состояний не бесконечна, должно присутствоватьи конечное состояние (бычий глаз), которое завершает последовательность переходов. Обычно переход от начального псевдосостоянияк первому «настоящему» состоянию происходит автоматически.

Начальное псевдосостояние используется просто как удобный маркердля обозначения начала ряда переходов состояний.состояние = OffLight bulb {protocol}событиеturnOnOnOffturnOffburnOutOffOnсостояниепереходРис. 21.2. Диаграмма состояний электрической лампочки21.5. Состояния477Когда переключатель устанавливается в положение «On» (включен),лампочке посылается событие turnOn (рис.

21.2). В диаграммах состояний события считаются мгновенными, т. е. от переключателя к лампочке событие доходит мгновенно. Мгновенные события существенноупрощают теорию автоматов. Если бы события не были мгновенными,возникали бы условия состязания, когда два события наперегонкиустремляются от источника к одному и тому же реактивному объекту.Это состязание пришлось бы моделировать как некую разновидностьавтомата!События обуславливают переходы состояний.Лампочка получает событие turnOn и в ответ на него меняет свое состояние на On. В этом суть автоматов – объекты могут менять состояниепри получении события. Лампочка переходит в состояние Off при получении события turnOff.

В некоторый момент может произойти событие burnOut (лампочка перегорает). Оно завершает конечный автомат.Все элементы конечного автомата подробно рассматриваются в следующих разделах.21.5. СостоянияВ книге «UML Reference Manual» [Rumbaugh 1] состояние определяется как «условие или ситуация в жизни объекта, при которых он удовлетворяет некоторому условию, осуществляет некоторую деятельность или ожидает некоторого события». Состояние объекта меняетсясо временем, но в любой отдельный момент оно определяется:• значениями атрибутов объекта;• отношениями с другими объектами;• осуществляемыми деятельностями.Состояние – это семантически значимое состояние объекта.С течением времени объекты обмениваются сообщениями. Эти сообщения и являются событиями, которые могут привести к изменениюсостояния объекта.

Важно очень точно осознать, что мы понимаем под«состоянием». В случае электрической лампочки можно было быпредположить (если бы мы были специалистами в квантовой физике),что каждое изменение любого атома или мельчайшей частицы лампочки образует новое состояние. Строго говоря, это верно, но привелобы нас к несметному числу состояний, по большей части, идентичных.Должны быть выявлены значимые состояния системы.478Глава 21. Конечные автоматыColorred : intgreen : intblue : intРис. 21.3. Класс ColorОднако с точки зрения пользователя значимыми состояниями лампочки являются On, Off и конечное состояние, когда она перегорает.

Выявление значимых состояний системы – ключ к успешному моделированию состояний.В качестве другого примера рассмотрим простой класс Color, приведенный на рис. 21.3.Если предположить, что атрибуты red (красный), green (зеленый) и blue(синий) могут принимать значения от 0 до 255, тогда на основании только этих значений у объектов данного класса может быть 256 × 256 × 256 == 16777216 возможных состояний. Вот это была бы диаграмма состояний! Однако мы должны задать себе вопрос: в чем основная семантическая разница между каждым из этих состояний? Ответ: никакой разницы. Каждое из 16777216 возможных состояний представляет цвети только.

Характеристики

Список файлов книги