Ad/2010-08-01 Concrete Syntax for a uml action Language for Foundational uml (Alf) Second Revised Submission

10.4.8Activities

Activities are namespaces (see Subclause 10.2) that may be defined as Alf units (see Subclause 10.1). Activities may also be implicitly defined by the in-line specification of behavior for active classes (see Subclause 10.4.3) or operations (see Subclause 10.5.3).

In UML, activities are also classes (see UML Superstructure, Subclause 12.3.4) and so may have attributes, operations and specialization. However, for simplicitly, Alf does not provide a textual notation for features and specializations on activities. Instead, an active class may be used to model structural features along with a related behavior (see Subclause 10.4.3).

Examples

activity getNodeActivations

(in node: ActivityNode): ActivityNodeActivation[*] {

return this.activations -> select a (a.node == node);

}

activity execute()

//@parallel

{

'activity' = (Activity)(this.types[1]);

group = new ActivityNodeActivationGroup();

group.activityExecution = this;

}

{

group.activate('activity'.node, 'activity'.edge);

}

}

}

accept (checkout: Checkout);

this.establishCustomer(checkout);
do {
accept (chargeSubmission: SubmitCharge);

this.processCharge(chargeSubmission);

declined = true;

this.declineCharge();
} or accept (PaymentApproved) {

declined = false;

}
} while (declined);
this.packAndShip();

accept (OrderDelivery);

this.notifyOfDelivery();

}

Syntax

ActivityDeclaration(d: ActivityDefinition)
= "activity" Name(d.name) [ TemplateParameters(d) ] FormalParameters(d)
[ ReturnParameter(d.ownedMember) ]

ActivityDefinition(d: ActivityDefinition)

FormalParameters(d: NamespaceDefinition)

FormalParameterList(d: NamespaceDefinition)

FormalParameter(p: FormalParameter)

ParameterDirection(dir: String)

ReturnParameter(p: FormalParameter)

Figure 10 69 Abstract Syntax of Activity Definitions and Formal Parameters

1. 
   Block see Subclause 9.1
   
2. 
   ClassifierDefinition see Subclause 10.4.1
   
3. 
   TypePart see Subclause 10.5.2
   
4. 
   TypedElementDefinition see Subclause 10.5.2
   

Formal Parameters

The definition of an activity includes the names and types of any in, out and inout parameters, as well as, optionally, the type of a single return parameter. The activity acts as the namespace for its parameters (but parameters are not packageable elements and, therefore, cannot be imported; see Subclause 10.3). Return parameters cannot be named in Alf. The type part of a formal parameter definition statically specifies the type and multiplicity of the formal parameter in the same way as for a property (see Subclause 10.5.2).

A formal parameter may also have one or more stereotype annotations applied to it. Such annotations have the same semantics as annotations made on a unit definition (see Subclause 10.1), except that the qualified names do not need to be fully qualified and are resolved in the current scope of the enclosing activity, rather than in model scope.

Activities as Units

An activity definition can either be a model unit in itself or a subunit of another Alf unit. As a subunit, an activity definition may complete a stub declaration for an activity as a nested classifier (see Subclause 10.4.2), as the classifier behavior of an active class (see Subclause 10.4.3) or as the method of an operation (see Subclause 10.5.3).

An activity definition that completes a classifier behavior declaration may not be a template and may not have any parameters. An activity definition that completes an operation also may not be a template but must have formal and return parameters (if any) that match exactly, in order, the parameters of the operation in direction, name, type and multiplicity. An activity definition that completes a nested activity stub must also match the parameters of the stub, as for an operation. (The type name of a parameter of an activity does not need to lexically match exactly that of the corresponding operation parameter, but the activity parameter type name must resolve to the same classifier as the corresponding parameter of the operation, or the activity and operation parameters must both be untyped.)

Note also that any stereotype annotations made on an activity definition subunit (see Subclause 10.1) that completes an operation maps to a stereotype on the method for that operation, not the operation itself. Stereotype annotations for the operation itself (such as @Create for a constructor or @Destroy for a destructor) must be made on the operation stub declaration (see Subclause 10.4.2).

Local and Parameter Names

An activity can introduce local names for elements within it. Such named elements are not namespace elements of the activity. Local names are used in Alf to denote intermediate values in computations within an activity. The scope of such local names is generally from the point at which they are defined lexically to the end of the containing activity. However, the local names defined in an activity are never visible outside that activity. (See also the discussion of local names in Subclauses 8.1 and 9.1.)

The names of the parameters of an activity are not technically local names, since they are owned namespace members of the activity. However, they are used within the body of an activity in much the same way as local names. Further, while parameter names may be qualified with the name of the activity, this is not required, meaning that they are generally written as unqualified names, again much like local names.

An in parameter may be referenced by name within the body of an activity (see Subclause 8.3.3), but it cannot be reassigned. It is treated similarly to a local name whose assigned source is always given by its input value at the start of the execution of an activity.

Both out and inout parameters, on the other hand, may be referenced and assigned (see Subclause 8.8) within the body of an activity. An out parameter is initially unassigned, while an inout parameter is initially assigned its input value at the start of the execution of an activity. The values returned for these parameters by the activity are from their final assigned sources.

Activity Execution

An activity may be executed as the classifier behavior of an active class (see Subclause 10.4.3), as an operation method (see Subclause 10.5.3) or as a stand-alone behavior in its own right. A classifier behavior is automatically started asynchronously when an instance of the class that owns it is created (see Subclause 8.3.12). A stand-alone activity can also be started asynchronously by instantiating it as a class, as long as it does not have parameters (see Subclause 8.3.12), or it can be called synchronously using a behavior invocation (see Subclause 8.3.9). An operation method can only be called synchronously (see Subclause 8.3.10).

However it is invoked, an activity is then executed by executing the block given in its definition (see Subclause 9.1). That is, each of the statements in the block are executed sequentially in order, and the activity terminates once the last statement in the block completes execution.