Activity Parameters/Return

To specify the return type of an activity as well as the parameters, bring up the properties dialog of the activity and navigate to Behavior. There you can specify the return type and the parameters

Activity Parameter

Info

If the return type is not defined inside the Behavior the function will be generated with void as return type.

Embedded Engineer no longer only relies on the return type in the Behavior... If a return parameter is defined with a type this will be taken primarily.

You can adjust the parameters also directly in the Parameters section of the activity.

Activity Parameter

Parameter

Selecting the type for the parameters and the activity type is a bit tricky. Enterprise Architect only shows the predefined UML types, which you cannot use for C-Code.

Instead, click on the ellipsis ... next to the type combobox, and either select a type from your project or add a new one. You can use any classifier (Data Type, Class, Actor, Activity, Interface, ...) as type – the generated code will use the name of the classifier to designate the type. In order to use parameters and types, open the activity diagram and your activity (for which you've just opened the diagram) onto the diagram.

Now you can start to model the activity inside the newly created element. Think of it as a container, everything which is part of the activity element will be part of the activity. The parameters of the activity are shown at the outline of the activity.

To add parameters, use the context menu on the activity and go to New Element Activity Parameter, or use the properties dialog for the activity.

Info

If you've already defined parameters, but they don't show up on the diagram, use the context menu on the activity and go to Structural Elements... where you can select the parameters which you want to show on your diagram.

Return Value

For modeling the return value of an activity, add a parameter whose direction is return instead of the default in. You must make sure that you never have more than one such parameter, only one such parameter will be taken into account. You can use these newly created activity parameters just as you'd use other input/output pins. Finally, your diagram may look like this:

Activity Parameter

Warning

An Activity without an ActivityFinal will generate no return statement.

Normal generated Code

In this example, the activity has one input parameter count of type int and one output parameter of type int. The name is not relevant for the output parameter, but since out parameters look the same as in parameters, it's nonetheless helpful to give it a meaningful name. The activity calls an operation ClassOp which in turn calls another activity (not shown here). It also returns a value which is computed with another activity Add.

int ActivityParameter_AddOne(int count)
{
    int return_1;
    extern ActivityParameter me_ActivityParameter;
    ActivityParameter* me = &me_ActivityParameter;
    return_1 = ActivityParameter_Sum(1, count);
    ActivityParameter_ClassOp();
    return return_1;
}

Singleton generated Code

Note that the first two lines of the function are inserted because the class which owns this activity was marked as singleton Stereotype. Therefore there is only one instance of this class in the system, which doesn't need to be passed around as parameter. This is also the reason why there's no me parameter for ActivityParameter_ClassOp() or ActivityParameter_Sum(int, int). This would be the code without the class being a singleton:

int ActivityParameter_AddOne(ActivityParameter* const me, int count)
{
    int return_1;
    return_1 = ActivityParameter_Sum(me, 1, count);
    ActivityParameter_ClassOp(me);
    return return_1;
}