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.

Deriving ControlFlows

(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 ControlFlowderived ControlFlowresulting code

Example Code Generated
int32_t result_6 = 12;
int tmp = i;
int tmp2 = test_Addone(me, 1);
result_6 = tmp + tmp2;
return result_6;

Both Activities model a simple behavior to:

  1. store a parameter inside a variable
  2. specify a value for an OperationCall parameter and store the return value inside another variable
  3. returning both variables (added together) as main result*

*  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.

See also

Decision & Merge - Ordered Decisions

  • No labels