UML14 — 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."

The text implies that PackageMerge is an operation on an ordered pair of two packages (respectively the target package and the source package) to produce a third package, whose contents differs from the contents of the source package, differs from the contents of the target package, and differs from the union of the source and target (taking "union" in the set-theoretic sense, where the elements owned by a package are regarded as a set.

This operation known as PackageMerge is performed when it is desired to produce new elements (with generalization relationships and redefinitions that did not exist "prior to" performing this operation) in a new package, which (to repeat myself) is distinct from either of the two packages one had to start with .

This implication comes thru use of the English verb "to merge" , used to explain PackageMerge, and the characterization of PackageMerge as "a mechanism", and from the statement in the Associations subsection that "mergingPackage references the Package that is being extended…". After being extended, a package is not what it was prior to being extended. Further, it comes from the statement, in the Semantics subsection, that "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."

Note in the sentence just quoted, the condition "unless the source package already [emphasis added] contains a classifier of the same kind with the same name. By saying this, the spec implies there is a distinction to be drawn between what th source package contains before the PackageMerge operation is performed, and what it contains afterwards .

A reductio ad absurdum argument can be posed, as follows:

Suppose for the sake of argument that a given package S, which plays the role of source (merged) package in a PackageMerge relationship, owns a classifier named E1 of kind K1, but does not own a Classifier named E2 of kind K2.

Suppose further that another package T (for Target), not the same as S, does have a Classifier named E2 of kind K2, but none named E1 of kind K1.

If S has a PackageMerge relationship with T, and PackageMerge is not an operation creating a third package distinct from S and from T, then S both does, and does not, have a Classifier named E3 of kind K2.

Therefore, PackageMerge is either an inconsistent relationship between S and T, or it is an operation on S and T which produces a third package, X, distinct from S and T.

Suggested resolution: rewrite the PackageMerge section to explicitly present it as an operation producing a new package distinct from both target and source.

see above