Новиков Ф.А. Учебно-методическое пособие по дисциплине Анализ и проектирование на UML
Подождите немного. Документ загружается.
Теперь наконец мы может точно
107
и кратко определить основные сущности на
диаграмме деятельности UML. Таковых две:
• состояние действия — это состояние, внутренняя активность (разд. 4.2.1)
которого является действием;
• состояние деятельности — это состояние, внутренняя активность которого
является деятельностью.
Состояние действия не имеет специальной нотации и изображается на диаграмме
как простое состояние с действием на входе. Вообще говоря, понятие состояния
действия не имеет глубокого смысла: без него вполне можно обойтись.
Действительно, при переходе в состояние действия выполняется действие на входе
(которое атомарно и мгновенно) и немедленно после этого выполняется переход по
завершении (см. первое примечание в разд. 4.3.2). Такую ситуацию можно
промоделировать простым переходом, как показано на рис. 4.31. На этом рисунке
на фрагменте диаграммы слева использовано состояние действия, а справа
приведен эквивалентный фрагмент без состояния действия.
A
entry/D2
B
C
A
C
E [G] / D1
E [G] / D1,D2
Рис. 4.31. Элиминация состояния действия
Пожалуй, единственной причиной, по которой состояние действия оставлено в
UML, является стремление угодить вкусам тех, кто привык на блок-схемах
операторы присваивания писать внутри прямоугольников, а не над стрелками.
Видимо поэтому состояние действия разрешается обозначать в виде фигуры
состояния деятельности, внутрь которой вписано действие, а не деятельность.
Состояние деятельности,
108
напротив, является существенным элементом
диаграммы деятельности и имеет специальное обозначение — прямоугольник со
скругленными сторонами. Это обозначение очень похоже на обозначение простого
107
Что нам кажется очень полезным в данном случае. Данные понятия систематически путают все,
кроме авторов языка, включая переводчиков книг и разработчиков инструментов.
108
Мы иногда для краткости речи вместо словосочетания "состояние деятельности" употреблять
просто слово "деятельность", если из контекста ясно, что подразумевается именно состояние
деятельности.
состояния (прямоугольник со скругленными углами), но в тоже время отлично от
него.
109
Тем самым подчеркивается родственная связь диаграмм состояний и
действий. Внутри фигуры состояния деятельности пишется так называемое
выражение деятельности. Никакого специального синтаксиса для данного
выражения UML не определяет: это может быть текст на псевдокоде, фрагмент
кода на языке программирования и просто название деятельности на естественном
языке. Никакой видимой внутренней структуры состояние деятельности не имеет, в
противоположность простому состоянию, которое может иметь действия на входе,
выходе, внутренние и отложенные переходы. Собственно говоря, то, что написано
внутри фигуры состояния деятельности — это и есть его внутренняя активность.
Но это отнюдь не означает, что состояние деятельности атомарно и не имеет
внутренней структуры. Напротив, оно по определению не атомарно и имеет
внутреннюю структуру. Предполагается, что либо эта структура не важна на
выбранном уровне абстракции, либо она раскрывается в другом месте
110
с
помощью машины состояний, другой диаграммы деятельности или иным
способом.
На диаграмме деятельности применяется еще один тип сущностей — объекты — и
целый ряд фигур, похожих на сущности, но таковыми не являющимися. Мы
обсудим их в подходящем контексте.
4.3.2. Переходы по завершении и ветвления
На диаграмме деятельности применяется один основной тип отношений —
простые переходы по завершении (а также поток объектов, см. разд. 4.3.4). Переход
по завершении не имеет возбуждающего события — событием является
завершение внутренней активности (деятельности) в состоянии. Как правило,
исходящий переход по завершении один; если их несколько, они должны быть
снабжены сторожевыми условиями, образующими полную дизъюнктную систему
предикатов (см. разд. 4.2.2). Кроме того, можно использовать и переходы,
возбуждаемые событиями. Срабатывание такого перехода означает прерывание
выполнения деятельности в состоянии и переход в другое состояние.
ЗАМЕЧАНИЕ
Граница между диаграммой состояний и диаграммой деятельности весьма условна и
зыбка. Мы определим ее так: диаграмма деятельности – это такая диаграмма
состояний, в которой все или почти все состояния являются состояниями действия
или деятельности, и все или почти все переходы являются переходами по
завершении. Осталось только договориться, что значит "почти все".
Таким образом, в рамках объектно-ориентированной семантики машины состояний
авторы UML сумели описать семантику обычных блок-схем (в которых нет
109
При достаточно мелком масштабе отличие заметно разве что под микроскопом. Честно говоря,
мы затрудняемся дать однозначную оценку тому факту, что обозначения путаются. С одной
стороны, это нехорошо, а с другой стороны, как еще побудить людей, привыкших думать в
терминах блок-схем, побудить начать думать в терминах переходов-состояний? Только подав
новое
средство в привычной упаковке. Но в UML 2.0 от этих проблем решили просто отказаться — все
рисуется одинаково.
110
Почти все инструменты поддерживают эффективную навигацию в модели, позволяющую
раскрыть структуру состояния деятельности, если она определена.
никаких событий, а есть последовательная передача управления следующей
деятельности по завершении предыдущей деятельности).
Оставим пока в стороне особые добавления к диаграммам деятельности,
имеющиеся в UML, и рассмотрим пример самой обычной блок-схемы (в нотации
UML), описывающую последовательность действий при выполнении некоторого
сценария. В нашей информационной системе отдела кадров предусмотрен вариант
использования DeleteDeparment для удаления подразделения. Удаление
подразделения не такая простая операция — нельзя просто взять и удалить
подразделение — оно может быть связано отношением композиции с другими
подразделениями и должностями, а те, в свою очередь, связаны с другими
сущностями и т. д. Мы должны решить, какие элементарные операции и в какой
последовательности нужно выполнить, чтобы достичь требуемого не нарушив
целостность наших данных. Допустим, что в нашем распоряжении имеются классы
и операции, представленные на рис. 4.32 (детали, ненужные в данном примере,
опущены).
size() : Integer
deletePos(in pos : Position)
getNextPos() : Position
Department
isFree() : Boolean
Position
pos : Position
«exception»
posOccupied
1
*
deleteDpt(in dpt : Department)
«signal»posOccupied(in pos : Position)
«utility»
Company
1
*
Рис. 4.32. Некоторые классы в информационной системе отдела кадров
Операция size класса Department доставляет количество должностей в
подразделении, deletePos — удаляет указанную должность, getNextPos —
итератор, позволяющий перебирать должности в подразделении. Функция
isFree
класса Position проверяет вакантность должности. Операция обработки
исключения posOccupied и операция deleteDpt определены в службе общего
пользования Company. Разумеется, нам должно быть известно, какое именно
подразделение следует удалить — пусть этот объект называется dpt. В этой
ситуации можно предложить различные варианты поведения — все зависит от
кадровой политики организации, которую нужно реализовать. Допустим, что в
нашей информационной системе отдела кадров действует такое правило: если в
подразделении есть "живые люди", то его нельзя просто так удалить — это ошибка,
а если нет никого или только "мертвые души", то можно удалять все не
задумываясь. Тогда алгоритм удаления подразделения на псевдокоде
111
можно
описать, например, следующим образом.
111
См. сноску 3 в разд. 5.1.1.
if dpt.size() > 0
repeat
pos := dpt.getNextPos()
if not pos.isFree() then
send posOccupied(pos)
stop
dpt.deletePos(pos)
until dpt.size() = 0
deleteDpt(dpt)
Это же поведение в нотации диаграммы деятельности UML представлено на
рис. 4.33.
Рис. 4.33. Диаграмма деятельности по удалению подразделения в информационной системе
отдела кадров
Здесь мы считаем нужным отступить от основного русла разбора примера и
сделать существенное замечание относительно нотации. Ромбик, который
используется на диаграмме деятельности, хотя и является значком, но не является
сущностью. Это не более чем связующий символ, позволяющий более экономно
изображать сегментированные переходы (см. разд. 4.2.2, рис. 4.10). В примере на
рис. 4.30 два ромбика в верхней части диаграммы использованы, чтобы показать
место ветвления потока управления на альтернативные
112
потоки управления. Но
сегментировать в виде дерева можно не только множество исходящих переходов
данного состояния, но и множество входящих переходов. В таком случае можно
также использовать ромбик, чтобы показать место слияния альтернативных
потоков управления (нижний ромбик на рис. 4.30). При ветвлении ромбик
соединяет один входящий и несколько исходящих сегментов перехода, а при
слиянии ромбик соединяет несколько входящих и один исходящий сегмент.
На этом можно было бы успокоиться, поскольку в обычных блок-схемах больше
ничего и не бывает, а можно рассмотреть рис. 4.34 и задаться вопросом, что может
означать фрагмент диаграммы на рис. 4.34 справа.
Ветвление Слияние ? ? ?
Рис. 4.34. Варианты использования ромбика на диаграммах деятельности
Стандарт и авторы языка на этот счет хранят молчание и в своих примерах таких
конструкций не используют. Авторы же популярных руководств по UML и
разработчики инструментов либо также обходят этот вопрос молчанием, либо
считают данную конструкцию синтаксической ошибкой. Мы же полагаем, что
такую конструкцию вполне осмысленной: на рис. 4.35 смысл фрагмента диаграммы
слева раскрыт на фрагменте диаграммы справа. Другими словами, мы считаем
разумным и допустимым произвольный ациклический ориентированный граф из
переходных состояний, обозначенных ромбиками, и сегментов перехода, считая
семантикой такого графа сегментированных переходов множество переходов,
прочитанных, как все возможные пути в этом графе.
[Q]
[P]
A
CB
D
[P]
[P]
[Q]
A
CB
D
[Q]
Рис. 4.35. Семантически эквивалентные фрагменты диаграммы деятельности
Возвращаясь к нашему примеру, мы считаем синтаксически возможным описать
деятельность по удалению подразделения диаграммой на рис. 4.36.
112
Не следует путать альтернативные потоки управления с параллельными.
Рис. 4.36. Диаграмма деятельности по удалению подразделения
По нашему мнению, диаграмма на рис. 4.36 соответствует следующему
псевдокоду:
while dpt.size() > 0
pos := dpt.getNextPos()
if not pos.isFree() then
send posOccupied(pos)
stop
dpt.deletePos(pos)
deleteDpt(dpt)
Вообще говоря, можно поспорить, что более наглядно: диаграммы деятельности на
рис. 4.33 и рис. 4.36 или приведенные программы на псевдокоде. Если положить
перед человеком два листа: с диаграммой рис. 4.33 (или 4.36) и с текстом на
псевдокоде, и предложить выбрать, то реакция, как показывают наблюдения
автора, далеко не однозначна и сильно зависит от личностных качеств
испытуемого. Чтобы читатель мог оценить, какой стиль ему предпочтителен, мы
приведем еще несколько вариантов графической записи данного элементарного
алгоритма, уже не в стиле структурной блок-схемы, как на рис. 4.36, а стиле
машины состояний UML. Начнем с очевидного: традиционные ромбики не нужны,
они только занимают место на диаграмме (рис. 4.37).
Рис. 4.37. Диаграмма деятельности без использования переходных состояний
Если вам еще не надоел данный пример, попробуйте прочитать диаграмму на
рис. 4.38. Здесь мы попытались отразить основную структуру разбираемого
алгоритма: если подразделение пусто, то его можно удалять без всяких сомнений, а
если нет, то нужно анализировать состояние должностей. Этот анализ выполняется
в простом состоянии in Doubt. В данном состоянии имеется внутренняя
активность do, состоящая в "бесконечном" циклическом переборе должностей в
подразделении. Но никакой бесконечности, разумеется, нет: на каждом шаге цикла
выполняется внутренний переход, в результате которого либо мы натыкаемся на
занятую должность и работа машины состояний грубо обрывается действием
terminate, либо уменьшаем размер перебираемого множества, так что процесс
неизбежно закончится.
Рис. 4.38. Использование простого состояния с внутренней активностью и переходами
Состояние deleteDpt является, на самом деле, состоянием действия, а не
состоянием деятельности и без него, как мы отмечали, можно обойтись. Вглядимся
теперь внимательно в простое состояние
in Doubt. В сущности, там в цикле
выполняется пара действий: взять следующую должность, обработать ее. Таким
образом, имеются две точки, два мгновения в вычислительном процессе: когда мы
от взятия переходим к обработке и когда от обработки переходим к взятию. Мы
можем считать эти мгновения состояниями (но это не состояния объекта или
системы, это состояния нашего вычислительного процесса!). Сами по себе эти
состояния не важны — алгоритм определяется тем, в каком порядке посещаются
эти состояния и какие содержательные действия выполняются на переходах. В
результате мы получаем конечный автомат, приведенный на рис. 4.39. Все
действия выполняются на переходах, а простые состояния служат только для
определения смежности переходов. Их можно было бы никак не назвать, но
синтаксис UML требует наличия имен простых состояний, поэтому мы их просто
перенумеровали.
Рис. 4.39. Эквивалентный конечный автомат
Мы надеемся, что повторный просмотр рис. 4.33–4.39 даст читателю достаточно
пищи для размышлений и выработки собственного
113
отношения к машинам
состояний и диаграммам деятельности в UML.
4.3.3. Дорожки
В UML имеется своеобразное графическое средство, которое называется дорожкой.
Дорожка — это графический комментарий, позволяющий классифицировать по
некоторому признаку сущности на диаграмме деятельности.
Дорожка не является элементом модели — в метамодели UML нет такого
понятия.
114
Это именно графический комментарий, подобный границам системы на
диаграмме использования (разд. 2.2.2). Поэтому никаких формальных правил
применения дорожек нет.
113
Будь на то наша воля, мы бы предпочли видеть спецификацию поведения операции удаления
подразделения dpt примерно такой: ∀pos∈dpt(isFree(pos))→deleteDpt(dpt).
114
В последних версиях стандаратных метамоделей появилось.
Дорожки (или подобные им конструкции) часто применяются при моделировании
бизнес-процессов в организациях, откуда они и были заимствованы в UML.
Рассмотрим бизнес-процесс приема сотрудника на работу в нашей
информационной системе отдела кадров (см. разд. 3.3.2–3.3.3, рис. 3.11–3.14).
Обсуждая сценарий этого варианта использования, в главе 3 мы сосредоточили
свое внимание не на самом бизнес-процессе приема, а на участии моделируемой
системы в этом процессе. Давайте допустим, что нас интересует прохождение
всего процесса в целом, включая как те шаги, которые выполняются системой, так
и те шаги, которые (пока) предполагается выполнять вручную. Польза такого
описания очевидна: если мы будем знать необходимые в бизнес-процессе шаги, в
том числе выполняемые вручную, мы сможем составить более надежный план его
поэтапной автоматизации. Даже в самом простом случае приема на работу этапу
оформления документов предшествуют другие этапы: сбор информации о
кандидате, проверка и обработка этой информации, принятие решения и наконец
собственно прием или отказ в приеме. На рис. 4.40 представлена диаграмма
деятельности, отражающая простейший бизнес-процесс найма на работу. Мы
считаем, что наш процесс включает четыре деятельности:
• Interview — сбор информации;
• Approve — анализ собранной информации и принятие решения;
• Fill Forms — заполнение документов;
• Refuse — отказ в найме.
Рис. 4.40. Диаграмма деятельности процесса найма на работу
На диаграмме рис. 4.40 нет никаких дорожек — все деятельности равноправны и
однородны. Допустим теперь, что деятельность, в которую нанимаемый вовлечен
непосредственно (
Interview, Fill Forms, Refuse) происходит в одном месте и,
так сказать, у него на глазах, а важная деятельность (о которой нанимаемый может
не догадываться) по анализу информации и принятию решения осуществляется в
другом месте и, может быть, другими действующими лицами (техническими
специалистами, руководителями подразделений и т. д.). Эта важная информация не
является частью модели,
т. к. не имеет отношения к поведению системы, но мы
можем отразить ее на диаграмме с помощью дорожек (рис. 4.42). В данном случае
мы подразумеваем, что дорожка с названием HRDpt содержит деятельности,
выполняемые в приемной отдела кадров, а дорожка с названием SomeDpt содержит
деятельности, выполняемые в том подразделении, куда предполагается принять
кандидата.
Рис. 4.42. Дорожки
Графически дорожки изображаются в виде прямоугольников с названиями. Как
правило, их изображают со смыкающимися боковыми сторонами, хотя это и не
обязательно. Авторы UML утверждают, что изображение, подобное приведенному
на рис. 4.42, напоминает плавательные дорожки в бассейне, откуда и произошло
название данной графической конструкции. Возложим ответственность за
правомерность такой ассоциации на авторов UML и завершим этот несложный
раздел.
4.3.4. Траектория объекта
Диаграммы деятельности UML позволяют моделировать поведение не только
определяя поток управления, как в приведенных выше примерах, но и (до
некоторой степени) поток данных.
Поток управления и поток данных
В программе, написанной на обычном процедурном языке
программирования, порядок выполнения операторов (шагов алгоритма)
определяется порядком расположения операторов в тексте программы
и структурами управления. Фактически, обычная программа задает
поток управления (разд. 4.1.2). Но при выполнении шагов алгоритма
выполняются преобразования данных: переменные приобретают и
меняют своих значения. Последовательность изменения данных
называется потоком данных. Поток
управления (в детерминированной
программе) определяет и поток данных. Действительно, если,