How do I merge ControlFlow and ObjectFlow in UML2 Activity Diagram?

Question

It seems that I need to have a MergeNode with incoming ControlFlow and ObjectFlow while according to paragraph 15.3.3.5 Merge Nodes of OMG® Unified Modeling Language® (OMG UML®) Version 2.5.1

If the outgoing edge of a MergeNode is a ControlFlow, then all incoming edges must be ControlFlows, and, if the outgoing edge is an ObjectFlow, then all incoming edges must be ObjectFlows.

Here is the diagram:

enter image description here

The intent was to model a process which once started continuously receives and process Order Records and Trade Records. As soon as Stop Request received, the process stops.

The nodes A and B are ok since all flows are ObjectFlows. The nodes marked C and D are problematic since the flows from the InitialNodes are ControlFlows.

I need flows from the InitialNodes to initially enable Trade Record Received and Order Record Received nodes since according to paragraph 15.2.3.6 Activity Execution

When an Activity is first invoked, none of its nodes other than input ActivityParameterNodes will initially hold any tokens. However, nodes that do not have incoming edges and require no input data to execute are immediately enabled.

Thus Stop Request Received will be enabled when the activity is first invoked while Trade Record Received and Order Record Received will not be.

Is there a way to make this diagram conforming with UML specification?

If I set isControlType=true for Trade Record, Stop Request and Order Record pins would it mean that all flows are now ControlFlows for according to paragraph 15.4.3.1 Object Nodes:

If isControlType=true for an ObjectNode, ControlFlows may be incoming to and outgoing from the ObjectNode, objects tokens can come into or go out of the ObjectNode along ControlFlows, and these tokens can flow along ControlFlows reached downstream of the ObjectNode. The values on such object tokens may be used to affect the control of ExecutableNodes that are the targets of such ControlFlows, though the specific meaning of such values is not defined in this specification

• user188153: You can't have two start nodes, can you?
• zer0hedge: @qwerty_so I can. From paragraph 15.3.3.1: An InitialNode is a ControlNode that acts as a starting point for executing an Activity. An Activity may have more than one InitialNode
• user188153: Right. One never stops to learn. Means in my example you may use 2 start nodes instead of the one with the fork.

Answer 1

Many ways lead to Rome. So here's what I would do:

enter image description here

The two actions start in parallel (after the fork). There are two queues (the data stores) for trades and orders. They are filled somewhere else and order or trade being available are signaled via events. The actions react to these signals and pop the next order/trade to process them. Now the object flows outside the interruptible region and order/trade can be processed. After entering back that region any received stop will terminate the whole process.

Note that transactional security is delicate. Implementation details (you would likely need semaphores) are better shown in design sketches with SDs. But an AD is intended to give some kind of business overview.

---

Rather than using a single start node with a fork it's possible to use two separate start nodes going to the left/right merge nodes. I was not aware of that possibility.

• zer0hedge: Thanks. I appreciate the idea to use Interruptible Activity Region
• zer0hedge: But I'm trying to model the process that fills the "datastores". The essense is the cycle that continuously receives events from the outside, sends them for further processing by someone else and receives another one. A kind of conveyor belt.
• user188153: Not what you wrote: The intent was to model a process which once started continuously receives and process Order Records and Trade Records. As soon as Stop Request received, the process stops.
• zer0hedge: Let me try to merge both statements: The intent was to model a process which once started continuously receives (from outside) and process Order Records and Trade Records (i.e. saves them into "datastore" or sends them for further processing by someone else). As soon as Stop request ... Does it make sense?
• user188153: That's actually what the model does. Placing elements at the end of a queue is uncritical and can be done in any fashion. Only the part that takes elements out is critical. If you think it does not fit then I doubt your business model. What does stopping mean? Reject further trades/orders?

Answer 2

Finally I dug out the answer in OMG® Unified Modeling Language® (OMG UML®) Version 2.5.1 documentation:

The clause 16.10.3.1 Accept Event Action says in the end:

... an AcceptEventAction with no incoming edges remains enabled after it accepts an Event occurrence. That is, it does not terminate after accepting an Event occurrence and outputting any values ... , but continues to wait for another Event occurrence.

Thus the nodes C and D (the only purpose of which is to re-enable Trade Record Received and Order Record Received) are not needed.