Общий раздел > UML SysML и пр.
UML Best Practice: "На диаграммах деятельности не рисуйте деятельности"
[прилетело НЛО и...]:
Наткнулось на заметку Geert Bellekens "UML Best Practice: There are no Activities on an Activity Diagram"
Подумало, как клёво, что в 2012-м людям в Бельгии всё уже было ясно.
Стало смотреть диаграммы [глазом из нынешнего 2021го]. Ротовые щупальца встали дыбом.
Чел из Бельгии рисует такое и пишет, что одноимённые узлы (он называет их "деятельностями") это ужас-ужас.
Но потом избавляет нас от ужаса, делая их узлами действия вызова одной и той же деятельности:
Ну, вот, щупальца улеглись, можно продолжать разговор.
По стандарту прямоугольничек со скруглёнными углами, из которого выходит (или в который входит) стрелочка-поток мы не можем прочесть как Activity. Втыкай в эту прямоугольную "картофелину" вилку, вытыкай назад, это никак на стандартное прочтение не повлияет. Потому что, по-любому, это узел действия, т. е. Action. С вилкой Action становится узлом действия специального вида, у которого длинное название: узел действия вызова деятельности. Ну, т. е., действие состоит в том, что запускается некая Activity.
Воткнув вилки и добавив двоеточия бельгиец не избавился от дублирования (глазом это видно). Два раза нарисовано одно и то же. Изменилось лишь одно. Без вилок это были два OpaqueAction или два CallBehaviourAction, что говорило нам о невыразимости средствами UMLя сути хреновины по имени "Process Payment". С вилками мы утверждаем, что кто-то может нарисовать отдельную диаграмму деятельности, где будут видны внутренности "Process Payment".
Может ли на диаграмме деятельности присутствовать деятельность? Может, конечно. Обычно, при этом она выгладит как прямоугольная со скруглёнными углами рамка, внутри которой находится всё содержимое диаграммы. Если заморочиться, то можно нарисовать две такие "диаграммы в рамочках" рядом. Потом можно захотеть их соединить. Стандарт запрещает это делать напрямую. Каждая деятельность сначала должна будет вырастить на своей границе объектный узел специального вида -- параметр. И вот эти выращенные параметры (output с input) можно будет соединить стрелкой-потоком.
Сергей():
--- Цитата: [прилетело НЛО и...] от 08 Июля 2021, 02:19:20 ---По стандарту прямоугольничек со скруглёнными углами, из которого выходит (или в который входит) стрелочка-поток мы не можем прочесть как Activity.
Втыкай в эту прямоугольную "картофелину" вилку, вытыкай назад, это никак на стандартное прочтение не повлияет. Потому что, по-любому, это узел действия, т. е. Action.
С вилкой Action становится узлом действия специального вида, у которого длинное название: узел действия вызова деятельности. Ну, т. е., действие состоит в том, что запускается некая Activity.
--- Конец цитаты ---
Запуски могут быть синхронными и асинхронными.
На этой диаграмме это как-то отражается какими-нибудь специальными символами?
--- Цитата: [прилетело НЛО и...] от 08 Июля 2021, 02:19:20 ---Может ли на диаграмме деятельности присутствовать деятельность? Может, конечно.
Обычно, при этом она выгладит как прямоугольная со скруглёнными углами рамка, внутри которой находится всё содержимое диаграммы.
Если заморочиться, то можно нарисовать две такие "диаграммы в рамочках" рядом.
Потом можно захотеть их соединить. Стандарт запрещает это делать напрямую. Каждая деятельность сначала должна будет вырастить на своей границе объектный узел специального вида -- параметр. И вот эти выращенные параметры (output с input) можно будет соединить стрелкой-потоком.
--- Конец цитаты ---
Можете показать пример такого "соединения" деятельностей?
И можете пожалуйста объяснить, чем по поределению деятельность отличается от действия?
[прилетело НЛО и...]:
--- Цитата: Сергей() от 18 Июля 2021, 11:32:29 ---Запуски могут быть синхронными и асинхронными.
На этой диаграмме это как-то отражается какими-нибудь специальными символами?
--- Конец цитаты ---
Графических средств для этого почти нет. Можно приклеить уродливый коммент с явным выписыванием isSynchronous=true или isSynchronous=false.
"Почти нет", т. к. есть один финт.
На фрагменте а) видим узел действия вызова деятельности. И у этого узла видим выходящий пин. По стандарту узлу с isSynchronous=false запрещено иметь такие пины. Значит, этот узел с isSynchronous=true.
--- Цитата: Сергей() от 18 Июля 2021, 11:32:29 ---Можете показать пример такого "соединения" деятельностей?
--- Конец цитаты ---
На практике такое вряд ли кто нарисует. Это всё равно, что две диаграммы вместе слитно нарисовать.
Берём иллюстрацию из стандарта. Рядом справа рисуем деятельность разбирающую компы обратно на части. Заводим ей входной параметр Assembled Comps. Соединяем стрелкой-потоком один из выходных параметров первой деятельности со входным параметров второй.
--- Цитата: Сергей() от 18 Июля 2021, 11:32:29 ---И можете пожалуйста объяснить, чем по определению деятельность отличается от действия?
--- Конец цитаты ---
Деятельность -- это конструкция из кирпичиков, каждый из которых атомарен (элементарен, не раскладывается на части). Кирпичики принято называть узлами. Один из видов узлов -- узлы действия. Т. е. деятельность собирается из действий. А действие ни из чего не собирается. Оно целёхонькое и прочное -- его на куски не расколотить.
Сергей():
--- Цитата: [прилетело НЛО и...] от 19 Июля 2021, 04:25:01 ---На практике такое вряд ли кто нарисует. Это всё равно, что две диаграммы вместе слитно нарисовать.
Берём иллюстрацию из стандарта. Рядом справа рисуем деятельность разбирающую компы обратно на части. Заводим ей входной параметр Assembled Comps. Соединяем стрелкой-потоком один из выходных параметров первой деятельности со входным параметров второй.
--- Конец цитаты ---
--- Цитата: [прилетело НЛО и...] от 19 Июля 2021, 04:25:01 ---Деятельность -- это конструкция из кирпичиков, каждый из которых атомарен (элементарен, не раскладывается на части). Кирпичики принято называть узлами.
Один из видов узлов -- узлы действия. Т. е. деятельность собирается из действий. А действие ни из чего не собирается. Оно целёхонькое и прочное -- его на куски не расколотить.
--- Конец цитаты ---
Понятно, спасибо за разъяснения.
--- Цитата: [прилетело НЛО и...] от 19 Июля 2021, 04:25:01 ---Графических средств для этого почти нет. Можно приклеить уродливый коммент с явным выписыванием isSynchronous=true или isSynchronous=false.
"Почти нет", т. к. есть один финт.
На фрагменте а) видим узел действия вызова деятельности. И у этого узла видим выходящий пин. По стандарту узлу с isSynchronous=false запрещено иметь такие пины. Значит, этот узел с isSynchronous=true.
--- Конец цитаты ---
Но если у узла нету пина, то остается неопределенным, чему равен признак isSynchronous этого узла.
:(
А вообще, есть какие-нибудь средства (нотации) моделирования, которые позволяют графически наглядно показать асинхронные вызовы?
[прилетело НЛО и...]:
--- Цитата: Сергей() от 19 Июля 2021, 05:15:30 ---Но если у узла нету пина, то остается неопределенным, чему равен признак isSynchronous этого узла.
:(
А вообще, есть какие-нибудь средства (нотации) моделирования, которые позволяют графически наглядно показать асинхронные вызовы?
--- Конец цитаты ---
Приплету, что по стандарту дефолтное значение isSynchronous = true. Из экономии мы можем полагать, что диаграмма без явных указаний чего-либо про isSynchronous означает, что значение дефолтное. Тогда неопределённое значение нашим усилием приравнивается к дефолтному.
Стандарт не содержит примеров явного указания isSynchronous. Поэтому кочку опоры придётся придумать самим. Например, известно, что класс, которому отказано в праве на переопределение в потомке метится isLeaf=true. Известно, что стандарт не даёт примера конкретного синтаксиса. Поэтому народ рисует так:
Вот и мы можем писать что-то вроде {asynchronous}.
Тут надо заметить, что тот же isLeaf=true для State стандарт позволяет рисовать кейвордом {final} после называния состояния. Это чтобы с final state-ом перепутывать что ли?
В сторону можно заметить, что несчастный класс должен помимо isLeaf ещё размечаться isFinalSpecialization. То есть почва зыбкая, даже авторы стандарта "плывут".
И надо запастись поп-корном и сесть ждать когда наконец будет нормальное описание не только абстрактного синтаксиса UML, но и конкретного синтаксиса тоже.
Навигация
Перейти к полной версии