In this paper we describe the use of ATL as part of a tool chain that calculates coverage measures for UML class diagrams. The tool chains uses the USE tool as a parser and validator for UML diagrams, and represents the diagrams internally using the EMF framework. ? This work is supported by a John & Pat Hume Scholarship from NUI Maynooth.
Typically, test suites for source code can be measured in terms of their coverage
of code features, such as statement, condition or decision coverage. In the context
of Model Driven Engineering (MDE), a considerable body of research exists in
the area of model-based testing [
In this paper we restrict our attention to structural speci cation, in
particular UML class diagrams. These have the unusual feature that their instances,
namely object diagrams, are explicitly available in UML, making it possible to
calculate coverage data entirely within the UML framework. In this context,
coverage calculation becomes a matter of quantifying these diagrams, and is thus
closely related to deriving metrics for models. While there have been a number
of di erent approaches to this problem, we limit ourselves to those based entirely
in an MDE framework, and distinguish three main types of approach:
I. De ne the metrics directly as queries over the UML diagram [
Of course many other variations are possible. A further elaboration of
approach III, not considered here, would be to represent the metric speci cations
themselves explicitly as a metamodel, following the UML22Measure approach
[
As a trivial example to distinguish approaches I-III, consider the task of counting the number of classes in a UML class diagram. Following approach I we would simply de ne an OCL query on the class diagram metamodel to count and return the number of classes. Following approach II, we would de ne a transformation that would count the classes, and its target metamodel would be instantiated with the relevant name-value pair to represent the result. Finally, following approach III, we would rst de ne a transformation to project the relevant classes to a metamodel of measurable entities, and the metrics themselves would be de ned as queries over that metamodel.
We believe the third approach has a number of advantages. First, it clearly
separates the three steps of the measurement process, which, following Kuhne
[
In this paper we describe the use of ATL (ATLAS Transformation Language)
in extending our previous work [
Implementation
As a rst step to implement a coverage tool for UML class diagrams we have
implemented a tool-chain to calculate Generalisation (GN ) coverage [
EMF (Eclipse Modeling Framework) is framework within the Eclipse IDE that
provides code generation and tool support for modelling and metamodelling.
ATL is a model transformation language that transforms models based on
OCLlike rules [
Figure 1 shows how USE, EMF and ATL are linked together in a tool-chain to perform coverage calculations. The inputs to the tool chain are a class diagram and one or more corresponding object diagrams, speci ed using the USE syntax. The output is an XML le representing an instance of our coverage metamodel.
Our tool-chain essentially uses the USE tool as a parser and validator for the class and object diagrams. This seemed more e cient than using other UML tools since USE is open-source, provides a good GUI to allow viewing of object and class diagrams, and provides many more facilities than shown here, which we hope to exploit in the future.
We have modi ed the USE tool in two ways. First we have annotated the USE Java source code that represents a UML metamodel, and used this as input to EMF to generate a UML metamodel in ECore format. Second we have implemented a visitor that walks an object diagram and generates the Java code that, when compiled and run, instantiates our EMF metamodel.
As shown in Figure 1, the output of the USE layer in our tool chain is a class diagram and a corresponding object diagram, both represented as instances of a corresponding ECore metamodel in EMF. <?xml version="1.0" encoding="ISO-8859-1"?> <xmi:XMI xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.nuim.lunar="http:///org/nuim/lunar.ecore"> <instantiatedClass name="Dolphin"> <generalisation src="Dolphin" dst="Aquatic" name="Dolphin"/> <generalisation src="Aquatic" dst="Animal" name="Dolphin"/> <generalisation src="Dolphin" dst="Mammal" name="Dolphin"/> <generalisation src="Mammal" dst="Animal" name="Dolphin"/> <GN Coverage count="4" maximum="10" value="0.4" accValue="0.4"/> </instantiatedClass> <instantiatedClass name="Pig"> <generalisation src="Pig" dst="Terrestrial" name="Pig"/> <generalisation src="Terrestrial" dst="Animal" name="Pig"/> <generalisation src="Pig" dst="Mammal" name="Pig"/> <generalisation src="Mammal" dst="Animal" name="Pig"/> <GN Coverage count="4" maximum="10" value="0.4" accValue="0.8"/> </instantiatedClass> <instantiatedClass name="Trout"> <generalisation src="Trout" dst="Aquatic" name="Trout"/> <generalisation src="Aquatic" dst="Animal" name="Trout"/> <generalisation src="Trout" dst="Fish" name="Trout"/> <generalisation src="Fish" dst="Animal" name="Trout"/> <GN Coverage count="4" maximum="10" value="0.4" accValue="1.0"/> </instantiatedClass> </xmi:XMI> In order to calculate the class model coverage data, a coverage metamodel shown in Figure 2(a) has been designed and used as the target model for an ATL transformation. The coverage metamodel contains a list of instantiated classes, each of which may have zero or multiple generalisation links. Each instantiated class stores relevant values in one GN Coverage. Then the ATL transformation takes in the necessary data from the class and object diagrams, projects out the countable entities, in this case generalisation links, abstracts to record instances of these from the object diagram, and uses ATL rules to transform this to the relevant coverage data.
Figure 2(b) shows a UML class diagram, taken from an introductory text on
UML [17, pg 226]. This class diagram has 8 classes in total, with 10 generalisation
links between these classes. Thus, by the generalisation criterion proposed by
Andrews et al. [
In fact, to calculate GN Coverage it is only necessary to consider whether or not a given class has been instantiated at least once. For example, knowing that the class P ig from Figure 2(b) has been instantiated allows us to conclude that the four generalisation links between P ig and Animal have been covered. Figure 3 shows an example of the XML coverage le that is output for an object diagram containing at least one instantiation of Dolphin, P ig and T rout. At present our tool chain is limited in functionality as it only calculates generalisation coverage and a restricted version of association coverage. However, we believe that as a prototype it demonstrates the feasibility of the approach. We are currently working on an extension of the tool to handle other features of UML class and object diagrams, and hope eventually to harness the OCL constraints to assist in completing the coverage measures for class diagrams.