Simple inheritance
Asset B inherits from asset A. Inherited are all features from asset A except display labels and type declarations but including incoming arcs. Inherited features are placed in front of the features in asset B, eventually some features replaced by overriding features from asset B.
Asset B may override features. A feature F1 inherited from asset A is overridden by a feature F2 of asset B if both F1 and F2 have the same signature. The following table shows how signatures are computed:
| Feature | Signature | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Primary key | The key name, if not defined the list of field names, sorted in alphabetic order | ||||||||
| Properties | Signatures are derived
from property definitions by removing all sub-properties, cardinality
constraints, and type definitions. In case of simple properties this boils
down to the name of the property. In case of unions and bags, the sub-signatures of their elements are first brought into alphabetic order before constructing the complete signature. Examples:
Note: Signatures are constructed on syntactical level. Semantically equivalent property expressions such as ((a|b),(a|c)) and (a,(b|c)) may have different signatures and, if so, do not override each other. |
||||||||
| Outgoing arcs | The role name of the arc. If no role is specified the role name defaults to the name of the target asset. | ||||||||
| Clusters | The list of role names of the clusters members, sorted alphabetically | ||||||||
| Constraints | Context expression + constraint text | ||||||||
| Operations | Context expression + operation name | ||||||||
| Annotations | Context expression + annotation text in canonical XML form. Annotations defined in Level 2 Structures and on model level are not inherited. | ||||||||
| Incoming arcs | The role name of the arc plus the qualified arc of the origin asset. |
Note: Should two features within the same asset have identical signatures, an order number is added to the signature to differentiate between the two features. If, for example, asset X has two properties named "a", and asset Y has three properties named "a", the first "a" of X matches with the first "a" of Y, the second "a" of X matches with the second "a" of Y, and the third "a" of Y does not match.
How primary keys are overridden:
A primary key that overrides a inherited key with the same signature does not simply replace the inherited key. Instead, it's set of key fields is computed as the union of its own key fields and the key fields of the inherited key.
How arcs are inherited:
Both incoming and outgoing arcs are replicated. Incoming arcs will acquire a cluster at their source end (if they do not already origin from a cluster). If a range specification of an inherited arc does not fit into the new environment, the range specification is removed, i.e. the range of the arc is the default range.
Inheritance and Namespaces
Inheritance can happen across namespaces but the inherited properties are incorporated into the namespace of the inheriting asset. We say, that the inherited property transcends into the new namespace. Consequently, the properties of each asset are always in the namespace of the asset.
Multiple inheritance
is possible, provided the definitions made in assets A1 and A2 are compatible. Definitions inherited by asset B from both A1 and A2 are constructed by intersection: if two definitions are incompatible, their intersection is empty.
Again, signatures are used to decide which features must be matched.
Examples:
| From A1 | From A2 | To B | Remark |
name(first,last) |
- |
name(first,last) |
no conflict |
integer duration |
float duration |
- |
types are incompatible |
integer duration |
short duration |
short duration |
narrower type wins |
item? |
item+ |
item |
Intersection of [0..1] and [1..*] |
name(first*,last) |
name(first,middle?,last) |
name(first,last) |
Intersection of [0..*] and [1..1] Intersection of [0..0] and [0..1] |
name(first,last) |
name |
- |
not compatible |
How primary keys are combined:
The fields sets of primary keys with the same signature are joined by union.
How arcs are combined:
Arcs that refer to different keys but have the same signature are considered incompatible. When two compatible arcs are matched, their cardinality constraints are narrowed by intersection.
Example: arc1 [0..5], arc2 [2..*], result is [2..5].
The only exception are arcs within clusters: in this case their cardinality constraints are widened.
Example: arc1 [0..5], arc2 [2..*], result is [0..*].
Clustered inheritance
works differently. The inheriting asset first inherits from the first member of the cluster, producing a derived asset. This process is repeated by stepping through all the members of the cluster. Each time we get a different derived asset. Finally, the original asset is replaced by this group of derived assets.
For a given structure with cluster inheritance we can always construct an equivalent asset structure without cluster inheritance, as far as the relationships between assets are concerned. Given, for example, the following structure:
we can resolve this by using display labels to mimic a union between assets:
Note: Resolving a clustered inheritance in such a way can conflict with the organization of Level 2 Structures!
Optional inheritance
An inheritance arc may be decorated with a "?" to denote optional inheritance. Optional inheritance from an asset A is equivalent to clustered inheritance from that asset A and an empty asset.
For example:
can be resolved into:
