With conditional structured activities you can model conditions explicitly without resorting to control flow and decision/merge structures.

You can add them to your diagram by clicking on Structured Activity in the toolbox, and clicking on the activity diagram afterwards.

There you can select Conditional Node which will add a conditional node to your diagram.

The behavior is similar to that of the Loop Node. In the [Test] section of each clause you specify an action which is used as a test, and in the [Body] section you have the actions which should be executed if the test evaluates to true. The tests will be evaluated in sequence until a test returns true, which also means that at most one [Body] section will ever be executed. The [Test] section must not be left empty.

Because of technical reasons it's important to always save the diagram of the activity before generating code with conditional nodes.

When define a clause and adding a [Test] Action either named "else" or setting the Effect to "else" you can define an else block for your if...elseif block.
(Version 2.3.2)


(available since version 2.2)

A Structured Activity - Conditional Node will by default generate an "if ... elseif ..." block, if it gets extended with the "switchCase" stereotype the generation will be changed to write a "switch case" block.

Additionally the Conditional Node will get a "Condition" tagged value where the condition part of the switch case needs to be added.

Empty [Body] sections will be omitted.

Generated code
	/* start of activity code */
    switch (me->a)
    case 1:
    case 3:
        /* SyncableUserCode{A248A86E-0D11-4a4b-AF11-93529E726A78}:AMsxkuysmm */
        //Test 1 & 3 Body
        /* SyncableUserCode{A248A86E-0D11-4a4b-AF11-93529E726A78} */

    case 2:
        /* SyncableUserCode{4F626FFF-FD12-4198-AF89-7B97D920BE5B}:1btusFyuvc */
        //Test 2 Body
        /* SyncableUserCode{4F626FFF-FD12-4198-AF89-7B97D920BE5B} */

    case default:
        /* MISRA Rule 15.3: The final clause of a switch statement shall be the default clause. */

Regarding Version <= 3.1: When using multiple actions inside a conditional node, body or test please also model a controlflow. The current implementation will take the first element without an incoming controlflow to be the "starting point". This might lead to missing code during generation.

For various reasons it can happen that not all nodes are correctly assigned to the proper parts of the conditional node. If this happens, try to move the respective nodes out of the conditional and into the conditional again. Save the diagram, close it and re-open it. The nodes should now appear in the correct parts of the conditional node.

Please consider that Uml 2.4.1 - 12.3.17 Clause specifies that test and body of the ConditinalNode - Clauses are lists of ExecutableNodes.

Therefore you can not use Decisions (or other ControlNodes) as the first/inital node inside these parts. 

Since version 3.2 the Conditinal Node will only consider Opaque-, CallOperation-, CallBehavior- and SendSignal Actions to be the "starting point".

This way ValueSpecification-, Read/WriteVariable- and other Actions do not need to be overly constraint with a ControlFlow and the Embedded Engineer will still generate executable code.