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
(available since version 2.2)
A new approach was taken to allow the positioning/prioritization of multiple Control Flow originating from one Decision, creating an if ... elseif .. block.
(available since version 3.3)
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:
|normal ControlFlow||derived ControlFlow||resulting code|
Both Activities model a simple behavior to:
* 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)
In the second Activity with the derived ControlFlow, we now can omit the ControlFlows from/to the ValueSpecification and WriteVariable Action since the Embedded Engineer infers the action sequence via the ObjectFlows from/to the CallOperation Action.
If needed the ControlFlow can still be modelled.