Звоните! 
 (926)274-88-54 
 Бесплатная доставка. 
 Бесплатная сборка. 
Ассортимент тканей

График работы:
Ежедневно. С 8-00 до 20-00.
Почта: soft_hous@mail.ru
Читальный зал -->  Диаграммы параллельных состояний 

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 [ 39 ] 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57

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

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

Подтверждение Оплаты

выполнить подтверждение/

проверить . оплату

[оплата выполнена]

Оплата Подтвер]щена

[оплата не выполнена]

Отвергнут

[отправлен]

Доставка

Рис. 8.4. Подтверждение оплаты заказа

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

Таким образом, поведение объекта Заказ определяется как комбинация поведений, изображенных на рис. 8.1 и 8.4. Все эти состояния и рассмотренное ранее состояние Отмена можно объединить в одну диаграмму параллельных состояний (рис. 8.5).

Обратите внимание, что на рис. 8.5 детали внутренних состояний не изображены.




отменен

Отмена

( Ожидание

Проверка

Позиции Заказа



Подтверждение \ Оплата Оплаты Подтверждена


Отправка

конечное состояние

Отвергнут

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

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

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



Когда использовать диаграммы состояний

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

Например, диаграммы взаимодействия (см. главу 5) являются хорошим средством для описания поведения нескольких объектов в одном варианте использования, а диаграммы деятельности (см. главу 9) удобны для представления общей последовательности действий для нескольких объектов и вариантов использования.

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

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

Где найти дополнительную информацию

Как в Руководстве пользователя (Буч, Рамбо и Джекобсон, 1999 [6]), так и в Справочнике пользователя (Рамбо, Джекобсон и Буч, 1999 [37]) можно найти дополнительную информацию по диаграммам состояний. Многие разработчики-практики склонны довольно часто использовать модели состояний, поэтому неудивительно, что в книге Дугласа (Douglass), 1998 [17] много говорится о диаграммах состояний, включая различные аспекты их реализации.

Если вы планируете интенсивно использовать диаграммы, то следует обратиться к книге Кука и Дэниелса (1994) [13]. Хотя имеются различия в семантике обозначений схем состояний и диаграмм состояний в языке UML, авторы подробно рассматривают такие вопросы, в которых желательно разбираться, если вы пользуетесь диаграммами состояний.



1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 [ 39 ] 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57



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



Звоните! Ежедневно!
 (926)274-88-54 
Продажа и изготовление мебели.


Копирование контента сайта запрещено.
Авторские права защищаются адвокатской коллегией г. Москвы
.