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
- nestedPackage: Package [*] References the owned
members that are Packages. Subsets Package::ownedMember.
- ownedMember: PackageableElement
[*] Specifies the members
that are owned by this Package. Redefines Namespace::ownedMember.
- ownedType: Type [*] References the owned
members that are Types. Subsets Package::ownedMember.
- package: Package [0..1] References the owning package
of a package. Subsets NamedElement::namespace.
- packageMerge: Package [*] References the
PackageMerges that are owned by this Package. Subsets Element::ownedElement.
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).
-
If the members of the package are not shown within the large rectangle,
then the name of the package should be placed within the large
rectangle.
- If the members of the package are shown within the large
rectangle, then the name of the package should be placed within the tab.
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
- mergedPackage: Package [1] References the
Package that is to be merged with the source of the PackageMerge.
Subsets DirectedRelationship;;target.
- mergingPackage: Package [1] References the Package
that is being extended with the contents of the target of the
PackageMerge. Subsets Element::owner and DirectedRelationship::source.
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.