Арлоу Д., Нейштадт А. UML2 и Унифицированный процесс. Практический объектно-ориентированный анализ и проектирование

Подождите немного. Документ загружается.

304 Глава 13. Дополнительные аспекты реализации прецедентов

модействия конкретные значения в виде параметров. Это обеспечивает

огромные возможности и гибкость!

На рис. 13.7 можно увидеть, что два варианта употребления взаимо

действий возвращают значения, присваиваемые временным перемен

ным theStudent (студент) и theCourse (курс). Эти временные переменные

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

13.2.2. Шлюзы

Шлюзы (gates) – это входы и выходы взаимодействий.

Шлюзы – это входы и выходы взаимодействий.

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

вать линией жизни, которая не является частью взаимодействия. Вос

пользуемся операциями FindStudent и FindCourse на рис. 13.6, чтобы про

иллюстрировать применение шлюзов (рис. 13.8).

Как видно из рисунка, шлюз – это точка на рамке диаграммы последо

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

общением внутри рамки. Сигнатуры обоих сообщений должны быть

одинаковыми.

Рисунок 13.7 можно изменить, применив эти новые диаграммы после

довательностей со шлюзами, как показано на рис. 13.9.

Теперь у FindStudent и FindCourse есть явные входы и выходы. Эти взаи

модействия даже стали еще более гибкими, чем раньше. Рассмотрим

рис. 13.10, на котором показан другой возможный вариант примене

ния взаимодействия FindCourse.

шлюзы

:RegistrationManager

findCourse( name )

sd FindCourse

:RegistrationManager

findStudent( name )

sd FindStudent

Рис. 13.8. Шлюзы

13.2. Включения взаимодействий 305

И шлюзы, и параметры обеспечивают гибкость в многократном ис

пользовании взаимодействий. Возникает вопрос: когда должны при

меняться шлюзы, а когда – параметры?

• Параметры используются, когда известны исходные и целевые ли

нии жизни всех сообщений взаимодействия.

• Шлюзы используются, когда некоторые сообщения приходят изза

границ рамки взаимодействия и заранее неизвестно, откуда они мо

гут поступить.

:RegistrationManager

sd RegisterJimForUMLCourse

:Registrar

theCourse:Course

theStudent = findStudent( "Jim" )

theCourse = findCourse( "UML" )

шлюз

ref

FindStudent

ref

FindCourse

Рис. 13.9. Диаграммы последовательностей с шлюзами

:RegistrationManager

theStudents = getStudents()

sd GetStudentsOnUMLCourse

:Registrar

uml:Course

getRegisteredStudents( "UML" )

uml = findCourse( "UML" )

ref

FindCourse

Рис. 13.10. Вариант применения взаимодействия FindCourse

306 Глава 13. Дополнительные аспекты реализации прецедентов

13.3. Продолжения

Продолжения (continuations) позволяют фрагменту взаимодействия

показать, что его поток завершается таким образом, что он может быть

подхвачен и продолжен другим фрагментом взаимодействия. Продол

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

ленными углами.

Продолжения обеспечивают возможность завершать фрагмент взаимо

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

Когда продолжение является последним элементом фрагмента взаи

модействия, оно обозначает точку, в которой этот фрагмент заверша

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

Если продолжение является первым элементом фрагмента взаимодей

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

предыдущего фрагмента.

Продолжения обеспечивают способ соединения разных взаимодейст

вий. По сути, одно взаимодействие завершается, оставляя свои линии

жизни в определенном состоянии, а другие взаимодействия могут при

соединиться в этой точке и продолжить работу.

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

ния, которые обсуждались в разделе 12.9.4. Однако продолжение – это

лишь способ соединения разных взаимодействий в помеченных точ

ках. Оно не обязательно отображается в конкретное состояние автома

та контекстного классификатора.

На рис. 13.11 показана простая диаграмма последовательностей, на ко

торой :RegistationUI (UI – пользовательский интерфейс) вызывает актера

:Registrar сначала для получения имени курса, а затем для осуществле

ния одной из трех операций: добавить, удалить или найти. В зависимо

сти от того, какой вариант выбран, взаимодействие заканчивается од

ним из трех продолжений: addCourse, removeCourse или findCourse.

На рис. 13.12 можно увидеть взаимодействие HandleCourseOption (произ

вести действие над курсом), которое включает GetCourseOption (получить

вариант действия над курсом) и затем выбирает одно из его продолже

ний. Как видите, продолжения позволяют:

• разъединить взаимодействия GetCourseOption и HandleCourseOption;

• потенциально повторно использовать GetCourseOption и HandleCourse

Option с другими взаимодействиями, имеющими аналогичные про

должения.

При использовании продолжений необходимо помнить следующее:

• Продолжения начинают и заканчивают взаимодействия, следова

