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

8.2Qualified Names

A namespace is itself a named element. A qualified name is one that includes both the unqualified name of a named element as well as the name of a namespace of which the named element is a member. The name of the namespace may or may not itself be qualified. A local name is never qualified.

A qualifed name has the form of a list of the names of namespaces followed by the unqualified name of the named element. Syntactically, the names in the list are separated by the either the symbol “::” or the symbol “.”

NOTE. The UML Superstructure specifies the symbol “::” as the separator used in qualified names. However, it is also common in other languages to use “.” in qualified names, so Alf allows either. Only one or the other must be used throughout a single qualified name, though.

If any individual name listed in a qualified name is for a template (see Subclause 6.2 on templates), then a template binding may be optionally provided with that name. A template binding lists the qualified names of argument elements to be substituted for each of the formal template parameters in the template, surrounded by the angle brackets “<” and “>”.

The fully qualified name of a named element is either its unqualified name, if it is not owned by a namespace, or else its name qualified with the fully qualified name of its owning namespace.

Examples

customer

Ordering.Order.customer

FoundationalModelLibrary::BasicInputOutput

FoundationalModelLibrary.BasicInputOutput

Set

MapString, V=>Entry>

Map.KeySet

List< List >

CollectionClasses::Set::add

Syntax

TypeName(q: QualifiedName)
= QualifiedName(q)
| "any"

QualifiedName(q: QualifedName)
= ColonQualifiedName(q)
| DotQualifiedName(q)
| UnqualifiedName(q)

PotentiallyAmbiguousQualifiedName(q: QualifedName)
= ColonQualifiedName(q)
| DotQualifiedName(q) (q.isAmbiguous=true)
| UnqualifiedName(q)

ColonQualifiedName(q: QualifiedName)
= NameBinding(q.nameBinding) "::" { NameBinding(q.nameBinding) "::" }
NameBinding(q.nameBinding)

DotQualifiedName(q: QualifiedName)
= NameBinding(q.nameBinding)) "." { NameBinding(q.nameBinding) "." }
NameBinding(q.nameBinding)

UnqualifiedName(q: QualifiedName)
= NameBinding(q.nameBinding)

NameBinding(n: NameBinding)
= Name(n.name) [ TemplateBinding(n.binding) ]

TemplateBinding(b: TemplateBinding)
= PositionalTemplateBinding(b)
| NamedTemplateBinding(b)

PositionalTemplateBinding(b: PositionalTemplateBinding)
= "<" QualifiedName(b.argumentName)
{ "," QualifiedName(b.argumentName) } ">"

NamedTemplateBinding(b: NamedTemplateBinding)

TemplateParameterSubstitution(s: TemplateParameterSubstitution)

Figure 8 3 Abstract Syntax of Qualified Names

1. 
   Syntax Element see Subclause 6.5
   
2. 
   Name see Subclause 7.5
   

It is ambiguous whether a syntactic element of the form n₁.n₂. … .n_m, where the n_i are name bindings and m ≥ 2, should be parsed as a qualified name or a feature reference (see Subclause 8.3.6) when the element is used in the following contexts.

• 
  As an Expression (NameExpression, Subclause 8.3.3, versus PropertyAccessExpression, Subclause 8.3.6)
  
• 
  As an InvocationTarget (BehaviorInvocationTarget, Subclause 8.3.9, versus FeatureInvocationTarget, Subclause 8.3.10)
  
• 
  As a LeftHandSide (QualifiedName versus FeatureReference, see Subclause 8.8)
  

• 
  If n₁.n₂. … .n_m-1 resolves to a namespace, then the original element should be considered a qualified name.
  
• 
  Else, the original element should be considered a feature reference, with name n_m and target expression determined by the disambiguation (if necessary) of n₁.n₂. … .n_m-1.
  

Element naming and namespaces do not have executable semantics and are therefore not addressed in the fUML Specification. Nevertheless, the use of named elements is particularly important in Alf, since, in a textual notation, model elements are primarily referenced by name. Such named references must be resolved into actual abstract syntax element references when the Alf text is mapped into a fUML model.

The semantics of names, namespaces and visibility are defined in detail in the UML Superstructure, particularly in Subclauses 7.3.34 Namespace, 7.3.55 VisibilityKind, 7.3.15 ElementImport and 7.3.39 PackageImport. Depending on the context in which it is used (as defined in subsequent subclauses), a name may either be part of the definition of a named element or it may denote a reference to a named element defined elsewhere.

Current Scope

The current scope for the resolution of a reference to a name is the specific innermost namespace in which that named reference lexically appears.

A name is said to be visible in the current scope if a named element with the given name is a member of the current scope namespace or is visible in the namespace immediately enclosing the current scope (if any). Such an element may be referenced using an unqualified name.

