Ad/2010-08-01 Concrete Syntax for a uml action Language for Foundational uml (Alf) Second Revised Submission
Download 1.74 Mb.
|
- Navigate this page:
- 10.3Packages
10.2NamespacesA namespace is a UML element used to provide the definition context for a set of named elements known as the owned members of the namespace. A package is a UML construct whose primary function is simply as a namespace for defining other elements (see Subclause 10.3). However, a classifier (class, structured data type, enumeration, association, signal or activity) also acts as a namespace for various sub-elements defined within it (see Subclause 10.4). Generally, each kind of namespace has specific restrictions on the kinds of named elements that can be owned members, as reflected in the Alf notation for them described in subsequent subclauses. In UML, an operation is also considered to be a namespace for its parameters, and it can be used as such in the qualified name for those parameters (see Subclause 8.2). However, an operation can only be defined textually within the context of a class (see Subclauses 10.4.2 and 10.5.3). Therefore, the definition of an operation in Alf is not considered to syntactically be a namespace definition, in the same sense that package and classifier definitions are. In particular, an operation definition cannot be used as a unit (though an activity acting as the method for an operation can be used as a subunit completing an operation stub declaration—see Subclause 10.4.8). Since a namespace is a named element, it may itself be an owned member of an enclosing namespace. In addition to its owned members, the members of a namespace include the members of any enclosing namespace (unless hidden by an owned member with the same name). A namespace may also have members that are imported from other packages.
NamespaceDefinition(d: NamespaceDefinition) = PackageDefinition(d) | ClassifierDefinition(d) VisibilityIndicator(v: String) = ImportVisibilityIndicator(v) | "protected"(v) NOTE. The actual definition of specific kinds of named elements allowed in various kinds of namespaces is given in the following subclauses. However, the syntax and semantics of visibility are discussed here, because they are largely common across the different kinds of named element definitions. 
Figure 10 60 Abstract Syntax of Namespace Definitions Cross References
Semantics Members
Each kind of namespace definition contains constituent definitions for owned members of the namespace. The members of a namespace must be distinguishable as specified in the UML Superstructure, Subclause 7.3.34, Namespace. However, in any case that the UML Superstructure considers two names to be distinguishable if they are different, an Alf implementation may instead impose the stronger requirement that the names not be conflicting, in the sense defined in Subclause 7.5 (of the Alf specification). Model Scope All owned members of an Alf namespace must be represented in Alf. However, Alf text may occur in the context of a larger UML model, not all of which is represented in Alf. In such a case, it is possible from within the Alf text to refer by name to named elements defined in the wider model context. For any Alf namespace, the model scope is the innermost namespace enclosing the Alf namespace that is not itself represented in Alf, if any. If there is no such namespace, then the Alf unit has an empty model scope. Whether a name is visible in the model scope is expected to be determined using the usual UML Superstructure rules. At the very least, the names of all members of the model scope namespace should be visible. However, the management of namespaces at the model scope and any enclosing namespaces above that is the responsibility of the modeling environment and not otherwise defined in the Alf specification. UML does not in general require that a named element be a member of a namespace or that there be only one hierarchy of namespaces. However, in order to be referenced in an Alf text, any model element external to that text must be nameable by a qualified name beginning with a name visible in the model scope. Visibility The visibility of a name outside the scope of the namespace owning the named element can be controlled by placing a visibility indicator on the definition of the named element: one of “public”, “private” or “protected”. A named element definition with no visibility indicator is considered to have package visibility. The visibility of a named element outside its defining scope is as defined in the UML Superstructure, Subclause 7.3.55, VisibilityKind. 10.3PackagesA package is a namespace whose sole function is to group its member elements, which must be packageable elements. In Alf, the supported kinds of packageable element definitions are just the namespace definitions for packages and the various kinds of classifiers (see Subclause 10.4). Note also that only packageable elements may be imported into other namespaces (see Subclause 10.1). A packageable element may be fully defined within the textual body of a package definition. Alternatively, a stub declaration may be given for the element, which includes only the element name and visibility (and, for an activity, its signature). The full definition of the element is then given in a subunit definition (see Subclause 10.1). Examples package Ordering // Base unit { public assoc Selects // Nested namespace { public cart: ShoppingCart[0..*]; public selectedProducts: Product[1..*]; public selectionInfo: ProductSelection; }
public abstract active class Order; public class ProductSelection; }
PackageDeclaration(d: PackageDefinition)
PackageDefinition(d: PackageDefinition) = PackageDeclaration(d) "{" { PackagedElement(d.ownedMember) } "}" PackagedElement(m: Member) = [ DocumentationComment(m.documentation) ] { StereotypeAnnotation(m.annotation) } ImportVisibilityIndicator(m.visibility) PackagedElementDefinition(m) PackagedElementDefinition(m: Member) = NamespaceDefinition(m) | NamespaceStubDeclaration(m) NamespaceStubDeclaration(m: Member) = PackageStubDeclaration(m) | ClassifierStubDeclaration(m) PackageStubDeclaration(m: Member) = PackageDeclaration(m) ";" (m.isStub=true) 
Figure 10 61 Abstract Syntax of Package Definitions Cross References
Semantics The package being defined is the current scope for all packaged element definitions within it. Stereotype annotations apply to the element defined by the following packaged element definition. 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 package, rather than in model scope. If the package element definition is a stub declaration, then the annotation for a stereotype may be applied either to the stub declaration or the subunit definition, but not both. See also the discussion of the semantics for namespaces in general in Subclause 10.2. Directory: spec spec -> Illinois state board of education spec -> Volume Ⅴ (2015) On The 2015 China Victory Day Parade spec -> General information spec -> Topeka capital-journal spec -> P-8153 Frederick Tilp II (upper right) with plumbers who worked for him spec -> Catalog of My Wine Library Thomas Pinney Claremont, California 2004 note spec -> Unique 00225 Mobile Barrier (2015 Specifications: 12-04-14) spec -> Annual Conference " Initium Novum" spec -> Petroleum Development Oman L. L. C. Document Title: Specification for hse cases Download 1.74 Mb. Share with your friends:
|