Logo Kybele

Towards the effective use of traceability in Model-Driven Engineering projects

Iván Santigo, Juan M. Vara, Valeria de Castro, Esperanza Marcos

32nd International Conference on Conceptual Modeling (ER 2013)

iTrace Process

Move mouse over each phase for more information

process

Click here to view full size figure.


iTrace Metamodel

The iTrace metamodel is defined to support the modeling of traces obtained from the execution of transformations and the processing of weaving models.

Click on image to view full size


iTrace Denormalized Metamodel

The iTrace denormalized metamodel is devised to support an intermediate step in the analysis process implemented by iTrace. In particular, the different iTrace models are consumed by an ATL transformation to produce "agregated" information in the form of an iTrace denormalized model.

Click on image to view full size

Model-Driven Analysis. Mapping rules overview

The goal of the Data-Oriented Analysis supported by iTrace is to elicit knowledge from the trace models of the project under study. To that end, denormalized trace models are used to populate QlikView dashboards. As a result, high-level overviews of the relationships between the artefacts involved in the development process are obtained.

Figure A shows a code excerpt from the UML2SQL2003 transformation. In particular, it shows the MemberEnd2NotNullOnTT mapping rule. To understand the functionality of this rule and what type of elements it maps, a minimum knowledge of ATL is needed.

By contrast, a quick look at the dashboard (Figure B) beside shows at first sight which the purpose of the mapping rule is. Indeed, no previous knowledge of ATL is needed. The information displayed on the upper side of the dashboard reveals that the rule maps objects from UML models into SQL2003 objects. In particular, the lower side of the dashboard shows that the rule is responsible for mapping pairs of Class and Property objects into NotNull objects.

Note that the dashboard provides this type of information for all the transformations that conform the project under study. The upper side of the dashboard provides a set of filters that allow the user to select a particular transformation, source model, target model or mapping rule/s (non-selected filtering values are greyed-out). The bottom part of the dashboard shows the type of elements transformed by the mapping rules that meet the criteria established by the user. Note also that this analysis may be useful in order to document not only m2m transformations, but also m2t ones.

(A) ATL Rule

(B) Mapping rules overview dashboard

Click on image to view full size

Model-Driven Analysis. Mapping rules workload

The dashboard shown in figure goes a step further, since it provides a closer look at the transformations. In particular, it allows identifying which are the rules involved in a given transformation and which is their role in the project. The latter refers to the workload of such rules, i.e. the amount of objects effectively mapped by the mapping rule under consideration. To that end, upper side of the dashboard bundles a set of controls to define high-level criteria for the analysis. This way, the traces that will be analyzed can be filtered according to:

  • Transformations: only traces produced by the select model transformations will be considered.
  • Type: only model-to-model or model-to-text traces will be considered.
  • Transformation Rule: only traces produced by the selected mapping rules will be considered.

Click on image to view full size

Likewise, the model elements that will be object of consideration can be filtered according to another set of criteria:
  • Artefact: only elements included in the selected models or source-code files will be considered.
  • Relation Type: depending on the selection, only model elements used that were either as source or target objects of the selected transformations will be considered.
  • Abstraction Level: only model elements belonging to models defined at the selected abstraction levels will be considered.
  • Artefact Type: depending on the selection, only model elements or source-code blocks will be considered.

Obviously, none of the criteria above are mandatory. That is to say, the user might set no values for any of them. If so, no filtering is applied and every trace (respectively model element) is considered in the analysis. Once the criteria have been fixed (if any), the central and lower part of the dashboard collects aggregated data regarding the number of traces, model elements (referred to as traced elements) and source-code blocks, which fulfill the criteria. In this case, the table in the middle shows which are the mapping rules producing more traces. In particular, it shows the top 8 rules, while the rest are blended into the Others row.

First and second columns show respectively the transformations and mapping rules rules under consideration (those that meet the filtering criteria). Next columns show the number of trace links produced by each mapping rule and the percentage over total number of traces produced by the mapping rules selected. Following columns show also the number of model elements and source-code blocks referenced by each mapping rule. For instance, second row of the table states that the MemberEnd2NotNullOnTT of the UML2SQL2003 transformation generates 16 trace links (15.38% over the total number of trace links produced by the selected mapping rules) and such links refer to 48 model elements (note that not every trace link represents a one-to-one relationship).

Finally, lower side of the dashboard provides different views of these data. The bar graph on the left summarizes the number of trace links produced by each transformation rule, while the pie chart on the right represents the distribution of traced elements by transformation rule.