Previous UML Classes Table of Contents UML Packages Next


7.3.40 PackageMerge

Kernel


   A package merge defines how the contents of one package are extended by the contents of another package.

*Generalizations

   

    DirectedRelationship (from Kernel ) on page 62

*Description

   A package merge is a directed relationship between two packages that indicates that the contents of the two packages are to be combined. It is very similar to Generalization in the sense that the source element conceptually adds the characteristics of the target element to its own characteristics resulting in an element that combines the characteristics of both.

   This mechanism should be used when elements defined in different packages have the same name and are intended to represent the same concept. Most often it is used to provide different definitions of a given concept for different purposes, starting from a common base definition. A given base concept is extended in increments, with each increment defined in a separate merged package. By selecting which increments to merge, it is possible to obtain a custom definition of a concept for a specific end. Package merge is particularly useful in meta-modeling and is extensively used in the definition of the UML metamodel.

   Conceptually, a package merge can be viewed as an operation that takes the contents of two packages and produces a new package that combines the contents of the packages involved in the merge. In terms of model semantics, there is no difference between a model with explicit package merges, and a model in which all the merges have been performed.

*Attributes

   No additional attributes

*Associations

*Constraints

   No additional constraints

*Semantics

   A package merge between two packages implies a set of transformations, whereby the contents of the package to be merged are combined with the contents of the receiving package. In cases in which certain elements in the two packages represent the same entity, their contents are (conceptually) merged into a single resulting element according to the formal rules of package merge specified below.

   As with Generalization, a package merge between two packages in a model merely implies these transformations, but the results are not themselves included in the model. Nevertheless, the receiving package and its contents are deemed to represent the result of the merge, in the same way that a subclass of a class represents the aggregation of features of all of its superclasses (and not merely the increment added by the class). Thus, within a model, any reference to a model element contained in the receiving package implies a reference to the results of the merge rather than to the increment that is physically contained in that package. This is illustrated by the example in Figure 7.65 in which package P1 and package P2 both define different increments of the same class A (identified as P1::A and P2::A respectively). Package P2 merges the contents of package P1, which implies the merging of increment P1::A into increment P2::A. Package P3 imports the contents of P2 so that it can define a subclass of A called SubA. In this case, element A in package P3 (P3::A) represents the result of the merge of P1::A into P2::A and not just the increment P2::A. Note that if another package were to import P1, then a reference to A in the importing package would represent the increment P1::A rather than the A resulting from merge.

Figure 7.65 - Illustration of the meaning of package merge

   To understand the rules of package merge, it is necessary to clearly distinguish between three distinct entities: the merged increment (e.g., P1::A in Figure 7.65), the receiving increment (e.g., P2::A), and the result of the merge transformations. The main difficulty comes from the fact that the receiving package and its contents represents both the operand and the results of the package merge, depending on the context in which they are considered. For example, in Figure 7.65, with respect to the package merge operation, P2 represents the increment that is an operand for the merge. However, with respect to the import operation, P2 represents the result of the merge. This dual interpretation of the same model element can be confusing, so it is useful to introduce the following terminology that aids understanding:

    This terminology is based on a conceptual view of package merge that is represented by the schematic diagram in Figure

    7.66 (NB: this is not a UML diagram). The owned elements of packages A and B are all incorporated into the namespace of package B. However, it is important to emphasize that this view is merely a convenience for describing the semantics of package merge and is not reflected in the repository model, that is, the physical model itself is not transformed in any way by the presence of package merges.

Figure 7.66 - Conceptual view of the package merge semantics

   The semantics of package merge are defined by a set of constraints and transformations. The constraints specify the preconditions for a valid package merge, while the transformations describe its semantic effects (i.e., postconditions). If any constraints are violated, the package merge is ill formed and the resulting model that contains it is invalid. Different metatypes have different semantics, but the general principle is always the same: a resulting element will not be any less capable than it was prior to the merge. This means, for instance, that the resulting navigability, multiplicity, visibility, etc. of a receiving model element will not be reduced as a result of a package merge. One of the key consequences of this is that model elements in the resulting package are compatible extensions of the corresponding elements in the (unmerged) receiving package in the same namespace. This capability is particularly useful in defining metamodel compliance levels such that each successive level is compatible with the previous level, including their corresponding XMI representations.

   In this specification, explicit merge transformations are only defined for certain general metatypes found mostly in metamodels (Packages, Classes, Associations, Properties, etc.), since the semantics of merging other kinds of metatypes (e.g., state machines, interactions) are complex and domain specific. Elements of all other kinds of metatypes are transformed according to the default rule: they are simply deep copied into the resulting package. (This rule can be superseded for specific metatypes through profiles or other kinds of language extensions.)

   General package merge rules

   A merged element and a receiving element match if they satisfy the matching rules for their metatype.

   CONSTRAINTS:

   Package rules

   Elements that are a kind of Package match by name and metatype (e.g., profiles match with profiles and regular packages with regular packages).

   TRANSFORMATIONS:

   Class and DataType rules

   Elements that are kinds of Class or DataType match by name and metatype. TRANSFORMATIONS:

   Property rules

   Elements that are kinds of Property match by name and metatype. CONSTRAINTS:

   Association rules

   Elements that are a kind of Association match by name (including if they have no name) and by their association ends where those match by name and type (i.e., the same rule as properties). These rules are in addition to regular property rules described above.

   CONSTRAINTS:

   TRANSFORMATIONS:

   Operation rules

   Elements that are a kind of Operation match by name, parameter order, and parameter types, not including any return type. CONSTRAINTS:

   Enumeration rules

   Elements that are a kind of EnumerationLiteral match by owning enumeration and literal name. CONSTRAINTS:

   1. Matching enumeration literals must be in the same order. TRANSFORMATIONS:

   1. Non-matching enumeration literals from the merged enumeration are concatenated to the receiving enumeration.

   Constraint Rules

   CONSTRAINTS:

   1. Constraints must be mutually non-contradictory. TRANSFORMATIONS:

   1. The constraints of the merged model elements are conjunctively added to the constraints of the matching receiving model elements.

*Notation

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


   Figure 7.67 - Notation for package merge

*Examples

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

   PQA AC


   


«merge»


   B



   


«merge»

   S

   «merge»


   R


   D


   A

   A

   B

   Figure 7.68 - Simple example of package merges

    The transformed packages R and S are shown in Figure 7.69. The expressions in square brackets indicating which individual increments were merged into produce the final result, with the @ character denoting the merge operator (note that these expressions are not part of the standard notation, but are included here for explanatory purposes).


   Figure 7.69 - Simple example of transformed packages following the merges in Figure 7.68

    In Figure 7.70, additional package merges are introduced by having package T, which is empty prior to execution of the merge operation, merge packages R and S defined previously.


   Figure 7.70 - Introducing additional package merges

    In Figure 7.71, the transformed version of package T is depicted. In this package, the partial definitions of A, B, C, and D have all been brought together. 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 elements in package T.

Figure 7.71 - The result of the additional package merges in Figure 7.70