Раздел 5 анализ и проектирование на uml

РАЗДЕЛ 5 АНАЛИЗ И ПРОЕКТИРОВАНИЕ НА UML

1. Назначение UML

2. Модель и ее элементы – сущности

3. Модель и ее элементы – отношения

4. Модели и их представления – использования, поведения и структуры

5. Общие свойства модели и механизмы расширения – стереотипы, помеченные значения, ограничения

6. Иерархия диаграмм в UML 1 и UML 2

7. Диаграммы use case (вариантов использования)

8. Реализация вариантов использования

9. Моделирование структуры на UML

10. Диаграмма классов. Классы

11. Диаграмма классов. Отношения

12. Компоненты и интерфейсы

13. Диаграммы реализации

14. Моделирование поведения на UML

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

16. Диаграммы деятельности

17. Диаграмма последовательности и диаграмма коммуникации

18. Паттерны проектирования и каркасы на UML

19. Управление моделями

20. Влияние UML на процесс разработки

1. Назначение UML

Определение OMG(Object Management Group)

"The Unified Modeling Language (UML) is a graphical language for visualizing, specifying, constructing, and documenting the artifacts of a software-intensive system. The UML offers a standard way to write a system's blueprints, including conceptual things such as business processes and system functions as well as concrete things such as programming language statements, database schemas, and reusable software components."-

Язык графического описания для объектного моделирования систем (Википедия)

В UML используются следующие виды диаграмм (для исключения неоднозначности приведены также обозначения на английском языке):

Structure Diagrams:

Class diagram

Component diagram

Composite structure diagram

Collaboration (UML2.0)

Deployment diagram

Object diagram

Package diagram

Profile diagram (UML2.2)

Behavior Diagrams:

Activity diagram

State Machine diagram

Use case diagram

Interaction Diagrams:

Communication diagram (UML2.0) / Collaboration (UML1.x)

Interaction overview diagram (UML2.0)

Sequence diagram

Timing diagram (UML2.0)

Структурные диаграммы:

Диаграмма классов

Диаграмма компонентов

Диаграмма композитной/составной структуры

Диаграмма кооперации (UML2.0)

Диаграмма развёртывания

Диаграмма объектов

Диаграмма пакетов

Диаграмма профилей (UML2.2)

Диаграммы поведения:

Диаграмма деятельности

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

Диаграмма вариантов использования

Диаграммы взаимодействия:

Диаграмма коммуникации (UML2.0) / Диаграмма кооперации (UML1.x)

Диаграмма обзора взаимодействия (UML2.0)

Диаграмма последовательности

Диаграмма синхронизации (UML2.0)

2. Модель и ее элементы – сущности

(Туривный С.)

Для удобства обзора сущности в UML можно подразделить на четыре группы:

структурные;

поведенческие;

группирующие;

аннотационные.

Структурные сущности, как нетрудно догадаться, предназначены для описания структуры. Обычно к структурным сущностям относят следующие.

Объект (object) 1 ‒ сущность, обладающая уникальностью и инкапсулирующая в себе состояние и поведение.

Класс (class) 2 ‒ описание множества объектов с общими атрибутами, определяющими состояние, и операциями, определяющими поведение.

Интерфейс (interface) 3 ‒ именованное множество операций, определяющее набор услуг, которые могут быть запрошены потребителем и предоставлены поставщиком услуг.

Кооперация (collaboration) 4 ‒ совокупность объектов, которые взаимодействуют для достижения некоторой цели.

Действующее лицо (actor) 5 ‒ сущность, находящаяся вне моделируемой системы и непосредственно взаимодействующая с ней.

Компонент∇ (component) 6 ‒ модульная часть системы с четко определенным набором требуемых и предоставляемых интерфейсов.

Артефакт (artifact) 7 ‒ элемент информации, который используется или порождается в процессе разработки программного обеспечения. Другими словами, артефакт ‒ это физическая единица реализации, получаемая из элемента модели (например, класса или компонента).

Узел (node) 8 ‒ вычислительный ресурс, на котором размещаются и при необходимости выполняются артефакты.

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

Состояние (state) 1 ‒ период в жизненном цикле объекта, находясь в котором объект удовлетворяет некоторому условию и осуществляет собственную деятельность или ожидает наступления некоторого события.

Деятельность (activity) 2 можно считать частным случаем состояния, который характеризуется продолжительными (по времени) не атомарными вычислениями.

Действие (action) 3 ‒ примитивное атомарное вычисление.

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

Несколько особняком стоит сущность ‒ вариант использования.

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

Группирующая сущность в UML одна ‒ пакет ‒ зато универсальная.

Пакет (package) 1 ‒ группа элементов модели (в том числе пакетов).

Аннотационная сущность тоже одна ‒ комментарий.

Комментарий (comment) 2 ‒ произвольное по формату и содержанию описание одного или нескольких элементов модели.

