Дж. Арлоу, А. Нейштадт - UML 2 и Унифицированный процесс - Практический объектно-ориентированный анализ и проектирование, страница 86
Описание файла
PDF-файл из архива "Дж. Арлоу, А. Нейштадт - UML 2 и Унифицированный процесс - Практический объектно-ориентированный анализ и проектирование", который расположен в категории "". Всё это находится в предмете "объектно-ориентированный анализ и проектирование" из 7 семестр, которые можно найти в файловом архиве МГУ им. Ломоносова. Не смотря на прямую связь этого архива с МГУ им. Ломоносова, его также можно найти и в других разделах. .
Просмотр PDF-файла онлайн
Текст 86 страницы из PDF
Конечные автоматыКонечный автомат моделирует динамическое поведение реактивногообъекта.И диаграммы деятельности, и диаграммы состояний моделируют аспекты динамического поведения системы, но их семантика и назначение в моделировании сильно различаются. Диаграммы деятельностибазируются на технологии сетей Петри (глава 14) и обычно используются для моделирования бизнеспроцессов, в которых принимают участие несколько объектов. В основе конечных автоматов UML лежитработа Харела (Harel) [Harel 1]. С их помощью обычно моделируетсяпредыстория жизненного цикла одного реактивного объекта. Онапредставляется в виде конечного автомата – автомата, который можетсуществовать в конечном числе состояний. В ответ на события конечный автомат четко осуществляет переходы между этими состояниями.Рис.
21.1. План главы21.8. Что мы узнали21.6.2. Ветвление переходов – псевдосостояние выбора21.6.1. Соединение переходов – переходное псевдосостояние21.6. Переходы21.5. Состояния21.5.1. Синтаксис состоянияизучаем переходыизучаем состояния21.4. Диаграммы состояний21.3. Конечные автоматы и UP21.7.4. События времени21.7.3. События изменения21.7.
Событияизучаем события21.7.2. Сигналы21.7.1. События вызова21.2.2. Конечные автоматы и классы21.2.1. Поведенческие и протокольные автоматы21.2. Конечные автоматы472Глава 21. Конечные автоматы21.2. Конечные автоматы473Три основных элемента автоматов – состояния, события и переходы:• состояние (state) – «условие или ситуация в жизни объекта, при которых он удовлетворяет некоторому условию, осуществляет некоторую деятельность или ожидает некоторого события» [Rumbaugh 1];• событие (event) – «описание заслуживающего внимания происшествия, занимающего определенное положение во времени и пространстве» [Rumbaugh 1];• переход (transition) – переход из одного состояния в другое в ответна событие.Намного подробнее состояния, события и переходы будут рассмотреныв этой главе несколько позже.Реактивный объект – это объект, в широком смысле этого слова, который предоставляет автомату контекст.
Реактивные объекты:• отвечают на внешние события (т. е. события, происходящие внеконтекста объекта);• могут генерировать и отвечать на внутренние события;• их жизненный цикл смоделирован как последовательность состояний, переходов и событий;• их текущее поведение может зависеть от предыдущего поведения.Реальный мир полон реактивных объектов, которые можно смоделировать с помощью автоматов.
В UMLмоделировании конечные автоматы обычно описываются в контексте конкретного классификатора.Затем конечный автомат моделирует поведение, общее для всех экземпляров этого классификатора. Конечные автоматы могут использоваться для моделирования динамического поведения таких классификаторов, как:• классы;• прецеденты;• подсистемы;• целые системы.21.2.1.
Поведенческие и протокольные автоматыСпецификация UML 2 определяет два типа конечных автоматов, имеющих общий синтаксис:• поведенческие автоматы;• протокольные автоматы.Поведенческие автоматы определяют поведение.Поведенческие автоматы с помощью состояний, переходов и событийопределяют поведение контекстного классификатора. Они могут использоваться, только если у контекстного классификатора есть некоторое поведение, которое можно смоделировать. У некоторых класси474Глава 21. Конечные автоматыфикаторов, например интерфейсов и портов, такого поведения нет;они просто описывают протокол использования. Состояния поведенческих автоматов могут определять одно или более действий, выполняемых при входе в состояние, нахождении в нем или выходе из него (см.раздел 21.5.1).Протокольные автоматы определяют протокол.Протокольные автоматы используют состояния, переходы и событиядля определения протокола контекстного классификатора.
Протоколвключает:• условия, при которых могут вызываться операции классификатораи его экземпляров;• результаты вызовов операций;• порядок вызовов операций.Протокольные автоматы ничего не сообщают о реализации этого поведения. Они только определяют, как оно представляется внешней сущности. Протокольные автоматы могут использоваться при описаниипротокола для всех классификаторов, включая те, которые не имеютреализации.
Состояния протокольных автоматов не могут определятьдействия; это дело поведенческих автоматов.На практике разработчики моделей редко проводят различие междуповеденческими и протокольными автоматами. Однако по желаниюпосле имени протокольного автомата можно указывать ключевое слово{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состояниепереходРис.