10672

Практическая работа. Моделирование динамики системы: потоки управления

Практическая работа

Информатика, кибернетика и программирование

Практическая работа №6 Моделирование динамики системы: потоки управления Диаграмма состояний Цель работы: изучение понятий автомат состояние переход диаграммы состояний. Приобретение основных навыков построения диаграмм состояний в программной среде StarUML. Реал...

Русский

2013-03-30

288.5 KB

5 чел.

Практическая работа №6

Моделирование динамики системы: потоки управления (Диаграмма состояний)

Цель работы: изучение понятий автомат, состояние, переход, диаграммы состояний. Приобретение основных навыков построения диаграмм состояний в программной среде StarUML.

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

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

События могут быть синхронными или асинхронными, и их моделирование является составной частью моделирования процессов и нитей.

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

UML предоставляет средства для графического представления событий, как видно из рисунка 6.1. Такая нотация позволяет визуализировать объявления событий (например, сигнала ТрубкаПовешена) и показать, как наступление события приводит к переключению между состояниями (например, сигнал ТрубкаПовешена вызывает переход телефона из состояния Активен в состояние Ожидание).


Рисунок 6.1
 - События

События могут быть:

  •  внутренними
  •  внешними.

Внешние события передаются между системой и ее актерами. Примерами могут служить нажатие кнопки или прерывание от датчика столкновений. Внутренние события передаются между объектами, существующими внутри самой системы. Так, исключение, генерируемое при переполнении, является примером внутреннего события.

В UML можно моделировать четыре вида событий:

  •  сигналы,
  •  вызовы
  •  истечение промежутка времени
  •  изменение состояния.

Сигнал - это именованный объект, который асинхронно возбуждается одним объектом и принимается (перехватывается) другим. Исключения, которые поддерживаются в большинстве современных языков программирования, - это наиболее распространенный вид внутренних сигналов, который вам придется моделировать. (Создание и уничтожение объектов - это тоже разновидность сигналов)

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

Примечание: Атрибуты сигнала выступают в роли его параметров. Например, при посылке сигнала Столкновение можно указать значения его атрибутов в виде параметров: Столкновение (3,5).

Сигнал может быть послан как действие перехода (изменения) состояния в автомате или как отправка сообщения при взаимодействии. При выполнении операции тоже могут посылаться сигналы. На практике, когда моделируется класс или интерфейс, важной частью спецификации поведения является указание сигналов, которые он может посылать. В UML связь между операцией и событиями, которые она может посылать, моделируется с помощью отношения зависимости со стереотипом send.

Как показано на рисунке 6.2, в UML сигналы (и исключения) моделируются стереотипными классами. Для указания на то, что некоторая операция посылает сигнал, можно воспользоваться зависимостью со стереотипом send.


Рисунок 6.2
 - Сигналы

Если событие сигнала представляет возбуждение сигнала, то событие вызова предназначено для описания выполнения операции. И в том, и в другом случае событие может вызвать переход состояния в автомате.

В то время как сигнал является событием асинхронным, событие вызова обычно синхронно. Это означает, что, когда один объект инициирует выполнение операции на другом объекте, у которого есть свой автомат, управление передается от отправителя получателю, срабатывает соответствующий переход, затем операция завершается, получатель переходит в новое состояние и возвращает управление отправителю.

По рисунку 6.3 видно, что в модели событие вызова неотличимо от события сигнала. В обоих случаях событие вместе со своими параметрами выглядит как триггер для перехода состояния.


Рисунок 6.3 - События вызова

Примечание: Хотя визуально события сигнала и вызова неотличимы, разница совершенно отчетливо проявляется на заднем плане модели. Получатель события, конечно же, знает о различии (путем объявления операции в своем списке операций). Сигнал, как правило, обрабатывается на уровне автомата, а событие вызова - методом. Для перехода от события к сигналу или операции можно воспользоваться инструментальной программой. 

Событие времени представляет собой истечение промежутка времени. На рисунке 6.4 показано, что в UML событие времени моделируется с помощью ключевого слова after (после), за которым следует выражение, вычисляющее некоторый промежуток времени. Выражение может быть простым (например, after 2 seconds) или сложным (например, after 1 ms c момента выхода из состояния Ожидание). Если явно не указано противное, то отсчет времени начинается с момента входа в текущее состояние.


Рисунок 6.4 - События времени и изменения

С помощью события изменения описывается изменение состояния или выполнение некоторого условия. На рисунок 6.4 показано, что в UML событие изменения моделируется посредством ключевого слова when, за которым следует булевское выражение. Такое выражение может использоваться для обозначения абсолютного момента времени (например, when time=11: 59) или проверки условия (например, when altitude < 1000).

