Нужно ли соединять разветвленные узлы? Диаграмма состояния UML

Question

Нужно ли в конце соединять разветвленные узлы? И могут ли исходящие узлы-вилки иметь охрану?

По сути, я пытаюсь вернуть клиенту изменения и одновременно продолжить машину wa sh.

Но , может быть, есть лучший способ сделать это?

Answer 1

Нужно ли в конце соединять разветвленные узлы?

Это зависит. Если вы хотите продолжить ваш разделенный поток, тогда да. Если вы не присоединяетесь к ним, у вас просто два свободных конца, продолжающиеся независимо, пока каждый из них не завершит тот или иной путь.

И могут ли у исходящих узлов разветвления быть защитники?

П. 360 состояний UML 2.5

• fork_segment_guards

Сегмент вилки не должен иметь охранников или триггеров.

inv: (source.oclIsKindOf(Pseudostate) and source.oclAsType(Pseudostate).kind = PseudostateKind::fork) implies (guard = null and trigger->isEmpty())

(я ошибся и исправил это после того, как bruno заметил меня об этом.)

может быть, есть лучший способ сделать это?

Конечно. Есть много способов описать вещи. Но за исключением лишнего охранника, который вроде бы в порядке.

Answer 2

Нужно ли в конце соединять разветвленные узлы?

Для меня нет, это не обязательно, но группа закончится, когда все потоки и связанные элементы закончатся тоже

могут ли исходящие узлы-форки иметь охрану?

Вы имеете в виду исходящие потоки , норма гласит: сегмент вилки не должен иметь охранников или триггер

По сути, я пытаюсь вернуть клиенту изменения и одновременно продолжить машину wa sh.

Да, они могут выполняться параллельно, с точки зрения машины wa sh все делается, когда она возвращает изменение, и операция wa sh тоже выполняется

Answer 3

Короче говоря

Это не написано черным по белому, но если вы раскошелиться, у вас будут некоторые ограничения, которые рано или поздно потребуют от вас присоединиться на практике. Существует только одна допустимая конструкция, которая позволяет вам избежать объединения на практике.

Более подробно

Это косвенное следствие параллельного потока токенов и правил его завершения.

В соответствии со спецификациями UML 2.5, финал потока имеет следующее поведение:

FlowFinalNode - это FinalNode, который завершает поток. Все токены, принятые FlowFinalNode, уничтожаются. Это не влияет на другие потоки в Деятельности.

Вы можете использовать его для поглощения токенов в одном из параллельных потоков, без влияния на другие ветви.

Аналогично, финал действия подчиняется следующему принципу:

ActivityFinalNode - это FinalNode, который останавливает все потоки в Activity. Токен, достигший ActivityFinalNode, принадлежащий Activity, прекращает выполнение этой Activity.

Но не существует правила, определяющего скорость каждого потока или то, что каждый поток будет выполнять все ожидаемые действия, если у вас нет соединения. Это проблема отсутствующей синхронизации.

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

Если у действия есть более одного ActivityFinalNode, то первый, принявший токен (если есть), завершает выполнение действия, включая выполнение любых других ActivityFinalNodes ,

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

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

Если один из циклов потока у вас есть проблема умножения токенов du на параллельные потоки, которые повторно вводятся в схему (которые соответствуют параллельному выполнению).

Единственный способ избежать узла соединения - использовать неявное соединение:

ExecutableNode не должен выполняться, пока все входящие ControlFlow (если они есть) не предлагают токены. То есть существует неявное соединение для входящих потоков управления. Определенные c виды ExecutableNodes могут иметь дополнительные предварительные условия, которые должны быть выполнены, прежде чем узел сможет работать.

Но неявное или явное, это соединение ;-)