UML2 и унифицированный процесс. Джим арлоуайла нейштадтпрактический объектно ориентированныйанализ и проектированиеu
 Скачать 6.08 Mb.
|
|
Рис. 14.10. Примеры имен узлов действия 14.7. Узлы действия 321 под названием «заказ», тогда как нижний пример явно ссылается на класс Order, который можно найти где то в модели. Детали действия фиксируются в описании узла действия. Часто это обычное текстовое описание, такое как «Написать письмо», но на этапе проектирования оно превращается в структурированный текст, псев докод или реальный код. При моделировании прецедента диаграмма деятельности могла бы опережать поток прецедента на два три шага. Но это может вызвать трудности, поскольку придется постоянно син хронизировать прецедент и соответствующую диаграмму деятельности. Существует четыре типа узлов действия; они перечислены в табл. 14.1. Подробное обсуждение типов узлов действия можно найти в разделах, указанных в таблице. Таблица 14.1 14.7.1. Узел вызова действия Самыми распространенными узлами действий являются узлы вызова действия (call action node). Этот тип узлов может инициировать: • деятельность; • поведение; • операцию. Синтаксис Имя Семантика Раздел Узел вызова действия Инициирует деятельность, поведение или операцию. 14.7.1 Посылка сигнала Действие посылки сигнала – посылает сигнал асинхронно (отправитель не ожи дает подтверждения получения сигнала). Для создания сигнала может принимать входные параметры. 15.6 Узел дейст вия, прини мающий событие Принимает событие – ожидает события, установленного объектом владельцем, и выдает событие на выходе. Активируется при получении маркера по входящему ребру. Если нет входящего ребра, запускается при запуске включающей его деятельно сти и всегда является активированным. 15.6 Узел дейст вия, прини мающий событие времени Принимает событие времени – отвечает на определенное значение времени. Генерирует события времени соответст венно своему временному выражению. 14.7.2 Некоторое действие ИмяСигнала ПринятьСобытие Выражение для описания времени 322 Глава 14. Диаграммы деятельности Узел вызова действия может инициировать деятельность, поведение или операцию. Некоторые примеры синтаксиса узла вызова действия приведены на рис. 14.11. Как видно из рисунка, синтаксис очень гибок! • Посредством специального символа «грабли» в нижнем правом уг лу пиктограммы узла можно указать, что действие вызывает другое действие. Имя узла соответствует имени вызываемой им деятельно сти. • Можно вызвать поведение – это прямой вызов поведения контекста деятельности без указания какой либо конкретной операции. • Можно вызвать операцию, используя стандартный синтаксис опе рации, описанный в разделе 7.5.3. • Можно вызвать операцию, описывая ее детали на конкретном язы ке программирования. Это может быть особенно полезным при ис пользовании инструментального средства UML, позволяющего ге нерировать код из диаграмм деятельности (например, iUML от ком пании Kennedy Carter, www.kc.com). • С помощью ключевого слова self можно использовать возможности контекста деятельности. Узлы вызова действия, используемые в диаграммах деятельности на уровне анализа, обычно вызывают поведение. Узлы вызова действия, инициирующие конкретные операции, как правило, используются для более детального моделирования деятельности при проектировании. вызов операции Создать Order вызов деятельности Закрыть Order вызов поведения getBalance():double (Account::) имя операции имя класса (необязательное) Получить баланс (Account::getBalance():double) имя узла имя операции (необязательное) язык программирования (например, Python) if self.balance <= 0: self.status = 'INCREDIT' else self.status = 'OVERDRAWN' Рис. 14.11. Примеры синтаксиса узла вызова действия 14.8. Узлы управления 323 14.7.2. Узел действия, принимающий событие времени Узел действия, принимающий события времени, реагирует на время. Узел действия, принимающий события времени, реагирует на время. Этот тип узла имеет временное выражение и генерирует событие вре мени, когда это выражение становится истинным. Поведение такого узла зависит от наличия входящего ребра. Например, на рис. 14.12 показан узел действия, принимающий собы тия времени, без входящего ребра. Этот узел станет активным и будет генерировать событие времени после запуска его деятельности вла дельца, когда его временное выражение становится истинным. В при веденном примере событие времени генерируется в конце каждого фи нансового года и инициирует деятельность Отправить налоговую деклара цию компании. Однако в примере на рис. 14.13 действие, принимающее событие вре мени, имеет входящее ребро и станет активным только после получе ния маркера по этому ребру. Этот пример является фрагментом систе мы управления лифтом. Первое действие открывает дверь лифта и за пускает действие, принимающее событие времени. Это действие ожи дает десять секунд и затем передает маркер действию Закрыть дверь. Обратите внимание, что временное выражение может указывать на: • некоторое событие (например, конец финансового года); • конкретный момент времени (например, 11/03/1960); • временной интервал (например, ожидать 10 секунд). 14.8. Узлы управления Узлы управления контролируют поток управления деятельности. В табл. 14.2 представлены все узлы управления UML 2; их подробное обсуждение см. в следующих разделах. наступил конец финансового года временное выражение Отправить налоговую декларацию компании Рис. 14.12. Узел действия, принимающий событие времени, без входящего ребра ожидаем 10 секунд временное выражение Открыть дверь Закрыть дверь Рис. 14.13. Узел действия, принимающий событие времени, с входящим ребром 324 Глава 14. Диаграммы деятельности Таблица 14.2 14.8.1. Начальный и конечный узлы Начальный узел показывает, где начинается деятельность. Как уже говорилось в разделе 14.4, начальный узел (initial node) – это точка, в которой начинается поток при вызове деятельности. У дея тельности может быть более одного начального узла. В этом случае по токи запускаются во всех начальных узлах одновременно и выполня ются параллельно. Конечный узел деятельности завершает все потоки деятельности. Деятельность также может быть инициирована действием принятия со бытия (раздел 15.6) или узлом, являющимся параметром (раздел 14.9.3). Таким образом, начальные узлы не являются обязательными, по скольку есть другие способы запуска деятельности. Конечный узел потока завершает один из потоков деятельности. Синтаксис Имя Семантика Раздел Началь ный узел Указывает, где начинается поток при вызове деятельности. 14.8.1 Конечный узел дея тельности Завершает деятельность. Конечны е уз лы 14.8.1 Конечный узел пото ка Завершает определенный поток деятельности – другие потоки не затрагиваются. 14.8.1 Узел решения Поток проходит по исходящему ребру, сторожевое условие которого истинно. Может иметь входные данные (необя зательно). 14.8.2 Узел слияния Копирует входные маркеры в единст венное выходное ребро. 14.8.2 Узел ветвления Разделяет поток на несколько парал лельных потоков. 14.8.3 Узел объ единения Синхронизирует несколько парал лельных потоков. Может иметь описание объединения (не обязательно) для изменения его се мантики. 14.8.3 «decisionInput» условие принятия решения {описание объединения} 14.8. Узлы управления 325 Конечный узел (final node) деятельности завершает все потоки дея тельности. Конечных узлов деятельности может быть много, и тот, ко торый будет активирован первым, завершит все остальные потоки и са му деятельность. Конечный узел потока просто останавливает один из потоков деятель ности, остальные потоки продолжают выполнение. Пример приведен на рис. 15.10. 14.8.2. Узлы решения и слияния Узел решения имеет одно входящее ребро и два и более альтернатив ных исходящих ребер. Маркер, поступающий по входящему ребру, бу дет предложен всем исходящим ребрам, но пройдет только по одному из них. Узел решения – это перекресток потоков, на котором маркер должен выбрать только один путь. Узел решения передает маркер на то выходное ребро, для которого вы полняется сторожевое условие. Каждое выходное ребро защищено сторожевым условием (guard con dition ), которое означает, что ребро примет маркер только в случае вы полнения сторожевого условия. Важно, чтобы сторожевые условия были гарантированно взаимоисключающими, т. е. чтобы в любой мо мент времени истинным могло быть только одно из них. В противном случае согласно спецификации UML 2 поведение узла решения фор мально является неопределенным! Для задания ребра, по которому пройдет поток управления в случае невыполнения всех сторожевых условий, может использоваться клю чевое слово else. На рис. 14.14 показан простой пример узла решения. После действия Получить корреспонденцию поток управления попадает в узел решения. Если выполняется условие [это мусор], почта отправляется в мусорную корзину, в противном случае ( else) почтовое сообщение открывается. Узел, отмеченный стереотипом «decisionInput» (входные данные реше ния), представляет условие принятия решения. Его результат исполь зуется сторожевыми условиями на исходящих ребрах. Пример фраг мента деятельности показан на рис. 14.15. Здесь условие принятия ре шения сравнивает запрашиваемую для снятия сумму с балансом сче та. Если баланс больше или равен запрашиваемой сумме, условие принимает значение истина и поток переходит к действию Снять сумму. В противном случае регистрируется неплатежеспособность. На рис. 14.14 показан узел слияния (merge node). В узлах слияния схо дятся два или более входящих ребра и выходит одно исходящее. Они объединяют все входящие потоки в один исходящий. Семантика слия ния очень проста: все маркеры, предлагаемые на входящих ребрах, предлагаются на исходящем ребре. Маркеры и поток не изменяются. 326 Глава 14. Диаграммы деятельности Узел слияния и непосредственно следующий за ним узел решения мо гут быть объединены в один символ, как показано на рис. 14.16. Одна ко мы не рекомендуем применять такую сокращенную нотацию, по скольку изображение узлов по отдельности придает диаграмме боль шую наглядность. 14.8.3. Узлы ветвления и объединения – параллелизм Узел ветвления разделяет поток на несколько параллельных потоков. Параллельные потоки деятельности можно создать путем разделения одного потока с помощью узла ветвления. Хотя обычно параллелизм является решением, принимаемым во время проектирования, нередко необходимо показать параллельные деятельности при моделировании бизнес процессов. По этой причине мы будем часто использовать узлы ветвления и объединения как при анализе, так и при проектировании. [это мусор] else Обработка корреспонденции ключевое слово сторожевое условие узел решения узел слияния Bin mail Open mail Получить корреспонденцию Рис. 14.14. Пример узла решения и узла слияния Зарегистрировать неплатежеспособность Снять сумму Запросить сумму для снятия со счета [ложь] условие принятия решения [истина] «decisionInput» balance >= amount Рис. 14.15. Фрагмент деятельности с узлом, помеченным стереотипом «decisioninput» 14.8. Узлы управления 327 Узел ветвления имеет одно входящее и два или более исходящих ребер. Маркеры, поступающие по входящим ребрам, дублируются и предла гаются на всех исходящих ребрах одновременно. Тем самым единст венный входящий поток разделяется на несколько параллельных ис ходящих потоков. У каждого исходящего ребра может быть сторожевое условие, и маркер, как и в узлах решения, может передаваться по исхо дящему ребру только в случае выполнения сторожевого условия. Узел объединения синхронизирует и объединяет несколько входящих потоков в единственный исходящий. В узле объединения несколько входящих ребер встречаются и объеди няются в одно исходящее. Эти узлы синхронизируют потоки: маркер на их единственном исходящем ребре предлагается только после того, как поступили маркеры всех входящих потоков. Они осуществляют операцию логического И над всеми своими входящими ребрами. На рис. 14.17 показан простой пример Процесс производства продукта, в ко тором используются узлы ветвления и объединения. В этом примере: [условие1] [условие2] [условие3] слияние решение Рис. 14.16. Узел слияния и узел решения могут быть объединены в один символ Спроектировать новый продукт Найти рынок сбыта продукта Изготовить продукт Продать продукт Процесс производства продукта ветвление объединение Рис. 14.17. Деятельность Процесс производства продукта включает узлы ветвления и объединения 328 Глава 14. Диаграммы деятельности • продукт сначала разрабатывается; • поиск рынка сбыта и изготовление продукта осуществляются па раллельно; • продукт реализуется только после завершения обоих процессов – поиска рынка сбыта и изготовления. На рис. 14.17 деятельность Процесс производства продукта начинается с действия Спроектировать новый продукт. После этого узел ветвления раз деляет единый поток на два параллельных. В одном из этих потоков ве дется поиск рынка сбыта продукта ( Найти рынок сбыта продукта), в дру гом – продукт изготавливается ( Изготовить продукт). Узел объединения синхронизирует эти два параллельных потока, поскольку ожидает маркер от каждого из параллельных действий. Получив маркер от каж дого действия, он предлагает маркер на своем выходном ребре, и поток переходит к действию Продать продукт. При моделировании узлов объединения важно гарантировать получе ние маркера всеми входными ребрами. Например, на рис. 14.17 узел объединения никогда не смог бы получить подходящие маркеры для активации, если бы на исходящие потоки ветвления были наложены взаимоисключающие сторожевые условия. Это привело бы к «зависа нию» деятельности. 14.9. Объектные узлы Объектные узлы показывают, что экземпляры классификатора доступны. Объектные узлы – это специальные узлы, показывающие, что экземп ляры конкретного классификатора доступны в данной точке деятель ности. Они обозначены именем классификатора и представляют его экземпляры или подклассы. Фрагмент деятельности на рис. 14.18 по казывает объектный узел, представляющий экземпляры классифика тора Order или подклассы Order. Потоки объектов представляют движение объектов в деятельности. Входящие и исходящие ребра объектных узлов называют потоками объектов (object flows). Это особые типы потоков, представляющие Order объектный узел поток объектов имя классификатора Рис. 14.18. Объектный узел 14.9. Объектные узлы 329 движение объектов в деятельности. Сами объекты создаются и исполь зуются узлами действия. На рис. 14.19 показана деятельность Процесс производства продукта, впер вые представленная на рис. 14.17. Она была дополнена: включены разделы и действием Спроектировать новый продукт создается объект Prod uctSpecification (спецификация продукта), который используется дейст вием Изготовить продукт для описания производственного процесса. Выходные ребра объектного узла конкурируют за каждый выходной маркер. Когда объектный узел получает объектный маркер по одному из своих входных ребер, он предлагает его всем выходным ребрам одновремен но, и эти ребра конкурируют за этот маркер. Главное то, что маркер всего один – он не тиражируется на все ребра! Этот маркер получает поток, готовый первым принять его. 14.9.1. Семантика буфера объектного узла Объектные узлы имеют очень интересную семантику. Они действуют как буферы – участки деятельности, где могут находиться объектные маркеры в ожидании принятия другими узлами. Объектные узлы выступают в роли буферов. Местонахождение Спроектировать новый продукт Найти рынок сбыта продукта Продать продукт Проектирование Маркетинг Производство Нью Йорк Лондон Процесс производства продукта поток объектов объектный узел ProductSpecification Изготовить продукт Рис. 14.19. Деятельность Процесс производства продукта дополнена разделами, действием Спроектировать новый продукт и объектом ProductSpecification 330 Глава 14. Диаграммы деятельности По умолчанию каждый объектный узел может удерживать бесконеч ное число объектных маркеров. Однако иногда необходимо ограни чить размер буфера. Для этого задают верхнюю границу (upper bound) объектного узла. Она показывает максимальное число маркеров, кото рые могут удерживаться в узле в любой момент времени. Узел прини мает объектные маркеры до тех пор, пока не заполнится. Пример объ ектного узла с заданной верхней границей приведен на рис. 14.20. Для объектных узлов можно задать два аспекта семантики буфера. • У объектных узлов есть порядок расположения (ordering) (рис. 14.20), определяющий поведение буфера. Применяемым по умолчанию по рядком является FIFO (first in, first out – первым вошел, первым вышел). Это означает, что объект, первым поступивший в буфер, первым предлагается его выходным ребрам. Существует обратный порядок расположения – LIFO (last in, first out – последним во шел, первым вышел). • Объектные узлы могут обладать селективным поведением (selection behavior ). Это закрепленное за узлом поведение, по которому объек ты из входных потоков выбираются согласно некоторому критерию, определенному разработчиком модели. Критерий задается примеча нием со стереотипом «selection» (выбор), как показано на рис. 14.21. В данном примере объектный узел выбирает только те объекты Order, которые были созданы в декабре, и предлагает их своим выходным потокам в применяемом по умолчанию порядке (FIFO). Объектный узел может использоваться для сбора объектов из несколь ких входящих объектных потоков или для распределения объектов по нескольким исходящим объектным потокам. В этих случаях узел используется исключительно из за его буферной семантики. Таким образом, чтобы подчеркнуть этот факт, узел можно обозначить стерео типом « centralBuffer» (центральный буфер). Order { upperBound = 12} {ordering = LIFO} в этом объектном узле может храниться максимум 12 объектных маркеров объект, поступивший в буфер последним, первым предлагается на выходе |