![](bg6.png)
both the model itself (M) and its transformation as specified by the technical actor
interpretation (T). High relevance means that no more statements are included in the
model than those which are going to be transformed. Relevance can be measured as
the percentage of model elements actually used in a particular transformation. Making
a larger model than necessary has a negative consequence in MDD; one has to drag
along unused model elements (or code), which may complicate documentation, blur
comprehension and hamper maintenance.
Precision reflects the level of detail and accuracy required for a model to be
transformed successfully. The result of the transformation may be another model,
which in case must be well-formed. Or, the result may be program code which can be
compiled without errors and which constitutes some meaningful result, e.g. a
component, a class structure or an interface. It may be possible to measure precision
on a scale (ordinal or interval). However, these authors prefer to evaluate model
precision as yes/no. This means, either the model is sufficiently precise for
transformation, or it is not.
Well-formedness is a syntactic quality of utmost importance to model
transformation. According to OMG [2], a transformation from one model to another is
dependent on a mapping between the two respective metamodels. Hence, any model
to be transformed must comply with its metamodel. For example, a model written in
UML must comply with UML’s metamodel. Also, there may exist sub-languages with
limitations on the vocabulary and/or grammar rules of the overall language. Examples
of such sub-languages are UML profiles. A well-formed model complies not only to
its metamodel, but also to its sub-language (profile) if appropriate. A measure of well-
formedness should yield 100 % before transformation is started.
3.3 Maintainability
3.3.1 Traceability
Traceability has been pointed out as an important aspect of MDD. One of the
purposes of maintaining traces between model elements is to check a model element’s
origin, e.g. in a requirement model, and to follow a model element through
transformations. In the latter case, the trace can also tell what kind of transformation
was used, and which transformation rule was applied. Albeit traceability doubtlessly
may involve more than one model, and indeed may involve artefacts other than
models, this section discusses traceability as a quality of a model. This means, to what
degree the model is usable in a scenario where traceability is needed.
Traceability may be vital for the management of large MDD projects, and for the
maintenance of systems built according to MDD. Tool-supported traceability may
range from “enterprise-wide” traceability solutions to simple traces maintained by the
modelling workbench. A model’s traceability depends on unique identifiers for the
different elements that constitute the model; otherwise no traces can be established.
Unique identifiers are supported by some modelling tools, but not all. In addition to
the identification of model elements, one will need a mechanism that logs and
documents all transitions undergone by each model element. Such a mechanism is
currently under development in the IST project MODELWARE [8].
32