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

10Units

This clause describes how structural models (largely within the fUML subset) can be respresented textually as Alf units. This includes the notation for defining the kinds of classifiers included in the fUML subset (see Subclause 10.4) and for defining packages to group the definition of other elements (see Subclause 10.3). Subclause 10.5 discusses the representation of various kinds of features of classifiers.

The structural modeling constructs defined in this clause are only included at the extended compliance level of Alf (see Subclause 2.1 on the definition of syntactic conformance).

10.1Overview

Since an Alf unit can be processed into a UML abstract syntax representation, a portion of a model represented in Alf can always be integrated into a larger model on that basis, regardless of the surface representation of any portion of the model.

private import ProductSpecification::Product; // Element import

private import EE_OnlineCustomer as OL_Customer; // Element import with alias

private import DomainDataTypes::*; // Package import

package Ordering // Unit definition

{

class Order; // Stub declaration

namespace Ordering; // Namespace declaration

@apply(DataProfile) // Profile application

@Entity(tableName=>"CustomerTable") // Stereotype annotation

class Customer {

...

}

Syntax

NamespaceDeclaration(q: QualifiedName)

ImportDeclaration(i: ImportReference)

ImportVisibilityIndicator(v: String)

ImportReference(i: ImportReference)

ElementImportReference(i: ElementImportReference)

AliasDefinition(n: String)

PackageImportReference(i: PackageImportReference)

StereotypeAnnotation(s: StereotypeAnnotation)

TaggedValues(s: StereotypeAnnotation)

TaggedValueList(t: TaggedValueList)

TaggedValue(t: TaggedValue)

LiteralValue(t: TaggedValue)

Figure 10 59 Abstract Syntax of Unit Definitions

1. 
   DocumentedElement see Subclause 6.5
   
2. 
   DocumentationComment see Subclause 7.4.2
   
3. 
   Name see Subclause 7.5
   
4. 
   BooleanLiteral see Subclause 7.7.1
   
5. 
   NaturalLiteral see Subclause 7.7.2
   
6. 
   UnboundedValueLiteral see Subclause 7.7.3
   
7. 
   StringLiteral see Subclause 7.7.4
   
8. 
   QualifiedName see Subclause 8.2
   
9. 
   ColonQualifiedName see Subclause 8.2
   
10. 
    DotQualifiedName see Subclause 8.2
    
11. 
    UnqualifiedName see Subclause 8.2
    
12. 
    NumericUnaryOperator see Subclause 8.5.4
    
13. 
    QualifiedNameList see Subclause 9.15
    
14. 
    NamespaceDefinition see Subclause 10.2
    
15. 
    Member see Subclause 10.2
    

Subunits

For example, the following definition for the package Ordering has a stub declaration for the class Order.

package Ordering {
class Order; // Stub declaration
}

The subunit defining class Order must then have a corresponding namespace declaration indicating that it is completing a stub in the namespace Ordering.

namespace Ordering; // Namespace declaration
class Order { // Subunit definition
…
}

(See the subclause for each kind of namespace definition for further discussion of stub declarations.)

Model Units

An Alf model unit is an Alf unit that is not a subunit of any other Alf unit. It may be used to represent the model of a classifier or package that is intended to be individually referenced as a named element.

A model unit is not required to have a namespace declaration. But, if it does have such a declaration, then, by definition, the referenced namespace will not be represented using Alf. If it does not have a namespace declaration, then which namespace it is placed in, if any, is tool specific.

A model unit may represent an entire UML model (at least within the limits of the fUML subset) or it may represent a model element (such as a class or standalone activity) intended to be used within some larger model. The Alf specification does not define how such an Alf unit is created within a specific modeling environment or how it is attached to some larger model within the environment. It does, however, place requirements on the modeling environment to allow references from within Alf units to named elements defined in namespaces outside of those units (see Subclause 10.2).

Import Declarations

An import declaration specifies a UML import dependency (see UML Superstructure, Subclauses 7.3.15 and 7.3.39). Such a declaration may specify an element import or a package import, and it may be public or private. Alf notation only provides for import declarations on namespaces defined as units. The import declarations for a unit are placed after the namespace declaration (if any) and before any stereotype annotations and the body of the definition for the unit. The qualified name given in an import declaration must be a fully qualified name (as defined in Subclause 8.2).

For an element import reference:

• 
  The name must resolve to a packageable element with either an empty or public visibility.
  
• 
  The visibility of the named element within the scope of the unit definition is as specified in the UML Superstructure, Subclause 7.3.15, ElementImport.
  

• 
  The name must resolve to a package with either an empty or public visibility.
  
• 
  The visibility of the named element within the scope of the unit definition is as specified in the UML Superstructure, Subclause 7.3.39, PackageImport.
  

private import ProductSpecification::Product; // Element import

This declaration specifies that the element with the qualified name ProductSpecification::Product be included as a member of the namespace Ordering. Since this is a private import, the element is imported as a private member and is not visible outside Ordering. On the other hand, a public import such as

public import ProductSpecification::Product; // Public element import
package Ordering { // Namespace definition
…
}

specifies that the element be imported as a public member of Ordering. In this case, the qualified name Ordering::Product refers to the same element as ProductSpecification::Product.

An element may also be imported with an alias. For example:

public import ProductSpecification::Product as Prod; // Import with alias

In this case, within the Ordering namespace, the unqualified name for ProductSpecification::Product is Prod, not Product. Further, since the import is public, outside Ordering the qualified name Ordering::Prod can be used to refer to the same element as ProductSpecification::Product.

A package import declaration may be used to import all the elements of a package. For example, the following declaration:

private import ProductSpecification::*; // Package import

specifies that all the elements of the package ProductSpecification should be imported into the namespace Ordering as private members. This is equivalent to giving a private element import declaration for each of the elements in ProductSpecification. As with an element import declaration, a package import may also be public. However, aliases cannot be defined with a package import.

Unless it is stereotyped as a «ModelLibrary», an Alf unit has an implicit, private package import for each of the sub-packages of the Alf::Library package (see 11). These packages must therefore be available in the modeling environment for any Alf unit.

The standard «ModelLibrary» stereotype can be applied to a package to indicate that it “contains model elements that are intended to be reused by other packages” (see UML Superstructure, Annex C). This stereotype can be applied to a package represented in Alf using a @ModelLibrary annotation (see below). A package so annotated does not have the implicit imports for the StandardModelLibrary packages and must import these explicitly if they are needed.

NOTE. This rule is to allow for the minimization of dependencies of model library packages represented in Alf on other packages that they may not need. It also allows for the possibility of representing the StandardModelLibrary as a model libary package in Alf without requiring it to implicitly, circularly import subpackages of itself.

Stereotype Annotations

A stereotype annotation specifies the application of a stereotype to a unit. Such annotations are listed immediately before the namespace definition for the unit. In general, the qualified name in a stereotype application must resolve to a stereotype in a profile applied to some (directly or indirectly) enclosing package. The unit must be of a syntactic type that corresponds to the metaclass extended by the identified stereotype. Any stereotype may be applied at most once to a unit.

NOTE. Profiles and stereotypes are not included in the fUML subset. However, allowing stereotype application in Alf provides an extensible annotation mechanism based on profiles. Modeling tools may use such annotations to implement profile-specific mappings of Alf text to the strict fUML subset for execution. Note, however, that Alf does not provide a textual notation for the definition of profiles, only their application.

The stereotype name does not need to be qualified if there is only one applied profile with a stereotype of the given name (except for the special cases given in Table 10 -7 and discussed further below). Otherwise the stereotype must be fully qualified with the name of the profile. However, the UML superstructure standard profiles (see UML Superstructure, Annex C) are considered to be implicitly applied, and stereotypes from these profiles can be always be used without explicit qualification of their names. Thus, any stereotype with a name that conflicts with the name of a standard stereotype must always be fully qualified.

A stereotype annotation may optionally be followed by a list of tagged values. There are two forms for such a list.

The first form has a syntax similar to that of a named tuple (see Subclause 8.3.8), with a value associated with each attribute of the stereotype. Optional attributes (multiplicity lower bound of 0) may be omitted.This Alf syntax only allows for tagged values of a primitive type and only one value per attribute. Therefore, this form of annotation can only be used for stereotypes with attributes that have one of the standard primitive types (Boolean, String, Integer or UnlimitedNatural) and a multiplicity lower bound of at most 1.

The second form of tagged value list is a list of qualified names. In this case, the stereotype must have a single attribute whose type is a metaclass from the UML abstract syntax. The listed names must be fully qualified and resolve in model scope for the unit to model elements consistent with the required metaclass for the stereotype (see Subclause 10.2 for the definition of model scope).

Alf also uses the annotation syntax for a limited number of cases other than strict stereotype application, as shown in Table 10 -7. In the case that there are visible stereotypes with the same name as these special case annotations, then the unqualified names always denote the special cases, not the stereotypes. To apply the stereotypes, they must be qualified with the name of the profile in which they are defined, whether or not that would otherwise be necessary.

Table 10 7 Non-Stereotype Annotations

Annotation	Applies To	Description
@apply(p1,…,pn)	Package Definition	Apply the profiles denoted by the qualified names p1, …, pn. The names must resolve to profiles.
@primitive	Data Type Definition or Activity Definition	If applied to a data type, indicates that the data type is to be registered as a primitive data type. The data type may not have any attributes. If applied to an activity, indicates that the activity is instead to be mapped as a primitive behavior. How the implementation of this primitive behavior is actually defined is implementation specific. Definitions marked as primitive may not be templates or stubs.
@external (file=>"…")	NamespaceDefinition	Must be applied to a stub declaration. Indicates that the stub is to be completed by a subunit implementation external to the normal UML/Alf modeling environment. How this implementation is attached to the UML model and what specific kinds of namespaces can be annotated as external are tool-specific. However, the file tag can optionally be used to give a file reference for the subunit implementation.

The first special case shown in Table 10 -7 is for denoting the application of a profile. For cases other than the standard UML profiles, such a profile application annotation for the profile must appear before the stereotypes for the profile are used in stereotype annotations. Once a profile is applied to a unit, however, it is also available without further application to all subunits of that unit.