UML2 и унифицированный процесс. Джим арлоуайла нейштадтпрактический объектно ориентированныйанализ и проектированиеu
 Скачать 6.08 Mb.
|
|
Рис. 14.20. Объектный узел с верхней границей согласно этому селективному поведению выбираются объекты Order, созданные в декабре Order все объекты Order объекты Order, созданные в декабре «selection» Order.monthCreated = «Dec» Рис. 14.21. Объектный узел с селективным поведением 14.9. Объектные узлы 331 Наряду с отдельными объектами объектные узлы могут буферизовать множества (sets) объектов. Множество – это коллекция объектов, в которой нет дублирования, т. е. каждый объект имеет уникальный идентификатор. Чтобы показать это, перед именем классификатора просто указывают Set of (множество). Пример приведен на рис. 14.23. Немного подробнее стереотипы «selection» и «centralBuffer» рассматрива ются в разделах 15.8.2 и 15.11. 14.9.2. Представление объектов в состоянии Объектные узлы могут представлять объекты, находящиеся в опреде ленном состоянии. Объектные узлы могут представлять объекты, находящиеся в опреде ленном состоянии. Например, на риc. 14.22 показан фрагмент дея тельности обработки заказа, которая принимает объекты Order, нахо дящиеся в состоянии Открытый, и отправляет их по назначению. Состо яния объектов, на которые ссылаются объектные узлы, могут быть смоделированы с помощью конечных автоматов (см. главу 21). 14.9.3. Параметры деятельности Параметры деятельности – это объектные узлы, поступающие в или ис ходящие из деятельности. Объектные узлы могут использоваться для обеспечения входных и вы ходных данных деятельности, как показано на рис. 14.23. Входящие и исходящие объектные узлы должны перекрывать рамку деятельно сти. Входящие объектные узлы связаны с деятельностью одним или более исходящими ребрами, а у исходящих объектных узлов – одно или более входящих ребер, поступающих из деятельности. На рис. 14.23 деятельность Производство продукта на заказ имеет три входных параметра: CustomerRequest (запрос клиента), Set of BusinessCon straint (множество бизнес ограничений) и Order, а также один выходной параметр, Order. Узел Set of BusinessConstraint содержит множество объек тов BusinessConstraint. Order [Открытый] Отправить Order [Отправлен] Создать Заказ объект в определенном состоянии Рис. 14.22. Объект Order находится в состоянии Открытый 332 Глава 14. Диаграммы деятельности К этому процессу предъявляется несколько бизнес требований: • Продукты проектируются на основании CustomerRequest. При этом создается ProductSpecification (спецификация продукта). • При проектировании продукта учитываются все BusinessConstraint. • Оплата производится только после завершения проектирования продукта. • Изготовление продукта не может быть начато до тех пор, пока не будет получен платеж и создана спецификация продукта (объект ProductSpecification). • Доставка не может осуществляться до тех пор, пока продукт не бу дет изготовлен. Проанализируем данную деятельность. 1. Деятельность начинается, когда по входным потокам объектов дей ствия Спроектировать продукт на заказ поступают CustomerRequest и мно жество BusinessConstraint. Действие принимает входящие объекты и выдает объект ProductSpecification. 2. Действие Принять платеж выполняется, когда получает управляющий маркер от Спроектировать продукт на заказ и объект Order по входному потоку объектов. Оно меняет состояние объекта Order на Оплачен и выдает его на свой единственный выходной поток объектов. 3. Затем поток управления переходит к действию Изготовить продукт. Оно принимает объект ProductSpecification, производимый в действии Спроектировать продукт на заказ, и предлагает маркер управления дей ствию Доставить продукт. 4. Доставить продукт выполняется, когда от Изготовить продукт поступает маркер управления и объект Order находится в состоянии Оплачен. Спроектировать продукт на заказ Принять платеж Доставить продукт Маркетинг Производство Доставка CustomerRequest Set of BusinessConstraint Order [Доставлен] Производство продукта на заказ Order входной параметр выходной параметр поток объектов объект в определенном состоянии ProductSpecification Изготовить продукт Order [Оплачен] Рис. 14.23. Деятельность Производство продукта на заказ имеет три входных параметра и один выходной 14.10. Контакты 333 Результатом действия будет объект Order в состоянии Доставлен. Этот объект Order является выходным параметром деятельности. Как видите, мы довольно легко смогли выполнить бизнес требования. • Мы не будем пытаться Спроектировать продукт на заказ до тех пор, пока клиент не сделает запрос ( CustomerRequest) и не будет получено мно жество бизнес ограничений ( Set of BusinessConstraint). • Мы не можем Принять платеж, пока не будет сделан заказ (объект Or der) и не будет завершено действие Спроектировать продукт на заказ. • Мы не можем Изготовить продукт до тех пор, пока нет спецификации продукта ( ProductSpecification) и не завершено действие Принять платеж (иначе говоря, пока продукт не оплачен!). • Мы не можем Доставить продукт, пока он не изготовлен (не заверши лось действие Изготовить продукт) и не оплачен (пока объект Order не перейдет в состояние Оплачен). Этот пример иллюстрирует мощь диаграмм деятельности. Они могут кратко и точно моделировать сложные процессы. 14.10. Контакты Деятельность, в которой много потоков объектов, может стать очень запутанной. Чтобы немного прояснить ситуацию, используйте кон такты! Контакт – это объектный узел, представляющий один вход или выход из действия. Контакт – это просто объектный узел, представляющий один вход или выход из действия. У входных контактов только одно входное ребро, а у выходных – только одно выходное ребро. Во всем остальном их се мантика и синтаксис аналогичны объектным узлам. Однако из за их небольшого размера всю информацию, например имя классификато ра, приходится указывать вне контакта, но как можно ближе к нему. На рис. 14.24 показана деятельность Войти в систему, имеющая два по тока объектов. Деятельность начинается с действия Получить UserName. Его результатом является допустимый (valid) объект UserName. Сле дующее действие – Получить Password, на выходе которого получается допустимый объект Password. Деятельность Аутентифицировать объект User начинает выполнение, когда получает действительные объекты User Name и Password по своим входным потокам объектов. Осуществляется аутентификация пользователя, и деятельность завершается. На рис. 14.25 показана та же деятельность, но представленная с ис пользованием контактов. Как видите, нотация контактов выглядит более компактно, и диаграмма становится более аккуратной. 334 Глава 14. Диаграммы деятельности Сравнивая рис. 14.24 и рис. 14.25, можно заметить, что объектный узел UserName эквивалентен комбинации выходного контакта действия Получить UserName и входного контакта действия Аутентифицировать объ ект User. Поэтому объектные узлы иногда называют автономным кон тактом (stand alone style pin). 14.11. Что мы узнали В этой главе было показано, что диаграммы деятельности можно ис пользовать для моделирования множества различных процессов. Мы узнали следующее: • Диаграммы деятельности – это ОО блок схемы: • они используются для моделирования всех типов процессов; • диаграммы деятельности можно создать для любого элемента модели для описания его поведения; • хорошая диаграмма деятельности описывает один конкретный аспект поведения системы; • в UML 2 диаграммы деятельности имеют семантику технологии сетей Петри. • Деятельности – это схемы, состоящие из узлов, соединенных ребрами. • Категории узлов: • узлы действия – элементарные единицы работы в рамках дея тельности; Получить UserName Получить Password Аутентифицировать User Войти в систему UserName [Допустимый] Password [Допустимый] Рис. 14.24. Деятельность с двумя потоками объектов выходной контакт входной контакт Получить Password Аутентифицировать User Войти в систему UserName [Допустимый] Password [Допустимый] Получить UserName Рис. 14.25. Та же деятельность с применением контактов 14.11. Что мы узнали 335 • узлы управления – управляют потоком деятельности; • объектные узлы – представляют объекты, используемые в дея тельности. • Категории ребер: • потоки управления – представляют поток управления дея тельности; • потоки объектов – представляют поток объектов деятельности. • Маркеры перемещаются по сети (network) и могут представлять: • поток управления; • объект; • некоторые данные. • Движение маркеров по ребрам от начального узла к целевому уз лу зависит от: • постусловий начального узла; • сторожевых условий ребра; • предусловий целевого узла. • Деятельности могут иметь предусловия и постусловия. • Узлы действия. • Выполняются при одновременном поступлении маркеров по всем входным ребрам И удовлетворении всех предусловий. • После выполнения узлы действия предлагают маркеры одновре менно на всех выходных ребрах, постусловия которых удовле творены: • неявное ветвление. • Узел вызова действия: • инициирует деятельность – используется символ «грабли»; • инициирует поведение; • инициирует операцию. • Узел действия, посылающий сигнал (см. раздел 15.6). • Узел действия, принимающий событие (см. раздел 15.6). • Узел действия, принимающий событие времени, выполняется, когда временное выражение становится истинным: • некоторое событие (например, конец финансового года); • конкретный момент времени (например, 11/03/1960); • временной интервал (например, ожидать 10 секунд). • Узлы управления: • начальный узел показывает, где начинается поток при вызове деятельности; • конечный узел деятельности заканчивает деятельность; 336 Глава 14. Диаграммы деятельности • конечный узел потока заканчивает конкретный поток деятель ности; • узел решения – поток направляется по исходящему ребру, сто рожевое условие которого истинно: • может иметь стереотип « decisionInput»; • узел слияния копирует входные маркеры в единственное исхо дящее ребро; • узел ветвления разделяет поток на несколько параллельных по токов; • узел объединения синхронизирует несколько параллельных по токов: • может иметь { описание объединения}. • Разделы деятельности – высокоуровневая группировка взаимосвя занных действий. • Разделы формируют иерархию, корнем которой является изме рение. • Объектные узлы представляют экземпляры классификатора. • Входящие и исходящие ребра – потоки объектов – представляют движение объектов. • Исходящие ребра объектного узла конкурируют за каждый ис ходящий маркер. • Объектные узлы работают как буферы: • { upperBound = n } • { ordering = FIFO } XOR { ordering = LIFO }; • по умолчанию применяется { ordering = FIFO }; • могут иметь стереотип « selection». • Объектные узлы могут представлять объекты, находящиеся в определенном состоянии: • должны соответствовать конечным автоматам. • Параметры деятельности – это объектные узлы, входящие в или исходящие из деятельности: • на диаграмме перекрывают рамку деятельности; • входящие параметры имеют один или более исходящих ре бер, поступающих в деятельность; • исходящие параметры имеют один или более входящих ре бер, поступающих из деятельности. • Контакт – это объектный узел, представляющий один вход в или выход из действия или деятельности. 15 Дополнительные аспекты диаграмм деятельности 15.1. План главы В этой главе рассматриваются дополнительные возможности диа грамм деятельности. Они вряд ли будут использоваться каждый день, но могут быть очень полезны в определенных ситуациях моделирова ния. Разделы этой главы можно читать в любой последовательности. Можно вообще только просмотреть главу, чтобы получить общее пред ставление, а затем обращаться к соответствующим разделам и в случае необходимости использовать ту или иную конкретную возможность. 15.2. Разъемы Основное правило: применения разъемов необходимо избегать. Одна ко если диаграмма очень сложна и не поддается упрощению, разъемы можно использовать для разрыва длинных ребер, которые трудно про следить, и для «распутывания» пересекающихся ребер. Это может упростить диаграммы деятельности и повысить их удобочитаемость. Синтаксис разъема представлен на рис. 15.2. В заданной деятельности каждому исходящему разъему должен соответствовать единственный входящий разъем с такой же меткой. Метки – это идентификаторы разъема, никакой другой семантики у них нет. Обычно в их качестве выступают буквы алфавита. Разъемы могут разрывать длинные ребра, которые трудно проследить, и «распутывать» пересекающиеся ребра. 338 Глава 15. Дополнительные аспекты диаграмм деятельности учимся делать диаграммы деятельности более аккуратными 15.2. Разъемы 15.3. Области с прерываемым выполнением действий 15.4. Обработка исключений 15.5. Узлы расширения 15.6. Отправка сигналов и прием событий 15.7. Потоковая передача 15.8.1. Входные эффекты и выходные эффекты 15.13. Что мы узнали 15.8. Дополнительные возможности потоков объектов 15.8.2. Стереотип «selectio n » 15.8.3. Стереотип «tra n sformatio n » 15.9. Групповая рассылка и групповой прием 15.10. Наборы параметров 15.11. Узел «ce n tralBuffer» 15.12. Диаграммы обзора взаимодействий учимся прерывать деятельности учимся добавлять обработчики исключений в узлы учимся обрабатывать коллекции объектов изучаем сигналы и события изучаем потоковую передачу объектов учимся моделировать поток между взаимодействиями изучаем эффекты действия изучаем дополнительные возможности потоков объектов учимся выбирать объекты учимся преобразовывать объекты изучаем групповую рассылку и групповой прием учимся задавать параметры действий учимся использовать узлы в качестве буферов Ри с . 1 5 .1 . Пл ан гл ав ы 15.3. Области с прерываемым выполнением действий 339 15.3. Области с прерываемым выполнением действий Области с прерываемым выполнением действий – это области деятель ности, прерываемые при прохождении маркера по прерывающему ребру. Когда область прерывается, все ее потоки немедленно прекра щаются. Области с прерываемым выполнением действий полезны для моделирования прерываний и асинхронных событий. Чаще всего они используются при проектировании, но также могут быть полезны при анализе для представления процесса обработки асинхронных бизнес событий. Области с прерываемым выполнением действий – это области деятельно сти, прерывающиеся при прохождении маркера по прерывающему ребру. На рис. 15.3 показана простая деятельность Войти в систему, имеющая область с прерываемым выполнением действий. Область обозначена отрисованным пунктирной линией прямоугольником со скругленны ми углами, включающим действия Получить UserName, Получить Password и Отменить. Если принимающее событие действие Отменить получает со бытие Cancel в тот момент, когда управление находится в этой области, оно выводит маркер на прерывающее ребро и внезапно прекращает об ласть. Все действия – Получить UserName, Получить Password и Отменить – прерываются. Прерывающие ребра изображаются как зигзагообразные стрелки (рис. 15.3) или как обычные стрелки с пиктограммой зигзага над ними (рис. 15.4). Действие1 Деятельность входящий разъем A Действие2 A исходящий разъем Рис. 15.2. Синтаксис разъема 340 Глава 15. Дополнительные аспекты диаграмм деятельности 15.4. Обработка исключений Современные языки программирования часто обрабатывают ошибки посредством механизма, называемого обработкой исключений (excep tion handling ). В случае выявления ошибки в защищенной части кода создается объект исключения. Поток управления переходит в обработ чик исключения, который некоторым образом обрабатывает объект исключения. В этом объекте исключения содержится информация об ошибке, которая может использоваться обработчиком исключения. Обработчик исключения может прервать приложение или попытаться восстановить нормальное состояние. Часто информация объекта ис ключения сохраняется в журнале регистрации ошибок. Обработку исключений на диаграммах деятельности можно моделиро вать с помощью контактов исключений, защищенных узлов и обработ чиков исключений. У защищенного узла есть обработчик исключений. На рис. 15.5 представлена обновленная деятельность Войти в систему. Теперь деятельность Аутентифицировать User выдает объект LogOnExcep tion (исключение при входе) при неудачной аутентификации пользова теля. Этот объект принимается действием Зарегистрировать ошибку, ко Получить UserName Получить Password Аутентифицировать User Войти в систему Отменить область с прерываемым выполнением действий прерывающее ребро UserName [Допустимый] Password [Допустимый] |