**4.2 Dynamic analysis**

Dynamic analysis operates by generating execution snapshots to collect life cycle traces of object instances and observing the executions to extract information. Ernst (2003) argues that whereas the chief challenge of static analysis is choosing a good abstract interpretation, the chief challenge of performing good dynamic analysis is selecting a representative set of test cases. A test case can help to detect properties of the program, but it can be difficult to detect whether results of a test are true program properties or properties of a particular execution context. The main limitation of dynamic analysis is related to the quality of the test cases used to produce diagrams.

Integrating dynamic and static analysis seems to be beneficial. The static and dynamic information could be shown as separated views or merged in a single view. In general, the outcome of the dynamic analysis could be visualized as a set of diagrams, each one associated with one execution trace of a test case. Although, the construction of these diagrams can be automated, their analysis requires human intervention in most cases. Dynamic analysis depends on the quality of the test cases.

Maoz and Harel (2010) present a powerful technique for the visualization and exploration of execution traces of models that is different from previous approaches that consider execution traces at the code level. This technique belongs to the domain of model-based dynamic analysis adapting classical visualization paradigms and techniques to specific needs of dynamic analysis. It allows relating the system execution traces and its models in different tasks such as testing whether a system run satisfies model properties. We consider that these results allow us to address reverse engineering challenges in the context of modeldriven development.

#### **4.3 An example: Recovering class diagram**

In this section we describe how to extract class diagrams from Java code. A class diagram is a representation of the static view that shows a collection of static model elements, such as

MDA-Based Reverse Engineering 75

usage of weakly typed container. Then, associations determined from the types of container declarations in the text do not specify the type of the contained object. A specialization of the generic forward propagation algorithm shown in 4.1 can be defined to solve this

Another problem is how to distinguish between aggregation or composition. For instance, the association between A and B (Figure 4) could be an aggregation or a composition. An aggregation models the situation where an object is made up of several parts. Other

 type-anti-symmetry: the aggregation from a type A (as whole) to a type B (as part), prevents the existence of another aggregation from B ( as a whole) to A ( as part)

Milanova (2007) proposes an implementation-level ownership and composition model and a static analysis for identifying composition relationships in accordance with the model. In addition, they present an evaluation which shows that the analysis achieves "almost perfect

Another problem is how to infer OCL specifications (e.g. preconditions and postconditions of operations, invariants and association constraints) from code. In these cases, we need to

Dynamic analysis allows generating execution snapshot to collect life cycle traces of object instances and reason from tests and proofs. Execution tracer tools generate execution model snapshots that allow us to deduce complementary information. The execution traces of different instances of the same class or method, could guide the construction of invariants or

Dynamic analysis could also help to detect lifetime dependencies in associations scanning dependency configurations between the birth and death of a part object according to those

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

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

properties that characterize the aggregation are the following:

precision, that is, it almost never misses composition relationships".

capture system states through dynamic analysis.

**5. Specifying metamodel-based transformations** 

pre- and post-conditions respectively.

of the whole.

with EMOF.

problem.

 instance-reflexivity instance anti-symmetry

classes, interfaces, methods, attributes, types as well as their properties (e.g., type and visibility). Besides, the class diagram shows the interrelationships holding among the classes (UML, 2010a; UML, 2010b).

Some relevant work for automatic extraction of UML class diagram is present in the literature (Telea et al, 2009) (Milanova, 2007).

Reverse engineering of UML class diagram annotated in OCL from code is difficult task that cannot be fully automated. Certain elements in the class diagram carry behavioral information that cannot be inferred just from the analysis of the code.

A basic algorithm to extract class diagrams can be based on a purely syntactic analysis of the source code.

Figure 4 shows relationships that can be detected in this way between a Java program and a UML class diagram.

By analyzing the syntax of the source code, internal class features such as attributes and methods and their properties (e.g. the parameters of the methods and visibility) can be recovered. From the source code, associations, generalization, realizations and dependencies may be inferred too.

Fig. 4. ISM Java constructs versus PSM Java constructs

The main problems of the basic syntactic analysis are linked to the fact that declared types are an approximation of the classes instantiated due to inheritance and interfaces or, the 74 Reverse Engineering – Recent Advances and Applications

classes, interfaces, methods, attributes, types as well as their properties (e.g., type and visibility). Besides, the class diagram shows the interrelationships holding among the classes

Some relevant work for automatic extraction of UML class diagram is present in the

Reverse engineering of UML class diagram annotated in OCL from code is difficult task that cannot be fully automated. Certain elements in the class diagram carry behavioral

A basic algorithm to extract class diagrams can be based on a purely syntactic analysis of the

Figure 4 shows relationships that can be detected in this way between a Java program and a

By analyzing the syntax of the source code, internal class features such as attributes and methods and their properties (e.g. the parameters of the methods and visibility) can be recovered. From the source code, associations, generalization, realizations and dependencies

The main problems of the basic syntactic analysis are linked to the fact that declared types are an approximation of the classes instantiated due to inheritance and interfaces or, the

information that cannot be inferred just from the analysis of the code.

(UML, 2010a; UML, 2010b).

source code.

UML class diagram.

may be inferred too.

literature (Telea et al, 2009) (Milanova, 2007).

Fig. 4. ISM Java constructs versus PSM Java constructs

usage of weakly typed container. Then, associations determined from the types of container declarations in the text do not specify the type of the contained object. A specialization of the generic forward propagation algorithm shown in 4.1 can be defined to solve this problem.

Another problem is how to distinguish between aggregation or composition. For instance, the association between A and B (Figure 4) could be an aggregation or a composition. An aggregation models the situation where an object is made up of several parts. Other properties that characterize the aggregation are the following:


Milanova (2007) proposes an implementation-level ownership and composition model and a static analysis for identifying composition relationships in accordance with the model. In addition, they present an evaluation which shows that the analysis achieves "almost perfect precision, that is, it almost never misses composition relationships".

Another problem is how to infer OCL specifications (e.g. preconditions and postconditions of operations, invariants and association constraints) from code. In these cases, we need to capture system states through dynamic analysis.

Dynamic analysis allows generating execution snapshot to collect life cycle traces of object instances and reason from tests and proofs. Execution tracer tools generate execution model snapshots that allow us to deduce complementary information. The execution traces of different instances of the same class or method, could guide the construction of invariants or pre- and post-conditions respectively.

Dynamic analysis could also help to detect lifetime dependencies in associations scanning dependency configurations between the birth and death of a part object according to those of the whole.
