*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.
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:
• merged package - the first operand of the merge, that is, the package that is to be merged into the receiving package (this is the package that is the target of the merge arrow in the diagrams).
• receiving package - the second operand of the merge, that is, the package that, conceptually, contains the results of the merge (and which is the source of the merge arrow in the diagrams). However, this term is used to refer to the package and its contents before the merge transformations have been performed.
• resulting package - the package that, conceptually, contains the results of the merge. In the model, this is, of course, the same package as the receiving package, but this particular term is used to refer to the package and its contents after the merge has been performed.
• merged element - refers to a model element that exists in the merged package.
• receiving element - is a model element in the receiving package. If the element has a matching merged element, the two are combined to produce the resulting element (see below). This term is used to refer to the element before the merge has been performed (i.e., the increment itself rather than the result).
• resulting element - is a model element in the resulting package after the merge was performed. For receiving elements that have a matching merged element, this is the same element as the receiving element, but in the state after the merge was performed. For merged elements that have no matching receiving element, this is the merged element. For receiving elements that have no matching merged element, this is the same as the receiving element.
• element type - refers to the type of any kind of TypedElement , such as the type of a Parameter or StructuralFeature.
• element metatype - is the MOF type of a model element (e.g., Classifier, Association, Feature).
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.
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:
1. There can be no cycles in the «merge» dependency graph.
2. A package cannot merge a package in which it is contained.
3. A package cannot merge a package that it contains.
4. A merged element whose metatype is not a kind of Package, Class, DataType , Property, Association, Operation, Constraint, Enumeration, or EnumerationLiteral , cannot have a receiving element with the same name and metatype unless that receiving element is an exact copy of the merged element (i.e., they are the same).
5. A package merge is valid if and only if all the constraints required to perform the merge are satisfied.
6. Matching typed elements (e.g., Properties, Parameters) must have conforming types. For types that are classes or data types, a conforming type is either the same type or a common supertype. For all other cases, conformance means that the types must be the same.
7. A receiving element cannot have explicit references to any merged element. TRANSFORMATIONS:
1. (The default rule) Merged or receiving elements for which there is no matching element are deep copied into the resulting package.
2. The result of merging two elements with matching names and metatypes that are exact copies of each other is the receiving element.
3. Matching elements are combined according to the transformation rules specific to their metatype and the results included in the resulting package.
4. All type references to typed elements that end up in the resulting package are transformed into references to the corresponding resulting typed elements (i.e., not to their respective increments).
5. For all matching elements: if both matching elements have private visibility, the resulting element will have private visibility, otherwise, the resulting element will have public visibility.
6. For all matching classifier elements: if both matching elements are abstract, the resulting element is abstract, otherwise, the resulting element is non-abstract.
7. For all matching elements: if both matching elements are not derived, the resulting element is also not derived, otherwise, the resulting element is derived.
8. For all matching multiplicity elements: the lower bound of the resulting multiplicity is the lesser of the lower bounds of the multiplicities of the matching elements.
9. For all matching multiplicity elements: the upper bound of the resulting multiplicity is the greater of the upper bounds of the multiplicities of the matching elements.
10. Any stereotypes applied to a model element in either a merged or receiving element are also applied to the corresponding resulting element.
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:
2. An element import owned by the receiving package is transformed into a corresponding element import in the resulting package. Imported elements are not merged (unless there is also a package merge to the package owning the imported element or its alias).
1. A nested package from the merged package is transformed into a nested package with the same name in the resulting package, unless the receiving package already contains a matching nested package. In the latter case, the merged
nested package is recursively merged with the matching receiving nested package.
Class and DataType rules
Elements that are kinds of Class or DataType match by name and metatype. TRANSFORMATIONS:
1. All properties from the merged classifier are merged with the receiving classifier to produce the resulting classifier according to the property transformation rules specified below.
2. Nested classifiers are merged recursively according to the same rules.
Property rules
Elements that are kinds of Property match by name and metatype. CONSTRAINTS:
1. The static (or non-static) characteristic of matching properties must be the same.
2. The uniqueness characteristic of matching properties must be the same.
3. Any constraints associated with matching properties must not be conflicting.
4. Any redefinitions associated with matching properties must not be conflicting. TRANSFORMATIONS:
1. For merged properties that do not have a matching receiving property, the resulting property is a newly created property in the resulting classifier that is the same as the merged property.
2. For merged properties that have a matching receiving property, the resulting property is a property with the same name and characteristics except where these characteristics are different. Where these characteristics are different, the resulting property characteristics are determined by application of the appropriate transformation rules.
3. For matching properties: if both properties are designated read-only, the resulting property is also designated read-only. Otherwise, the resulting property is designated as not read-only.
4. For matching properties: if both properties are unordered, then the resulting property is also unordered. Otherwise, the resulting property is ordered.
5. For matching properties: if neither property is designated as a subset of some derived union, then the resulting property will not be designated as a subset. Otherwise, the resulting property will be designated as a subset of that derived union.
6. For matching properties: different redefinitions of matching properties are combined conjunctively.
7. For matching properties: different constraints of matching properties are combined conjunctively.
8. For matching properties: if either the merged and/or receiving elements are non-unique, the resulting element is non-unique. Otherwise, the resulting element is designated as unique.
9. The resulting property type is transformed to refer to the corresponding type in the resulting package.
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:
1. These rules only apply to binary associations. (The default rule is used for merging n-ary associations.)
2. The receiving association end must be a composite if the matching merged association end is a composite.
3. The receiving association end must be owned by the association if the matching merged association end is owned by the association.
TRANSFORMATIONS:
1. A merge of matching associations is accomplished by merging the Association classifiers (using the merge rules for classifiers) and merging their corresponding owned end properties according to the rules for properties and association ends.
2. For matching association ends: if neither association end is navigable, then the resulting association end is also not navigable. In all other cases, the resulting association end is navigable.
Operation rules
Elements that are a kind of Operation match by name, parameter order, and parameter types, not including any return type.
CONSTRAINTS:
1. Operation parameters and types must conform to the same rules for type and multiplicity as were defined for properties.
2. The receiving operation must be a query if the matching merged operation is a query. TRANSFORMATIONS:
1. For merged operations that do not have a matching receiving operation, the resulting operation is an operation with the same name and signature in the resulting classifier.
2. For merged operations that have a matching receiving operation, the resulting operation is the outcome of a merge of the matching merged and receiving operations, with parameter transformations performed according to the property transformations defined above.
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.
