Prev Next

Code Generation - Activity Diagrams

Code generation from 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 constructs from which code can be generated. Enterprise Architect also transforms the constructs into one of the various action types (if appropriate), similar to the Interaction diagram constructs.

Actions

Action

Description

See also

Call Actions (Invocation Actions)

Used to invoke operations or behaviors in an Activity diagram; the two main variants of Call Actions supported in behavioral code generation are:

  • CallOperation Action - 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
  • CallBehavior Action - used to invoke another Activity in an activity flow; the referenced Activity is expected to be within the same Class

Arguments

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 Synchronize button of the 'Arguments' dialog.

 Assign Action Pins Behavior Calls Synchronize Arguments

CreateObjectAction

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

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

Loops

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.

You can have a single loop, nested loops, and multiple levels of nested loops.

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.

Notes

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

Learn more