how to "merge" object flows in activity diagram

[Shegit Brahm]

I have the following simple activity diagram:



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: the EA 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:

the EA 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?


I found that I can use ExpansionNodes to have object flows in and out of a Merge Node.

Just my actions are no ExpansionRegions as in

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



Suggestions how to get valid UML here?

PS: Sidenote: in some cases it is necessary that the object is transfered to a later action than the one right behind the merge / decision.

[Shegit Brahm]

I found a "workaround" to connect a merge with an ActionPin:

Go to toolbox "Activity Relationships", click "object flow" and connect Merge with ActionPin...

EA does not bother (validation check iO)

So either this is a bug that it needed a workaround in the end - or it is violated UML and a bug that it worked in the end....

Suggestions?

Thanks, Shegit

[qwerty]

Your top picture will not represent a working flow. The last actions waits for two objects to arrive. But only one actually will be delivered. So it waits forever.

q.

[Shegit Brahm]

Your top picture will not represent a working flow. The last actions waits for two objects to arrive. But only one actually will be delivered. So it waits forever.

q.

I guess I know that in my question post (after spec quotes):

[...] 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.

[...]

That is why I search(ed) for a solution.

Thanks, Shegit

[qwerty]

Well, it depends on things you are not telling us (or maybe it's hidden between the UML citations?). Anyhow, if your last action shall continue supply it with a single pin which is fed from either action above - as ONE possible way. There are more ways, but without knowing the background we can't tell.

q.

[KP]

Do you need to use a Synchronization instead of a Merge Node? A Synchronization will wait for both flows to complete before continuing.

[Eve]

A merge node can have incoming and outgoing ObjectFlows.

The opposite end would have an action pin.

Also, because the action can't execute until there is a token at all of its input pins you can omit the control flow.

[Shegit Brahm]

Do you need to use a Synchronization instead of a Merge Node? A Synchronization will wait for both flows to complete before continuing.

No, no sync. The decision before is made to go either way, not both. So only one token will pass through and be waited for in the last action.

A merge node can have incoming and outgoing ObjectFlows.

The opposite end would have an action pin.

Also, because the action can't execute until there is a token at all of its input pins you can omit the control flow.

I could get a workaround here with using the toolbox feature. (see my own answerhttps://www.sparxsystems.com/forums/smf/index.php/topic,42918.msg254570.html#msg254570)

clicking on the merge node and use this small arrow feature to connect to an existing action pin: the connector highlights the action pin and "refuses to connect" thus vanishes the moment I lift the mouse finger.
That "vanishing" behavior is independet wether the input flows to the merge come from action pins or actions (aka control flows).

Yes, the first pic is wrong as I wrote in my first post, because like you said: the last action waits for second token which cannot arrive due to decision.
That's why I needed to reduce the tokens with a merge.

As I'm confident now that a object flow merge is valid UML, I see it as a  "gui bug" in EA that the connector refuses to connect.

cheers

[Shegit Brahm]

Well, it depends on things you are not telling us (or maybe it's hidden between the UML citations?). Anyhow, if your last action shall continue supply it with a single pin which is fed from either action above - as ONE possible way. There are more ways, but without knowing the background we can't tell.

q.

the background seemed simple to me:

having decisions and merges between some actions and their control flows.
and having objects, that follow this path or another - just not always side by side along all control flows, that I would could use only object flows.

(and in this case: no fork/ join)


So what question of yours did I miss?

(I personnally feel finished with the technical part as I feel convinced my UML goal is valid)

[qwerty]

Does the lowest action expect two objects or is it that there are two alternative ones?

q.

[Shegit Brahm]

the lowest action expects one object G.

the result of either transformation A or transformation B. 

[qwerty]

Then proceed as I suggested above: lead both object flows into the same pin and don't have two of them. That would do what you intend.

q.

[Eve]

clicking on the merge node and use this small arrow feature to connect to an existing action pin: the connector highlights the action pin and "refuses to connect" thus vanishes the moment I lift the mouse finger.
That "vanishing" behavior is independet wether the input flows to the merge come from action pins or actions (aka control flows).

What version/build of EA are you using? I can't reproduce this behavior.

I created a model showing the way I expected it to work using just the quicklinker (after creation of a starting action)

• Drop an action from the toolbox.
• Drag quicklinker from action. Select Object Flow | Decision  (Additional output pin created on source)
• Repeat 2
• Drag quicklinker from decision. Select Object Flow | Action  (Additional input pin created on target)
• Repeat 4
• Drag quicklinker from action. Select Object Flow | MergeNode  (Additional output pin created on source)
• Drag quicklinker from other action to existing merge node. Select Object Flow  (Additional output pin created on source)
• Drag quicklinker from merge node. Select Object Flow | Action  (Additional input pin created on target)

(I skipped the initial and final but that shouldn't make any difference)

[Shegit Brahm]

@Eve:

Thanks for your retry.  I have a 13.5.1351 at hand.

Your quicklink way worked as well in my diagram.

My problem arised because I made the actions first and the object flows later (steps 7+). That is why this way might be still / was in old EA not working:

• Drop an action from toolbox.
• Drag quicklinker from action. Select Decision|Control Flow
• Drag quicklinker from decision. Select Action|Control Flow
• Repeat 3.
• Drag quicklinker from Action. Select Merge|Control Flow
• Connect action from 4 to Merge from 5. Select Control Flow
• Drag quicklinker from Merge. Select Action|Control Flow
• Right click on action. Select "new child element| action pin"
• Repeat 8 on any action twice, on last action (7) only once.
• Connect Action pins "according" Control flows for action (1), (3), (4).
• Drag quicklinker from action pin of action(3). Select Merge|Object Flow
• Drag quicklinker from action pin of action(4) and connect to merge(11)
• Drag quicklinker from merge(11) to action pin of last action(7)

The workaround:
Drag from toolbox "Activity Relationships" the Object Flow from Merge (11) to action pin of action(7).

What (in my EA configuration) also not works:
- Drag quicklinker from merge node to desired action: no question "control/ object flow?" like when from action to action. It just sets a control flow.

why the object flow later? Because my modeling process starts sometimes with control flows only

Thanks for your time, Shegit