(http://book.uml3.ru/sec_1_4)

3. Модель и ее элементы – отношения

(Туривный С.)

В UML используются четыре основных типа отношений:

зависимость (dependency);

ассоциация (association);

обобщение (generalization);

реализация (realization).

Зависимость ‒ это наиболее общий тип отношения между двумя сущностями.

Отношение зависимости указывает на то, что изменение независимой сущности каким-то образом влияет на зависимую сущность.

Графически отношение зависимости изображается в виде пунктирной линии со стрелкой 1, направленной от зависимой сущности 2 к независимой 3, как показано на следующем рисунке. Как правило, семантика конкретной зависимости уточняется в модели с помощью дополнительной информации. Например, зависимость со стереотипом «use» означает, что зависимая сущность использует (скажем, вызывает операцию) независимую сущность.

Ассоциация ‒ это наиболее часто используемый тип отношения между сущностями.

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

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

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

Графически обобщение изображается в виде линии с треугольной незакрашенной стрелкой на конце 1, направленной от частного 2 (подкласса) к общему 3 (суперклассу), как показано на следующем рисунке.

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

Отношение реализации указывает, что одна сущность является реализацией другой.

Например, класс является реализацией интерфейса. Графически реализация изображается в виде пунктирной линии с треугольной незакрашенной стрелкой на конце 1, направленной от реализующей сущности 2 к реализуемой 3, как показано на следующем рисунке.

(http://book.uml3.ru/sec_1_4)

4. Модели и их представления – использования, поведения и структуры

(Туривный С.)

Идея состоит в том, что абстрактный граф модели, состоящий из множества разнотипных сущностей и отношений, не подлежит конструированию или изучению в целом. Каждый раз для визуализации, изменения или иных манипуляций из этого общего графа вычленяются только сущности и отношения, релевантные для определенного аспекта моделируемой системы, а все остальные игнорируются. Такой вид с определенной точки зрения, можно сказать, проекцию модели, мы называем представлением(view). Можно сказать, что представление ‒ это средство логического структурирования модели.

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

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

Концептуальная модель (conceptual model). На диаграммы такой модели будут смотреть, их будут обдумывать, но с самой моделью ничего делать не будут. Это не означает, что модель не нужна ‒ это означает, что модель используется только для управления мыслительным процессом, для понимания. Поэтому мы называем такие модели концептуальными (также применются терминымодель анализа (analysis model) или аналитическая модель). Такой тип использования моделей один из самых важных, например, потому что так используются модели, которые получаются в результате анализа предметной области. Концептуальные модели довольно стабильны: если не меняется предметная область, то нет нужды менять и модель. Главное требования к модели предметной области: концептуальная целостность (consistency).

Модель проектирования (design model). Модель проектирования представляет собой высокоуровневое (на уровне подсистем) и низкоуровневое (на уровне классов, если речь идет об использовании объектно-ориентированного подхода) описание программной системы. Модель проектирования предназначена для того, чтобы, руководствуясь ею, разработать программный код приложения. Как правило, архитектура (высокоуровневое описание) и код разрабатываются итеративно, и разработчикам в процессе разработки необходимо модифицировать модель проектирования, чтобы она соответствовала принимаемым решениям. Главное требование к модели проектирования: понятность (usability). Действительно, разработчики должны полностью понимать модель, чтобы вести разработку.

Модель реализации (implementation model). Модель реализации предназначена для автоматического преобразования, возможно многократного, в существенно другой вид, например, в исполнимый код. Такое предназначение требует указания необходимых деталей реализации в модели, поскольку "от себя" компьютер их добавить не сможет. Главное требование к моделям реализации: полнота(completeness).

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

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

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

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

(http://book.uml3.ru/sec_1_7)

5. Общие свойства модели и механизмы расширения – стереотипы, помеченные значения, ограничения

(Туривный С.)

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

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

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

В настоящем разделе описываются все стандартные элементы подобного рода.

Стереотипы

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

Примечание: Некоторые из элементов, представленных в таблице, являются, строго говоря, не стереотипами, а стандартными ключевыми словами. Различие между ними довольно тонкое. В метамодели UML некоторые элементы, например trace, имеют очевидную семантику, то есть являются явной частью метамодели, а не настоящими стереотипами. С точки зрения разработчика, однако, они все равно изображаются в нотации стереотипов. Такие элементы определены как стандартные ключевые слова, чтобы можно было зарезервировать их использование в согласии с метамоделъю UML. В таблице ключевые слова выделены курсивом.

Обычно стереотипный элемент изображается следующим образом: имя стереотипа размещается над именем элемента и заключается в двойные кавычки, например "trace". Co стереотипом может быть ассоциирована пиктограмма, используемая как альтернативная форма визуализации данного элемента. Хотя в самом UML такие пиктограммы ни для одного стереотипа не заданы, в таблице все же приводятся некоторые общепринятые изображения.

Стереотип/ ключевое слово

Символ, к которому он применим

Назначение

actor

Класс (class)

Определяет связанное множество ролей, которые играет пользователь прецедента при взаимодействии с ним

access

Зависимость (dependency)

Сообщает, что открытое содержание целевого пакета доступно в пространстве имен исходного пакета

association

Концевая точка связи (link end)

Указывает, что соответствующий объект видим ассоциацией

become

Сообщение (message)

Целевой объект совпадает с исходным, но в более поздний момент времени. При этом, возможно, у него будут другие значения, состояния или роли

bind

Зависимость (dependency)

Исходный класс инстанцирует целевой шаблон с данными фактическими параметрами

call

Зависимость (dependency)

Исходная операция вызывает целевую

copy

Сообщение (message)

Целевой объект - это точная, но независимая копия исходного

create

Событие (event), сообщение (message)

Целевой объект создан в результате события или сообщения

derive

Зависимость (dependency)

Исходный объект может быть вычислен по целевому

destroy

Событие (event), сообщение (message)

Целевой объект уничтожен в результате события или сообщения

document

Компонент (component)

Компонент представляет документ

enumeration

Класс (class)

Определяет перечислимый тип, включая его возможные значения как набор идентификаторов

exception

Класс (class)

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

executable

Компонент (component)

Описывает компонент, который может быть выполнен в узле

extend

Зависимость (dependency)

Целевой вариант использования расширяет поведение исходного в данной точке расширения

facade

Пакет (package)

Пакет, который является лишь представлением другого пакета

file

Компонент (component)

Компонент, который представляет документ, содержащий исходный код или данные

framework

Пакет (package)

Пакет, состоящий в основном из образцов (паттернов)

friend

Зависимость (dependency)

Исходный класс имеет специальные права видимости в целевом

global

Концевая точка связи (link end)

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

import

Зависимость (dependency)

Открытое содержание целевого пакета становится частью плоского пространства имен исходного пакета, как если бы оно было объявлено непосредственно в нем

implementation

Обобщение (generalization)

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

implementationClass

Класс (class)

Реализация класса на некотором языке программирования

include

Зависимость (dependency)

Исходный прецедент явно включает поведение другого прецедента в точке, определяемой исходным

instanceOf

Зависимость (dependency)

Исходный объект является экземпляром целевого классификатора

instantiate

Зависимость (dependency)

Операции над исходным классом создают экземпляры целевого класса

interface

Класс (class)

Описывает множество операций, определяющих, что может делать класс или компонент

invariant

Ограничение (constraint)

Ограничение, которое всегда должно выполняться для ассоциированного элемента

library

Компонент (component)

Статическая или динамическая объектная библиотека

local

Концевая точка связи (link end)

Соответствующий объект видим, так как находится в локальной области действия

metaclass

Классификатор (classifier)

Классификатор, все объекты которого являются классами

model

Пакет (package)

Описывает семантически замкнутую абстракцию системы

parameter

Концевая точка связи (link end)

Соответствующий объект видим, так как является параметром

postcondition

Ограничение (constraint)

Ограничение, которое должно выполняться после выполнения операции

powertype

Класс (class)

Классификатор, все объекты которого являются потомками данного родителя

Зависимость (dependency)

Говорит, что целевой классификатор связан с исходным отношением powertype

precondition

Ограничение (constraint)

Ограничение, которое должно выполняться перед выполнением операции

process

Класс (class)

Классификатор, экземпляр которого представляет ресурсоемкий поток управления

refine

Зависимость (dependency)

Говорит, что исходный объект является более детальной абстракцией, чем целевой

requirement

Комментарий (comment)

Описывает желаемое свойство или поведение системы

responsibility

Комментарий (comment)

Описывает контракт или обязательство класса

send

Зависимость (dependency)

Исходная операция посылает целевое событие

signal

Класс (class)

Асинхронный стимул, который передается одним экземпляром другому

stereotype

Класс (class)

Классификатор - это стереотип, который может быть применен к другим элементам

stub

Пакет (package)

Пакет выступает в роли заместителя для открытого содержимого другого пакета

subsystem

Пакет (package)

Описывает группирование элементов, ряд которых составляет спецификацию поведения других элементов

system

Пакет (package)

Описывает пакет, представляющий всю моделируемую систему

table

Компонент (component)

Компонент, представляющий таблицу базы данных

thread

Класс (class)

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

trace

Зависимость (dependency)

Целевой элемент - это исторический предок исходного

type

Класс (class)

Абстрактный класс, который используется только для спецификации структуры и поведения (но не реализации) множества объектов

use

Зависимость (dependency)

Семантика исходного элемента зависит от семантики открытого содержания целевого элемента

utility

Класс (class)

Определяет класс, для которого область действия всех атрибутов и операций - класс

Помеченные значения

Приведенные ниже помеченные значения определены как стандартные элементы UML. Для каждого помеченного значения в таблице указывается имя, символ UML, к которому оно применимо, и назначение.

В большинстве случаев помеченное значение изображается посредством размещения метки и значения под именем элемента, к которому оно присоединено. При этом все сочетание заключается в фигурные скобки, например {location = client }. Если значение метки представляет собой длинный текст, то помеченное значение можно поместить в дополнительный раздел классификатора.

Помеченное значение

Символы, к которым оно применимо

Назначение

documentation

Все элементы

Содержит комментарий, описание или пояснение к тому элементу, к которому присоединено

location

Большинство элементов

Определяет узел или компонент, которому принадлежит элемент

persistence

Класс (class), ассоциация (association) атрибут (attribute)

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

semantics

Класс (class), операция (operation)

Описывает назначение класса или операции

Ограничения

Приведенные ниже ограничения определены как стандартные элементы UML. Для каждого помеченного значения в таблице указывается имя, символ UML, к которому оно применимо, и назначение.

В большинстве случаев ограничение размещается рядом с элементом и заключается в фигурные скобки, например {complete}. Можно изображать ограничение и по-другому - помещая в примечание, соединенное с элементом зависимостью.

Ограничение

Символ, к которому оно применимо

Назначение (о чем говорит данное ограничение)

complete

Обобщение (generalization)

В модели специфицированы все потомки в данном обобщении (хотя некоторые могут быть скрыты на диаграммах), и дополнительных потомков определять не разрешается

destroyed

Экземпляр (instance), связь (link)

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

disjoint

Обобщение (generalization)

Объекты данного родителя могут иметь не более одного заданного потомка в качестве типа

implicit

Ассоциация (association)

Отношение является не явно выраженным, а концептуальным

incomplete

Обобщение (generalization)

Специфицированы не все потомки в обобщении (учитывая и скрытых). Разрешается определять дополнительных потомков

new

Экземпляр (instance), связь (link)

Экземпляр или связь создаются в процессе выполнения объемлющего взаимодействия

or

Ассоциация (association)

Из множества ассоциаций ровно одна является явно выраженной для каждого ассоциированного объекта

overlapping

Обобщение (generalization)

Объекты данного родителя могут иметь более одного заданного потомка в качестве типа

transient

Экземпляр (instance), связь (link)

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

(http://dit.isuct.ru/ivt/books/CASE/case11/prB.htm)

6. Иерархия диаграмм в UML 1 и UML 2

(Туривный С.)

В UML 1∇ всего определено 9 канонических типов диаграмм. Ниже перечислены их названия, принятые в этой книге (в других источниках есть отличия).

Диаграмма использования∇ (Use Case diagram)

Диаграмма классов (Class diagram)

Диаграмма объектов (Object diagram)

Диаграмма состояний (State chart diagram)

Диаграмма деятельности (Activity diagram)

Диаграмма последовательности (Sequence diagram)

Диаграмма кооперации (Collaboration diagram)

Диаграмма компонентов (Component diagram)

Диаграмма размещения∇∇ (Deployment diagram)

В UML 2∇ внесены значительные коррективы как в список канонических диаграмм, а именно их число увеличилось до 13, так и в список доступных конструкций языка, что значительно расширило область его применения. Кроме этого две диаграммы были переименованы: диаграмма кооперации была переименована в диаграмму коммуникации∇∇, а диаграмма состояний в диаграмму автомата∇∇∇.

Список новых диаграмм и их названий, принятых в этой книге, приведен ниже.

Диаграмма внутренней структуры (Composite Structure diagram)

Диаграмма пакетов (Package diagram)

Диаграмма автомата (State machine diagram)

Диаграмма коммуникации (Communication diagram)

Обзорная диаграмма взаимодействия (Interaction Overview diagram)

Диаграмма синхронизации (Timing diagram)

(http://book.uml3.ru/sec_1_4)

7. Диаграммы use case (вариантов использования)

(Туривный С.)

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

В процессе тестирования, описанные ранее варианты использования позволяют проще оценить точность реализации требований пользователей и позволяют провести пошаговую проверку этих требований.

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

Состав диаграммы Use Case

Диаграмма вариантов использования состоит из актеров, для которых система производит действие и собственно действия Use Case, которое описывает то, что актер хочет получить от системы. Актер обозначается значком человечка, а Use Case - овалом. Дополнительно в диаграммы могут быть добавлены комментарии.

Ответы на следующие вопросы позволят определить актеров, взаимодействующих с системой:

кто взаимодействует с системой или использует систему;

кто передает или принимает информацию в/из системы;

кто является внешним по отношению к системе.

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

Виды взаимодействий

Между актерами и вариантами использования могут быть различные виды взаимодействия. Основные виды взаимодействия следующие:

Простая ассоциация - отражается линией между актером и вариантом использования (без стрелки). Отражает связь актера и варианта использования. На рисунке между актером администратор и вариантом использованияпросматривать заказ.

Направленная ассоциация - то же что и простая ассоциация, но показывает, что вариант использования инициализируется актером. Обозначается стрелкой.

Наследование - показывает, что потомок наследует атрибуты и поведение своего прямого предка. Может применяться как для актеров, так для вариантов использования.

Расширение (extend) - показывает, что вариант использования расширяет базовую последовательность действий и вставляет собственную последовательность. При этом в отличие от типа отношений "включение" расширенная последовательность может осуществляться в зависимости от определенных условий.

Включение - показывает, что вариант использования включается в базовую последовательность и выполняется всегда (на рисунке не показан).

(http://www.caseclub.ru/articles/use_case.html)

8. Реализация вариантов использования

9. Моделирование структуры на UML

(Туривный С.)

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

Представление классов

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

Рис.1. Изображение класса в нотации UML

(http://www.informicus.ru/Default.aspx?SECTION=6&id=73&subdivisionid=3)

10. Диаграмма классов. Классы

(Туривный С.)

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

Для каждого атрибута класса можно задать видимость (visibility). Эта характеристика показывает, доступен ли атрибут для других классов. В UML определены следующие уровни видимости атрибутов:

Открытый (public) – атрибут виден для любого другого класса (объекта);

Защищенный (protected) – атрибут виден для потомков данного класса;

Закрытый (private) – атрибут не виден внешними классами (объектами) и может использоваться только объектом, его содержащим.

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

Класс содержит объявления операций, представляющих собой определения запросов, которые должны выполнять объекты данного класса. Каждая операция имеет сигнатуру, содержащую имя операции, тип возвращаемого значения и список параметров, который может быть пустым. Реализация операции в виде процедуры – это метод, принадлежащий классу. Для операций, как и для атрибутов класса, определено понятие «видимость». Закрытые операции являются внутренними для объектов класса и недоступны из других объектов. Остальные образуют интерфейсную часть класса и являются средством интеграции класса в ПС.

(http://www.informicus.ru/Default.aspx?SECTION=6&id=73&subdivisionid=3)

11. Диаграмма классов. Отношения

(Туривный С.)

Каждая ассоциация несет информацию о связях между объектами внутри ПС. Наиболее часто используются бинарные ассоциации, связывающие два класса. Ассоциация может иметь название, которое должно выражать суть отображаемой связи (см. рис. 2). Помимо названия, ассоциация может иметь такую характеристику, какмножественность. Она показывает, сколько объектов каждого класса может участвовать в ассоциации. Множественность указывается у каждого конца ассоциации (полюса) и задается конкретным числом или диапазоном чисел. Множественность, указанная в виде звездочки, предполагает любое количество (в том числе, и ноль). Например, на рис.2 ассоциация связывает один объект класса «Набор товаров» с одним или более объектами класса «товар». Связаны между собой могут быть и объекты одного класса, поэтому ассоциация может связывать класс с самим собой. Например, для класса «Житель города» можно ввести ассоциацию «Соседство», которая позволит находить всех соседей конкретного жителя.

Рис.2 Применение ассоциаций

Ассоциация «включает» показывает, что набор может включать несколько различных товаров. В данном случае направленная ассоциация позволяет найти все виды товаров, входящие в набор, но не дает ответа на вопрос, входит ли товар данного вида в какой-либо набор.

Ассоциация сама может обладать свойствами класса, то есть, иметь атрибуты и операции. В этом случае она называется класс-ассоциацией и может рассматриваться как класс, у которого помимо явно указанных атрибутов и операций есть ссылки на оба связываемых ею класса. В примере на рис.2 ассоциация «включает» по существу есть класс-ассоциация, у которой есть атрибут «Количество», показывающий, сколько единиц каждого товара входит в набор (см. рис.4).

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

Рис.3 Наследуются атрибуты и операции

Как уже говорилось ранее, UML позволяет строить модели с различным уровнем детализации. На рис.4 показана детализация модели, представленной на рис.2.

Рис. 4 Детализация модели набора товаров

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

(http://www.informicus.ru/Default.aspx?SECTION=6&id=73&subdivisionid=3)

12. Компоненты и интерфейсы

(Туривный С.)

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

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

Диаграмма компонентов разрабатывается для следующих целей:

визуализации общей структуры исходного кода программной системы;

спецификации исполняемого варианта программной системы;

обеспечения многократного использования отдельных фрагментов программного кода;

представления концептуальной и физической схем баз данных.

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

Компоненты

Для представления физических сущностей в языке UML применяется специальный термин - компонент (component). Компонент реализует некоторый набор интерфейсов и служит для общего обозначения элементов физического представления модели. Для графического представления компонента используется специальный символ - прямоугольник со вставленными слева двумя более мелкими прямоугольниками. Внутри большого прямоугольника записывается имя компонента и, при необходимости, некоторая дополнительная информация. Изображение этого символа может незначительно варьироваться в зависимости от характера ассоциируемой с компонентом информации.

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

Отдельный компонент может быть представлен на уровне типа или на уровне экземпляра. Графическое изображение в обоих случаях одинаковое, но правила записи имени компонента отличаются. Если компонент представляется на уровне типа, то в качестве его имени записывается только имя типа с заглавной буквы. Если же компонент представляется на уровне экземпляра, то в качестве его имени записывается <имя компонента>':'<имя типаХ>. При этом вся строка имени подчеркивается.

В качестве простых имен принято использовать имена исполняемых файлов (с указанием расширения ехе после точки-разделителя), динамических библиотек (расширение dll), Web-страниц (расширение html), текстовых файлов (расширения txt или doc) или файлов справки (hip), файлов баз данных (DB) или файлов с исходными текстами программ (расширения h, cpp для языка C++, расширение java для языка Java), скрипты (pi, asp) и другие.

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

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

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

В языке UML выделяют три вида компонентов:

развертывания, которые обеспечивают непосредственное выполнение системой своих функций. Такими компонентами могут быть динамически подключаемые библиотеки с расширением dll, Web-страницы на языке разметки гипертекста с расширением html и файлы справки с расширением hlp;

рабочие продукты. Как правило, это файлы с исходными текстами программ, например, с расширениями h или срр для языка C++;

исполнения, представляющие собой исполняемые модули - файлы с расширением ехе.

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

Другим способом спецификации различных видов компонентов является явное указание его стереотипа компонента перед именем. В языке UML для компонентов определены следующие стереотипы:

библиотека (library) - определяет первую разновидность компонента, который представляется в форме динамической или статической библиотеки;

таблица (table) - также определяет первую разновидность компонента, который представляется в форме таблицы базы данных;

файл (file) - определяет вторую разновидность компонента, который представляется в виде файлов с исходными текстами программ;

документ (document) - определяет вторую разновидность компонента, . который представляется в форме документа;

исполнимый (executable) — определяет третий вид компонента, который может исполняться в узле.

Интерфейсы

Следующим элементом диаграммы компонентов являются интерфейсы. В общем случае, интерфейс графически изображается окружностью, которая соединяется с компонентом отрезком линии без стрелок. Имя интерфейса должно начинаться с заглавной буквы "I" и записываться рядом с окружностью. Семантически линия означает реализацию интерфейса, а наличие интерфейсов у компонента означает, что данный компонент реализует соответствующий набор интерфейсов.

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

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

Рекомендации по построению диаграммы компонентов

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

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

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

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

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

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

Если проект содержит некоторые физические элементы, описание которых отсутствует в языке UML, то следует воспользоваться механизмом расширения и использовать дополнительные стереотипы для отдельных нетиповых компонентов или помеченные значения для уточнения их отдельных характеристик.

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

(http://www.info-system.ru/designing/methodology/uml/theory/component_diagram_theory.html)

13. Диаграммы реализации

(Туривный С.)

Диаграммы реализации предназначены для отображения состава компилируемых и выполняемых модулей системы, а так же связей между ними. Диаграммы реализаций разделяются на два конкретных вида: диаграммы компонентов(component diagrams) и диаграммы развертывания (deployment diagrams).

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

– зависимость - это зависимость любого типа (использование, совместная компиляция);

– композиция - это включение одних компонентов в состав других.

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

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

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

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

имя типа,

в случае узла - экземпляра имя выглядит так:

имя узла: имя типа.

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

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

(http://www.maksakov-sa.ru/ModelUML/DiagrReal/index.html)

14. Моделирование поведения на UML

(Туривный С.)

Диаграммы поведения

Пять основных диаграмм поведения в UML используются для визуализации, специфицирования, конструирования и документирования динамических аспектов системы. Можно считать, что динамические аспекты системы представляют собой ее изменяющиеся части. Например, динамические аспекты жилого дома - это перемещение потоков воздуха и людей по комнатам. Динамические аспекты программной системы охватывают такие ее элементы, как поток сообщений во времени и физическое перемещение компонентов по сети.

Диаграммы поведения в UML условно разделяются на пять типов в соответствии с основными способами моделирования динамики системы:

диаграммы прецедентов описывают организацию поведения системы;

диаграммы последовательностей акцентируют внимание на временной упорядоченности сообщений;

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

диаграммы состояний описывают изменение состояния системы в ответ на события;

диаграммы деятельности демонстрируют передачу управления от одной деятельности к другой.

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

Следующие две диаграммы семантически идентичны, так же как и две последние. Иными словами, для моделирования динамики системы можно воспользоваться диаграммами одного типа, а затем преобразовать их к другому типу без потери информации. Это позволяет лучше понять различные аспекты динамики системы. Например, можно сначала создать диаграмму последовательностей, иллюстрирующую временную упорядоченность сообщений, а затем преобразовать в диаграмму кооперации, помогающую легко разрабатывать структурные отношения между классами, объекты которых участвуют в этой кооперации (разумеется, не воспрещено двигаться и в обратном направлении, от диаграммы кооперации к диаграмме последовательностей). Можно также начать с диаграммы состояний, показывающей реакцию системы на события, и преобразовать ее в диаграмму действий, которая заостряет внимание на потоке управления (или же, наоборот, от диаграммы действий перейти к диаграмме состояний). Причина, по которой в UML предусмотрены семантически эквивалентные диаграммы, состоит в том, что моделирование динамики системы - очень непростая задача, и зачастую приходится подходить к решению какой-нибудь многогранной проблемы сразу с нескольких сторон.

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

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

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

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

Диаграмма состояний показывает автомат, содержащий состояния, переходы, события и действия (см. главу 24). Диаграммы такого рода относятся к динамическому виду системы и особенно важны при моделировании поведения интерфейса, класса или кооперации. Основное внимание в них уделяется порядку возникновения событий, связанных с объектом, что особенно полезно при моделировании реактивных систем.

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

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

Диаграмма автомата (state machine diagram) ‒ это один из способов детального описания поведения в UML на основе явного выделения состояний и описания переходов между состояниями.

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

На диаграмме автомата применяют один основной тип сущностей ‒ состояния 1, и один тип отношений ‒ переходы 2, но и для тех и для других определено множество разновидностей, специальных случаев и дополнительных обозначений. Перечислять их все во вступительном обзоре не имеет смысла.

Диаграмма деятельности (activity diagram) ‒ способ описания поведения на основе указания потоков управления и потоков данных.

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

На диаграмме деятельности применяют один основной тип сущностей ‒ действие 1, и один тип отношений ‒ переходы 2 (передачи управления и данных). Также используются такие конструкции как развилки, слияния, соединения, ветвления 3, которые похожи на сущности, но таковыми на самом деле не являются, а представляют собой графический способ изображения некоторых частных случаев многоместных отношений.

Диаграмма последовательности (sequence diagram) ‒ это способ описания поведения системы на основе указания последовательности передаваемых сообщений.

Фактически, диаграмма последовательности ‒ это запись протокола конкретного сеанса работы системы (или фрагмента такого протокола). В объектно-ориентированном программировании самым существенным во время выполнения является пересылка сообщений между взаимодействующими объектами. Именно последовательность посылок сообщений отображается на данной диаграмме, отсюда и название.

На диаграмме последовательности применяют один основной тип сущностей ‒ экземпляры взаимодействующих классификаторов 1 (в основном классов, компонентов и действующих лиц), и один тип отношений ‒ связи 2, по которым происходит обмен сообщениями 3. Предусмотрено несколько способов посылки сообщений, которые в графической нотации различаются видом стрелки, соответствующей отношению.

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

Ось времени может быть направлена горизонтально, в этом случае считается, что время течет слева направо.

На следующем рисунке показаны основные элементы нотации, применяемые на диаграмме последовательности. Для обозначения самих взаимодействующих объектов применяется стандартная нотация ‒ прямоугольник с именем экземпляра классификатора. Пунктирная линия, выходящая из него, называется линией жизни (lifeline) 4. Это не обозначение отношения в модели, а графический комментарий, призванный направить взгляд читателя диаграммы в правильном направлении. Фигуры в виде узких полосок, наложенных на линию жизни, также не являются изображениями моделируемых сущностей. Это графический комментарий, показывающий отрезки времени, в течении которых объект владеет потоком управления (execution occurrence) 5 или другими словами имеет место активация(activation) объекта. Составные шаги взаимодействия(combined fragment) 6 позволяют на диаграмме последовательности, отражать и алгоритмические аспекты протокола взаимодействия.

Диаграмма коммуникации (communication diagram) ‒ способ описания поведения, семантически эквивалентный диаграмме последовательности.

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

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

На рисунке показаны основные элементы нотации, применяемые на диаграмме коммуникации. Для обозначения самих взаимодействующих объектов применяется стандартная нотация ‒ прямоугольник с именем экземпляра классификатора. Взаимное положение элементов на диаграмме кооперации не имеет значения ‒ важны только связи (чаще всего экземпляры ассоциаций), вдоль которых передаются сообщения 3. Для отображения упорядоченности сообщений во времени применяется иерархическая десятичная нумерация.

(http://ooad.asf.ru/standarts/UML/LanguageUML/List07-5.aspx, http://book.uml3.ru/sec_1_5)

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

(Туривный С.)

Диаграммы состояний (state diagrams)

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

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

Рисунок 2.23 "Диаграмма состояний №1"

1. Состояния

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

Состояние может иметь иерархическую структуру. Каждое подсостояние (substate) может иметь свое начальное и конечное псевдосостояния. Переход в такое состояние означает переход в начальное псевдосостояние внутри него. Переход в конечное псевдосостояние подсостояния означает завершение работы данного подсостояния; завершение работы всех подсостояний означает завершение активности данного состояния и выход из него.

Состояние представляется на диаграмме как прямоугольник с закругленными углами (рис.2.24). Он может иметь одну или несколько секций. В них содержатся:

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

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

Внутреннее поведение. Указывается список внутренних действий, выполняемых когда объект находится в данном состоянии. Каждое действие описывается следующим образом:

<имя события><список параметров>‘/’<действие>

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

‘entry’ ‘/’ <действие> - действие, выполняемое при входе в состояние.

‘exit’ ‘/’ <действие> - действие, выполняемое при выходе из состояния.

‘do’ ‘/’ <действие> - действие, выполняемое при нахождении в состоянии.

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

Рисунок 2.24 "Состояние"

2. Подсостояния

Состояние может быть усовершенствовано введением последовательных подсостояний со связями типа “И” или взаимоисключающих подсостояний со связями типа “ИЛИ”. Любое состояние может быть усовершенствовано одним из этих способов. Его подсостояния так же могут быть усовершенствованы первым или вторым способом.

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

Объект, перешедший в конечное псевдосостояние, прекращает свое существование.

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

Расширение состояния в виде параллельных подсостояний представляется как несколько окон, расположенных в данном состоянии одно под другим и разделенных пунктирной линией (рис.2.26). Каждое подсостояние может иметь свое имя и может содержать вложенную диаграмму непересекающихся состояний. Секции с текстовой информацией при данном представлении отделяются сплошной линией.

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

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

Рисунок 2.25 "Диаграмма состояний с последовательными подсостояниями"

Рисунок 2.26 "Диаграмма состояний с параллельными подсостояниями"

3. События

Событием (event) называется заслуживающее внимания происшествие. В диаграмме состояний оно может вызывать переход из состояния в состояние. События могут быть различных видов:

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

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

Истечение определенного промежутка времени после обозначенного события. Описывается временным интервалом, по истечении которого вызывается переход.

Сигнал или вызов события может быть определен следующим образом:

<имя события>‘(’<параметр>‘,’ . . .‘)’

Параметры имеют следующий формат:

<имя параметра>‘:’<тип>

Сигнал может быть представлен как класс со стереотипом "signal" на диаграмме классов (рис.2.27). Параметры будут в этом случае атрибутами класса. Сигнал также может быть определен как подкласс другого сигнала.

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

[date = Jan. 1, 2000] или [10 seconds since exit from state A].

События могут быть объявлены на диаграмме классов как класс со стереотипом "event".

Рисунок 2.27 "Объявление сигнала"

4. Простой переход

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

Переход на диаграмме состояний представляется сплошной линией со стрелкой на конце, проведенной от одного состояния (исходное состояние) к другому состоянию (конечное состояние), помеченной строкой перехода. Данная строка имеет следующий формат:

<описание события>‘[’<условное выражение>]‘/’<действие>‘^’<посылка сообщения>

Описание события описывает событие и его аргументы:

<имя события>‘(‘<параметр>‘,’ . . . ‘)’

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

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

Посылка сообщения определяет сообщение (или сигнал), посылаемое при возникновении данного события, и имеет следующий формат:

<адресат>‘.’<имя сообщения>‘(‘<параметр>‘.’ . . . ‘)’

Переход может содержать несколько таких предложений. Порядок их расположения определяет порядок их выполнения.

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

Имя сообщения содержит в себе имя события, о котором посылается сообщение (сигнал).

Параметры передаются вместе с данным сообщением (сигналом) объекту-адресату.

Пример:

right-mouse-down (location) [location in window] / object := pick-object (location) ^ object.highlight ()

5. Сложный переход

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

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

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

Сложный переход представляется на диаграмме состояний коротким вертикальным закрашенным прямоугольником (рис.2.28). От прямоугольника может исходить одна или несколько линий со стрелками на конце, проведенных к конечным состояниям. К символу сложного перехода могут быть проведены одна или несколько линий со стрелками на конце, проведенных от исходных состояний. Строка перехода располагается около данного символа. Конкретные линии, проведенные к определенным состояниям не могут иметь своих строк перехода.

Рисунок 2.28 "Сложный переход"

6. Переход в состояние со сложной структурой

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

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

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

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

Состояние может содержать в себе индикатор предшествующего состояния (history state indicator), представляемый на диаграмме состояний как маленький кружок с буквой "Н" внутри (рис.2.30). Индикатор предшествующего состояния может иметь любое количество входящих переходов, но не может иметь выходящих переходов. Если в него выполняется переход, то это означает, что объект возвращается в то состояние, в котором он пребывал, перед тем как покинуть данное сложное состояние. Необходимые входные ("entry") действия при этом также выполняются.

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

Рисунок 2.29 "Пример переходов в сложном состоянии"

Рисунок 2.30 "History state indicator"

7. Посылка сообщений

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

Посылка сообщения на диаграмме представляется сплошной линией со стрелкой на конце, проведенной от данного объекта к объекту-адресату. Стрелка помечается именем события, списком его аргументов.

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

Рисунок 2.31 "Посылка сообщений"

(http://www.exponenta.ru/soft/Others/mvs/stud2/26.asp)

16. Диаграммы деятельности

(Туривный С.)

Диаграммы деятельности - это один из пяти видов диаграмм, применяемых в UML для моделирования динамических аспектов поведения системы (другие виды: диаграммы последовательностей и кооперации, состояний, прецедентов, см. главы 18, 24 и 17 соответственно). Диаграмма деятельности - это, по существу, блок-схема, которая показывает, как поток управления переходит от одной деятельности к другой.

Диаграммы деятельности можно использовать для моделирования динамических аспектов поведения системы. Как правило, они применяются, чтобы промоделировать последовательные (а иногда и параллельные) шаги вычислительного процесса. С помощью диаграмм деятельности можно также моделировать жизнь объекта, когда он переходит из одного состояния в другое в разных точках потока управления. Диаграммы деятельности могут использоваться самостоятельно для визуализации, специфицирования, конструирования и документирования динамики совокупности объектов, но они пригодны также и для моделирования потока управления при выполнении некоторой операции. Если в диаграммах взаимодействий акцент делается на переходах потока управления от объекта к объекту, то диаграммы деятельности описывают переходы от одной деятельности к другой. Деятельность (Activity) - это некоторый относительно продолжительный этап выполнения в автомате. В конечном итоге деятельность сводится к некоторому действию (Action, см. главу 15), которое составлено из атомарных вычислений, приводящих к изменению состояния системы или возврату значения.

Диаграммы деятельности важны не только для моделирования динамических аспектов поведения системы, но и для построения выполняемых систем посредством прямого и обратного проектирования.

Введение

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

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

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

В строительной индустрии, как правило, применяются методики, основанные на Gantt- и Pert-диаграммах, которые позволяют визуализировать, специфицировать, конструировать и документировать последовательность операций при выполнении проекта.

При моделировании программных систем вы сталкиваетесь с аналогичной проблемой. Как лучше всего промоделировать рабочий процесс или функционирование системы? То и другое - аспекты ее динамики (моделирование структурных аспектов системы рассмотрено в частях 2 и 3 данной книги). В принципе есть два варианта, которые напоминают применение Gantt- и Pert-диаграмм.

С одной стороны, можно построить несколько прецедентов, описывающих взаимодействие различных представляющих интерес объектов и сообщения, которыми они обмениваются. В UML такие прецеденты можно моделировать двумя способами: делая акцент на упорядочении сообщений по времени (с помощью диаграмм последовательностей) или на структурных отношениях между взаимодействующими объектами (с помощью диаграмм кооперации, см. главу 18). Такого рода диаграммы взаимодействия близки к Gantt-диаграммам, в фокусе которых находятся объекты (ресурсы), выполняющие некоторую работу во времени.

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

Рис. 19.1 Диаграмма деятельности

Термины и понятия

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

Общие свойства

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

Наполнение

Диаграмма деятельности в общем случае состоит из:

состояний деятельности и состояний действия;

переходов (см. главу 21); Q объектов (см. главу 13).

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

Диаграмма деятельности, как и любая другая диаграмма, может содержать примечания и ограничения.

Состояния действия и состояния деятельности

В потоке управления, моделируемом диаграммой деятельности, происходят различные события. Вы можете вычислить выражение, в результате чего изменяется значение некоторого атрибута или возвращается некоторое значение. Также, например, можно выполнить операцию (см. главы 4 и 9) над объектом (см. главу 15), послать ему сигнал (см. главу 20) или даже создать его или уничтожить. Все эти выполняемые атомарные вычисления называются состояниями (см. главу 21) действия, поскольку каждое из них есть состояние системы, представляющее собой выполнение некоторого действия. Как показано на рис. 19.2, состояния действия изображаются прямоугольниками с закругленными краями. Внутри такого символа можно записывать произвольное выражение.

Рис. 19.2 Состояния действия

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

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

Примечание: Конечно, в реальном мире для любого вычисления требуется некоторое время и память. Учет этих свойств в модели особенно важен для встроенных систем реального времени. (Моделирование времени и пространства обсуждается в главе 23.)

В противоположность этому состояния деятельности могут быть подвергнуты дальнейшей декомпозиции, вследствие чего выполняемую деятельность можно представить с помощью других диаграмм деятельности. Состояния деятельности не являются атомарными, то есть могут быть прерваны. Предполагается, что для их завершения требуется заметное время. Можно считать, что состояние действия - это частный вид состояния деятельности, а конкретнее - такое состояние, которое не может быть подвергнуто дальнейшей декомпозиции. А состояние деятельности можно представлять себе как составное состояние, поток управления которого включает только другие состояния деятельности и действий. Взгляните более пристально на внутреннюю структуру состояния деятельности, и вы найдете еще одну диаграмму деятельности. Как видно из рис. 19.3, состояния деятельности и действий обозначаются одинаково, с тем отличием, что у первого могут быть дополнительные части, такие как действия входа и выхода (то есть выполняемые соответственно при входе в состояние и выходе из него), и оно может сопровождаться спецификациями подавтоматов (см. главу 21).

Рис. 19.3 Состояния деятельности

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

Переходы

Когда действие или деятельность в некотором состоянии завершается, поток управления сразу переходит в следующее состояние действия или деятельности. Для описания этого потока используются переходы (Transitions, см. главу 21), показывающие путь из одного состояния действия или деятельности в другое. В UML переход представляется простой линией со стрелкой, как показано на рис. 19.4.

Рис. 19.4 Нетриггерные переходы

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

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

Ветвление

Простые последовательные переходы встречаются наиболее часто, но их одних недостаточно для моделирования любого потока управления. Как и в блок-схеме, вы можете включить в модель ветвление, которое описывает различные пути выполнения в зависимости от значения некоторого булевского выражения. Как видно из рис. 19.5, точка ветвления представляется ромбом. В точку ветвления может входить ровно один переход, а выходить - два или более. Для каждого исходящего перехода задается булевское выражение, которое вычисляется только один раз при входе в точку ветвления. Ни для каких двух исходящих переходов эти сторожевые условия не должны одновременно принимать значение "истина", иначе поток управления окажется неоднозначным. Но эти условия должны покрывать все возможные варианты, иначе поток остановится. (Ветвление семантически эквивалентно множественным переходам со сторожевыми условиями, см. главу 21.)

Рис. 19.5 Ветвление

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

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

Примечание: UML не предписывает язык для этих выражений. В общем случае вы можете использовать структурированный текст; для большей строгости можно воспользоваться синтаксисом и семантикой определенного языка программирования.

Разделение и слияние

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

Рассмотрим, например, параллельные потоки, используемые в устройстве, которое имитирует человеческую речь и жестикуляцию. Как показано на рис. 19.6, точка разделения соответствует расщеплению одного потока управления на два выполняющихся параллельно. В этой точке может существовать ровно один входящий переход и два или более исходящих. Каждый исходящий переход представляет один независимый поток управления. После точки разделения деятельности, ассоциированные с каждым путем в графе, продолжают выполняться параллельно. С концептуальной точки зрения имеется в виду истинный параллелизм, то есть одновременное выполнение, но в реальной системе это может как выполняться (если система функционирует на нескольких узлах, см. главу 26), так и не выполняться (если система размещена только на одном узле). В последнем случае имеет место последовательное выполнение с переключением между потоками, что дает лишь иллюзию истинного параллелизма.

Рис. 19.6 Разделение и слияние

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

Примечание: Должен поддерживаться баланс между точками разделения и слияния. Это означает, что число потоков, исходящих из точки разделения, должно быть равно числу потоков, приходящих в соответствую -щую ей точку слияния. Деятельности, выполняемые в параллельных потоках, могут обмениваться друг с другом информацией, посылая сигналы. Такой способ организация взаимодействия последовательных процессов называется сопрограммами (Coroutine). В большинстве случаев при моделировании такого взаимодействия применяются активные объекты (см. главу 22). Но посылку сигналов (см. главу 20) и получение ответов можно моделировать и с помощью подавтоматов, ассоциированных с каждым из взаимодействующих состояний деятельности. Предположим, к примеру, что деятельность Поток речи должна сообщить деятельности Синхронизация движения губ о важных паузах и интонациях. Тогда в автомате, реализующем Поток речи, нужно было бы посылать сигналы автомату, реализующему Синхронизацию движения губ. А в автомате для Синхронизации движения губ присутствовали бы срабатывающие при получении таких сигналов переходы в состояния, где этот автомат на них отвечает.

Дорожки

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

Рис. 19.7 Дорожки

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

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

Траектория объекта

В потоке управления, ассоциированном с диаграммой деятельности, могут участвовать объекты (см. главу 13). К примеру, для последовательности операций по обработке заказа, которая изображена на рис. 19.7, словарь (см. главу 4) проблемной области будет, вероятно, включать такие классы, как Заказ и Счет. Некоторые виды деятельности будут порождать объекты-экземпляры этих классов (например, Обработать заказ создаст объект Заказ), тогда как другие виды деятельности будут модифицировать эти объекты (например, Отгрузить заказ может изменить состояние объекта Заказ на выполнен).

Как видно из рис. 19.8, относящиеся к деятельности объекты можно включить в диаграмму деятельности и с помощью символа зависимости (см. главы 5 и 10) привязать к той деятельности или переходу, где они создаются, модифицируются или уничтожаются. Такое сочетание зависимостей и объекта называется траекторией объекта (Object flow), поскольку описывает его участие в потоке управления.

Рис. 19.8 Траектория объекта

Кроме изображения траектории объекта на диаграмме деятельности вы можете показать, как изменяются его роль, состояние (см. главу 13) и значения атрибутов (см. главы 4 и 9). Как показано на рисунке, для изображения состояния объекта его имя заключается в скобки и помещается под именем объекта. Аналогично можно представить и значения атрибутов объекта.

Типичные примеры применения

Диаграммы деятельности используются для моделирования динамических аспектов системы. Эти динамические аспекты могут предполагать деятельность любого уровня абстракции любого вида системной архитектуры (см. главу 2), включая классы (в том числе активные, см. главу 22), интерфейсы (см. главу 11), компоненты (см. главу 2.5) и узлы (см. главу 26).

Использовать диаграмму деятельности для моделирования некоторого динамического аспекта системы можно в контексте практически любого элемента модели. Но чаще всего они рассматриваются в контексте системы в целом, подсистемы (см. главу 31), операции (см. главы 4 и 9) или класса (см. там же). Можно присоединять диаграммы деятельности к прецедентам (см. главу 16) и кооперациям (для моделирования динамических аспектов сообщества объектов).

При моделировании динамических аспектов системы диаграммы деятельности применяются в основном двумя способами:

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

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

Типичные приемы моделирования

Рабочий процесс

Программные системы не существуют изолированно; всегда имеется некоторый контекст (см. главу 17), в рамках которого система функционирует, причем он всегда включает актеры, взаимодействующие с системой. Рассматривая необходимое для бизнеса программное обеспечение масштаба предприятия, вы обязательно обнаружите, что автоматизированная система работает в контексте бизнес-процессов более высокого уровня. Такие бизнес-процессы являются примерами рабочих процессов, поскольку описывают, как функционирует предприятие и какие в него вовлечены объекты. Например, в розничной торговле имеются как автоматизированные системы (скажем, кассовые терминалы, взаимодействующие с подсистемами маркетинга и складского учета), так и неавтоматизированные (люди, работающие в торговых точках, в отделах дистанционных продаж, маркетинга, заказов и отгрузки). Моделировать эти бизнес-процессы с точки зрения кооперации различных автоматизированных и неавтоматизированных систем можно с помощью диаграмм деятельности.

Для того чтобы построить модель рабочего процесса, необходимо следующее:

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

Выберите бизнес-объекты, на которые возложена ответственность высокого уровня за части всего рабочего процесса. Это могут быть реальные сущности, вошедшие в системный словарь (см. главу 4), или более абстрактные объекты. В любом случае следует создать отдельную дорожку для каждого бизнес-объекта.

Идентифицируйте предусловия для начального состояния рабочего процесса и постусловия (см. главу 9) для его конечного состояния. Это поможет при моделировании границ процесса.

Начиная с исходного состояния опишите деятельности и действия, выполняемые в различные моменты времени, а затем отразите их на диаграмме деятельности в виде состояний деятельности или действий.

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

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

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

Например, на рис. 19.9 показана диаграмма действий для бизнеса, связанного с розничной торговлей. Диаграмма описывает, что происходит, когда клиент возвращает товар, заказанный по почте. Процесс начинается с действия Запрос возврата со стороны Клиента, затем переходит на дорожку Дистанционные продажи (Получить номер возврата), возвращается на дорожку Клиент (Отправить товар), переходит на дорожку Склад (Принять товар, затем Переучесть товар) и завершается на дорожке Бухгалтерия (Кредитовать расчетный счет). Как видно из диаграммы, в процессе участвует один существенный объект (i - экземпляр класса Товар), состояние которого изменяется с возвращен на доступен.

Рис. 19.9 Моделирование рабочего процесса

Примечание: Рабочие процессы, чаще всего представляют собой бизнес-процессы, но это не обязательно. Например, диаграммы действий можно применить для описания процессов разработки программного обеспечения - скажем, процесса управления конфигурацией. В равной мере они пригодны для моделирования непрограммных систем, таких как поток пациентов в учреждении здравоохранения.

В этом примере нет ни ветвлений, ни разделений, ни слияний. С этими элементами мы встретимся при рассмотрении более сложных рабочих процессов.

Операция

Диаграмму деятельности можно присоединить к любому элементу модели для визуализации, специфицирования, конструирования и документирования поведения этого элемента, в частности к классам (см. главы 4 и 9), интерфейсам (см. главу 11), компонентам (см. главу 25), узлам (см. главу 26), прецедентам (см. главу 16) и кооперациям (см. главу 27). Чаще всего диаграммы деятельности присоединяются к операциям.

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

Моделирование операции состоит из следующих шагов:

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

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

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

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

Лишь в том случае, если владельцем операции является активный класс (см. главу 22), используйте точки разделения и слияния для описания параллельных потоков выполнения, если в этом возникает необходимость.

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

Так, на рис. 19.10 представлена диаграмма деятельности для класса Line (ПрямаяЛиния), которая описывает алгоритм операции пересечение. Сигнатура алгоритма состоит из одного параметра (1 - входной параметр класса Line) и одного возвращаемого значения (класса Point, Точка). Из атрибутов класса Line интерес представляют два: slope (тангенс угла наклона прямой) и delta (смещение прямой относительно начала координат).

Рис. 19.10 Моделирование операции

Алгоритм операции пересечения несложен, как явствует из диаграммы деятельности. В самом начале имеется сторожевое условие, которое проверяет, совпадает ли наклон текущей прямой с наклоном параметра 1. Если условие выполнено, то прямые не пересекаются и возвращается точка Point (0, 0). В противном случае сначала вычисляется абсцисса х точки пересечения, а затем - ордината у. Объекты х и у являются локальными для операции. И наконец, возвращается точка Point (х,у).

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

Прямое и обратное проектирование

Для диаграмм деятельности возможно прямое проектирование (создание кода на основе модели), особенно если диаграмма моделирует операцию. Например, из показанной выше диаграммы работ инструментальная программа могла бы сгенерировать для операции пересечение следующий код на языке C++:

Point Line::intersection(I : Line) {

if (slope == 1.slope) return Point(0,0);

int x = (1.delta - delta) / (slope - 1.slope);

int у = (slope * x) + delta;

return Point(x,y);

}

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

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

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

Советы

Создавая в UML диаграммы деятельности, не забывайте, что они лишь моделируют срез некоторых динамических аспектов поведения системы. С помощью единственной диаграммы деятельности никогда не удастся охватить все динамические аспекты системы. Вместо этого следует использовать разные диаграммы деятельности для моделирования динамики рабочих процессов или отдельных операций.

Диаграмму деятельности можно признать хорошо структурированной, если она:

сконцентрирована на описании одного аспекта динамики системы;

содержит только те элементы, которые существенны для понимания этого аспекта;

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

не настолько кратка, чтобы читатель упустил из виду важные аспекты семантики.

Рисуя диаграмму деятельности, руководствуйтесь следующими принципами:

дайте диаграмме имя, соответствующее ее назначению;

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

располагайте элементы так, чтобы число пересечений было минимальным;

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

(http://dit.isuct.ru/ivt/books/CASE/case11/ch19.htm)

17. Диаграмма последовательности и диаграмма коммуникации

(Туривный С.)

Диаграмма последовательности

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

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

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

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

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

На диаграммах последовательности допустимо использование стандартных стереотипов класса:

Actor – экземпляр участника процесса (роль на диаграмме прецедентов)

Boundary – Класс-Разграничитель - используется для классов, отделяющих внутреннюю структуру системы от внешней среды (экранная форма, пользовательский интерфейс, устройство ввода-вывода). Объект со стереотипом < отличается от, привычного нам, класса <<Интерфейс>>, который по большей части предназначен для вызова методов класса, с которым он связан. Объект boundary показывает именно экранную форму, которая принимает и передает данные обработчику.

Control – Класс-контроллер - активный элемент, который используются для выполнения некоторых операций над объектами (программный компонент, модуль, обработчик)

Entity – Класс-сущность - обычно применяется для обозначения классов, которые хранят некую информацию о бизнес-объектах (соответствует таблице или элементу БД)

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

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

Диаграмма последовательности объединяет диаграмму деятельности, диаграмму состояний и диаграмму классов.

Таким образом, на диаграмме последовательности мы можем увидеть следующие аспекты:

Сообщения, побуждающие объект к действию

Действия, которые вызываются сообщениями (методы) – зачастую это передача сообщения следующему объекты или возвращение определенных данных объекта

Последовательность обмена сообщениями между объектами

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

В UML различают следующие виды сообщений:

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

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

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

потерянное сообщение (lost) – сообщение, не имеющее адресата сообщения, т.е. для него существует событие передачи и отсутствует событие приема

найденное сообщение (found) – сообщение, не имеющее инициатора сообщения, т.е. для него существует событие приема и отсутствует событие передачи

Для сообщений также доступен ряд предопределенных стереотипов. Наиболее часто используемые стереотипы это create и destroy.

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

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

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

ограничение продолжительности (Duration Constraint) – минимальное и максимальное значение продолжительности передачи сообщения

ограничение продолжительности ожидания между передачей и получением сообщения (Duration Constraint Between Messages)

перехват продолжительности сообщения (Duration Observation)

временное ограничение (Timing Constraint) – временной интервал, в течение которого сообщение должно прийти к цели (устанавливается на стороне получателя)

перехват времени, когда сообщение было отправлено (Timing Observation)

Форма заказа передает данные Менеджеру заказа, при этом передача данных не должна длиться больше 30 сек. – данное ограничение может понадобиться при выявлении требований к быстродействию Системы. Далее получение данных с формы инициирует запуск метода для создания экземпляра класса Заказ. Между получением данных от Формы заказа и инициализацией создания объекта должно пройти не более 30 сек., в противном случае пользователю может быть предоставлено сообщение об ошибке или недоступности сервера. Длительность передачи сообщения о создании объекта может быть зафиксирована в переменной d.

Данное значение может понадобиться при установке временного ограничения на получение ответного сообщения клиентом. В момент передачи сообщения фиксируется временное значение и заносится в переменную t. Таким образом, можно установить ограничение на стороне приемника, указав переменную t в качестве минимального значения и t+<допустимый интервал> в качестве максимального значения.

До появления UML 2.0 диаграмма последовательности рассматривалась только в рамках моделирования последовательности обмена сообщениями. Расширение сценария отображались с помощью ветвления линий сообщений, что не давало полной картины взаимодействия объектов. Таким образом, для целей моделирования расширения сценария, параллельности процессов или цикличности использовались диаграммы деятельности. Для решения данных задач в UML 2.0 было введено понятие фрейма взаимодействия и операторов взаимодействия.

Отдельные фрагменты диаграммы взаимодействия можно выделить с помощью фрейма. Фрейм должен содержать метку оператора взаимодействия. UML содержит следующие операнды:

Alt - Несколько альтернативных фрагментов (alternative); выполняется только тот фрагмент, условие которого истинно

Opt - Необязательный (optional) фрагмент; выполняется, только если условие истинно. Эквивалентно alt с одной веткой

Par - Параллельный (parallel); все фрагменты выполняются параллельно

loop - Цикл (loop); фрагмент может выполняться несколько раз, а защита обозначает тело итерации

region - Критическая область (critical region); фрагмент может иметь только один поток, выполняющийся за один прием

Neg - Отрицательный (negative) фрагмент; обозначает неверное взаимодействие

ref - Ссылка (reference); ссылается на взаимодействие, определенное на другой диаграмме. Фрейм рисуется, чтобы охватить линии жизни, вовлеченные во взаимодействие. Можно определять параметры и возвращать значение

Sd - Диаграмма последовательности (sequence diagram); используется для очерчивания всей диаграммы последовательности, если это необходимо.

При использовании фрагмента условного операнда фрейм должен содержать условие для ограничения взаимодействия. При использовании условного или параллельного операнда фрейм делится на регионы взаимодействия с помощью разделителя операторов взаимодействия.

К условным операндам относятся alt и opt. Операнд alt используется при моделировании расширения сценария, т.е. при наличии альтернативного потока взаимодействия. Оператор opt используется, если сообщение должно быть передано, только при истинности какого-то условия. Данный фрейм используется без разделения на регионы.

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

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

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

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

Также диаграммы последовательности подойдут для моделирования взаимодействия пользователя и Системы в целом.

На уровне детальной спецификации требований диаграммы последовательности используются для моделирования взаимодействия компонентов Системы и пользовательских классов в рамках выбранного прецедента.

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

Диаграммы коммуникации

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

Кроме отображения связей, которые представляют собой экземпляры ассоциаций, можно также показать временные связи, возникающие только в контексте взаимодействия. В данном случае связь «local» (локальная) от объекта Order (Заказ) к объекту Product (Продукт) – это локальная переменная, а другими временными связями являются «parameter» (параметр) и «global» (глобальная). Эти ключевые слова употреблялись в UML 1, но пропали из UML 2. Они полезны, поэтому я надеюсь, что разработчики от них не откажутся.

Стиль нумерации на рис. 12.1 простой и общеупотребительный, но в языке UML он не разрешен. В соответствии с правилами UML необходимо придерживаться вложенной десятичной нумерации, как показано на рис. 12.2.

Вложенная десятичная нумерация нужна, потому что требуется исключить неопределенность при самовызовах. На рис. 4.2 четко показано, что метод getDiscountInfo вызывается из методаcalculateDiscount.

Однако в случае применения линейной нумерации, как на рис. 12.1, нельзя будет сказать, вызывается ли метод getDiscountInfo из метода calculateDiscount или из более общего методаcalculatePrice. Схема вложенной нумерации позволяет обойти эту трудность.

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

Кроме чисел в сообщениях можно увидеть и буквы. Эти символы обозначают различные потоки управления. Так, A5 и B2 могут быть различными потоками; сообщения 1a1 и 1b1 могут быть различными потоками, параллельно вложенными в сообщение 1. Буквы, обозначающие потоки, можно увидеть также и на диаграммах последовательности, хотя это и не дает визуального представления о параллельности.

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

и «delete» соответствуют общепринятым соглашениям.

(http://it-gost.ru/articles/view_articles/94, http://www.planerka.info/item/Diagrammy-kommunikacij-UML)

18. Паттерны проектирования и каркасы на UML

(Туривный С.)

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

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

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

Рис. 14.1. Изображение паттерна в форме параметризованной кооперации

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

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

№

Название паттерна

Перевод

Назначение паттерна

1

Abstract Factory

Абстрактная фабрика

Предоставляет интерфейс для создания множества связанных между собой или независимых объектов, конкретные классы которых неизвестны.

2

Adapter(синоним - Wrapper)

Адаптер (Обертка)

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

3

Bridge

Мост

Отделяет абстракцию класса от его реализации, благодаря чему появляется возможность независимо изменять то и другое.

4

Builder

Строитель

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

5

Chain of Responsibility

Цепочка обязанностей

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

6

Command

Команда

Инкапсулирует запрос в виде объекта, обеспечивая параметризацию клиентов типом запроса, установление очередности запросов, протоколирование запросов и отмену выполнения операций.

7

Composite

Компоновщик

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

8

Decorator

Декоратор

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

9

Facade

Фасад

Предоставляет единый интерфейс к множеству операций или интерфейсов в системе на основе унифицированного интерфейса для облегчения работы с системой.

10

Factory Method

Фабричный метод

Определяет интерфейс для разработки объектов, при этом объекты данного класса могут быть созданы его подклассами.

11

Flyweight

Приспособленец

Использует принцип разделения для эффективной поддержки большого числа мелких объектов.

12

Interpreter

Интерпретатор

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

13

Iterator

Итератор

Дает возможность последовательно перебрать все элементы составного объекта, не раскрывая его внутреннего представления.

14

Mediator

Посредник

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

15

Memento

Хранитель

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

16

Observer

Наблюдатель

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

17

Prototype

Прототип

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

18

Proxy

Заместитель

Подменяет выбранный объект другим объектом для управления контроля доступа к исходному объекту.

19

Singleton

Одиночка

Для выбранного класса обеспечивает выполнение требования единственности экземпляра и предоставления к нему полного доступа.

20

State

Состояние

Позволяет выбранному объекту варьировать свое поведение при изменении внутреннего состояния. При этом создается впечатление, что изменился класс объекта.

21

Strategy

Стратегия

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

22

Template Method

Шаблонный метод

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

23

Visitor

Посетитель

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

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

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

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

На рис. 28.3 показан такой каркас, названный ЦиклическийИсполнитель. Среди прочего каркас включает кооперацию (ОбщиеСобытия), охватывающую множество классов событий (см. главу 20), и механизм (ОбработчикСобытий) для циклической обработки событий. Клиент, построенный на базе этого каркаса (к примеру, СердечныйСтимулятор) может пользоваться абстракциями из кооперации ОбщиеСобытия путем порождения производных классов, а также применять механизм ОбработчикСобытий.

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

(http://www.intuit.ru/studies/courses/32/32/lecture/1026?page=3, http://dit.isuct.ru/ivt/books/CASE/case11/ch28.htm#Heading7)

19. Управление моделями

(Туривный С.)

Пакет Управление моделями

Пакет Управление моделями (Model Management) специфицирует базовые элементы языка UML, которые необходимы для формирования всех модельных представлений. Именно в нем определяется семантика модели (Model), пакета (Package) и подсистемы (Subsystem). Эти элементы служат своеобразными контейнерами для группировки других элементов модели.

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

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

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

Подсистема есть просто группировка элементов модели, которые специфицируют некоторое простейшее поведение физической системы. В метамоде-ли UML подсистема является подклассом как пакета, так и классификатора. Элементы подсистемы делятся на две части - спецификацию поведения и его реализацию.

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

Рис. 3.9. Графическое изображение подсистемы в языке UML

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

(http://dit.isuct.ru/ivt/books/CASE/case6/gl3/gl3.html#16)

20. Влияние UML на процесс разработки