user-defined links that might be necessary to meet different project needs [7]. On the
other hand, since the choice of semantic, attributed to a link, is guided by the reasoning
about what the user will perform with the link [1], not predefining the link semantics,
may result in failure of reasoning, due to misuse of the semantics.
3 Traceability Approach
The main idea of our approach is to rely on work and solutions already available and
not to implement yet another transformation language. Nevertheless, is the aim to fo-
cus on current traceability solutions, consolidate benefits of implicit and explicit trace
link generation and tackle the above-mentioned challenges to derive the necessary re-
quirements for a generic traceability framework. In essence, our approach follows two
research directions both based on a commonly used conceptional layer. The main moti-
vation for such a conceptional layer is based on the idea, proposed in [7], that the kind
of traceability data to be collected is dependent on the actual traceability goal, that is,
which traceability question is expected to be answered. To formalize this traceability
concern, a system of rules and regulations is necessary, on when to trace, what kind of
traceability data; additionally, to specify, the granularity level and what kind of trace
links are allowed between certain artefact types, given a certain traceability goal. This
formalization will be defined w.r.t a domain specific language for traceability, which
is called Trace-DSL in the following. The Trace-DSL logic encompasses all heuris-
tics on how to manifest traceability-specific rules for arbitrary model transformation
approaches, providing explicit knowledge to the developer on their integration.
To create a traceability model we discussed two classes of transformationapproaches
in section 2. Explicit trace link generation requires the incorporation of additional trans-
formation rules to generate trace links. As this task is generally done manually, it is
likely to be error-prone and time consuming. Although work has been done on the au-
tomation, e.g. [6], still every transformation template needs to be adapted individually,
for the explicit generation. For generators, that already provide a dedicated traceability
support, e.g. QVT, this effort would theoretically not be necessary, yet there is a need
to tune the level of granularity of trace links, as motivated in section 2. Native tracing
without a clear rule system on the conditions and measures of tracing, may lead to an
unnecessary overkill of traceability information, performance issues and violation of
security measures. The guidance, to trace only relevant information is provided by the
Trace-DSL.
Hence, the following two research directions are investigated, showing different
approaches on how to achieve the population of a traceability metamodel. The first re-
search direction (Fig.1a) is proposedto enhance the generatorlogic itself for the purpose
of traceability functionality. a) Augmentation of the generator logic: One way to pop-
ulate a traceability metamodel is to provide a generic interface and trace engine for arbi-
trary generators. In this case the interface supplies the engineer with an API to connect
his generator to the trace engine. As a result, the generator is featured with traceability
functionality. The interface is based on the Trace-DSL, to account for a formalized rule
system on traceability. The second approach (Fig.1b) to be examined follows the idea
of high order transformations and in contrast to the first approach does not focus on the
46