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|
|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:
|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.|
|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?"|