Джим Арлоу, Айла Нейштадт - UML 2 и Унифицированный процесс. Практический объектно-ориентированный анализ и проектирование (1037782), страница 64
Текст из файла (страница 64)
Это событие называют триггером (trigger).•Когда действие получает триггер события соответствующего типа,оно выдает маркер, описывающий событие. Если событие было сигналом, маркер является сигналом.•Действие продолжает принимать события до тех пор, пока выполняется деятельность.На рис. 15.8 показана деятельность Проверить кредитную карту, отправляющая события AuthorizationRequestEvents и принимающая событияAuthorizationEvents.Ниже приведен поэтапный анализ деятельности Проверить кредитнуюкарту.1.
Деятельность Проверить кредитную карту начинается, когда получаетвходной параметр CardDetails. Затем она предлагает пользователюввести PINкод.2. Действие AuthorizationRequestEvent начинает выполняться, как только на его входные ребра поступают объекты PIN и CardDetails (информация карты). Используя эти входные параметры, оно создает сигнал AuthorizationRequestEvent и посылает его. Действия отправки сигналов изображаются в виде выпуклых пятиугольников, как показано на рисунке.3. Сигналы отправляются асинхронно, и поток управления незамедлительно переходит к действию приема события AuthorizationEvent,которое изображено в виде вогнутого пятиугольника.
Это действиеожидает получения сигнала AuthorizationEvent.4. Получив этот сигнал, поток переходит в узел принятия решения.Если AuthorizationEvent.isAuthorized истинно, вызывается действие Авторизован, в противном случае выполняется действие Не авторизован.Рассмотрим другой пример действий, принимающих события. Нарис. 15.9 моделируется деятельность Показать новости, имеющая двапринимающих события действия, которые инициируются автоматически при запуске деятельности. Когда действие приема события NewsEvent получает событие NewsEvent (событие новостей), оно передаетсядействию Отобразить новости.
После этого поток управления переходитв конечный узел потока, и этот конкретный поток завершается. Однако выполнение деятельности продолжается, и оба действия приема событий продолжают ожидать события. Когда деятельность получает событие TerminateEvent (событие завершения), управление переходит в ко346Глава 15. Дополнительные аспекты диаграмм деятельностиПоказать новостиT erminateEventNewsEventОтобразить новостиРис. 15.9. Деятельность Показать новостинечный узел деятельности, и вся деятельность, включая оба действияприема событий, немедленно завершается.Если необходимо показать движение сигналов по диаграмме деятельности, их можно представить как объектные узлы.
Хотя семантикасигналов аналогична семантике остальных объектных узлов, они имеют особый синтаксис (рис. 15.10). Их символ является сочетаниемпиктограмм действия отправки сигнала и действия приема события,так что запомнить их легко.объектныйузел сигналаOrderEventРис. 15.10. Синтаксис сигналов15.7. Потоковая передачаОбычно действия принимают маркеры со своих входных ребер толькотогда, когда начинают выполнение, и предлагают их на своих выходных ребрах по завершении выполнения. Однако иногда требуется,чтобы действие выполнялось непрерывно, периодически принимаяи предлагая маркеры.
Такое поведение называют потоковой передачей. В UML 2 оно может быть проиллюстрировано любым из четырехспособов, как показано на рис. 15.11.Потоковая передача – действие выполняется непрерывно, принимаяи предлагая маркеры.15.8. Дополнительные возможности потоков объектоввариант 1Опроситьпорт мышиMouseEventОбработатьMouseEventобозначает потоковую передачувариант 2Опроситьпорт мышиMouseEvent347потоковая передачапо обычным контактамОбработатьMouseEvent{stream}вариант 3Опроситьпорт мышиMouseEventОбработатьMouseEventпотоковая передачапо объектным узлам(автономные контакты)обозначает потоковую передачувариант 4Опроситьпорт мышиMouseEvent{stream}ОбработатьMouseEventРис. 15.11. Четыре способа отображения потоковой передачиПо нашему мнению, четыре способа – это слишком много для представления потоковой передачи.
Рекомендуется по возможности выбрать и придерживаться только одного из них. Первый вариант является самым лаконичным – контакты закрашиваются черным; именноего мы и советуем использовать.Пример на рис. 15.11 иллюстрирует обычное применение потоковойпередачи. Действие Опросить порт мыши непрерывно считывает данныес порта мыши и предлагает информацию о ее деятельности в виде потока событий MouseEvent (событие мыши), передаваемого на единственное выходное ребро.
Эти события принимаются действием ОбработатьMouseEvent.Любая ситуация, в которой необходимо непрерывно получать и обрабатывать информацию, является кандидатом на использование потоковой передачи.15.8. Дополнительные возможностипотоков объектовВ этом разделе будут рассмотрены некоторые дополнительные возможности потоков объектов. Вероятно, они будут использоваться неслишком часто, но их полезно знать!Эти возможности представлены на рис. 15.12.348Глава 15. Дополнительные аспекты диаграмм деятельностиПослать Receiptвходной эффектReceipt{timestamp}«transformation»Order.toReceipt() : ReceiptOrder[Оплачен]Принять PaymentЗаписать Transactionвыходной эффектTransaction{create}Order[!Оплачен]«selection»(сейчас – Order.date) > 28 днейПослать ReminderРис. 15.12.
Дополнительные возможности потоков объектов15.8.1. Входные и выходные эффектыВходные и выходные эффекты показывают влияние, оказываемое действием на его входящие и выходящие объекты. Эти эффекты обозначаются коротким описанием в скобках, которое располагают как можноближе к входящему или исходящему контакту.Входные и выходные эффекты показывают влияние, оказываемое действием на его входящие и выходящие объекты.На рис. 15.12 рядом с действием Послать Receipt (квитанцию) можноувидеть пример входного эффекта. Он показывает, что действие ПослатьReceipt присваивает timestamp (временную метку) каждой получаемойим квитанции (объект Receipt).
У действия Принять Payment (платеж) естьвыходной эффект {create} (создать). Это означает, что Принять Paymentсоздает все выдаваемые им объекты Transaction (транзакция).15.8.2. Стереотип «selection»Выбор – это условие, накладываемое на поток объектов, согласно которому он принимает только те объекты, которые удовлетворяют этому условию.Выбор (selection) – это условие, прикрепленное к потоку объектов, согласно которому он принимает только те объекты, которые удовлетво15.9. Групповая рассылка и групповой прием349ряют условию. Условие выбора отображается в узле со стереотипом«selection».На рис.
15.12 можно увидеть выбор, прикрепленный к потоку объектов между действиями Принять Payment и Послать Reminder (напоминание). Условие выбора: (сейчас – Order.date) > 28 дней. Выходной контактдействия Принять Payment предлагает объекты Order в состоянии !Оплачено, а выбор принимает только те объекты Order, которые ожидают оплаты более 28 дней. В результате этот поток выбирает все объекты Order,остающиеся неоплаченными дольше 28 дней, и передает их действиюПослать Reminder.15.8.3. Стереотип «transformation»Преобразование меняет типы объектов в потоке объектов.
Выражениепреобразования представлено в узле, отмеченном стереотипом «transformation» (преобразование).На рис. 15.12 преобразование можно увидеть на потоке объектов междудействиями Принять Payment и Послать Receipt. Оно определяет, что объекты Order, выдаваемые действием Принять Payment, будут преобразованыв объекты Receipt, ожидаемые действием Послать Receipt. В этом примерепреобразование осуществляется путем вызова операции toReceipt() длякаждого объекта Order при его прохождении по ребру.
Данная операцияпринимает информацию объекта Order и создает объект Receipt.Преобразование меняет типы объектов в потоке объектов.Преобразования используются, когда необходимо соединить выходной контакт экземпляров одного классификатора с входным контактом, ожидающим экземпляры другого классификатора.15.9. Групповая рассылка и групповой приемПри групповой рассылке объекты рассылаются многим получателям.Обычно объект имеет только одного получателя. Однако иногда необходимо показать, что объект посылается нескольким получателям.Это называется групповой рассылкой (multicast).