Предположим, существует некий бизнес-процесс, запускающийся по рабочим дням в 16:00 ("забрать документы из офиса A, привезти в офис B и пустить в обработку").
Этот процесс нужно отобразить на activity-диаграмме "регистрация клиента". Т.е. клиент приходит в офис "А" (в любое время), заполняет там документы, потом ждёт результата их обработки, после 16:00 (уже вне офиса).
Как отобразить запуск бизнес-процесса в 16:00?
Учитывая, что он существует независимо от прихода/неприхода клиента в офис A, неправильно, ИМХО, рисовать вход в сигнал "16:00" от форка от initial.
Второй initial, похоже, тоже рисовать неверно.
Подскажите, pls

Было бы проще использовать для этого нотацию BPMN, но в вашем случае можно передать разными способами, явно через decision node или guard condition на переходе, или использовать event action http://www.uml-diagrams.org/activity-diagrams-actions.html

По сути у Вас два независимых процесса - заполнение документов клиентом в офисе А и обработка их в офисе B. Каждый из этих процессов имеет свое инициирующее событие (приход клиента в первом и 16:00 во втором), количество экземпляров первого процесса будет соответствовать количеству клиентов, во втором он строго раз в день. Все что эти процессы связывает - накопленные до 16:00 документы.

Какова цель отобразить оба процесса на одной диаграмме?

Цели две:

• Проанализировать процесс, ничего не упустив
• Наглядно показать бизнесу, что происходит с документами. И при этом не хочется нарушать нотацию.

Galogen, я не очень понимаю, как тут поможет decision, если decision (без форков) подразумевает последовательное выполнение.

В моем же случае есть параллельная ветка исполнения, инициируемая по некоему сигналу ("будильник").

Цели две:

• Проанализировать процесс, ничего не упустив
• Наглядно показать бизнесу, что происходит с документами. И при этом не хочется нарушать нотацию.

С такими целями лучше использовать Bpmn. Там для описания межпроцессных взаимодействий есть все - и оркестровки, и хореографии.

Если критична диаграмма активности,  можно попробовать в качестве инициирующего события взять начало рабочего дня,  оформление документов описать как loop по клиентам, с прерыванием в 16:00 на пересылку документов и на конец рабочего дня.

Ну или описать оркестровку в стиле bpmn - два процесса,  каждый со своим инициирующим и финальным событием,с непересекающимися потоками управления и  object flow через хранилище  документов

Нашел пример с независимыми потоками управления
http://dit.isuct.ru/ivt/books/CASE/case11/ch19.htm
Рисунок 19.9

Один поток по отгрузке товара, второй по взаиморасчетам.

Еще пример по накоплению объектов в datastorage

http://it-gost.ru/articles/view_articles/96

Рисунок 19.9 из книжки про старый UML и на нём недостаёт одной стрелки, а другая нарисована сплошной вместо пунктирной.
Примеры по второй ссылке также не удачны (ЦБ с одним входным потоком и одним выходным; отсутствие select-а на потоке, идущем из datastore в "Обработать заказ").

Рисунок 19.9 из книжки про старый UML и на нём недостаёт одной стрелки, а другая нарисована сплошной вместо пунктирной.
Примеры по второй ссылке также не удачны (ЦБ с одним входным потоком и одним выходным; отсутствие select-а на потоке, идущем из datastore в "Обработать заказ").

А правильные то примеры с двумя асинхронными процессами встречаются? С удовольствием бы глянул. А то я похоже выразительные возможности диаграммы активности недооценивал

А правильные то примеры с двумя асинхронными процессами встречаются? С удовольствием бы глянул. А то я похоже выразительные возможности диаграммы активности недооценивал

Конечно, проще искать ошибки, чем предложить что-то конструктивное. Если уточните, что нужно, попробую представить. В каком-то смысле, для асинхронных процессов достаточно диаграммы с форком.

