**5. Specifying metamodel-based transformations**

We specify reverse engineering processes as MOF-based transformations. Metamodel transformations impose relations between a source metamodel and a target metamodel, both represented as MOF-metamodels. The transformations between models are described starting from the metaclass of the elements of the source model and the metaclass of the elements of the target model. The models to be transformed and the target models will be instances of the corresponding metamodel. Transformation semantics is aligned with QVT, in particular with the QVT Core. QVT depends on EssentialOCL (OCL, 2010) and EMOF (MOF, 2006). EMOF is a subset of MOF that allows simple metamodels to be defined using simple concepts. Essential OCL is a package exposing the minimal OCL required to work with EMOF.

A code-to-model transformation is the process of extracting from a more detailed specification (or code) another one, more abstract, that is conformed to the more detailed

MDA-Based Reverse Engineering 77

includes(sClass)) implies SetClassSource -> exists (t1 | t1.superclass.name = sClass.name)…

(source.ownedMember -> select(oclIsKindOf (JavaClass).extendingClass ->

Fig. 5. PSM and ISM Java Metamodels

specification. Next, we describe how to specify code-to-model transformations within the proposed framework.

Figure 5.b shows partially an ISM-Java metamodel that includes constructs for representing classes, fields and operations. It also shows different kind of relationships such as composition and generalization. For example, an instance of JavaClass could be related to another instance of JavaClass that takes the role of *superclass* or, it could be composed by other instances of JavaClass that take the role of *nestedClass*. Figure 5.b shows the metamodel for operations. An operation is a subtype of the metaclass Operation of the UML kernel. There is a generalization between operation, constructor and method and so on.

Figure 5.a shows partially a PSM-Java metamodel that includes constructs for representing classes, fields, operations and association-ends. It also shows different kind of relationships such as composition and generalization. For example, an instance of JavaClass could be related to another instance of JavaClass that takes the role of *superclass* or, it could be composed by other instances of JavaClass that takes the role of *nestedClass*. The main difference between a Java-ISM and a Java-PSM is that the latter includes constructs for associations.

The transformation specification is an OCL contract that consists of a name, a set of parameters, a precondition and postconditions. The precondition states relations between the metaclasses of the source metamodel. The postconditions deal with the state of the models after the transformation. Next, a model-to-code transformation between an ISM-Java and a PSM-Java is partially specified.

**Transformation** ISM-Java to PSM-Java

#### **parameters**

source: ISM-JavaMetamodel::JavaPackage

target: PSM-JavaMetamodel ::Java Package

#### **postconditions**

**let** SetClassSource: Set[ISM-JavaMetamodel::JavaPackage::JavaClass] =

source.ownedMember -> select (oclIsKindOf (JavaPackage).javaClasses

**in** /\*for each Java class in the ISM exists a PSM class with the same name\*/

SetClassSource -> forAll (sClass| target.ownedMember ->select (oclIsKindOf (JavaClass))->

exists (tClass|sClass.name = tClass.name) and

 /\*for each associationEnd of a class in the PSM exists a private attribute of the same name in the ISM\*/

sClass.fields->forAll (sField| SetClassSource->

exists (tc1| tc1.type = sField.type implies tc1.associationEnd -> includes (sField.type)

and /\*for each extends relation in Java exists a generalization in the PSM\*/

76 Reverse Engineering – Recent Advances and Applications

specification. Next, we describe how to specify code-to-model transformations within the

Figure 5.b shows partially an ISM-Java metamodel that includes constructs for representing classes, fields and operations. It also shows different kind of relationships such as composition and generalization. For example, an instance of JavaClass could be related to another instance of JavaClass that takes the role of *superclass* or, it could be composed by other instances of JavaClass that take the role of *nestedClass*. Figure 5.b shows the metamodel for operations. An operation is a subtype of the metaclass Operation of the UML kernel.

Figure 5.a shows partially a PSM-Java metamodel that includes constructs for representing classes, fields, operations and association-ends. It also shows different kind of relationships such as composition and generalization. For example, an instance of JavaClass could be related to another instance of JavaClass that takes the role of *superclass* or, it could be composed by other instances of JavaClass that takes the role of *nestedClass*. The main difference between a Java-ISM and a Java-PSM is that the latter includes constructs for

The transformation specification is an OCL contract that consists of a name, a set of parameters, a precondition and postconditions. The precondition states relations between the metaclasses of the source metamodel. The postconditions deal with the state of the models after the transformation. Next, a model-to-code transformation between an ISM-Java

There is a generalization between operation, constructor and method and so on.

proposed framework.

associations.

**parameters** 

**postconditions** 

in the ISM\*/

and a PSM-Java is partially specified. **Transformation** ISM-Java to PSM-Java

source: ISM-JavaMetamodel::JavaPackage target: PSM-JavaMetamodel ::Java Package

exists (tClass|sClass.name = tClass.name) and

sClass.fields->forAll (sField| SetClassSource->

**let** SetClassSource: Set[ISM-JavaMetamodel::JavaPackage::JavaClass] = source.ownedMember -> select (oclIsKindOf (JavaPackage).javaClasses

**in** /\*for each Java class in the ISM exists a PSM class with the same name\*/

SetClassSource -> forAll (sClass| target.ownedMember ->select (oclIsKindOf (JavaClass))->

/\*for each associationEnd of a class in the PSM exists a private attribute of the same name

exists (tc1| tc1.type = sField.type implies tc1.associationEnd -> includes (sField.type)

and /\*for each extends relation in Java exists a generalization in the PSM\*/

(source.ownedMember -> select(oclIsKindOf (JavaClass).extendingClass ->

includes(sClass)) implies SetClassSource -> exists (t1 | t1.superclass.name = sClass.name)…

MDA-Based Reverse Engineering 79

The level of formal specification includes specifications of MOF metamodels and metamodel transformations in the metamodeling language NEREUS that can be used to connect them

Our framework could be considered as an MDA-based formalization of the process described by Tonella and Potrich (2005). In this chapter we exemplify the bases of our approach with Class Diagram reverse engineering. However, our results include algorithms for extracting different UML diagrams such as interaction diagram, state diagram, use case diagram and activity diagram (Favre, 2010) (Favre, Martinez & Pereira, 2009) (Pereira,

Nowadays, software and system engineering industry evolves to manage new platform technologies, design techniques and processes. Architectural frameworks for information integration and tool interoperation, such as MDA, had created the need to develop new

A challenge on reverse engineering is the necessity to achieve co-evolution between different types of software artifacts or different representations of them. MDA allows us to develop and relate all different artifacts in a way that ensures their inter-consistency. MDA raises the level of reasoning to a more abstract level and therefore even more appropriate placing change and evolution in the center of software development process. The integration of business models with PIM, PSMs and code is a crucial challenge in

Existing formal methods provide a poor support for evolving specifications and incremental verification approaches. In particular, with the existing verification tools, simple changes in a system require to verify its complete specification again making the cost of the verification proportional to its size. To use formal methods that place change and evolution in the center of the software development process is another challenge. The progress in the last decade in scalability and incremental verification of formal methods could impact in MDA reverse

OMG is involved in the definition of standards to successfully modernize existing information systems. Concerning ADM, current work involves building standards to facilitate the exchange of existing systems meta-data for various modernization tools. The main limitations of MDA tools are related to the incipient evolution of MDA standards such as QVT or KDM and to the lack of specification in terms of these standards of various

In summary, a lot remains to be done to provide support for MDA-based software evolution: research on formalisms and theories to increase understanding of software evolution processes; development of methods, techniques and heuristics to provide support for software changes; new verification tools that embrace change and evolution as central in software development processes; development of new sophisticated tools to develop industrial size software systems and definition of standards to evaluate the quality of

with different formal and programming languages.

Martinez & Favre, 2011) (Martinez, Pereira, & Favre, 2011).

**7. Challenges and strategic directions** 

analysis tools and specific techniques.

MDA.

engineering processes.

evolved artifacts/systems.

platforms and bridges between platforms.
