3

I have the following simple activity diagram:

Simple AD with object flows

My problem / question about is the last activity and its incoming object flows:

  • how to model proper UML here?

In UML-Spec 2.5.1 I find these quotes:

[15.2.3.1 Activities]

An object token is a container for a value that flows over ObjectFlow edges [...]. An object token with no value in it is called a null token. [...] Each token is distinct from any other, even if it contains the same value as another.

[15.2.3.4 Object Flows]

Object tokens pass over ObjectFlows, carrying data through an Activity via their values, or carrying no data (null tokens). A null token can still be passed along an ObjectFlow and used like any other token.

[15.3.3.5 Merge Nodes]

A MergeNode is a control node that brings together multiple flows without synchronization. [...] if the outgoing edge is an ObjectFlow, then all incoming edges must be ObjectFlows

[16.2.3.3 Pins]

The multiplicity bounds on a Pin constrain the total number of values that may be input or output by a single execution of an Action, not the number of tokens it contains (see the upperBound property inherited from ObjectNode). A Pin may hold null tokens that contain no values. [...] An Action cannot start execution if one of its InputPins has fewer values than the lower multiplicity of that InputPin.

[16.2.3.4 Actions and Pins in Activities]

Executing an Action in an Activity requires all of its InputPins to be offered all necessary tokens, as specified by their minimum multiplicity (except for the special cases of ActionInputPins and ValuePins, as discussed above).

I understand it that way, that my model is currently wrong - because it is impossible to have both object G as input due to the decision before.

So I have to reduce the object flows to 1 to succeed.

That seems to give me these options:

  1. set multiplicity to zero
    • but multiplicity is on value, not on token, so a token would be required to flow in
    • I just don't create even a null token in B if I decide for A
  2. use a separate merge for the object flow
    • simply said: my modeling tool does not allow an object flow to an object or action pin
    • could be a bug

Then there is more in spec:

[15.4.3.3. Central Buffer Nodes]

[...] It accepts all object tokens offered to it on all incoming flows, which are then held by the node. Held object tokens are offered to outgoing flows [...]. When an offer for a token is accepted by a downstream object node, that token is removed from the CentralBufferNode and moved to the accepting object node, as for any object node.

Well, sounds like a way out: any input is accepted and the moment an output is accepted, it is done.

Problem smaller:

my modeling tool now offers only Dependency, Trace and Information Flow (2) - no object flow to the receiving Action Pin. All I could get is an object flow (1) to the related action. Which misses the visualization - might it be necessary because an action pin is unable to accept a token?

same AD with central buffer node


[Update] My tool allows object flows into and out expansion nodes regarding merge nodes, like this updated diagram: AD with expansion nodes

My understanding problem is now located in this chapter

[16.14.22 ExpansionNode]

An ExpansionNode is an ObjectNode used to indicate a collection input or output for an ExpansionRegion.

I have only plain actions, no region to iterate this single object.

[/Update]

1
  • found a way to convince my tool to do as wanted: from merge to action pin. Let's call it a bug there. Commented Jun 28, 2019 at 6:31

1 Answer 1

4

Object flows may be connected to decision and merge nodes. As you found in the UML spec yourself, about merge nodes: "if the outgoing edge is an ObjectFlow, then all incoming edges must be ObjectFlows". This implies that object flows may be connected to merge nodes. You don't have to draw separate object flows.

I don't know whether your tool supports it, but this should be the diagram:

ad

7
  • thanks. In the specific case it is true that only the merge is in between. The decision needs control flows because "do the transformation" are some more actions and the object is bypassed. I discoverd my tool allows ExpansionNodes instead of ActionPins for desired flow - just my action is no ExpansionRegion (compare with UML 16.14.22). hm. Commented Jun 26, 2019 at 11:24
  • If I understand you correctly, I have answered your question about the merge, but you have a different problem with regard to decisions and expansion nodes. In that case, please mark my answer as 'accepted' and enter a separate question about decisions and expansion nodes. Commented Jun 26, 2019 at 11:32
  • Feedback-question: what makes you sure that your answer is a valid UML solution to get the object flows combined? Commented Jun 26, 2019 at 11:38
  • 1
    For two reasons: (1) UML is one of my main expertises and this is what I remember from the time I studied this part of the UML specifications in detail. (2) You found in the UML spec, in the section about merge nodes the following sentence: "if the outgoing edge is an ObjectFlow, then all incoming edges must be ObjectFlows". This implies that object flows may be connected to merge nodes. Commented Jun 26, 2019 at 11:43
  • @ShegitBrahm I also recommend that to you on Sparx' forum...
    – user188153
    Commented Jul 15, 2019 at 8:55

Your Answer

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

Not the answer you're looking for? Browse other questions tagged or ask your own question.