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:

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

Answer 1

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

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.

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.