3.6. Диаграммы состояний

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

Рис. 3.14. Диаграмма состояний

Существует много форм диаграмм состояний, незначительно отличающихся друг от друга семантикой. Наиболее популярная форма, используемая в объектно-ориентированных методах, впервые применялась в методе OMTи впоследствии была адаптирована Гради Бучем.

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

Процесс начинается с начальной точки, затем следует самый первый переход в состояние Проверка позиции заказа. Метка этого перехода - "/получить первую позицию заказа". Синтаксически метка перехода состоит из трех частей, каждая из которых является необязательной: <Событие> [<Условие>]/<Действие>. В данном случае метка включает только действие "получить первую позицию заказа". После выполнения этого действия мы попадаем в состояние Проверка позиции заказа. С этим состоянием связана деятельность, которая обозначается меткой со следующим синтаксисом: выполнить/деятельность. В данном случае деятельность называется "проверить позицию".

Следует отметить, что термин "действие" (action) используется для перехода, а термин "деятельность" (activity) - для состояния. Хотя и то, и другое — это процессы, реализуемые, как правило, некоторым методом класса Заказ, они трактуются различным образом. Действия связаны с переходами и рассматриваются как мгновенные и непрерываемые процессы. Деятельности связаны с состояниями и могут длиться достаточно долго. Деятельность может быть прервана в результате наступления некоторого события.

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

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

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

1) если проверены не все позиции, входящие в заказ, то получаем следующую позицию и возвращаемся в состояние Проверка позиции заказа;

2) если проверены все позиции и все они имеются на складе, то переходим в состояние Выдача заказа на поставку;

3) если проверены все позиции, но не все из них имеются на складе, то переходим в состояние Ожидание.

Рассмотрим сначала состояние Ожидание. Для этого состояния не существует деятельностей, поэтому данный заказ находится в состоянии ожидания, пока не наступит некоторое событие. Оба перехода из состояния ожидания помечены событием Позиция Получена. Это означает, что заказ ожидает до тех пор, пока он не обнаружит наступление данного события. При этом оцениваются условия переходов и выполняется тот переход, для которого условие "истинно" (либо в состояние Выдача заказа на поставку, либо обратно в состояние Ожидание).

В состоянии Выдача заказа на поставку имеется деятельность, которая инициирует поставку. Из этого состояния имеется единственный безусловный переход, управляемый событием Поставлен. Это означает, что данный переход обязательно произойдет, если произойдет данное событие. При этом переход никак не связан с завершением деятельности; наоборот, когда деятельность "инициировать поставку" завершится, то данный заказ останется в состоянии Выдача заказа на поставку, пока не наступит событие Поставлен.

Последнее, что нужно рассмотреть, — это переход под названием "отмена". Необходимо располагать возможностью отменить любой заказ в любой момент до завершения его выполнения. Это можно сделать, изобразив отдельные переходы из каждого состояния: Проверка позиции заказа, Ожидание и Выдача заказа на поставку. Альтернативный вариант - определение суперсостояния для трех перечисленных состояний и соответственно единственного перехода из него. Подсостояния просто наследуют любые переходы суперсостояния (рис. 3.15).

На этих диаграммах деятельность изображается внутри состояния в виде текста "выполнить/ деятельность". Внутри состояния можно также разместить и другую информацию.

Если состояние реагирует на событие, связанное с действием, которое не влечет за собой никакого перехода, этот факт можно изобразить, поместив в прямоугольник состояния текст вида "ИмяСобытия/ИмяДействия ".

Рис. 3.15. Диаграмма состояний с суперсостояниями

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

Помимо состояний заказа, связанных с получением информации о наличии предметов и их поставкой, существуют также состояния, связанные с проверкой платежей. Эти состояния отражает диаграмма на рис. 3.16.

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

Таким образом, поведение объекта Заказ определяется одновременно диаграммами на рис. 3.14 и 3.16. Их можно объединить в одну диаграмму параллельных состояний (рис. 3.17); детали внутренних состояний здесь опущены.

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

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

Рис. 3.16. Проверка платежа

Рис. 3.17.Диаграмма параллельных состояний

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

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