Kernel ­ the Packages Diagram


The Packages diagram of the Kernel package is shown in Figure 43.


In order to locate the metaclasses that are referenced from this diagram,
· See "Classifier (from Kernel, Dependencies, PowerTypes)" 1.
· See "DirectedRelationship (from Kernel)".
· See "Namespace (from Kernel)" .
· See "PackageableElement (from Kernel)" .

Package (from Kernel)

A package is used to group elements, and provides a namespace for the grouped elements.

Description

A package is a namespace for its members, and may contain other packages. Only packageable elements can be owned members of a package. By virtue of being a namespace, a package can import either individual members of other packages, or all the members of other packages.

In addition a package can be merged with other packages.

Attributes

No additional attributes.

Associations
Constraints

[1] If an element that is owned by a package has visibility, it is public or private.

self.ownedElements->forAll(e | e.visibility->notEmpty() implies e.visbility = #public or e.visibility = #private)

Additional Operations

[1] The query mustBeOwned() indicates whether elements of this type must have an owner.

Package::mustBeOwned() : Boolean
mustBeOwned = false

[2] The query visibleMembers() defines which members of a Package can be accessed outside it.

Package::visibleMembers() : Set(PackageableElement);
visibleMembers = member->select( m | self.makesVisible(m))

[3] The query makesVisible() defines whether a Package makes an element visible outside itself. Elements with no visibility and elements with public visibility are made visible.

Package::makesVisible(el: Namespaces::NamedElement) : Boolean;
pre: self.member->includes(el)
    makesVisible = el.visibility->isEmpty() or el.visibility = #public

Semantics

A package is a namespace and is also an packageable element that can be contained in other packages.

The elements that can be referred to using non-qualified names within a package are owned elements, imported elements, and elements in enclosing (outer) namespaces. Owned and imported elements may each have a visibility that determines whether they are available outside the package.

A package owns its owned members, with the implication that if a package is removed from a model, so are the elements owned by the package.

The public contents of a package is always accessible outside the package through the use of qualified names.

Notation

A package is shown as a large rectangle with a small rectangle (a "tab") attached to the left side of the top of the large rectangle. The members of the package may be shown within the large rectangle. Members may also be shown by branching lines to member elements, drawn outside the package. A plus sign (+) within a circle is drawn at the end attached to the namespace (package).
The visibility of a package element may be indicated by preceding the name of the element by a visibility symbol (`+' for public and `-' for private).

Presentation Options

A tool may show visibility by a graphic marker, such as color or font. A tool may also show visibility by selectively displaying those elements that meet a given visibility level, e.g., only public elements. A diagram showing a package with contents must not necessarily show all its contents; it may show a subset of the contained elements according to some criterion.

Elements that become available for use in a importing package through a package import or an element import may have a distinct color or be dimmed to indicate that they cannot be modified.

Examples

There are three representations of the same package Types in Figure 44. The one on the left just shows the package without revealing any of its members. The middle one shows some of the members within the borders of the package, and the one to the right shows some of the members using the alternative membership notation.


PackageMerge (from Kernel)


A package merge defines how one package extends another package by merging their contents.

Description

A package merge is a relationship between two packages, where the contents of the target package (the one pointed at) is merged with the contents of the source package through specialization and redefinition, where applicable.

This is a mechanism that should be used when elements of the same name are intended to represent the same concept, regardless of the package in which they are defined. A merging package will take elements of the same kind with the same name from one or more packages and merge them together into a single element using generalization and redefinitions.

It should be noted that a package merge can be viewed as a short-hand way of explicitly defining those generalizations and redefinitions. The merged packages are still available, and the elements in those packages can be separately qualified.

From an XMI point of view, it is either possible to exchange a model with all PackageMerges retained or a model where all PackageMerges have been transformed away (in which case package imports, generalizations, and redefinitions are used instead).

Attributes

No additional attributes.

Associations

Constraints

No additional constraints.

Semantics

A package merge between two packages implies a set of transformations, where the contents of the merged package is expanded in the merging package. Each element has its own specific expansion rules. The package merge is transformed to a package import having the same source and target packages as the package merge.

An element with private visibility in the merged package is not expanded in the merging package. This applies recursively to all owned elements of the merged package.

A classifier from the target (merged) package is transformed into a classifier with the same name in the source (merging) package, unless the source package already contains a classifier of the same kind with the same name. In the former case, the new classifier gets a generalization to the classifier from the target package. In the latter case, the already existing classifier gets a generalization to the classifier from the target package. In either case, every feature of the general classifier is redefined
in the specific classifier in such a way that all types refer to the transformed classifiers. In addition, the classifier in the source package gets generalizations to each transformed superclassifier of the classifier from the target package. This is because the superclassifiers may have merged in additional properties in the source package that need to be propagated properly to the classifier. Classifiers of the same kind with the same name from multiple target packages are transformed into a single classifier in the source package, with generalizations to each target classifier. Nested classifiers are recursively transformed the same way. If features from multiple classifiers are somehow conflicting, the same rules that apply for multiple inheritance are used to resolve conflicts.

Note that having an explicit generalization from a classifier in a source package to a classifier of the same kind with the same name in a target package is redundant, since it will be created as part of the transformation.

A subpackage from the target (merged) package is transformed into a subpackage with the same name in the source (merging) package, unless the source package already contains a subpackage with the same name. In the former case, the new subpackage gets a package merge to the subpackage from the target package. In the latter case, the already existing package gets a package merge to the subpackage from the target package. Subpackages with the same name from multiple target
packages are transformed into a single subpackage in the source package, with package merges to each target subpackage.

Nested subpackages are recursively transformed the same way.

A package import owned by the target package is transformed into a corresponding new package import in the source package.

Elements from imported packages are not merged (unless there is also a package merge to the imported package). The names of merged elements take precedence over the names of imported elements, meaning that names of imported elements are hidden in case of name conflicts and need to be referred to using qualifiers. An element import owned by the target package is transformed into a corresponding new element import in the source package. Imported elements are not merged (unless there is also a package merge to the package owning the imported element or its alias).

A non-generalizable packageable element owned by the target package is copied down to the source package. Any classifiers referenced as part of the packageable element are redirected at transformed classifiers, if any.

Notation

A PackageMerge is shown using a dashed line with a stick arrowhead pointing from the merging package (the source) to the merged package (the target). In addition, the keyword «merge» is shown near the dashed line.



Examples

In Figure 46, packages P and Q are being merged by package R, while package S merges only package Q.


The transformed packages R and Q are shown in Figure 47. While not shown, the package merges have been transformed into package imports.



In Figure 48, additional package merges are introduced by having the package T merge the packages R and S that were previously defined. Aside from the package merges, the package T is completely empty.


In Figure 49, the transformed version of the package T is depicted. In this package, the partial definitions of A, B, C, and D have all been brought together. Again, the package merges have been transformed to package imports. Note that the types of the ends of the associations that were originally in the packages Q and S have all been updated to refer to the appropriate types



It is possible to elide all but the most specific of each classifier, which gives a clearer picture of the end result of the package merge transformations, as is shown in Figure 50.