Towards the effective use of traceability in Model-Driven Engineering projectsIván Santigo, Juan M. Vara, Valeria de Castro, Esperanza Marcos32nd International Conference on Conceptual Modeling (ER 2013) |
|
iTrace MetamodelThe iTrace metamodel is defined to support the modeling of traces obtained from the execution of transformations and the processing of weaving models. |
iTrace Denormalized MetamodelThe 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. |
Model-Driven Analysis. Mapping rules overviewThe 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
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 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. |
Model-Driven Analysis. Mapping rules workloadThe 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:
|
Likewise, the model elements that will be object of consideration can be filtered according to another set of criteria:
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
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 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. |