тельно, они должны быть или первым, или последним элементом

взаимодействия.

13.3. Продолжения 307

• В контексте данного классификатора продолжения под одним име

нем должны охватывать один набор линий жизни.

• Продолжения имеют смысл, только если во взаимодействии при

сутствует хотя бы слабое упорядочение – очевидно, что если нет

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

• Продолжения должны охватывать все линии жизни включающего

их фрагмента (т. е. они являются глобальными в рамках этого фраг

мента).

:Registrar

:RegistrationUI

option = получить опцию

alt

sd GetCourseOption

[option == add]

[option == remove]

[option == find]

продолжение

addCourse

removeCourse

findCourse

name = получить имя курса

Рис. 13.11. Диаграмма последовательностей с тремя продолжениями

sd HandleCourseOption

:Registrar

:RegistrationUI :RegistrationManager

alt

продолжение

ref

GetCourseOption

addCourse

removeCourse

findCourse

addCourse( name )

removeCourse( name )

findCourse( name )

Рис. 13.12. Взаимодействие HandleCourseOption включает GetCourseOption

и затем выбирает одно из его продолжений

308 Глава 13. Дополнительные аспекты реализации прецедентов

Продолжения часто используются с оператором alt, как показано на

рис. 13.12, для создания точек ветвления во взаимодействии.

13.4. Что мы узнали

В этой главе были рассмотрены дополнительные возможности диа

грамм взаимодействия.

Мы изучили следующее:

• Включения взаимодействий – это ссылки на другое взаимодействие.

• Поток используемого взаимодействия включается в поток ис

пользующего его взаимодействия.

• Параметры – включения взаимодействия могут иметь парамет

ры; используется обычная нотация параметров.

• Шлюзы – входы и выходы взаимодействий:

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

щая сообщение, находящееся вне рамки, с сообщением, нахо

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

быть одинаковыми.

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

всех сообщений; в противном случае используются шлюзы.

• Продолжения – завершают фрагмент взаимодействия таким обра

зом, чтобы его мог продолжить другой фрагмент:

• если продолжение – первый элемент фрагмента, то фрагмент

продолжает другой фрагмент;

• если продолжение – последний элемент фрагмента, то фрагмент

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

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

14.1. План главы

Диаграммы деятельности – это «ОО блоксхемы». Они позволяют мо

делировать процесс как деятельность, состоящую из коллекции соеди

ненных ребрами узлов. UML 2 вводит новую семантику диаграмм дея

тельности, которая обеспечивает им намного большую мощь и гиб

кость, чем ранее. В этой главе рассматриваются основы диаграмм дея

тельности в объеме, достаточном для моделирования деятельности.

Более глубокие вопросы рассматриваются в следующей главе.

14.2. Что такое диаграммы деятельности

Диаграммы деятельности часто называют «ОО блоксхемами». Они

позволяют моделировать процесс как деятельность, которая состоит

из коллекции соединенных ребрами узлов.

В UML 1 диаграммы деятельности фактически были лишь особым слу

чаем диаграмм состояний (глава 21), где у каждого состояния было

входное действие, которое определяло некоторый процесс или функ

цию, имеющие место при входе в состояние. В UML 2 диаграммы дея

тельности имеют совершенно новую семантику, базирующуюся на

технологии сетей Петри (Petri Nets). В использовании этой техноло

гии есть два преимущества:

1. Формализм сети Петри обеспечивает большую гибкость при моде

лировании различных типов потока.

2. В UML теперь есть четкое разделение между диаграммами деятель

ности и диаграммами состояний.

Диаграммы деятельности – это ОО блоксхемы.

310 Глава 14. Диаграммы деятельности

14.10. Контакты

14.2. Что такое диаграммы деятельности

14.4. Деятельности

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

14.5. Семантика деятельности

14.6. Разделы деятельности

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

14.7. Узлы действия

14.7.1. Узел вызова действия

14.7.2. Узел действия, принимающий событие времени

14.8. Узлы управления

14.8.1. Начальный и конечные узлы

14.8.2. Узлы решения и слияния

14.8.3. Узлы ветвления и объединения – параллелизм

14.11. Что мы узнали

14.9. Объектные узлы

14.9.1. Семантика буфера объектного узла

14.9.2. Представление объектов в состоянии

14.9.3. Параметры деятельности

Рис. 14.1. План главы

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

Деятельность может быть добавлена к любому элементу модели с целью

моделирования его поведения. Элемент обеспечивает контекст для дея

тельности, и деятельность может использовать возможности своего кон

текста. Деятельности обычно добавляются к:

• прецедентам;

• классам;

• интерфейсам;

• компонентам;

• кооперациям;

• операциям.

Диаграммы деятельности также могут использоваться для моделиро

вания бизнеспроцессов и рабочих потоков. Мы кратко покажем, как

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

Хотя диаграммы деятельности обычно используются как блоксхемы

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

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

ставлением! Так что о каждом случае необходимо судить отдельно.

Хорошая диаграмма деятельности сосредоточена на отражении лишь

одного определенного аспекта динамического поведения системы. Та

ким образом, она должна находиться на соответствующем уровне абст

ракции, чтобы донести эту идею до целевой аудитории, и содержать

минимум необходимой информации. Диаграммы деятельности можно

дополнять состояниями и потоками объектов, но необходимо постоян

но спрашивать себя, проясняют ли эти элементы диаграмму или дела

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

симальной простоты.

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

Диаграммы деятельности могут использоваться во многих рабочих по

токах UP.

Благодаря своей гибкости диаграммы деятельности не имеют одного

определенного назначения в UP. Они обеспечивают универсальный

механизм моделирования поведения и могут использоваться везде, где

возникает необходимость в их применении. Мы обсуждаем их в рабо

чем потоке анализа, потому что чаще всего эти диаграммы использу

ются при анализе.

Уникальная способность диаграмм деятельности в том, что они позво

ляют моделировать процесс без необходимости определения статиче

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

но, это очень полезно на ранних этапах анализа при попытках выяс

нить, что представляет собой конкретный процесс.

312 Глава 14. Диаграммы деятельности

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

чаще всего используются в следующих случаях.

• В процессе анализа:

• для графического моделирования потока прецедента. Такое пред

ставление является более понятным для заинтересованных сто

рон;

• для моделирования потока между прецедентами. При этом ис

пользуется особая форма диаграммы деятельности – диаграмма

обзора взаимодействий (раздел 15.12).

• При проектировании:

• для моделирования деталей операции;

• для моделирования деталей алгоритма.

• При моделировании деловой активности:

• для моделирования бизнеспроцесса.

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

скольку большинство из них имеет представление о блоксхемах в той

или иной форме. Следовательно, диаграммы деятельности могут быть

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

Как будет видно в этой и следующей главах, UML 2 представляет мно

го мощных нововведений в синтаксисе и семантике диаграмм деятель

ности. Важно не слишком сильно увлекаться всем этим. При создании

любой UMLдиаграммы всегда нужно помнить о целевой аудитории

и использовать возможности UML соответственно. Нет смысла приме

нять все самые последние нововведения, если никто не поймет диа

грамму.

14.4. Деятельности

Деятельности – это системы узлов (nodes), соединенных ребрами (edges).

Существует три категории узлов:

1. Узлы действия (action nodes) – представляют отдельные единицы

работы, элементарные в рамках деятельности;

2. Узлы управления (control nodes) – управляют потоком деятельности;

3. Объектные узлы (object nodes) – представляют объекты, используе

мые в деятельности.

Ребра представляют потоки деятельности. Существует два типа ребер:

1. Ребра потоков управления (control flows) – представляют поток

управления деятельности;

Деятельности – это системы узлов, соединенных ребрами.

14.4. Деятельности 313

2. Ребра потоков объектов (object flows) – представляют поток объек

тов деятельности.

Все типы узлов и ребер будут подробно изучены в последующих раз

делах.

Давайте рассмотрим пример. На рис. 14.2 показана простая диаграм

ма деятельности бизнеспроцесса Послать письмо. Обратите внимание,

что деятельности могут иметь предусловия и постусловия, как и пре

цеденты. Предусловия – это условия, которые должны быть истинны

ми, чтобы деятельность могла начаться, а постусловия – это условия,

которые будут истинными по завершении деятельности. Действия

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

условия и постусловия, как показано на рис. 14.2.

Деятельности обычно начинаются с одного узла управления, началь

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

Один или более конечных узлов показывают места завершения дея

тельности.

В примере, изображенном на рис. 14.2, деятельность начинается в на

чальном узле. Затем управление переходит вдоль ребра к узлу дейст

вия Написать письмо. Этот узел обозначает элементарную часть работы

или поведения, поскольку содержит описываемую деятельность. По

ток проходит через узлы Адресовать письмо, Отправить письмо и затем

к конечному узлу, в котором деятельность завершается.

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

прецедента в виде последовательностей действий. На рис. 14.3 пока

зан прецедент PaySalesTax (выплата налога с оборота) из главы 4. Этот

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

как показано на рис. 14.4.

Адресовать письмо

Отправить письмо

Написать письмо

узел действия

Послать письмо

предусловие: найти тему письма

постусловие: письмо отправлено по адресу

поток управления

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

начальный узел

конечный узел

ребро

«localPrecondition»

адрес известен

«localPrecondition»

письмо адресовано

Рис. 14.2. Диаграмма деятельности бизнес+процесса Послать письмо