Наткнулось на заметку 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) можно будет соединить стрелкой-потоком.

По стандарту прямоугольничек со скруглёнными углами, из которого выходит (или в который входит) стрелочка-поток мы не можем прочесть как Activity.
Втыкай в эту прямоугольную "картофелину" вилку, вытыкай назад, это никак на стандартное прочтение не повлияет. Потому что, по-любому, это узел действия, т. е. Action.
С вилкой Action становится узлом действия специального вида, у которого длинное название: узел действия вызова деятельности. Ну, т. е., действие состоит в том, что запускается некая Activity.

Запуски могут быть синхронными и асинхронными.
На этой диаграмме это как-то отражается какими-нибудь специальными символами?

Может ли на диаграмме деятельности присутствовать деятельность? Может, конечно.
Обычно, при этом она выгладит как прямоугольная со скруглёнными углами рамка, внутри которой находится всё содержимое диаграммы.
Если заморочиться, то можно нарисовать две такие "диаграммы в рамочках" рядом.
Потом можно захотеть их соединить. Стандарт запрещает это делать напрямую. Каждая деятельность сначала должна будет вырастить на своей границе объектный узел специального вида -- параметр. И вот эти выращенные параметры (output с input) можно будет соединить стрелкой-потоком.

Можете показать пример такого "соединения" деятельностей?
И можете пожалуйста объяснить, чем по поределению деятельность отличается от действия?

Запуски могут быть синхронными и асинхронными.
На этой диаграмме это как-то отражается какими-нибудь специальными символами?

Графических средств для этого почти нет. Можно приклеить уродливый коммент с явным выписыванием isSynchronous=true или isSynchronous=false.
"Почти нет", т. к. есть один финт.

На фрагменте а) видим узел действия вызова деятельности. И у этого узла видим выходящий пин. По стандарту узлу с isSynchronous=false запрещено иметь такие пины. Значит, этот узел с  isSynchronous=true.
 

Можете показать пример такого "соединения" деятельностей?

На практике такое вряд ли кто нарисует. Это всё равно, что две диаграммы вместе слитно нарисовать.

Берём иллюстрацию из стандарта. Рядом справа рисуем деятельность разбирающую компы обратно на части. Заводим ей входной параметр Assembled Comps. Соединяем стрелкой-потоком один из выходных параметров первой деятельности со входным параметров второй.

И можете пожалуйста объяснить, чем по определению деятельность отличается от действия?

Деятельность -- это конструкция из кирпичиков, каждый из которых атомарен (элементарен, не раскладывается на части). Кирпичики принято называть узлами. Один из видов узлов -- узлы действия. Т. е. деятельность собирается из действий. А действие ни из чего не собирается. Оно целёхонькое и прочное -- его на куски не расколотить.

На практике такое вряд ли кто нарисует. Это всё равно, что две диаграммы вместе слитно нарисовать.
Берём иллюстрацию из стандарта. Рядом справа рисуем деятельность разбирающую компы обратно на части. Заводим ей входной параметр Assembled Comps. Соединяем стрелкой-потоком один из выходных параметров первой деятельности со входным параметров второй.

Деятельность -- это конструкция из кирпичиков, каждый из которых атомарен (элементарен, не раскладывается на части). Кирпичики принято называть узлами.
Один из видов узлов -- узлы действия. Т. е. деятельность собирается из действий. А действие ни из чего не собирается. Оно целёхонькое и прочное -- его на куски не расколотить.

Понятно, спасибо за разъяснения.

Графических средств для этого почти нет. Можно приклеить уродливый коммент с явным выписыванием isSynchronous=true или isSynchronous=false.
"Почти нет", т. к. есть один финт.
На фрагменте а) видим узел действия вызова деятельности. И у этого узла видим выходящий пин. По стандарту узлу с isSynchronous=false запрещено иметь такие пины. Значит, этот узел с  isSynchronous=true.

Но если у узла нету пина, то остается неопределенным, чему равен признак isSynchronous этого узла.


А вообще, есть какие-нибудь средства (нотации) моделирования, которые позволяют графически наглядно показать асинхронные вызовы?

Но если у узла нету пина, то остается неопределенным, чему равен признак isSynchronous этого узла.


А вообще, есть какие-нибудь средства (нотации) моделирования, которые позволяют графически наглядно показать асинхронные вызовы?

Приплету, что по стандарту дефолтное значение isSynchronous = true. Из экономии мы можем полагать, что диаграмма без явных указаний чего-либо про isSynchronous означает, что значение дефолтное. Тогда неопределённое значение нашим усилием приравнивается к дефолтному.
Стандарт не содержит примеров явного указания isSynchronous. Поэтому кочку опоры придётся придумать самим. Например, известно, что класс, которому отказано в праве на переопределение в потомке метится isLeaf=true. Известно, что стандарт не даёт примера конкретного синтаксиса. Поэтому народ рисует так:

Вот и мы можем писать что-то вроде {asynchronous}.
Тут надо заметить, что тот же  isLeaf=true для State стандарт позволяет рисовать кейвордом {final} после называния состояния. Это чтобы с final state-ом перепутывать что ли?
В сторону можно заметить, что несчастный класс должен помимо  isLeaf ещё размечаться isFinalSpecialization. То есть почва зыбкая, даже авторы стандарта "плывут".

И надо запастись поп-корном и сесть ждать когда наконец будет нормальное описание не только абстрактного синтаксиса UML, но и конкретного синтаксиса тоже.

И надо запастись поп-корном и сесть ждать когда наконец будет нормальное описание не только абстрактного синтаксиса UML, но и конкретного синтаксиса тоже.

Охохо, будет ли.

Подсказали, когда уместно нарисовать деятельность на диаграмме деятельности.
Если в описываемой диаграммой деятельности есть кусок, для моделирования которого прибегаем к рекурсии, то этот самый кусок можно изобразить как деятельность. И внутри этой деятельности будут узлы действия, из которых хотя бы 1 -- узел действия вызова деятельности, той самой которая изображает кусок.