Конечно, проще искать ошибки, чем предложить что-то конструктивное. Если уточните, что нужно, попробую представить. В каком-то смысле, для асинхронных процессов достаточно диаграммы с форком.

Во вложении набросал  пример процесса в bpmn с паттерном "Папочки" (участники процесса взаимодействуют, помещая и забирая документы из соответствующих папочек) и попробовал построить  эквивалентную ДА.

Смущает то, что в BPMN есть конструкция pool - процесс или  внешняя сущность. В UML такой конструкции нет, поэтому непонятно  насколько корректна такая ДА

1) Три потока , у каждого свое инициирующее событие и свой финал потока. Общего финального события нет.
2) Поскольку токены по каждому потоку гуляют  независимо нет необходимости описывать циклы

... непонятно  насколько корректна такая ДА

С точки зрения стандарта UML 2.5, если каждый из 3 процессов стартует из своего начального узла (initial node), то в рамках моделируемой деятельности "процесс клиента", "процесс перемещения" и "процесс обработки" отработает по одному разу. Т. е., скорее всего, в "процессе клиента" должен быть цикл, иначе в течение выполнения всей большой деятельности клиент будет лишь один (не более одного) и datastore не понадобится для его единственной заявки. 

С точки зрения стандарта UML 2.5, если каждый из 3 процессов стартует из своего начального узла (initial node), то в рамках моделируемой деятельности "процесс клиента", "процесс перемещения" и "процесс обработки" отработает по одному разу. Т. е., скорее всего, в "процессе клиента" должен быть цикл, иначе в течение выполнения всей большой деятельности клиент будет лишь один (не более одного) и datastore не понадобится для его единственной заявки.

Эх. Если нужен цикл, значит нужно придумывать, когда его начинать, а когда заканчивать. В случае с bpmn об этом можно не думать - событие прихода клиента поступает извне, а заявка начинает обрабатываться в соответствии с работой некоторого планировщика ( он в этом описании неважен, а потому и не отражен).

Если определить за initial node по процессам приема и обработки заявок начало рабочего дня, то надо будет думать как отражать незавершенное производство - заявки,  принятые после 16:00 в первом процессе,  и необработанные на начало дня заявки в третьем. А это диаграмму перегрузит.  То есть такую ДА хорошо бы дополнить диаграммой последовательности или диаграммой состояний, чтобы понять процесс в разрезе заявки.

То есть заменяем одну диаграмму bpmn двумя uml

Эх. Если нужен цикл, значит нужно придумывать, когда его начинать, а когда заканчивать.

А если посмотреть в сторону паттернов сети Петри, вернее оценочных сетей Петри. Ведь ДА в uml 2.0 в основе имеет сеть Петри с позициями вершинами и позициями переходами с разметкой. Разметка - это заявка (нашей СМО) следовательно нужно сделать:
- генератор заявок
- движение заявки по логике процесса
- аккумулятор заявок (под заявками считать метки)

Если не ошибаюсь паттерны для СМО через сети ПЕтри есть тут http://smart-torrent.org/sapr-programmi/gultyaev-vizualnoe-modelirovanie-srede-matlab-t81138.html

А если посмотреть в сторону паттернов сети Петри, вернее оценочных сетей Петри. Ведь ДА в uml 2.0 в основе имеет сеть Петри с позициями вершинами и позициями переходами с разметкой. Разметка - это заявка (нашей СМО) следовательно нужно сделать:
- генератор заявок
- движение заявки по логике процесса
- аккумулятор заявок (под заявками считать метки)

Если не ошибаюсь паттерны для СМО через сети ПЕтри есть тут http://smart-torrent.org/sapr-programmi/gultyaev-vizualnoe-modelirovanie-srede-matlab-t81138.html

Спасибо за подсказку. Покопался еще и нашел шаблон прямо в uml (во вложении)

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

Все таки в  bpmn шаблоны СМО присутствуют в коробке, и в том же bizagi если процесс построен правильно, иммитационную модель можно сразу же запустить.