7

As follow-up to this question I started digging in the UML specs regarding control flow in activity diagrams. Consider this simple example:

enter image description here

Notice that it neither has ActivityInitial nor ActivityFinal. I know (though I actually can't find the location) that the specs state that a flow is terminated when it has no outgoing edge. So if the [terminate] is passed the flow will stop after Final as if it has reached a FlowFinal. But - and here are my questions:

  • Will similarly to a missing outgoing edge a missing ingoing edge mean that the flow has to start here? So in my example, will the flow start at Implicit?
  • Since the loop? has only one guarded outgoing edge, what will happen to the token if it does not pass (I guess it will be stuck).
  • Is a merge node required to join the edges from the Decision and the Implicit action into Action? (I guess you don't need it since an Action will accept all tokens that are offered and not wait like a Join would do for all to arrive.)

Please use citation from the recent UML specs in your answer.

Improve this question
13
  • In addition to the spec quote that would state about this question, I'd be curious to know how many people actually respect that. I've updated all my activity diagrams to add merging nodes in similar cases and I feel like I just ruined my diagrams' readability.
    – Tim
    Sep 20, 2016 at 11:07
  • 2
    @TimF, I always make my merge nodes very small. These tiny diamonds don't really hurt readability.
    – www.admiraalit.nl
    Sep 20, 2016 at 13:16
  • 2
    Folks, please don't make your diagrams technically incorrect because you think they are more readable that way. That's like deciding to never use plurals in your writing because you don't like the way the S's look. There's a reason they exist.
    – Jim L.
    Sep 20, 2016 at 14:17
  • 2
    @ThomasKilian, these are the most thoughtful questions I've seen about UML in a long time. I wish we could discuss these more often!
    – Jim L.
    Sep 20, 2016 at 14:31
  • 2
    @JimL. I fully agree :-) I have (/had) a few more of those but they currently slipped my mind. I used to post them on a LinkedIn forum in the past, but definitely will go the SO-way in the future. Interestingly this one has been migrated to Programmers. Really odd, since programmers are those person who usually ignore UML at most.
    – user188153
    Sep 20, 2016 at 21:39

1 Answer 1

Reset to default
6

  1. Yes, the flow will start at Implicit. From the UML 2.5 specification:

    [15.2.3.2 Activity Nodes]

    An ActivityNode is enabled to begin execution when specified conditions are satisfied on the tokens offered to it on incoming ActivityEdges...

    [15.2.3.6 Activity Execution]

    ... nodes that do not have incoming edges and require no input data to execute are immediately enabled.

  2. The DecisionNode will be blocked from offering tokens on its outgoing edge.

    • As far as I understand, the specification does not mention what will happen to the token in detail. I guess saying "the outgoing edge will be blocked and hence the token will get stuck" is not too wrong. From the UML 2.5 specification:

      [15.3.3.6 Decision Nodes]

      A token offered on the primary incoming edge of a DecisionNode shall not traverse any outgoing edge for which the guard evaluates to false.

    • For InitialNodes, the specification states the following:

      [15.3.3.1 Initial Node]

      If the token offered by an InitialNode is not immediately accepted, or is otherwise blocked from moving downstream (for example by an ActivityEdge guard), then it remains on the InitialNode.

  3. A MergeNode is required here, because the two incoming edges are implicitly joined, meaning that both edges must offer a token for the activity to begin execution. From the UML 2.5 specification:

    [15.5.3.1 Executable Nodes]

    An ExecutableNode shall not execute until all incoming ControlFlows (if any) are offering tokens. That is, there is an implicit join on the incoming Control Flows.

Improve this answer
9
  • I don't understand 3. The join node is implicit, but a join is different from a merge, isn't it ? In this case we're more thinking of a merge behavior than of a join. A join has a synchronization meaning, which is exactly what Jim points as a blocking element, or have I not understood this ?
    – Tim
    Sep 20, 2016 at 13:31
  • 2
    The 'implicit join' statement implies that, in Thomas' example diagram, that 'Action' will never be executed, because it waits for two tokens to arrive: one from 'Implicit' and one from itself, via the decision node. A merge node is required to get the intended behavior.
    – www.admiraalit.nl
    Sep 20, 2016 at 13:32
  • So Jim was right. I'd be curious to know why the people who wrote the spec have decided to take an implicit join instead of an implicit merge, which seems to be the intuitive understanding for many people, like Thomas and me. I think I'll go on forgetting this merging node. Bad me.
    – Tim
    Sep 20, 2016 at 13:38
  • 2
    Thanks a bunch :-) Regarding 3: I read it the opposite way. In my example I'd expect Action to commence when the loop? passes on. But the passage you cite tells that there needs to be a merge since Implicit will only send a token once. So Action will not start. (P.S. exactly what @JimL. said)
    – user188153
    Sep 20, 2016 at 14:26
  • 1
    @ThomasKilian, TimF, www.admiraalit.nl, Jim L, thanks for your comments, I should have read the question more carefully. I have edited the question, now talking about a merge node.
    – sergej
    Sep 20, 2016 at 15:43

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.