Вопрос собственно вот в чем. По спецификации узлы управления конкурируют за объект, т.е. если объект соединен с двумя узлами управления то только один из них получит объект. А как показать на схеме что объект должны получить сразу оба узла управления.
Ну то-есть в коде это выглядело бы так:
Action1(object)
{
Action11(object)
Action12(object)
}

Так точно также, через синхронизацию или просто разветвление потока. Изобразить причем можно по-разному, например с использованием портов

Так точно также, через синхронизацию или просто разветвление потока. Изобразить причем можно по-разному, например с использованием портов

"Ты не мудри, ты пальцем покажи...", - из очень "бородатого" анекдота 

"Ты не мудри, ты пальцем покажи...", - из очень "бородатого" анекдота 

Мне кажется, начать лучше Вам Попробуйте нарисовать кусочек того, что нужно, а я и, возможно, другие поможем разобраться.

Так точно также, через синхронизацию или просто разветвление потока. Изобразить причем можно по-разному, например с использованием портов

Поясните плиз что вы имеете в виду под синхронизацией и разветвлением. Если fork и decision соответственно, то fork подразумевает параллелизм, а его здесь нету, а decision подразумевает выбор только одной ветки.

Пока, то что нашел это использование стереотипа <<datastore>> который как раз подразумевает дублирование маркера на все выходы.

Мне не понятны Ваши проблемы. Передать смысл можно по-разному. Что Вы хотите? Нарисуйте, проще будет обсуждать ваши задачи.
Конечно, decision node тут не причем, просто две стрелки от активити = использованию fork (в определенной степени)

Тоже быльём поросло, но я как НЛО могу встрять. Своё встревание предваряю замечанием, что, на мой взгляд, часть стандарта UML, описывающая объектные потоки в моделях деятельности, очень перемудрённая .

По стандарту fork подразумевает параллелизм, в том смысле, что он может его реализовать. Но параллелизм [после fork] возникает не во всех случаях. Если fork для объектных потоков, это значит, что любой входящий объектный токен копируется на каждый исходящий объектный поток. Если их готовы принять узлы, куда ведут потоки, то они [параллельно] проходят дальше. Если не готовы, то они стоят и ждут, когда их примут.

Datastore по стандарту не занимается рассылкой копий объектных токенов как таковой. Datastore сохраняет в себе копии всего того, что в него пришло (в единственном экземпляре). И за счёт этого "размноженный объектный токен" может пройти по разным исходящим потокам. 

P. S. Два объектных потока, исходящих из деятельности, предполагают, что у неё есть два выходных параметра (объектных узла), и из каждого такого узла, в общем случае, выйдут разные объектные токены. То есть, для объектных потоков такая конструкция не аналогична fork, как в случае потоков управления. Придётся либо помещать "объектный fork" явно вне деятельности, либо моделировать размножение внутри деятельности с явным указанием двух или более однотипных out-параметров, через которые будут выходить копии токенов.

"Ты не мудри, ты пальцем покажи...", - из очень "бородатого" анекдота 

Пример диаграммы, в которой один объектный курсор форкается и передаётся двум принимающим узлам, дан во вложении к этому сообщению.