Примечание: Хотя событие изменения моделирует условие, проверяемое непрерывно, обычно, проанализировав ситуацию, можно выявить дискретные моменты времени, когда это условие нужно проверять. 

В событиях сигнала и вызова участвуют по крайней мере два объекта: объект, посылающий сигнал или инициирующий операцию, и объект, которому событие адресовано. Поскольку сигналы по своей природе асинхронны, а асинхронные вызовы сами по себе являются сигналами, то семантика событий перекликается с семантикой активных и пассивных объектов.

Экземпляр любого класса может посылать сигнал принимающему объекту или инициировать в нем операцию. Отправив сигнал получателю, он продолжает свой поток управления, не дожидаясь от него ответа. Например, после того как актер, взаимодействующий с банкоматом, пошлет сигнал нажатьКнопку, он может выполнять другие действия независимо от того, что делает система, которой был послан сигнал. Напротив, если объект инициирует операцию, он должен дождаться ответа от получателя. Допустим, в трейдерской системе экземпляр класса Трейдер может инициировать операцию подтвердитьТранзакцию в некотором экземпляре класса Сделка, косвенно изменив тем самым состояние последнего. Если это синхронный вызов, то объект Трейдер будет ждать, пока операция закончится.

Примечание: В некоторых случаях возникает необходимость в изображении объекта, который посылает сигнал сразу нескольким объектам (мулъти-вещание, Multicasting) или всем ожидающим объектам в системе (широковещание, Broadcasting). Для моделирования мулътивещания следует изобразить объект, посылающий сигнал коллекции, в которую входят все получатели. Для моделирования широковещания нужно показать, что объект посылает сигнал другому объекту, представляющему систему в целом. 

Любой экземпляр любого класса может быть получателем события вызова или сигнала. Если это синхронное событие, то отправитель и получатель находятся в состоянии рандеву на всем протяжении выполнения операции. Это означает, что поток управления отправителя блокируется потоком управления получателя, пока операция не завершится. Если это сигнал, то отправитель и получатель не входят в состояние рандеву: отправитель посылает сигнал, но не дожидается ответа от получателя. В любом случае событие может быть потеряно (если не указано, что нужен ответ), может вызвать переход состояния в автомате, если он существует, или просто инициировать обычный вызов метода.

В UML события вызова, которые получает объект, моделируются как операции  над классом этого объекта. Именованные сигналы, получаемые объектом, моделируются путем перечисления в дополнительном разделе класса, как показано на рисунке 6.5.


Рисунок 6.5 - Сигналы и активные классы

Примечание: Точно так же можно присоединить именованные сигналы к интерфейсу. В любом случае, имена сигналов, перечисленные в дополнительном разделе, являются не объявлениями, а лишь указаниями на то, что сигнал используется. Сигналы, которые являются асинхронными операциями, перечисляются в разделе обычных операций класса. 

Диаграммы состояний - это один из пяти видов диаграмм в языке UML, используемых для моделирования динамических аспектов системы (к их числу относятся также диаграммы последовательностей и кооперации, диаграммы деятельности и диаграммы прецедентов). Диаграмма состояний показывает автомат. Ее частной разновидностью является диаграмма деятельности, в которой все или большая часть состояний - это состояния деятельности, а все или большая часть переходов инициируются в результате завершения деятельности в исходном состоянии. Таким образом, при моделировании жизненного цикла объекта полезны как диаграммы деятельности, так и диаграммы состояний. Но если диаграмма деятельности показывает поток управления от деятельности к деятельности, то на диаграмме состояний представлен поток управления от состояния к состоянию.

Диаграммы состояний используются для моделирования динамических аспектов системы. Диаграммы состояний можно присоединять к классам, прецедентам или системе в целом для визуализации, специфицирования, конструирования и документирования динамики отдельного объекта.

Диаграммы состояний важны не только для моделирования динамических аспектов системы, но и для конструирования исполняемых систем путем прямого и обратного проектирования.

Рассмотрим деятельность инвестора, финансирующего строительство нового небоскреба. Маловероятно, что этому человеку будут интересны подробности процесса возведения здания. Выбор материалов, график поставок и многочисленные совещания по поводу технических деталей - это заботы подрядчика, но никак не лица, вкладывающего в проект деньги.

Инвестор заинтересован в получении хорошей прибыли и, как следствие, в защите капиталовложений от рисков. Инвестор, доверяющий подрядчику, внесет определенную сумму денег, на время строительства займется другими делами и вернется только тогда, когда подрядчик будет готов вручить ему ключи от здания. Такой вкладчик заинтересован только в конечном результате.

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

