Control Flow

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 if ... elseif .. block. For this we have more information under: Decision & Merge - Ordered Decisions

Deriving ControlFlows

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

normal ControlFlow

ControlFlow

derived ControlFlow

ControlFlow

resulting 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;

Note

The default value was set to 12 in the return ParameterNode

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 result¹

Info

In the second Activity with the derived ControlFlow, we now can omit the ControlFlows from/to the ValueSpecification and Action since Embedded Engineer infers the action sequence via the ObjectFlows from/to the CallOperation Action.

If needed the ControlFlow can still be modelled.