Premise
The main idea behind modelling your behavior is to get a faster/better understanding and/or a more abstract view of certain aspects of the behavior. (It is easier to draw/view a decision tree then to read/write a description of a decision tree)
This is why Embedded Engineer allows you to model your behaviors as Activities or State Machines.
Since an Activity is basically just a simple list/tree of actions/instructions to do (regarding ControlFlow), we will generate an Operation for each Activity inside your model.
For this we have a Supported Elements list of Actions you can use. Each with their own semantics and behavior.
Depending on the level of abstraction you would like to have inside your model, you need to choose yourself how loose/restrictive you model your behaviors.
Example
The generated code for both models will basically be the same:
int tmp = i;
int tmp2 = ActivityClass_AddOne(me, 1);
return tmp + tmp2;
Restriction
Embedded Engineer will generate code for each element inside the Supported Elements list.
For all Actions with explicit semantics e.g.: ReadVariable, CallOperation, Decision, Loop,... we will generate fixed code.
Meaning: the code that will be generated can only be changed inside the model.
For all "opaque" behavior (basically just Opaque Action) we/Embedded Engineer can not infer the semantics/behavior from the type and will therefore simply output the effect/Body and Language into the code and will treat this as User Code.
The idea behind this is that the "Architect" can model certain "unchangable"/important behavior and can be sure that this will "never" change. But leave enough room for e.g.: "low level integrations" for the developer, via the User Code.
Example
- For example an Architect wants to be able to set fixed upper limits for a motor that can only be changed inside the model.
- But on the other hand he/she does not need to know the exact way on how to read sensor data and how to create a PWM to change motor speed.