Merge node missing?

[Ignacio G. T.]

I have always thought that, when you have a branch (decision node) in an activity diagram, and the flows reunite in a future action, you must use a merge node before that future action. Otherwise, that future action will wait (by default) for a token on each of the arriving edges, an event that will never happen. In other words, two edges arriving at one action are equivalent to an implicit join, not an implicit merge.

But in the "Activity Pattern" named "Basic Activity" provided in EA 9.3, you can find this very error! Who is mistaken, me or "EA 9.3"?

You can see the same (presumed) error in http://commons.wikimedia.org/wiki/File:Activity_Diagram_1.jpg (in "Attivita 5") or in http://upload.wikimedia.org/wikipedia/commons/e/e7/Activity_conducting.svg (in "Explain problem").

[qwerty]

If you're talking of tokens in the sense of Petri diagrams this applies to state machines (I'd say).

In activity diagram a decision routes a control flow. You can either route that later into a merge or just into an action/activity. If you use a fork that means that two control flows are acting in parallel. In that case you should use a join (which looks exactly like a fork) to indicate that the further control can only commence upon arrival of both control flows.

Finally, it's upon your reader whether your diagram is understandable...

q.

[Geert Bellekens]

I don't think there's such a requirement for decisions because the token will follow only one of the outgoing flows.
So with or without merge node I don't see any ambiguity.

Geert

[Ignacio G. T.]

I agree that, normally, there is no real ambiguity if you look at the whole diagram, but if you focus only in the area containing the 'future' action (which may be far away from the decision node) you can make wrong interpretations, especially if there are several decision, merge, join, and fork nodes around.

I am more concerned here with (syntax) correctness. I have dared downloading and reading the standard  , and I've found the following (in formal/11-08-06_supra):

12.3.2 Action
[...]
An action may have sets of incoming and outgoing activity edges that specify control flow and data flow from and to other nodes. An action will not begin execution until all of its input conditions are satisfied. The completion of the execution of an action may enable the execution of a set of successor nodes and actions that take their inputs from the outputs of the action.
[...]
Except where noted, an action can only begin execution when it has been offered control tokens on all incoming control flows and all its input pins have been offered object tokens sufficient for their multiplicity.
[...]
An action execution is created when all its object flow and control flow prerequisites have been satisfied (implicit join). Exceptions to this are listed below.
[...]
See ValuePin and Parameter for exceptions to rule for starting action execution.
[...]
12.3.50 ValuePin
[...]
ValuePins provide values to their actions, but only when the actions are otherwise enabled. If an action has no incoming edges or other way to start execution, a value pin will not start the execution by itself or collect tokens waiting for execution to start. When the action is enabled by other means, the value specification of the value pin is evaluated and the result provided as input to the action, which begins execution. This is an exception to the normal token flow semantics of activities.
[...]
12.3.41 Parameter
[...]
All required non-stream inputs must arrive for the behavior to be invoked. If there are only required stream inputs, then at least one must arrive for the behavior to be invoked.

If I have interpreted the standard correctly, the exceptions do not apply to the general cases I have presented. So, I think that the "Basic activity" pattern in EA 9.3 has an error.

[qwerty]

I guess you must not count too much on this "standard". Although quite a number of egg-heads have been working on it, they are all human. Somewhere in the net I once found a site which showed quite a large number of ambiguities, errors and information holes inside Superstructures (can't recall the address right now).

As I said before: what counts is the fact that the reader understands your message.

q.

[Geert Bellekens]

I still don't see anything in the specs that says to me there should be a merge node.

I can't seem to find this "Basic Activity" pattern you are talking about, so I can't really say if there's an error in that diagram.
Where/how did you get that?

Geert

[Ignacio G. T.]

Enterprise Architect 9.3.933 (Build: 633) - Unicode.
System Engineering Edition

Project --> New Diagram --> UML Behavioral --> Activity
In the tools panels (left): Activity Patterns: Basic Activity

Well, if nobody here sees this as an error, that means that nobody here sees this as an error

[Geert Bellekens]

Ah, I found the "Basic Activity" thing you were talking about.

[...]
An action execution is created [highlight]when all its object flow and control flow prerequisites[/highlight] have been satisfied (implicit join). Exceptions to this are listed below.
[...]

If I understand you correctly than this is what makes you think that Action1 would not be executed (because it has two control flows, and one of them will only get a token later, after the decision).
But then we would need to know what is meant by prerequisites.
For object flows it states that

The object flow prerequisite is satisfied when all of the input pins are offered all
necessary tokens, as specified by their minimum multiplicity, and accept them all at once up to their maximum
multiplicity, precluding them from being consumed by any other actions.

But it doesn't mention anything for control flows, and it doesn't mention what happens if you don't have input pins (as in the example from EA).

On the other hand, if you look through the examples in the UML specs you will find that they almost always use a merge when two control flows need to go the same Action.
But whether that is just a best practice from the author, or a mandatory thing is (at least for) not really obvious.

Anyways, even if syntactically this would be incorrect, I would never make an issue out of it when reviewing someone's model.

Geert

[Paolo F Cantoni]

Well,  I think it is the equivalent of "Defensive Driving".  Notwithstanding that the specification is unclear, by ensuring that there is ALWAYS a merge node (at least in the normative model ^{- ask me what I mean...} ) is more than good practice, it enforces consistency.

Manage Complexity,
   .   .   Reduce Ambiguity,
   .   .   .   .   Eliminate Inconsistency! ^TM

Paolo