Каждая такая веха обозначает некое устойчивое состояние проекта: закончено архитектурное проектирование, проведена инженерная подготовка, вырыт котлован, завершена подводка коммуникаций, загерметизированы швы и т.д. Для инвестора наблюдение за изменениями в ходе процесса намного важнее, чем контроль последовательности работ: этим может заняться подрядчик с помощью Pert-диаграмм .

При моделировании программных систем также необходимо отыскать наиболее естественный способ визуализации, специфицирования, конструирования и документирования поведения определенных типов объектов, когда основное внимание уделяется переходам из состояния в состояние, а не от деятельности к деятельности. Последнее можно выполнить с помощью блок-схем (или диаграмм деятельности в UML). Представьте себе моделирование поведения встроенной системы безопасности у себя дома. Она работает непрерывно, реагируя на внешние события, скажем на разбитое окно. Порядок событий изменяет поведение системы. Например, обнаружение разбитого окна вызовет срабатывание сигнализации, только если система предварительно была активизирована. Поведение такой системы лучше всего описывается путем моделирования ее устойчивых состояний (например, Ожидание, Активна, Проверка и т.д.), событий, инициирующих смену состояния, и действий, выполняемых при каждой такой смене.

В UML для моделирования поведения объекта с точки зрения порядка возникновения событий используются диаграммы состояний. Из рисунка 6.6 видно, что диаграмма состояний - это просто представление автомата, и основное внимание уделено потоку управления от одного состояния к другому.


Рисунок 6.6 - Диаграмма состояний

Диаграмма состояний (Statechart diagram) показывает автомат, фокусируя внимание на потоке управления от состояния к состоянию. Автомат (State machine) -это описание последовательности состояний, через которые проходит объект на протяжении своего жизненного цикла, реагируя на события, - в том числе описание реакций на эти события. Состояние (State) - это ситуация в жизни объекта, на протяжении которой он удовлетворяет некоторому условию, осуществляет определенную деятельность или ожидает какого-то события. Событие (Event) - это спецификация существенного факта, который происходит во времени и пространстве. В контексте автоматов событие - это стимул, способный вызвать срабатывание перехода. Переход (Transition) - это отношение между двумя состояниями, показывающее, что объект, находящийся в первом состоянии, должен выполнить некоторые действия и перейти во второе состояние, как только произойдет определенное событие и будут выполнены заданные условия. Деятельность (Activity) -это продолжающееся неатомарное вычисление внутри автомата. Действие (Action) - это атомарное вычисление, которое приводит к смене состояния или возврату значения. Диаграмма состояний изображается в виде графа с вершинами и ребрами.

Диаграмма состояний обладает свойствами, общими для всех диаграмм, то есть имеет имя и графическое содержание, проецируемое на модель. От прочих диаграмм она отличается именно этим содержанием.

Обычно диаграмма состояний включает в себя:

  •  простые и составные состояния;
  •  переходы вместе с ассоциированными событиями и действиями.

Примечание: Диаграмма состояний, по сути, составлена из элементов, встречающихся в любом автомате. Она может содержать ветвления, разделения, слияния, состояния деятельности и действий, объекты, начальные и конечные состояния, исторические состояния и т.д., - в общем, к диаграмме состояний применимы все без исключения характеристики автомата. Диаграмму деятельности  отличает от диаграммы состояний лишь то, что она состоит в основном из элементов, встречающихся в графе деятельности, и представляет собой разновидность автомата, в котором все или большая часть состояний есть состояния деятельности, а все или большая часть переходов инициируются фактом завершения деятельности в исходном состоянии. 

Как и все прочие диаграммы, диаграмма состояний может содержать примечания и ограничения.

