- Merging -
The ability to merge two or more models becomes important in large
scenarios, where applications are developed by multiple groups, or when
distinct applications grow together.
When merging two models, we usually have to deal with conflicting
definitions. We adopt the strategy to loosen constraints so that the
model can host all instances from the original models. Because this
results in a
loss of semantic information, the original models still remain
provide a specific view on the new model. This merging method is used
models from different domains into one integrated model.
To merge two models M1 and M2 into a new model M3, we use
- Namespace. M3 may establish a new default namespace. If
the default namespaces of M1 or M2 do not match this new default
namespace, their default namespace definitions are converted into
namespace prefix definitions.
- Scopes. The set S3 of scopes of the new model M3
is a union of the scopes S1 and S2 from M1 and M2. Duplicates are
- Assets. We construct a union of
assets belonging to M1 and M2.
- Assets that did not specify scopes, now do specify the
scopes of their original model (M1 or M2) if the new set of default
scopes S3 is unequal S1 or S2.
- Identically named assets that belong to the same namespace
and the same scope are merged into a single asset.
- L2S. Level 2 structures are
merged when their identifying assets are merged (see below).
- Annotations. Annotations in
models M1 and M2 and in all Level 2 Structures within M1 and M2 are
resolved before the merge is performed. "Resolved" means that all
annotations with context expressions are copied into their respective
target assets. The original definition is removed.
The set of annotations of the new model M3 is the union of the sets of
the remaining annotations from M1 and M2. Duplicates are removed.
When merging two assets A1 or A2 , the following rules
- Level 2 structures.
- If both A1 and A2 belong to the same Level 2 structure the
resulting asset A3 belongs to this L2S, too.
- If both A1 and A2 belong to different Level 2 structures S1
and S2, the resulting asset A3 belongs to S1. This means that the order
in which submodels are included has influence on the structure of the
- Scopes. The scopes of A1 and A2 are united. Duplicates are
removed. If A1 or A2 has a global scope, A3 has a global scope, too.
- Properties. The property collections (either sequences or
bags depending on the compositor) from A1 and A2 are connected with a
choice operator. The resulting regular expression can be algebraically
transformed in order to simplify it.
- Keys. The set of keys of the new
asset A3 is the union of the key sets from A1 and A2.
- Label. The set of display names
of the new asset A3 is the union of the display name sets from A1 and
- Constraints. The set of constraints of the new asset A3 is
the intersection if the set of constraints from asset A1 and the set of
constraints of asset A2.
- Operations. The set of abstract operations of the new asset A3 is the
union of the sets of abstract operations from A1 and A2. Duplicates are
- Annotations. The set of
annotations of the new asset A3 is the union of the sets of
annotations from A1 and A2. Duplicates are removed.
- Subject IDs. The subject IDs of A1 and A2 are united.
Duplicates are removed.
- Arcs. The set of arcs emanating
from the new asset A3 is the union of the sets of emanating arcs from
A1 and A2.
The set of arcs leading to the new asset A3 is the union of the sets of
arcs leading to A1 and A2.
Two arcs with the same origin and the same target are merged into one
arc, if their role names are identical. All other arcs are made
Cardinality constraints are merged in the following way:
Convert all constraints into the canonical form [n:m].
Merge [n1:m1] and [n2:m2] to [n:m] by
computing n = min(n1,n2), m = max(m1,m2).
When merging two
Level 2 structures
S1 and S2, the following rules apply:
Annotations. The set of annotations of the new Level 2
Structure S3 is the union of the sets of remaining annotations from S1
and S2. Duplicates are removed.
- Labels. The set of labels
of S3 is the union of the sets of labels from S1 and S2.
- Nested L2S. The set of nested L2S
of S3 is the union of the sets of nested L2S from S1 and S2.
Nested assets. The set of nested assets of S3 is the union of the sets of nested
assets from S1 and S2.
When merging two models, the merging process can be influenced by
applying a scope
to one or both components:
- Only those assets are considered for
merging that satisfy the specified scope.
- Only those arcs are considered for merging
whose target assets satisfy the specified scope.
- Only those L2S are considered for
merging whose identifying assets satisfy the specified scope. When an
L2S is discarded, its contents are moved into the container of the
When merging two models, the merging process can be influenced by
bindings between the two components. Bindings can be applied to L2S and assets. Given
model A and B, the following bindings
can be applied:
- An asset from model A may be mapped onto one or several
assets of model B. Copies of the model A asset will be merged with the
target assets in model B under the name of the respective target asset.
Similarly, an L2S from model A may be mapped onto one L2S of
model B. Both L2S will be merged. Additional bindings can be applied to
the contents of model A.
- One or several clones of an asset from model A may be created
in model B under different names. Similarly, one clone of an L2S from
model A may be created in model B under new display labels.
- An asset from model A may be suppressed and will not appear in
model B. Similarly, an L2S from model A may be suppressed and will not
appear in model B. Its contents, however, are unaffected, and can be
- An asset or L2S from model A may be merged into model B without
any modifications. This is the default when no binding was specified.
Structural restrictions apply. When an L2S L1 of model A is bound to
L2 of model B the contents of L1 must not be bound to items outside of
The application of Design Patterns to
similar to the merging of two models. The following differences apply:
default namespace of the pattern is not converted into a prefixed
namespace but vanishes. Items belonging to
this default namespace are transcended into the default namespace of
the target model. Practically, this has little consequences
because it is recommended to
explicitly bind each pattern item belonging to the pattern's default
to an element in the target model.
- Merging a pattern asset with a target model asset is done by
using the rules for asset inheritance
instead of using the asset merging rules outlined above. This means
that the target model asset inherits (and possibly overrides) the
features of the pattern asset it is merged with.
- During the binding process patterns are more flexible than models
pattern can define iteration constraints for asset and L2S other than
Contact: support 'at' aoModeling.org