Подскажите, пожалуйста, нужно ли здесь использовать Merge перед узлом финала деятельности.
Смотрела много источников, книги - некоторые используют, другие нет.
В чем отличие, если не использовать.
Спасибо! 

Почитайте М Фаулера -> UML Основы, 3 издание  - > Диаграммы деятельности
Если сами не найдете, то могу дать почитать.

Я, конечно, хотела бы услышать конкретный ответ
У меня есть, например, есть книга " УМЛ2  и унифицированный процесс" .Д. Арлоу, 2 изд.
Там , например, на рис 14.14 используется (пункт 14.8.2) merge после узла "решение" .-Пример  этот аналогичен моему с квад. уровнением.
А Шмулер (Освой самостоятельно УМЛ) в аналогичных случаях не использует.

1.
Fork показывает в какой момент поток(flow) разделяется на несколько потоков, которые выполняться одновременно.
Join используется для того, чтобы показать, в каком месте n одновременных потоков сливаются в один.
Хотя спецификация говорит только о "multiple concurrent flows", я бы добавил, что они ещё и независимы.
По крайней мере, мне с трудом видится ситуация, при которой, после fork два потока имеют общий decision/merge.

2.
Decision показывает место и условие, при котором поток(flow) может пойти по основному или альтернативному пути (path).
Merge показывает в каком месте несколько путей потока сливаются в одни.

Иными словами join/fork используется для потоков (flow), а decision/merge для путей потока (path)
Имеет ли значение используете ли вы merge или нет, если всё сходится в activity-final ?


FIG4a.png мне нравится больше, чем FIG4.png, хотя я оба варианта прочитаю с одинаковым успехом.
Capture.PNG - я бы прочитал, что там два одновременных flow. Но что-то мне подсказывает, что это не два одновременных flow ...
На Capture.PNG я бы использовал join, только если там действительно имеет место fork.

Почитайте М Фаулера -> UML Основы, 3 издание  - > Диаграммы деятельности

Спасибо за ответ. (Хотя и знаю значения этих символов). Я хотела бы понять, есть ли отличие в использование этого Merge на диаграммах (FIG4  и FIG4a). А рисунок Capture взят с http://www.omg.org/spec/UML/2.5/б Figure 15.43. Там написано, что возникают "гонки" 2х потоков. А почему нельзя соединить все дуги с финалом напрямую?

о_О
До меня таки дошло что происходит на Capture.PNG
Действительно Join там совсем не нужен.
Если бы я показал своим разрабам Capture.PNG,
то не был бы уверен, что без письменного комментария они поймут это правильно.

На счет использования merge  в FIG4a.png и FIG4.png
Даже если спецификацией определено, что не/использование merge в нашем случае значительно меняет суть дела, то я с трудом верю, что среднестатистический заказчик/разработчик/тестер/другой аналитик с легкостью это заметит.
Это действительно может иметь значение, если вы симулируете эту activity в каком-нибудь ЕА. Иными словами, такие тонкости имеют значение, если вы используете UML как язык программирования.

 

Спасибо за ответ. Вот меня как раз и интересует, как (не)использование этого merge повлияет на программный код. Возьмем , скажем, простые примеры на FIG4 и  FIG4a. В обоих же случаях  будем использовать IF-THEN-ELSE!

Вот еще пример с (не)использованием merge и final.

Когда в разных учебниках написано по-разному - я стараюсь найти и прочитать первоисточник.
В данном случае найти его не сложно. Это стандарт OMG http://www.omg.org/spec/UML/2.4.1/

Страница 400, рисунок 12.106

In the example below, either one or both of the behaviors, Buy Item or Make Item could have been invoked. As each
completes, control is passed to Ship Item. That is, if only one of Buy Item or Make Item completes, then Ship Item is
invoked only once; if both complete, Ship Item is invoked twice.

Промежуточный вывод.

Развилка Decision / Merge разбивает поток на 2 независимых пути.
Схождение на Merge не ожидает поступления всех разведенных потоков (в отличии от Join, который ждёт или всех потоков данных или части данных + команды от потока управления), а пропускает дальше первого добежавшего.
Таким образом, в Вашем примере с выходом без Merge на Final формальных ошибок нет. В любом случае после Decision вида (IF/ELSE ) гарантированно останется жить только один из потоков. Второго ждать не надо.

Однако.

Ваш вопрос - о программной реализации. И здесь о чем поговорить.
1. Как аналитик программиста, Вы фактически заставили меня использовать явный или неявный GOTO. Вы вышибли меня из основного потока программы в две процедуры обработки IF/ELSE и не сказали где вернуться обратно в основной поток, заказав сразу идти на выход, причем на ОДИН. Значит если писать код добуквенно - я буду ВЫНУЖДЕН встроить выход в один из потоков, а из второго прыгать на него прямым переходом, явным или неявным (за второе хоть не засмеют). Для простенькой программы, где в параллельных потоках выполняется по 1 действию - это не критично. Но такая радость бывает только на контрольной по информатике в 6 классе. Для и получить за такую контрольную можно только "3".
2. Вы не дали мне как программисту сообщить Вам (или пользователю, или тестировщику ... ) причину выхода. В общем это не совсем комильфо. Если Вы навсегда развели потоки - дайте им отдельные выходы. Это позволит встроить в процедуру завершения программы сообщение, лог или что-то ещё.

Уже вывод.
Правило хорошего тона. Порвал потоки на логическом "или" - сведи их обратно на том же "или", или заверши раздельно.

PS
Использование Правил хорошего тона в реальной жизни обязательным не является.

ПППС

Давайте напишу на свободном языке программный код по Вашей схеме

Начать
Инициировать условие
ЕСЛИ условие ВЫПОЛНЕНО
  Делать раз
  Поставить метку 1
  завершить процесс
ИНАЧЕ
  Делать два
  Перейти на метку 1


...
На этом всё.
По Вашей схеме - выхода из IF/ELSE нет. Выход из программы - в одной из веток

Спасибо за ответ. Но, например, Capture.jpg взят именно из документации http://www.omg.org/spec/UML/2.5/
стр.392 , рис. 15-43. Если после вершины merge стояла бы вершина "вывести лог" , то использование merge  для меня понятно.  А так почему нельзя сразу все вывести на final и завершить деятельность?  Ведь все условия desicion узлов- взаимо исключающие!

Хороший пример ведь ) Вы просто в его суть не вникли.

Переведите хотя бы это:
illustrating two concurrent flows racing to complete
А лучше - весь абзац.

А потом вернитесь к написанному мной.
После прохода развилки FORK жизнь идет в ОБОИХ потоках. И не важно, что в одном из них есть целая пачка DECISION/MERGE - важно, что все они сводятся и идут к финишу одним потоком - тем же самым, который родился на FORK.
Почему нет JOIN - потому что это логическое "И" или "И по условию".
Если поставить JOIN перед финишем - тот, кто придет раньше, будет вынужден ДОЖДАТЬСЯ второго, после чего ВМЕСТЕ идти к финишу.

Здесь же выживет только один. Второй должен быть убит на том месте, где его застигнет финиш первого.

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

А вот с этим:

Иными словами join/fork используется для потоков (flow), а decision/merge для путей потока (path)

Не согласен ) Термин "path" применяется в нотации для других целей.

Спасибо за ответ. Как я понимаю, выход на моем FIG. 4  без merge - это как выход из ветвей  IF-THEN_ELSE по return. В принципе, с(без) merge поведение здесь одинаково.
Что касается рисунка из документации я понимаю, что там 2 параллельных потока,  и деятельность заканчивается, когда один закончится (про join вопроса не было ). Вопрос в том, может ли  существовать эта схема без  merge. Ведь final все-равно заканчивает всю деятельность.  Как я понимаю., можно поставить и на каждую из ветвей по своему activity final.

Вопрос в том, может ли  существовать эта схема без  merge. Ведь final все-равно заканчивает всю деятельность.  Как я понимаю., можно поставить и на каждую из ветвей по своему activity final.

Я уже ответил Вам. Может. С точки зрения нотации ошибки нет.
Ни в одном из рассмотренных нами вариантов.

Вот пожалуйста скрин в скрепке - все они валидируются без ошибок.

Вопрос именно в хорошем или плохом стиле моделирования

Спасибо за ответ. Скажите, пожалуйста, какой именно программой Вы воспользовались?