Otherwise the first name listed in a qualified name must be visible as an unqualified name in the current scope in which the qualified name occurs. Each succeeding name must be the name of a visible member of the preceeding namespace.

Type Names

A type constrains the values represented by a typed element (see UML Superstructure, Subclause 7.3.51). Any value in UML is an instance of some classifier, so a type is always given by naming a classifier, which constrains the typed element to instances of that classifier. If the named classifier is a template (see Subclause 6.2 on templates), then an argument type must be given for each parameter of the template. The association of a classifier template with its arguments is known as a type binding.

A type name may be either a qualified name or the keyword any. If a type name is a qualified name, then this name must resolve to a classifier, which constrains a typed element to represent the values that are instances of that classifier. The keyword any is used to indicate that a typed element is actually untyped, that is, that there are no constraints on the values it may represent.

Type Conformance

One classifier conforms to another if the two classifiers are equivalent or if any direct generalization of the first classifier conforms to the second classifier. For the purpose of conformance, two classifiers are considered equivalent if they are the same or if they both have template bindings for equivalent templates with equivalent arguments for all template parameters (for non-classifier template parameters, the arguments must be identical).

Template Bindings

If a qualified name resolves to a template—that is, an element with template parameters—then a template binding may be appended to the qualified name. Such a binding names an argument element to be substituted for each template parameter. Such a qualified name with a template binding may itself be used as the qualification part of a larger qualified name.

The argument elements in a template binding may not themselves be templates. Each argument must be compatible with the corresponding template parameter. In general, a template parameter may represent any kind of packagable element, any kind of connectable element or an operation, and a compatible argument for a templete parameter must be an element of the same kind. In addition, the following special compatibility rules must hold for specific kinds of elements.

• 
  Classifier. A classifier template parameter may have constraining classifiers. A classifier template parameter with no constraining classifiers may be substituted with any classifier. A template parameter with constraining classifiers must be substituted with an argument that conforms to all of the constraining classifiers (see the definition of type compatibility above).
  
• 
  Value Specification. An argument is compatible with a value specification template parameter if it is a value specification whose type conforms to the type of the value specification represented by the template parameter.
  
• 
  Operation. An argument is compatible with an operation template parameter if it is an operation with the same number of parameters, in the same order, with the same types as the operation represented by the template parameter.
  
• 
  Connectable Element. An argument is compatible with a connectable element template parameter if it is the same kind of connectable element with the same type as the connectable element represented by the template parameter.
  

• 
  Classifiers as parameterable elements are described in UML Superstructure, Subclause 17.5.7, and classifier template parameters are described in Subclause 17.5.8. The above rule for compatibility presumes that allowSubstitutable=false for all classifier template parameters with constraining classifiers.
  
• 
  Value specifications as parameterable elments are described in UML Superstructure, Subclause 17.5.20, including the compatibility rule given above.
  
• 
  Operations as parameterable elements are described in UML Superstructure, Subclause 17.5.15, and operation template parameters are described in Subclause 17.5.16. However, even though Subclause 17.5.16 mentions “additional semantics related to the compatibility of actual and formal operation parameters”, no such additional semantics are actually provided in Subclause 17.5.15. Nevertheless, the compatibility rule given above for operations given above is necessary to ensure that the substitution of an argument for an operation template parameter leaves the model well formed.
  
• 
  Connectable elements as parameterable elements are described UML Superstructure, Subclause 17.5.17, but this subclause does not specify any special compatibility rule for connectable elements. However, the compatibility rule given above for connectable elements is necessary in general to ensure that the substitution of an argument for a connectable elment template parameter leaves the model well formed. UML Superstructure, Subclause 17.5.19, also describes specifically properties as parameterable elements, giving a compatibility rule of type conformance that is looser than the rule for connectable elements given above. However, since a property could be used within the body of a template as both a value and the target of an assignment, simple type conformance is not enough to ensure well-formedness on substitution. Instead, the arguments for template parameters representing properties (which are, in the end, kinds of connectable elements) are required in Alf to follow the general connectable element compatibility rule given above.
  

For example, the standard library class Set has a single template parameter T. The following are all legal bindings for this template, assuming that Task names a classifier.

Set

Set

Set >

NOTE. The space between the right angle brackets at the end of the last example above are necessary in order for it to parse correctly. If there was no space, then the symbol “>>” would be recognized as a right shift operator, not two angle brackets (see Subclause 7.8 on the lexical analysis of multi-character symbols).

The standard library class Map has two template parameters, K and V. The following are all equivalent bindings for this template.

Map

MapString, V=>Definition>

MapDefinition, K=>String>