We recently had a lot of discussion on topics around Acitivity Diagrams for code generation with LieberLieber Embedded Engineer 2.1 for Sparx Systems Enterprise Architect.

So we’ve documented a little more in our help page.

The short version:

  • Guards can only be used together with decision actions.
  • Each decision should have a merge and this should be “nested” properly

Keep in mind that we need to generate nested “if else” statements into the code to make it executable with a language like C.

Some Samples from our updated help page:

Some Examples How to Model If – Else – Paths

Invalid Approach

This example is another invalid approach for modelling an if – else if path, similar to the example shown above:

In the diagram, you can see the code that would result from this model, if code generation would be performed. Again, a goto statement would be needed, which is invalid.

Apart from that, a merge node is missing before final node.

Solution 1

One possible approach of modelling if – else paths could be:

Solution 2

Another possible approach of modelling if – else paths could be: