UML2 и унифицированный процесс. Джим арлоуайла нейштадтпрактический объектно ориентированныйанализ и проектированиеu
 Скачать 6.08 Mb.
|
|
Рис. 15.3. Деятельность Войти в систему имеет область с прерываемым выполнением действий Рис. 15.4. Вариант отображения прерывающего ребра 15.5. Узлы расширения 341 торое записывает информацию об ошибке в журнал регистрации оши бок. Для того чтобы показать, что выходной контакт представляет со бой объект исключения, его помечают небольшим равносторонним треугольником (рис. 15.5). Узел Зарегистрировать ошибку выступает в ро ли обработчика исключений, генерируемых действием Аутентифициро вать User. Если с узлом ассоциирован обработчик исключений, узел на зывают защищенным. Поскольку обработка исключений обычно является задачей проекти рования, а не анализа, защищенные узлы чаще используются при про ектировании. Однако иногда может быть полезным смоделировать за щищенный узел уже на стадии анализа, если он имеет важную бизнес семантику. 15.5. Узлы расширения Узлы расширения позволяют показать обработку коллекции объектов как часть диаграммы деятельности, называемую областью расшире ния (expansion region). Представление процесса обработки коллекции может быть довольно сложным и пространным, поэтому данная техни ка очень полезна как при анализе, так и при проектировании. Узел расширения – коллекция объектов, входящая в или выходящая из области расширения, исполняемой один раз для каждого объекта. Узел расширения – это объектный узел, который представляет коллек цию объектов, входящую в или выходящую из области расширения. Область расширения исполняется по одному разу для каждого входного элемента. На рис. 15.6 показан пример области расширения. Она пред ставлена в виде отрисованного пунктиром прямоугольника со скруг Аутентифицировать User Войти в систему Зарегистрировать ошибку LogOnException контакт исключения защищенный узел обработчик исключений Получить UserName Получить Password Отменить UserName [Допустимый] Password [Допустимый] Рис. 15.5. Деятельность Войти в систему с обработчиком исключений 342 Глава 15. Дополнительные аспекты диаграмм деятельности ленными углами и входящим и исходящим узлами расширения. Узел расширения выглядит как контакт, но с тремя квадратными ячейками. Это указывает на поступление коллекции, а не одного объекта. На узлы расширения накладываются два ограничения. • Тип выходной коллекции должен соответствовать типу входной коллекции. • Типы объектов входной и выходной коллекций должны быть оди наковыми. Эти ограничения означают, что области расширения не могут исполь зоваться для преобразования входных объектов одного типа в выход ные объекты другого типа. Количество выходных коллекций может не совпадать с количеством входных, поэтому области расширения могут использоваться для объ единения или разделения коллекций. У каждой области расширения есть режим, определяющий порядок обработки элементов входной коллекции. Режим может быть следую щим: • iterative (итеративный) – каждый элемент входной коллекции обра батывается последовательно; • parallel (параллельный) – элементы входной коллекции обрабатыва ются параллельно; • stream (потоковый) – элементы входной коллекции обрабатываются в порядке поступления в узел. Режим всегда должен быть задан явно, потому что спецификация UML не определяет применяемого по умолчанию режима. На рис. 15.6 область расширения принимает набор объектов Student (учащийся). Она обрабатывает каждый из этих объектов по очереди (режим = iterative) и выдает набор обработанных объектов Student. Два iterative Set of Student Set of Student Поставить оценки учащимся область расширения узел расширения режим Оценить результаты экзамена Оценить учащегося Рис. 15.6. Пример области расширения 15.6. Отправка сигналов и прием событий 343 действия внутри области сначала определяют результаты экзамена Student и затем ставят ему оценку. В данном случае выходная коллек ция объектов Student предлагается на выходном узле расширения толь ко после того, как обработаны все объекты Student. Однако если бы был задан режим stream, объекты Student предлагались бы на выходном уз ле расширения сразу после обработки. 15.6. Отправка сигналов и прием событий Сигнал представляет асинхронно передаваемую между объектами ин формацию. Сигнал моделируется как класс, отмеченный стереотипом «signal» (сигнал). Передаваемая информация хранится в атрибутах сиг нала. При анализе сигналы могут использоваться для отображения от правки и получения асинхронных бизнес событий (таких как OrderRe ceived (заказ получен)), а при проектировании они могут иллюстриро вать асинхронный обмен информацией между разными системами, подсистемами или частями оборудования. Сигналы представляют асинхронно передаваемую между объектами ин формацию. На рис. 15.7 показаны два сигнала, которые используются в деятель ности, представленной на рис. 15.8. Оба этих сигнала имеют тип SecurityEvent (событие системы безопасно сти). Сигнал AuthorizationRequestEvent (событие запроса авторизации) пе редает PIN и информацию карты, вероятно, в зашифрованном виде. В сигнале AuthorizationEvent (событие авторизации) хранится логиче ский флаг, указывающий, были ли авторизованы карта и PIN. Узел действия, отправляющий сигнал, представляет отправку сигнала. Сигнал можно послать с помощью узла действия, отвечающего за от правку сигнала. Он посылает сигнал асинхронно – деятельность, от «signal» AuthorizationRequestEvent pin : PIN cardDetails : CardDetails «signal» AuthorizationEvent isAuthorized : Boolean «signal» SecurityEvent Рис. 15.7. Два сигнала, используемые в деятельности Проверить кредитную карту 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 Отобразить новости Показать новости T erminateEvent Рис. 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» |