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:
Recent Comments