Code Generation - Activity Diagrams

Code generation from an Activity Diagrams in a Class requires a validation phase, during which Enterprise Architect uses the system engineering graph optimizer to analyze the diagram and render it into various code-generatable constructs. Enterprise Architect also transforms the constructs into one of the various action types (if appropriate), similar to the Interaction diagram constructs.




See also

Call Actions (Invocation Actions)

Call Actions are used to invoke operations or behaviors in an Activity diagram. The two main variants of Call Actions supported in behavioral code generation are:

  • CallOperationAction - used to invoke operations, which can be within the same Class or in other Classes within the same package. If referencing operations from other Classes within the same package, you must have a target to which the request is passed
  • CallBehaviorAction - used to invoke another Activity in an activity flow. The referenced activity is expected to be within the same Class


Call Actions can specify argument values corresponding to the parameters in the associated behavior or behavioral feature. You can add the arguments manually or create them automatically using the the Synchronize button of the Arguments dialog.

Assign Action Pins

Behavior Calls

Synchronize Arguments


CreateObjectAction is used to denote an object creation in the activity flow. You can set the result Pin of the CreateObjectAction as the object to be created, using the  Assign Action Pins dialog.

The Classifier of the CreateObjectAction signifies the Classifier for which an instance is to be created.

Assign Action Pins


DestroyObjectAction is used to denote an object deletion in the activity flow. You can set the target Pin of the DestroyObjectAction as the object to be destroyed, using the Assign Action Pins dialog.

Assign Action Pins


Enterprise Architect's system engineering graph optimizer is also capable of analyzing and identifying loops. An identified loop is internally rendered as an Action Loop, which is translated by the EASL code generation macros to generate the required code


Conditional Statements

To model a conditional statement, you use Decision/Merge nodes. Alternatively, you can imply Decisions/Merges internally. The graph optimizer expects an associated Merge node for each Decision node, to facilitate efficient tracking of various branches and analysis of the code constructs within them.



  • To be able to generate code from behavioral models, all behavioral constructs should be contained within a Class

Learn More: