Skip to content

Object Flow

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

ObjectFlow

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.

Input-/OutputPins

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)

ObjectFlow

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