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

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

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

Этот вид нотации может быть использован также в процессе моделирования на основе ролей, в рамках которого вначале моделируются кооперации и роли, а затем разрабатываются классы, которые реализуют эти роли. Дополнительную информацию об этом стиле проектирования можно найти в книге Ринскауга (Reenskaug), 1996 [35].

Когда использовать диаграммы пакетов и кооперации

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

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

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

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

Пакеты подробно рассмотрены в работе Роберта Мартина (Robert Martin), 1995 [30], которая, по моему мнению, является лучшей из книг по данной тематике на сегодняшний день. В этой книге приведен ряд примеров использования метода Буча в сочетании с языком С-Н-, при этом большое внимание уделено минимизации зависимостей. Полезную информацию можно найти также в книге Вирс-Брока (Wirfs-Brock), 1990 [46], в которой автор впервые говорит о пакетах как о подсистемах.

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

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

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

Существует несколько разновидностей представления диаграмм состояний, незначительно отличающихся друг от друга семантикой. Стиль, принятый в языке UML, основан на схемах состояний Дэвида Харела (David Harel), 1987 [22].

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

Из начальной точки процесс переходит в состояние Проверка. Этот переход имеет метку /получить первую позицию заказа .

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

выполнить/деятельность. В данном случае деятельность называется проверить позицию заказа .

начало -

[Не все позиции проверены] /получить следующую позицию.

/получить первую позицию заказа

[Все позиции проверены &&

Проверка

выполнить проверку/ проверить позицию ч заказа у

все позиции доступны]

[Все позиции проверены && некоторые позиции отсутствуют на складе]

Позиция получена [некоторые позиции отсутствуют на складе]

Отправка

выполнить отправку/

инициировать ч. доставку У

деятельность

Отправлен

Доставка

рефлексивный тюреход

Состояние

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

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

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

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

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 
Продажа и изготовление мебели.

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