Information Technology Reference
In-Depth Information
and that traceability itself is seen as a burden until it is necessary later on
although its benefits have been tested [24]. This situation creates a problem
which makes dicult to succesfully apply traceability.
In order to alleviate the first drawback, a classification of eight categories for
traces was presented in [26]. The second and third drawbacks can be solved by
automating the trace recording. However, in the RE field, the trace recording is
focused on pre-RS traceability, and needs to find traces in documents in natural
language. In turn, this generates models that must be supervised, with a high
percentage of irrelevant traces that dicult the comprehension and visualization
of the trace model, which usually has a huge number of traces already [28].
On the other hand, in the MDD field, the MDA framework is used [1, 5, 11,
22, 28]. The automatic derivation process starts from a CIM layer, where the
requirements are specified as models, usually by means of goal-oriented models
[7, 13, 15, 18, 21, 25, 32]. In this sense, the traceability research in the MDD field
is mainly focused on post-RS, which makes the automation of traces an easier
task and less prone to errors, since everything is either a model or an element in
a model. However, although more restrictive, the traceability definitions in this
field are not standard either. There are mainly two definitions of traceability in
the MDD community. The definition we will use in this paper comes from [22];
They define traceability as “[...] the ability to chronologically interrelate uniquely
identifiable entities in a way that matters. [...] [It] refers to the capability for
tracing artifacts along a set of chained [manual or automated] operations.”
In the DW field, as we previously stated, there is no mention of traceability
being included in the process, even though there are approaches which would
benefit from it. These approaches are based on model transformations through
multiple layers, either following MDA [16] or a similar set of layers [27]. Currently,
whenever a change to an element is done, the traceability as defined in [22] is lost,
since the elements are associated by name matching. Therefore, we lose all the
aforementioned benefits of traceability, which can be obtained in the DW field at
a low cost, since trace recording can be automated. Moreover, the quality metrics
presented in [27] could be provided in a more automated way with traceability
support, as opposed to performing the process manually, allowing us to increase
the quality of the final implementation.
Due to the peculiarity and idiosyncrasy of data warehouses, we will need to
difference between (i) the traces coming from the requirements (for requirements
validation and impact change analysis), (ii) the traces coming from the data
sources (for querying and derivation of initial Extraction, Transformation and
Load processes) and (iii) the traces linking elements in the multidimensional
conceptual models, based on their particular relationships [14].
3 A Traceability Approach and a Trace Metamodel for
Data Warehouses
As previously stated, if we wish to perform automatic operations with traces,
we must be able to identify the meaning of each trace. In order to do this, we
