Skip to content

Object Flow

Embedded Engineer supports limited object flow for activities. This means that you can model activities like this:


In contrast to the UML specification, object pins don't accumulate incoming objects, but only hold at most one instance of one object. In this example, what happens is this:

  • The code generator starts with copying the activity parameter values to the appropriate pins (here: copy the count parameter to the y pin of Sum).
  • The generator proceeeds at the initial node.
  • Code for the value specification is generated, which writes the value 1 to the pin x of Sum.
  • The code generator introduces a call to Sum, and writes the return value to the activity parameter return.
  • Now the call of ClassOp is added to the code.
  • Upon reaching the final node, the code generator returns the activity parameter return.
  • While this is similar to UML, and the results are often the same, you have to keep this in mind when modeling complex object flows.


An ObjectFlow should always be directional from an OutputPin to an InputPin.

Since Enterprise Architect derives the ActionPin type from the property: Kind (input, output) and this behavior lead to many users errors we opted for the ObjectFlow direction to identify Input- and OutputPins for code generation. (A warning will be generated to facilitate modeling integrity)


a = Class1_test(me, 1, 2, 3);

This behavior shows a CallOperationAction with the InputPin1 configured as the result of the operation and an assignment of the operation result to a variable called a.

Even though the InputPin1 Kind is set to input the code generation will generate the code as expected, because of the direction of the ObjectFlow between ActionPin: InputPin1 and value.

How to set ActionPin Kind

ActionPin Kind