19.10Signal (and Signal Reception) Definitions -
A signal definition maps to a signal.
Signal Members
-
A property definition maps to an owned attribute of the signal as specified in Subclause 19.14.
See also the mapping for visibility in Subclause 19.2.
Signal Reception Definition
-
A signal reception definition maps to a signal and a reception for the signal. The signal is mapped as if the signal reception definition was a signal definition and the signal becomes a nested classifier of the class mapped from the class definition that is the namespace of the signal reception definition. The reception becomes an owned reception of the same class.
19.11Activity Definitions -
An activity definition that is not primitive maps to an activity. If the activity is a classifier behavior, it is mapped as active (isActive=true). Otherwise, it is mapped as passive (isActive=false). The body of an activity maps as a block (see Subclause 18.1).
-
An activity definition that is primitive maps to an opaque behavior. An execution prototype for the opaque behavior is registered as a primitive behavior with the execution factory at the execution locus for the unit (see Subclause 8.2 of the fUML Specification). However, how this execution prototype is created is tool specific and not defined in the Alf standard.
Activity Members (Formal Parameters)
-
A formal parameter maps to an owned parameter of the activity (see Subclause 19.13). The type and multiplicity of a formal parameter are mapped as specified in Subclause 19.13.
-
Each in and inout parameter of the activity maps to an input activity parameter node for the parameter. Each such node is connected by an outgoing object flow to a fork node. This fork node acts as the (initial) assigned source for the values of the parameter within the activity (see also Subclause 17.4 on the reference to parameters by name).
-
Each inout, out and return parameter of the activity maps to an output activity parameter node for the parameter. For each inout and out parameter, the activity includes an object flow from the assigned source, if any, for the parameter name after the activity block. For the further mapping for return parameters, see the mapping for return statements (in Subclause 18.13).
NOTE.
Even though activities are classes in UML, Alf does not provide any notation for defining attributes, operations or receptions for activities. However, in order to allow for the use of Alf representation for activities in larger enclosing models not represented in Alf, Alf allows activity model units to be active and to have attributes, operations and receptions as features. But, since, these features cannot be represented in Alf, it is tool specific how these features are attached to the activity.
Alf also does not provide any notation for specifying superclasses for an activity. However, Alf allows a tool to provide means for specifying the superclasses for an activity (which may be regular classes or activities) otherwise represented as an Alf model unit. Members are inherited from activity superclasses in the same way as for regular classes (see Subclauses 10.4.2 and 10.4.3). But the semantics for inheritance of behavior from activity superclasses is not specified.
19.12Typed Element Definitions -
A typed element definition maps to an element that is both a typed element and a multiplicity element, as given for the specific kind of typed element definition in the appropriate subsequent subclause.
Typed Element
-
The type of the typed element definition maps to the type of the typed element.
Multiplicity Element
-
The lower attribute of the multiplicity element is a literal integer for the value given by the lower attribute of the typed element definition.
-
The upper attribute of the multiplicity element is a literal unlmited natural for the value given by the upper attribute of the typed element definition.
-
The isUnique and isOrdered attributes of the multiplicity element are set according to the isNonUnique (with opposite sense) and isOrdered attributes of the typed element definition
19.13Formal Parameters -
A formal parameter maps to a parameter of an activity or an operation with the given name and direction. Its type and multiplicity are mapped as given in Subclause 19.12.
19.14Property Definitions -
A property definition maps to a property with the given name that is a structural feature of the classifier mapped from the classifier definition that is the namespace of the property definition. Its type and multiplicity are mapped as given in Subclause 19.12.
-
If the property definition is composite, then the property has aggregation=composite. Otherwise it has aggregation = none.
-
An initializer expression is not mapped as part of the property definition, but, rather, as part of the mapping of the constructor(s) for the owning class (see Subclause 19.5Error: Reference source not found).
19.15Operation Definitions -
An operation definition maps to an operation with the given name and isAbstract value that is an owned operation of the class mapped from the class definition that is the namespace of the operation definition.
-
A formal parameter that is a member of an operation definition maps to an owned parameter of the operation (see Subclause 19.13).
-
If an operation declaration has redefined operations, then the operation has the these redefined operations.
-
If an operation definition has a body, then the operation has an associated activity (owned by the class of the operation) as its method, with the body mapped as if it was the body of an activity definition for this activity (see Subclause 18.1). The activity has an owned parameter corresponding, in order, to each owned parameter of the operation (see the mapping of formal parameters, below), with the same name, type, multiplicity and direction as the operation parameter.
-
If an operation definition is a stub, then its associated subunit maps to an activity. This activity becomes the method of the operation mapped from the operation definition.
Constructors
-
If the operation definition is a constructor, then it has an implicit return parameter with the owning class as its type. Further, the default constructor behavior (as described in Subclause 19.5) is included in the mapping of the operation body, sequentially before the explicit behavior defined for the constructor.
NOTE. If the method of a constructor operation is represented as an Alf statement sequence, but the operation is not itself represented using Alf textual notation, then the Alf standard does not specify the mapping of any behavior for the operation than that given in the explicit statement sequence. However, a modeling tool may insert additional behavior at the start of the constructor method, such as the default constructor behavior described above as part of the mapping of an Alf-represented constructor.
Share with your friends: |
