1. Основные элементы диаграммы

Основным элементом диаграммы деятельностей является состояние действия (action state). Оно представляет собой состояние, в котором определено внутреннее действие, и имеющее хотя бы один выходящий из него переход, включающий в себя неявное событие завершения данного внутреннего действия (при наличии условий перехода, таких переходов может быть несколько). Состояния действия не могут иметь внутренних или внешних исходящих переходов, основывающихся на явных событиях; в таких ситуациях используются обычные состояния. За одним состоянием действия следует другое состояние, вместе они образуют простую последовательность действий. Переходы, выходящие из состояния действия, неявно вызываются завершением некого события в состоянии. Переходы могут включать в себя условия перехода и действия. Выполняемое действие может быть описано на естественном языке или на любом языке программирования.

В диаграмме деятельностей может использоваться состояние, связанное с принятием решения - решение(decision).Решение используется в тех случаях, когда в зависимости от условий перехода, может быть выбран тот или иной переход на диаграмме.

Может показаться, что диаграмма действий является аналогом блок-схемы. Это не так. Рассмотрим диаграмму, представленную на рис.2.32. Обнаружить разницу можно, посмотрев на состояние действия Find Beverage. Оно активизирует два действия, связанные с поиском кофе и колы. Предположим, что кофе найден и мы стали двигаться вниз по "кофейному маршруту". Этот путь ведет к линейке синхронизации, с которой связана активация трех деятельностей - Put Coffee in Filter, Add Water to Reservoir и Get Cups. Диаграмма указывает на то, что все три деятельности могут выполняться параллельно и порядок их выполнения не играет роли. В этом и заключается главное различие между блок-схемой и диаграммой деятельностей. Блок схемы ограничиваются последовательными процессами, а диаграммы деятельностей могут поддерживать параллельные процессы.

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

Решение представляется на диаграмме как ромб, с одним или более входящим в него переходом и с одним или более выходящим переходом.

2. "Плавательные дорожки"

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

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

3. Декомпозиция на диаграмме деятельностей

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

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

Билет 70. UML. Диаграммы размещения.

Диаграммы размещения (deployment diagrams)

Диаграммы размещения (deployment diagrams) отражают физические взаимосвязи между программными и аппаратными компонентами системы, а также используются для изображения маршрутов перемещения объектов в распределенной системе.

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

1. Компоненты

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

Тип компоненты описывается следующим выражением:

<тип компоненты>

Экземпляр компоненты описывается строкой с подчеркиванием, содержащей собственное имя и тип:

<имя компоненты>‘:’<тип компоненты>

2. Узлы

Узел (node) - это физический объект, имеющий вычислительный ресурс, память и возможность обработки информации.

Узел представляется на диаграмме параллелепипедом (2.35). Тип узла описывается следующим выражением:

<тип узла>

Экземпляр узла описывается строкой с подчеркиванием, содержащей собственное имя и тип:

<имя>‘:’<тип узла>

Тип узла описывает разновидность данного узла. Пунктирная линия, проведенная от узла к компоненте, показывает возможность данного типа узла поддерживать данный тип компонент. Узлы могут содержать экземпляры компонент - это означает, что компонента "живет" или запускается в данном узле. Компоненты могут содержать в себе объекты; это говорит о том, что объект является частью компонента. Компоненты соединяются между собой пунктирными линиями, возможно использование интерфейсов. Это говорит о том, что один компонент использует другой компонент. Использование стереотипа уточняет вид данной зависимости.

Диаграммы размещения могут быть использованы для представления того, какие компоненты запускаются в каких узлах. Для этого используется связь со стереотипом "supports". Перемещение компонента из узла в узел или объекта из компонента в компонент может быть представлено с помощью связи со стереотипом “becomes".

Узлы могут быть связаны соединениями. Соединение может иметь стереотип, указывающий тип данной связи (например, тип канала в сети).

Представленный ниже пример представляет два узла, содержащие объект (cluster), переходящий из одного узла в другой, и также объект, располагающийся в узле постоянно.

Билет 71. UML и RUP.

Rational Unified Process (RUP) – одна из лучших методологий разработки программного обеспечения, созданная в компании Rational Software. Одним из основных столпов, на которые опирается RUP, является процесс создания моделей при помощи унифицированного языка моделирования (UML).

рис. 1 Фазы и потоки работ RUP