The Control Flow is used to model the sequence of the actions in an activity diagram.
A control flow can have Conditions/Guards to restrict the flow of control depending on the given condition.
Ordering Control Flows/Decisions
A new approach was taken to allow the positioning/prioritization of multiple Control Flows originating from one Decision, creating an
elseif .. block.
For this we have more information under: Decision & Merge - Ordered Decisions
Since modelling a path via Object- and ControlFlows through an Activity can be a tedious task, we updated the Activity generation behavior to derive certain action sequences from existing ObjectFlows.
This will lead to an Activity that is faster to model, not overly cluttered with connectors and therefore easier to read and understand.
For a better understanding here an example of the old and new implementation side by side, as well as the resulting code from both.
Example Code Generated int32_t result_6 = 12; int tmp = i; int tmp2 = test_Addone(me, 1); result_6 = tmp + tmp2; return result_6;
The default value was set to
12 in the
Both Activities model a simple behavior to:
- store a parameter inside a variable
- specify a value for an OperationCall parameter and store the return value inside another variable
- returning both variables (added together) as main result1
In the second Activity with the derived
ControlFlow, we now can omit the ControlFlows from/to the
Action since Embedded Engineer infers the action sequence via the
ObjectFlows from/to the
If needed the ControlFlow can still be modelled.
please also note that the "result" parameter in this Activity has a default value set to "12" (hence the first and last line of code) ↩