Диаграммы состояний применяются для моделирования динамических аспектов системы. Имеется в виду обусловленное порядком возникновения событий поведение объектов любого рода в любом представлении системной архитектуры, включая классы (в том числе активные, интерфейсы, компоненты и узлы.

Использовать диаграммы состояний для моделирования некоторого динамического аспекта системы можно в контексте практически любого элемента модели. Обычно, однако, диаграммы состояний применяются в контексте системы в целом, подсистемы или класса. Можно присоединять диаграммы состояний и к прецедентам (для моделирования сценария).

При моделировании динамических аспектов системы, класса или прецедента диаграммы состояний обычно используются только с целью моделирования реактивных объектов.

Реактивный, или управляемый событиями, объект - это такой объект, поведение которого лучше всего характеризовать его реакцией на внешние события. Как правило, реактивный объект находится в состоянии ожидания, пока не получит событие, а когда это случается, его реакция зависит от предшествующих событий. После того как объект отреагирует на событие, он снова переходит в состояние ожидания следующего события. Для таких объектов интерес представляют прежде всего устойчивые состояния, события, инициирующие переходы из одного состояния в другое, и действия, выполняемые при смене состояния.

Примечание: В противоположность этому диаграммы деятельности используются для моделирования рабочего процесса или операции. Они в большей степени подходят для показа протекания деятельности во времени и этим напоминают блок-схемы. 

При создании диаграммы состояний в UML не забывайте, что все диаграммы -это лишь проекции динамических аспектов одной и той же системы. Одна диаграмма состояний может описать семантику одного реактивного объекта, но никогда - семантику всей системы, за исключением самых тривиальных случаев.

Хорошо структурированная диаграмма состояний обладает следующими свойствами:

  •  сосредоточена на описании какого-либо одного аспекта динамики системы;
  •  содержит только те элементы, которые существенны для понимания этого аспекта;
  •  описывает лишь детали, которые соответствуют своему уровню абстракции;
  •  сбалансировано использует стилистику машин Мили и Мура.

При изображении диаграммы состояний пользуйтесь следующими рекомендациями:

  •  дайте ей имя, соответствующее назначению;
  •  начинайте с моделирования устойчивых состояний объекта, затем переходите к допустимым переходам состояний. Ветвления, параллельность и траектории объектов являются второстепенными деталями, которые можно изобразить на отдельной диаграмме;
  •  располагайте элементы так, чтобы число пересечений было минимальным.

Создание диаграммы состояний

В этом упражнении будет создана диаграмма Состояний для класса Заказ.

Постановка задачи

Проектируя класс Заказ, Карен поняла, что за поведением этого класса надо наблюдать. Многие требования к классу значительно изменялись при изменении состояния его экземпляра. Например, заказы, выполнение которых было приостановлено, вели себя не так, как выполненные заказы, а те, в свою очередь, не так, как отмененные заказы.

Чтобы убедиться, что проект удовлетворяет всем этим требованиям, Карен со своей группой разработчиков создала диаграмму Состояний для класса Заказ. С помощью этой диаграммы разработчики смогли окончательно понять, как надо писать код для этого класса.

Создание диаграммы Состояний

Разработайте диаграмму Состояний для класса Заказ, показанную на рисунке 12.

Рисунок 6.14 -  Диаграмма Состояний для класса Заказ.

Этапы выполнения упражнения

Создание диаграммы

  1.  В окне Model Explorer откройте правой кнопкой мыши меню Add diagram для класса Заказ модели Система обработки заказов и выберете Statechart Diagram (рисунок 6.15).
  2.   Назовите новую диаграмму "Ввод заказа".
  3.  Дважды щелкните на ней, чтобы открыть ее.

Рисунок 6.15 - Добавление Диаграммы состояний

Добавление начального и конечного состояний

  1.  На панели Toolbox (рисунок 6.16 ) инструментов нажмите кнопку InitialState (Начальное состояние).
  2.  Поместите это состояние на диаграмму.
  3.  На панели инструментов нажмите кнопку FinalState (Конечное состояние).
  4.  Поместите это состояние на диаграмму.

Добавление суперсостояния

  1.  На панели инструментов нажмите кнопку Submachine State.
  2.  Поместите это состояние на диаграмму.

Добавление оставшихся состояний

  1.  На панели инструментов нажмите кнопку State (Состояние).
  2.  Поместите это состояние на диаграмму.
  3.  Назовите состояние Отменен.
  4.  Повторив пункты 1-3, поместите диаграмму состояние Выполнен.
  5.  На панели инструментов нажмите кнопку State (Состояние).
  6.  Поместите это состояние на диаграмму внутрь суперсостояния.
  7.  Назовите состояние Инициализация.
  8.  Повторив пункты 5-7, поместите на диаграмму состояние Выполнение заказа приостановлено.

Подробное описание состояний

  1.  Дважды щелкните на состоянии Инициализация.

Рисунок 6.15 – Добавление списка внутренних действий

  1.  В появившемся пиктограммном меню выберите тип нового действия Add EntryAction.
  2.  Назовите его Сохранить дату заказа.
  3.  Повторите этапы 1-3, добавив следующие действия: Собрать клиентскую информацию, DoAction и Добавить к заказу новые графы, DoAction
  4.  Дважды щелкните на состоянии Отменен.
  5.  Повторите этапы 1 - 3, добавив действие Сохранить дату отмены, ExitAction.
  6.  Дважды щелкните на состоянии Выполнен.
  7.  Повторите этапы 1 - 3, добавив действие  Выписать счет, DoAction.

Добавление переходов

  1.  На панели инструментов нажмите кнопку Transition (Переход).
  2.  Щелкните мышью на начальном состоянии.
  3.  Проведите линию перехода к состоянию Инициализация.
  4.  Повторите этапы с первого по третий, создав следующие переходы:

От состояния Инициализация к состоянию Выполнение заказа приостановлено

От состояния Выполнение заказа приостановлено к состоянию Выполнен

От суперсостояния к состоянию Отменен

От состояния Отменен к конечному состоянию

От состояния Выполнен к конечному состоянию

  1.  На панели инструментов нажмите кнопку Self Transition(Переход к себе).
  2.  Щелкните на состоянии Выполнение заказа приостановлено.

Подробное описание переходов

  1.  Дважды щелкните на переходе от состояния Инициализация к состоянию Выполнение заказа приостановлено, открыв окно его спецификации.
  2.  В поле Событие введите фразу Выполнить заказ.
  3.  Повторите этапы с 1 и 2, добавив событие Отменить заказ к переходу между суперсостоянием и состоянием Отменен.
  4.  Дважды щелкните на переходе от состояния Выполнение заказа приостановлено к состоянию Выполнен, открыв окно его спецификации.
  5.  В поле Событие введите фразу Добавить к заказу новую позицию.
  6.  Перейдите на вкладку Detail (Подробно).
  7.  В поле Condition (Условие) введите No unfilled items remaining (Не осталось незаполненных позиций).
  8.  Щелкните на кнопке ОК, закрыв окно спецификации.
  9.  Дважды щелкните мышью на рефлексивном переходе (Transition to Self) состояния Pending (Выполнение заказа приостановлено).
  10.  В поле Event (Событие) введите фразу Add Order Item (Добавить к заказу новую позицию).
  11.  Перейдите на вкладку Detail (Подробно).
  12.  В поле Condition (Условие) введите Unfilled items remaining (Остаются незаполненные позиции).
  13.  Щелкните на кнопке ОК, закрыв окно спецификации.


 

А также другие работы, которые могут Вас заинтересовать

59256. Сценарій: Зустріч з казкою 66.5 KB
  Першою до нас в гості завітала українська народна казка Колобок яка вам вже є знайомою але уважно просимо додивитись її до кінця й тоді Ведуча: Та не треба поспішати а краще казку розпочати бо недаремно мудрі кажуть люди що краще раз побачити ніж десять раз почути.
59257. Свято Нептуна 41 KB
  І в зелену полонину Поведе Як на Пруті крига скресне Люту зиму перекреслить Оп’яніє від кохання Оп’яніє від кохання Голова Перелесник обіймає Та цілує не питає Та питає коли слати Старостів У такі зелені весни Кожен хлопець Перелесник Кожна дівчина...
59258. Скликаєм усіх на бал, на осінній карнавал 43 KB
  Осінь: Мене напевно не чекали Та вже прийшла моя пора. І ви мене усі впізнали Я – Щедра Осінь золота. Осінь: Ти Гарбуз всьому господар Ти найбільший на городі.
59260. Де Купало ночувало 43 KB
  Дівчата готують святкові строї хлопці – приладдя для парубоцьких ігор старі жіночки випікають солодощі для гостини. За день до проведення свята пізно ввечері хлопці ховають у схованки сюрпризи для дівчат а дівчата мають знайти їх пізно ввечері перед закінченням свята.
59261. Малі олімпійські ігри 43.5 KB
  Ознайомити дітей з історією Олімпійських ігор; З культурою і традиціями Стародавньої Греції символікою Олімпійських ігор прапор факел; Поглибити знання дітей про видатних спортсменів України; Розвивати інтерес до пізнання історії спорту нашої країни...
59262. ПІСНЯ – ДУША НАРОДУ 55.5 KB
  Яке диво дивне народна пісня Яку владну силу таїть вона в собі Минають віки змінюються суспільні устрої потрясають світ нищівні війни і голодомори на зміну одним поколінням приходять інші у кожного свої смаки свої уподобання.
59263. Разработка внутрифирменных практик ускоренного развития Менеджеров отделений страховой компании «АЛИКО» в интересах лидерства в темпах роста 3.33 MB
  Значение страхования жизни для экономики Российской Федерации остается пока минимальным в связи с небольшим объемом рынка по страхованию жизни. Доля премий по страхованию жизни в ВВП по-прежнему снижается
59264. Сценарій спортивного вечора у початковій школі 32.5 KB
  Вчитель. Змагання буде проводити вчитель фізвиховання судитимуть змагання. Вчитель фізкультури. Вчитель фізкультури.