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

Однако если бы былзадан режим stream, объекты Student предлагались бы на выходном узле расширения сразу после обработки.15.6. Отправка сигналов и прием событийСигнал представляет асинхронно передаваемую между объектами информацию. Сигнал моделируется как класс, отмеченный стереотипом«signal» (сигнал). Передаваемая информация хранится в атрибутах сигнала. При анализе сигналы могут использоваться для отображения отправки и получения асинхронных бизнессобытий (таких как OrderReceived (заказ получен)), а при проектировании они могут иллюстрировать асинхронный обмен информацией между разными системами,подсистемами или частями оборудования.Сигналы представляют асинхронно передаваемую между объектами информацию.На рис. 15.7 показаны два сигнала, которые используются в деятельности, представленной на рис.

15.8.Оба этих сигнала имеют тип SecurityEvent (событие системы безопасности). Сигнал AuthorizationRequestEvent (событие запроса авторизации) передает PIN и информацию карты, вероятно, в зашифрованном виде.В сигнале AuthorizationEvent (событие авторизации) хранится логический флаг, указывающий, были ли авторизованы карта и PIN.Узел действия, отправляющий сигнал, представляет отправку сигнала.Сигнал можно послать с помощью узла действия, отвечающего за отправку сигнала. Он посылает сигнал асинхронно – деятельность, от«signal»SecurityEvent«signal»AuthorizationRequestEventpin : PINcardDetails : CardDetails«signal»AuthorizationEventisAuthorized : BooleanРис. 15.7. Два сигнала, используемые в деятельности Проверить кредитную карту344Глава 15.

Дополнительные аспекты диаграмм деятельностиПроверить кредитную картуCardDetailsВвести PINPINAuthorizationRequestEventузел действия,отправляющий сигналAuthorizationEventузел действия,принимающий событие[AuthorizationEvent.isAuthorized]Авторизован[!AuthorizationEvent.isAuthorized]Не авторизованРис. 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 моделируется деятельность Показать новости, имеющая двапринимающих события действия, которые инициируются автоматически при запуске деятельности. Когда действие приема события 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). Аналогично можетпонадобиться представить получение объектов от нескольких отправителей.