2.6.3. Кооперативные диаграммы.
Кооперативные диаграммы акцентируют внимание на структурной организации объектов, участвующих во взаимодействии. Примеры кооперативных диаграмм приведены на рисунках 2.12.и.2.13. На кооперативной диаграмме экземпляры объектов показаны в виде пиктограмм. Стрелки обозначают сообщения, обмен которыми осуществляется в рамках данного ВИ. Их временная последовательность указывается путем нумерации сообщений. Для кооперативных диаграмм можно использовать различные варианты нумерации (см. рис 2.12 и 2.13).
Рисунок 2.12. Кооперативная диаграмма с простой нумерацией
Независимо от схемы нумерации, на диаграмме можно поместить управляющую информацию, как и на диаграмме последовательностей.
В этих примерах показаны различные схемы именования объектов, принятые в UML. Общая форма имени имеет вид: <имя объекта: имя класса>. Любая часть этой конструкции может отсутствовать. При отсутствии имени объекта нужно оставить двоеточие, чтобы было понятно, что это имя класса, а не объекта. Например, имя «строка Маккалана: Строка Заказа» означает, что экземпляр класса Строка Заказа называется строка Маккалана.
Рисунок 2.13. Кооперативная диаграмма с десятичной нумерацией
Обе формы диаграмм взаимодействия отличаются простотой. Если на диаграмме изображен единственный последовательный процесс, то . посмотрев на нее, можно увидеть все сообщения. Если же процесс содержит множество условных переходов или циклы, то в таком случае нужно строить отдельные диаграммы для каждого сценария или сопровождать сообщения условиями, показывающими поведение объектов.
2.6.4. Рекомендации по использованию диаграмм взаимодействия.
Диаграммами взаимодействия следует пользоваться, когда нужно описать поведение нескольких объектов в рамках одного ВИ. Они удобны для отображения взаимодействия между объектами, а для точного описания поведения объектов они не годятся.
Диаграммы состояний
Диаграммы состояний определяют все возможные состояния, в которых может находиться конкретный объект, а также процесс смены состояний объекта в результате влияния некоторых событий. В большинстве объектно-ориентированных методов диаграммы состояний строятся для единственного класса и отражают динамику поведения единственного объекта.
Существует несколько форм диаграмм состояний (ДС). Пример ДС, отражающей поведение объекта Заказ в Системе Обработки Заказов, приведен на рисунке 2.15. На этой диаграмме изображены различные состояния, в которых может находиться объект Заказ. Процесс начинается с Начальной точки, затем следует первый переход в состояние Проверка Позиции Заказа. Метка этого перехода «/получить позицию Заказа». Синтаксис метки: <событие>[<условие>]/ <действие>. Каждая из этих трех частей является необязательной. В данном случае метка включает только действие. После выполнения этого действия объект попадает в состояние Проверка Позиции Заказа. С этим состоянием связана деятельность, которая обозначается меткой «выполнить/ проверить позицию». Синтаксис этой метки: выполнить/<деятельность>. В данном случае деятельность называется «проверить позицию».
Рисунок 2.15. Диаграмма состояний
Термин «действие» используется для перехода, термин «деятельность» – для состояния. Хотя и то и другое – это процессы, реализуемые некоторым методом класса Заказ, но они различаются между собой.
Действия связаны с переходами и рассматриваются как мгновенные и непрерываемые.
Деятельности связаны с состояниями и могут длиться достаточно долго. Деятельность может быть прервана в результате наступления некоторого события. Если метка перехода не содержит никакого события, то переход происходит, как только завершается какая-то деятельность, связанная с данным состоянием (как только завершится Проверка Позиции Заказа).
Из состояния Проверка Позиции Заказа возможны 3 перехода. Метка каждого из них включает только условие. Условие это логическое, оно может принимать 2 значения – «истина» и «ложь». Если условие принимает значение «истина», то выполняется условный переход.
Из конкретного состояния в данный момент времени может произойти только 1 переход, т.е. условия являются взаимно исключающими. В нашем примере 3 условия:
если проверены не все позиции, входящие в Заказ, то мы получаем следующую позицию и возвращаемся в состояние Проверка Позиции Заказа;
если проверены все позиции и все они имеются на складе, то переходим в состояние Выдача Заказа на Поставку;
если проверены все позиции, но не все имеются на складе, то переходим в состояние Ожидание.
Рассмотрим состояние Ожидание. В этом состоянии нет деятельностей, поэтому Заказ находится в состоянии Ожидания, пока не наступит некоторое событие. Оба перехода из состояния Ожидание отмечены событием «позиция получена». Заказ ожидает до тех пор, пока он не обнаружит наступления данного события.
В состоянии Выдача Заказа на Поставку есть деятельность, которая инициирует поставку. Переход из этого состояния произойдет, если произойдет событие «поставлен».
Рисунок 2.16 Диаграмма состояний без суперсостояний.
В рассмотренном примере нет перехода под названием «отмена». У нас должна быть возможность отменить любой Заказ в любой момент времени до завершения его выполнения. На рисунке 2.16 добавлено состояние «отмена Заказа». Чтобы отменить Заказ, нужно изобразить переходы из каждого состояния (Проверка Позиции Заказа, Выдача Заказа и Ожидание).
Рисунок 2.17. Диаграмма состояний с суперсостояниями.
На диаграмме 2.17 изображен другой вариант – для 3 вышеперечисленных состояний определено суперсостояние и единственный переход из него. Подсостояния наследуют любые переходы суперсостояния.
Когда использовать диаграммы состояний.
Диаграммы состояний хорошо использовать для описания поведения некоторого объекта в нескольких различных ВИ. Для описания поведения нескольких взаимодействующих объектов эти диаграммы не удобны. С помощью диаграмм состояний полезно изображать поведение пользовательского интерфейса и управляющих объектов.
