Qué necesita saber antes de empezar a tomar Victrelis

The UMLClassDiag2Measurement transformation was written in 230 lines of ATL code composed of 10 transformation rules and 22 helpers. A number of the transfor- mation rules are reasonably straightforward to specify, since the source and target metamodels have a number of elements in common. For example, classes and gen- eralisations in a UML class diagram are mapped to class elements and parent/child relationships in the measurement metamodel. The UML metamodel contains a number of “similar” elements. However, these elements do not exist as distinct elements in the measurement metamodel so the decision was taken to map them to the same element of the measurement metamodel. For example, association classes and interfaces are both mapped to classes in the measurement metamodel. In some cases, elements are slightly re-interpreted; for example UML enumerations and data-types are mapped to user-defined types in the measurement metamodel, and UML primitive types correspond to “built-in” types in the measurement meta- model.

However, the measurement metamodel also makes distinctions that are not ex- plicitly present in UML class diagrams. For example, the measurement metamodel requires that the methods in a class be categorised as constructor, destructor, ac- cessor, mutator or general methods, since the kind of method can have an im- pact on coupling and cohesion metrics. The approach taken in the UMLClass- Diag2Measurement transformation was to identify and categorise such methods syntactically, based on standard naming conventions. For example, if a method has a name that begins with “get” followed by the name of an attribute of a class and it has a return parameter that is the same type as that attribute it is categorised as an accessor.

The measurement metamodel also requires that we introduce a distinction be- tween methods based on whether they were new, inherited or overridden. Thus overriddenoperations are identified in the UML context as operations that belong to a class which has an ancestor with an accessible operation with the same name and signature. Similarly, inherited operations are selected from the inherited mem- bers of the class and any operations that are identified as overridden are removed from this set. All other operations are identified as new operations. The declared and implemented methods of a class can be determined from the new, overridden and inherited methods.

While writing the transformation it was decided to make use of derived attributes as they are already implemented in the UML2 metamodel. While it would be possi- ble to re-implement this functionality in the ATL transformation, it seemed logical to reuse definitions that were already part of the target metamodel. From a test- ing point of view this could be problematic, since if we find an error in the model transformation it could be either in our ATL code or in the computation of de- rived attributes in the UML metamodel. For our purposes we will assume that the UML metamodel implementation is correct and make use of derived attributes in the transformation rather than write more complicated transformations using only non-derived attributes.

The final decision that was required was regarding mapping UML associations and other UML relationship types such as dependency, usage, abstraction and sub- stitution, since there are no corresponding concepts in the measurement metamodel. We made the decision to map association ends of associations to attributes in the measurement metamodel if and only if these ends are navigable. The owner of the attribute is the class on the opposite end of the association. All other relationships are ignored as we cannot guarantee that the different relationships mean that there will be an attribute created in the owning classes.

Any properties that belong to a class are also mapped to attributes in the mea- surement metamodel. An example of this transformation rule FieldProperty2- Attribute is given in Figure 5.4. This rule specifies that a property is trans- formed into an attribute if that property belongs to a class rather than an association. This rule means that for each property in the source model an attribute is created in the target model provided the guard of the rule evaluates to true. The guard is defined using the helper function isField. This helper returns true if the owner of the property is a class, interface or association class. In the case of the property

rule FieldProperty2Attribute { from p : UML!Property(p.isField()) to a : MeasurementMetamodel!Attribute( name <- p.name, type <- p.type ) }

-- Returns true if the property is a field in a Class, Interface -- or AssociationClass, and returns false otherwise

helper context UML!Property def: isField() : Boolean = if self.owner.oclIsTypeOf(UML!Class) then true else if self.owner.oclIsTypeOf(UML!Interface) then true else if self.owner.oclIsTypeOf(UML!AssociationClass) then if self.owningAssociation.oclIsUndefined() then true else false endif else false endif endif endif;

Figure 5.4: Example of a transformation rule in ATL. This piece of ATL code shows a

transformation rule, FieldProperty2Attribute, and an associated helper opera- tion called isField.

being owned by an association class an additional check is performed to ensure that the property is not an association end. In all other situations the helper returns false. The name and type of the newly created attribute is set using the name and type of the attributes matching property in the source model.

5.4

Measurement of Java programs: The Java2Measurement