Constraint derivation is a methodology whereby a single high-level artifact or set of artifacts (i.e. the Reference Information Model, Universal Datatypes and Universal Vocabulary model) are developed to encompass all possible requirements in the domain space. Then subsequent artifacts are developed that represent constraints of the high level artifact to reflect the requirements in a narrower domain space. This refinement process is repeated multiple times creating more rigorous specifications for ever narrower domain areas until you reach a tightly constrained fully defined implementable specification.
| Requirement
|
Within a 'derived' artifact, it must be possible to know for every element in that artifact what corresponding element it is derived from.
|
| Rationale
|
The derivation methodology is dependent on an assumption that you can only constrain, not extend. This ensures that a given piece of information (however rare) will always be communicated in the same way. To enforce this methodology, there needs to be a correspondence between each element in the derived model with the corresponding element in the base model.
In some situations, derivation may also need to be asserted "after the fact". E.g. This template I created happens to be a proper subset of model A and model B. The only way to show that is to trace the derivation relationship of each element within the model.
|
| NOTE
|
Only elements that could conceivably be constrained require derivation relationships. For example, a "constraint" annotation could conceivably be made tighter and therefore requires a derivation relationship. On the other hand, a mapping which provides no semantic meaning cannot be constrained and therefore requires no relationship
|
| MIF
|
???/derivationSupplier
|
| OMG
|
A stereotyped UML constraint with two constrained elements, one being the derived element and the other being the element it is derived from. (UML includes the concepts of derived properties and associations, but not other kinds of elements. And UML does not provide any formal way to capture from what a derived element is derived.)
|
| Requirement
|
When capturing derivation relationships between a child and parent model, there's a need to know the 'type' of relationship.
|
| Rationale
|
In some places, the rationale allows extension as well as constraint. In some places, derived models will be constructed that are incompatible in some way. While undesirable, it occurs and needs to be exposed. Also, derivation relationships can be asserted after the fact. E.g. "This profile is 'almost' compatible with this specification'
|
| Methodology
|
Possible derivation relationships are:
- restriction: The current element is a proper subset of the element it was derived from, but is not identical.
- extension: The element derived from is a proper subset of this element, but is not identical.
- conflicting: Neither the element nor the element derived from are proper subsets of the other.
- annotated: The element is unchanged from the element it is derived from with the exception of descriptive annotations. For datatype derivations, this effectively creates an Alias for an existing type.
- unchanged: The element is unchanged from the element it is derived from.
|
| MIF
|
mif-core-base.xsd/Derivation/@relationship
|
| OMG
|
A tagged value of the constraint stereotype.
|
| Requirement
|
When derivations are assessed, they need to indicate whether free-text portions have been assessed in determining the derivation relationship
|
| Rationale
|
Some relationships can't be assessed by automated means. For example, changing a free-text constraint or definition. However, these changes can make a semantic break with the parent artifact. I.e. Changing the wording might extend, restrict or even be conflicting with the base wording.
|
| MIF
|
mif-core-base.xsd/Derivation/@areAnnotationsReviewed
|
| OMG
|
A tagged value of the constraint stereotype.
|
| Requirement
|
When a model is derived from another model and constraints or extensions are applied there needs to be a mechanism to capture the reason for the change.
|
| Rationale
|
Whenever a change is made in a derived model, there's a reason for the change. Understanding this reason is essential to understanding the model as well as to ongoing maintenance. E.g. "Why did we tighten the cardinality from 0..* to 1..1 in this derived model again?"
|
| MIF
|
mif-core-base.xsd/Derivation/reason
|
| OMG
|
This seems to be primarily a model management issues, though the information could also be captured using a tagged value on the constraint stereotype.
|
