Арлоу Д., Нейштадт А. UML2 и Унифицированный процесс. Практический объектно-ориентированный анализ и проектирование
Подождите немного. Документ загружается.
344 Глава 15. Дополнительные аспекты диаграмм деятельности
правляющая сигнал, не ожидает подтверждения получения сигнала.
Посылающая сигнал деятельность имеет следующую семантику:
• Посылающая сигнал деятельность инициируется тогда, когда мар
кер одновременно присутствует на всех ее входных ребрах. Если
у сигнала имеются входные контакты, он должен получить входной
объект соответствующего типа для каждого из своих атрибутов.
• При выполнении действия создается и посылается объект сигнала.
Целевой объект обычно не указывается, но в случае необходимости
его можно передать на входной контакт действия, отправляющего
сигнал.
• Действие отправки не ожидает подтверждения принятия сигнала –
оно асинхронно.
• Действие завершается, и маркеры управления предлагаются на его
выходных ребрах.
Узел действия, принимающий событие, ожидает получения события со
ответствующего типа.
Узел действия, принимающий событие, не имеет ни одного или имеет
одно входное ребро. Он ожидает асинхронных событий, выявленных
Authorization
Event
Authorization
RequestEvent
Ввести PIN
Не авторизованАвторизован
CardDetails
[AuthorizationEvent.isAuthorized] [!AuthorizationEvent.isAuthorized]
Проверить кредитную карту
узел действия,
отправляющий сигнал
узел действия,
принимающий событие
PIN
Рис. 15.8. Деятельность Проверить кредитную карту
15.6. Отправка сигналов и прием событий 345
его контекстомвладельцем, и предлагает их на своем единственном
выходном ребре. Семантика его следующая.
• Действие приема события запускается входящим ребром управле
ния; если входящих ребер нет, оно запускается при вызове деятель
ностивладельца.
• Действие ожидает получения события определенного типа. Это со
бытие называют триггером (trigger).
• Когда действие получает триггер события соответствующего типа,
оно выдает маркер, описывающий событие. Если событие было сиг
налом, маркер является сигналом.
• Действие продолжает принимать события до тех пор, пока выпол
няется деятельность.
На рис. 15.8 показана деятельность Проверить кредитную карту, отправ
ляющая события AuthorizationRequestEvents и принимающая события
AuthorizationEvents.
Ниже приведен поэтапный анализ деятельности Проверить кредитную
карту.
1. Деятельность Проверить кредитную карту начинается, когда получает
входной параметр CardDetails. Затем она предлагает пользователю
ввести PINкод.
2. Действие AuthorizationRequestEvent начинает выполняться, как толь
ко на его входные ребра поступают объекты PIN и CardDetails (инфор
мация карты). Используя эти входные параметры, оно создает сиг
нал AuthorizationRequestEvent и посылает его. Действия отправки сиг
налов изображаются в виде выпуклых пятиугольников, как пока
зано на рисунке.
3. Сигналы отправляются асинхронно, и поток управления незамед
лительно переходит к действию приема события AuthorizationEvent,
которое изображено в виде вогнутого пятиугольника. Это действие
ожидает получения сигнала AuthorizationEvent.
4. Получив этот сигнал, поток переходит в узел принятия решения.
Если AuthorizationEvent.isAuthorized истинно, вызывается действие Ав
торизован, в противном случае выполняется действие Не авторизован.
Рассмотрим другой пример действий, принимающих события. На
рис. 15.9 моделируется деятельность Показать новости, имеющая два
принимающих события действия, которые инициируются автомати
чески при запуске деятельности. Когда действие приема события News
Event получает событие NewsEvent (событие новостей), оно передается
действию Отобразить новости. После этого поток управления переходит
в конечный узел потока, и этот конкретный поток завершается. Одна
ко выполнение деятельности продолжается, и оба действия приема со
бытий продолжают ожидать события. Когда деятельность получает со
бытие TerminateEvent (событие завершения), управление переходит в ко
346 Глава 15. Дополнительные аспекты диаграмм деятельности
нечный узел деятельности, и вся деятельность, включая оба действия
приема событий, немедленно завершается.
Если необходимо показать движение сигналов по диаграмме деятель
ности, их можно представить как объектные узлы. Хотя семантика
сигналов аналогична семантике остальных объектных узлов, они име
ют особый синтаксис (рис. 15.10). Их символ является сочетанием
пиктограмм действия отправки сигнала и действия приема события,
так что запомнить их легко.
15.7. Потоковая передача
Обычно действия принимают маркеры со своих входных ребер только
тогда, когда начинают выполнение, и предлагают их на своих выход
ных ребрах по завершении выполнения. Однако иногда требуется,
чтобы действие выполнялось непрерывно, периодически принимая
и предлагая маркеры. Такое поведение называют потоковой переда
чей. В UML 2 оно может быть проиллюстрировано любым из четырех
способов, как показано на рис. 15.11.
Потоковая передача – действие выполняется непрерывно, принимая
и предлагая маркеры.
NewsEvent
Отобразить новости
Показать новости
TerminateEvent
Рис. 15.9. Деятельность Показать новости
OrderEvent
объектный
узел сигнала
Рис. 15.10. Синтаксис сигналов
15.8. Дополнительные возможности потоков объектов 347
По нашему мнению, четыре способа – это слишком много для пред
ставления потоковой передачи. Рекомендуется по возможности вы
брать и придерживаться только одного из них. Первый вариант явля
ется самым лаконичным – контакты закрашиваются черным; именно
его мы и советуем использовать.
Пример на рис. 15.11 иллюстрирует обычное применение потоковой
передачи. Действие Опросить порт мыши непрерывно считывает данные
с порта мыши и предлагает информацию о ее деятельности в виде по
тока событий MouseEvent (событие мыши), передаваемого на единствен
ное выходное ребро. Эти события принимаются действием Обработать
MouseEvent.
Любая ситуация, в которой необходимо непрерывно получать и обра
батывать информацию, является кандидатом на использование пото
ковой передачи.
15.8. Дополнительные возможности
потоков объектов
В этом разделе будут рассмотрены некоторые дополнительные воз
можности потоков объектов. Вероятно, они будут использоваться не
слишком часто, но их полезно знать!
Эти возможности представлены на рис. 15.12.
потоковая передача
по обычным контактам
потоковая передача
по объектным узлам
(автономные контакты)
Опросить
порт мыши
обозначает потоковую передачу
Опросить
порт мыши
Опросить
порт мыши
обозначает потоковую передачу
Опросить
порт мыши
MouseEvent
Обработать
MouseEvent
Обработать
MouseEvent
Обработать
MouseEvent
Обработать
MouseEvent
MouseEvent
MouseEvent
MouseEvent
{stream}
{stream}
вариант 1
вариант 2
вариант 3
вариант 4
Рис. 15.11. Четыре способа отображения потоковой передачи
348 Глава 15. Дополнительные аспекты диаграмм деятельности
15.8.1. Входные и выходные эффекты
Входные и выходные эффекты показывают влияние, оказываемое дей
ствием на его входящие и выходящие объекты. Эти эффекты обознача
ются коротким описанием в скобках, которое располагают как можно
ближе к входящему или исходящему контакту.
Входные и выходные эффекты показывают влияние, оказываемое дей
ствием на его входящие и выходящие объекты.
На рис. 15.12 рядом с действием Послать Receipt (квитанцию) можно
увидеть пример входного эффекта. Он показывает, что действие Послать
Receipt присваивает timestamp (временную метку) каждой получаемой
им квитанции (объект Receipt). У действия Принять Payment (платеж) есть
выходной эффект {create} (создать). Это означает, что Принять Payment
создает все выдаваемые им объекты Transaction (транзакция).
15.8.2. Стереотип «selection»
Выбор – это условие, накладываемое на поток объектов, согласно кото
рому он принимает только те объекты, которые удовлетворяют этому ус
ловию.
Выбор (selection) – это условие, прикрепленное к потоку объектов, со
гласно которому он принимает только те объекты, которые удовлетво
Принять Payment
Order
[Оплачен]
Receipt
{timestamp}
Послать Reminder
входной эффект
Записать Transaction
«transformation»
Order.toReceipt() : Receipt
«selection»
(сейчас – Order.date) > 28 дней
Послать Receipt
выходной эффект
Order
[!Оплачен]
Transaction
{create}
Рис. 15.12. Дополнительные возможности потоков объектов
15.9. Групповая рассылка и групповой прием 349
ряют условию. Условие выбора отображается в узле со стереотипом
«selection».
На рис. 15.12 можно увидеть выбор, прикрепленный к потоку объек
тов между действиями Принять Payment и Послать Reminder (напомина
ние). Условие выбора: (сейчас – Order.date) > 28 дней. Выходной контакт
действия Принять Payment предлагает объекты Order в состоянии !Оплаче
но, а выбор принимает только те объекты Order, которые ожидают опла
ты более 28 дней. В результате этот поток выбирает все объекты Order,
остающиеся неоплаченными дольше 28 дней, и передает их действию
Послать Reminder.
15.8.3. Стереотип «transformation»
Преобразование меняет типы объектов в потоке объектов. Выражение
преобразования представлено в узле, отмеченном стереотипом «trans
formation» (преобразование).
На рис. 15.12 преобразование можно увидеть на потоке объектов между
действиями Принять Payment и Послать Receipt. Оно определяет, что объек
ты Order, выдаваемые действием Принять Payment, будут преобразованы
вобъекты Receipt, ожидаемые действием Послать Receipt. В этом примере
преобразование осуществляется путем вызова операции toReceipt() для
каждого объекта Order при его прохождении по ребру. Данная операция
принимает информацию объекта Order и создает объект Receipt.
Преобразование меняет типы объектов в потоке объектов.
Преобразования используются, когда необходимо соединить выход
ной контакт экземпляров одного классификатора с входным контак
том, ожидающим экземпляры другого классификатора.
15.9. Групповая рассылка и групповой прием
При групповой рассылке объекты рассылаются многим получателям.
Обычно объект имеет только одного получателя. Однако иногда необ
ходимо показать, что объект посылается нескольким получателям.
Это называется групповой рассылкой (multicast). Аналогично может
понадобиться представить получение объектов от нескольких отпра
вителей. Это называется групповым приемом (multireceive). Группо
вые рассылка и прием часто присутствуют в симметричных парах, как
показано на рис. 15.13.
При групповом приеме осуществляется прием объектов от многих от
правителей.
350 Глава 15. Дополнительные аспекты диаграмм деятельности
Чтобы показать, что поток объектов возникает из групповой рассылки
или является результатом группового приема, его обозначают стереоти
пом «multicast» и «multireceive» соответственно. На рис. 15.13 представ
лен простой бизнеспроцесс, аналогичный тому, который используется
OMG для сбора предложений по поводу стандартов. Сначала Техническая
группа устанавливает потребность в решении и формулирует ее в виде
RFP (Request For Proposal – запрос на предложение). Оно рассылается
многим Членам команды, которые вырабатывают потенциальные пред
ложения (объекты Proposal). Через групповой прием Техническая группа
получает эти предложения, оценивает их и выдает Принятые Proposal.
15.10. Наборы параметров
Наборы параметров обеспечивают действию альтернативные наборы
входных и выходных контактов.
Наборы параметров обеспечивают действию альтернативные наборы
(alternative sets) входных и выходных контактов. Эти наборы контак
тов называют наборами параметров (parameter sets). Наборы входных
параметров содержат входные контакты, а наборы выходных парамет
ров содержат выходные контакты. Смешанный набор входных и вы
ходных параметров невозможен.
Чтобы проиллюстрировать, зачем могут понадобиться наборы пара
метров, рассмотрим рис. 15.14, на котором представлены три типа ау
тентификации.
1. Получить UserName и Password – выдает объекты UserName и Password.
Определить
потребность
Техническая группа
Сделать запрос
на Proposal
RFP
Член
Создать Proposal
Proposal
[Потенциальное]
Оценить
объекты Proposal
Proposal
[Принятое]
Обработать запросы на Proposal
«multicast»
«multireceive»
Рис. 15.13. Групповая рассылка и групповой прием
15.10. Наборы параметров 351
2. Получить UserName и Passphrase – выдает объекты UserName и Passphrase
(идентификационная фраза).
3. Получить Card и PIN – выдает объекты Card и PIN.
Как видите, каждое из этих действий выдает разный набор объектов.
Одним из решений этой проблемы могло бы быть разделение аутентифи
кации на три действия для каждого набора объектов, например Authenti
cateUserNameAndPassword, AuthenticateUserNameAndPassphrase и Authenticate
CardAndPIN. Это разумное решение, но оно имеет несколько недостатков.
• Оно делает диаграмму деятельности слишком большой.
• Аутентификация распределена на три действия, а не локализована
в одном.
Применяя наборы параметров, можно создать единственное действие
Аутентифицировать, способное обрабатывать разные наборы входных па
раметров.
На рис. 15.14 представлено действие Аутентифицировать с тремя набора
ми входных и двумя наборами выходных параметров. Наборы вход
ных параметров:
• UserName AND Password;
• UserName AND Passphrase;
• Card AND PIN.
При каждом выполнении этого действия может использоваться толь
ко один из этих наборов входных параметров. Поэтому между ними
установлено отношение исключающее ИЛИ (XOR).
Обратите внимание, что в наборах {UserName, Password} и {UserName, Pass
phrase} есть общий контакт UserName. Как показано на рис. 15.14, это
можно обозначить путем наложения двух наборов параметров таким об
разом, чтобы общие контакты находились в области пересечения. Од
Аутентифицировать
UserName
Password
Passphrase
PIN
Card
User
[!Аутентифицирован]
Получить
UserName
и Passphrase
Получить
UserName
и Password
Получить
Card и PIN
Выбрать
метод
аутентификации
[password]
[passphrase]
[card]
User
Аутентифицировать User
входное условие: ( UserName AND Password ) XOR ( UserName AND Passphrase ) XOR ( Card AND PIN )
выходное условие: ( User [Аутентифицирован] ) XOR ( User [!Аутентифицирован] )
набор параметров
User
[Аутентифицирован]
Рис. 15.14. Использование наборов параметров
352 Глава 15. Дополнительные аспекты диаграмм деятельности
нако в этом случае очень легко запутаться, поэтому можно использо
вать два отдельных контакта UserName, по одному для каждого набора
входных параметров. Мы предпочитаем второй вариант решения. На
приведенной диаграмме (рис. 15.14) проиллюстрирован синтаксис на
ложения контактов на тот случай, если вы решите их использовать.
Действие Аутентифицировать имеет следующие наборы выходных пара
метров, каждый из которых содержит всего один контакт:
• User[Аутентифицирован];
• User[!Аутентифицирован].
Опять же при каждом выполнении деятельности будет использоваться
только один из этих наборов выходных параметров.
15.11. Узел «centralBuffer»
Центральный буфер – это объектный узел, используемый исключитель
но в качестве буфера.
Как упоминалось в разделе 14.9.1, все объектные узлы обладают спо
собностью буферизации.
Центральный буфер – это объектный узел, используемый исключи+
тельно как буфер между входными и выходными потоками объектов.
Он позволяет объединять несколько входных потоков объектов и рас
пределять объекты между несколькими выходными потоками объек
тов. Когда объектный узел используется как центральный буфер, он
должен быть обозначен стереотипом «centralBuffer».
На рис. 15.15 показан простой пример, в котором центральный буфер
используется для накопления различных типов объектов Order, непре
рывно поступающих по нескольким каналам продаж. Объекты Order
находятся в буфере в ожидании принимающего их действия Обработать
Order. В центральном буфере Order могут сохраняться объекты типа Order
или его подклассов: WebOrder (вебзаказ), PhoneOrder (заказ по телефону)
и PostOrder (заказ по почте).
Принять веб!Order
Принять Order по телефону
Принять Order по почте
«centralBuffer»
Order
[Новый]
WebOrder
[Новый]
PhoneOrder
[Новый]
PostOrder
[Новый]
Обработать объекты Order
Order
[Обработанный]
Обработать Order
Рис. 15.15. Центральный буфер для хранения объектов
15.12. Диаграммы обзора взаимодействий 353
15.12. Диаграммы обзора взаимодействий
Диаграммы обзора взаимодействий – особая форма диаграммы деятель
ности. Они показывают взаимодействия и включения взаимодействий
(interaction occurrences) и используются для моделирования высоко
уровневого потока управления между взаимодействиями. Взаимодей
ствия и диаграммы взаимодействий подробно обсуждаются в главе 12.
Одно особенно мощное применение диаграмм обзора взаимодействий –
иллюстрация потока управления между прецедентами. Если каждый
прецедент представить как взаимодействие, синтаксис диаграммы дея
тельности можно использовать для отображения движения потока
управления между ними.
Диаграммы обзора взаимодействий – это диаграммы деятельности, пред
ставляющие взаимодействия и включения взаимодействий.
На рис. 15.16 представлена диаграмма обзора взаимодействий Manage
Courses (организация курсов), которая показывает поток между низко
уровневыми взаимодействиями LogOn (войти), GetCourseOption (полу
чить варианты курсов), FindCourse (найти курс), RemoveCourse (удалить
курс) и AddCourse (добавить курс). Каждое из этих взаимодействий
представляет прецедент. Таким образом, диаграмма обзора взаимо
действий фиксирует поток управления между прецедентами.
Обратите внимание, что линии жизни, принимающие участие во взаи
модействии, могут быть перечислены после ключевого слова lifelines
(линии жизни) в заголовке диаграммы. Такое документирование мо
жет быть полезным, поскольку часто линии жизни скрыты внутри
включений взаимодействий.
Синтаксис диаграмм обзора взаимодействий аналогичен синтаксису
диаграмм деятельности, за исключением того, что здесь отображаются
встроенные взаимодействия и включения взаимодействий, а не дея
тельности и объектные узлы. Можно показать ветвление, параллель
ность и цикличность, как описано в табл. 15.1. Данная таблица также
предоставляет обзор различий между синтаксисом диаграммы после
довательностей и диаграммы обзора взаимодействий.
Таблица 15.1
Действие Диаграммы
последовательностей
Диаграмма
обзора взаимодействий
Ветвление Комбинированные фрагмен
ты alt и opt (раздел 12.10.1)
Узлы принятия решения и слия
ния (раздел 14.8.2)
Параллель
ность
Комбинированный фраг
мент par (раздел 20.5)
Узлы ветвления и объединения
(раздел 14.8.3)
Итерация Комбинированный фраг
мент loop (раздел 12.11.1)
Циклы на диаграмме