**3.2 Transforming metamodels into NEREUS**

We define a bridge between EMOF- and Ecore- metamodels and NEREUS. The NEREUS specification is completed gradually. First, the signature and some axioms of classes are obtained by instantiating reusable schemes. Associations are transformed by using a reusable component ASSOCIATION. Next, OCL specifications are transformed using a set of transformation rules and a specification that reflects all the information of MOF metamodels is constructed.

The OCL basic types are associated with NEREUS basic types with the same name. NEREUS provides classes for collection type hierarchies. The types Set, Ordered Set, Bag and Sequence are subtypes of Collection.

The transformation process of OCL specifications to NEREUS is supported by a system of transformation rules. By analyzing OCL specifications we can derive axioms that will be included in the NEREUS specifications. Preconditions written in OCL are used to generate preconditions in NEREUS. Postconditions and invariants allow us to generate axioms in NEREUS. We define a system of transformation rules that only considers expressions based on Essential OCL (OCL, 2010). The following metaclasses defined in complete OCL are not part of the EssentialOCL: *MessageType, StateExp, ElementType, AssociationClassCallExp, MessageExp,* and *UnspecifiedValueExp*. Any well-formed rules defined for these classes are consequently not part of the definition of the transformation rule system.

The system includes a small set with around fifty rules. It was built by means of an iterative approach through successive refinements. The set of rules was validated by analyzing the different OCL expression attached to the UML metamodels, MOF and QVT.

As an example we show a few rules of the system. A detailed description of the system may be found at (Favre, 2010). In each rule the shaded text denotes an OCL expression that can be translated by the non-shaded text in NEREUS:


66 Reverse Engineering – Recent Advances and Applications

NEREUS is an intermediate notation open to many other formal languages such as algebraic, logic or functional. We define its semantics by giving a precise formal meaning to each of the constructs of the NEREUS language in terms of the CASL language (Bidoit &

We define a bridge between EMOF- and Ecore- metamodels and NEREUS. The NEREUS specification is completed gradually. First, the signature and some axioms of classes are obtained by instantiating reusable schemes. Associations are transformed by using a reusable component ASSOCIATION. Next, OCL specifications are transformed using a set of transformation rules and a specification that reflects all the information of MOF

The OCL basic types are associated with NEREUS basic types with the same name. NEREUS provides classes for collection type hierarchies. The types Set, Ordered Set, Bag and

The transformation process of OCL specifications to NEREUS is supported by a system of transformation rules. By analyzing OCL specifications we can derive axioms that will be included in the NEREUS specifications. Preconditions written in OCL are used to generate preconditions in NEREUS. Postconditions and invariants allow us to generate axioms in NEREUS. We define a system of transformation rules that only considers expressions based on Essential OCL (OCL, 2010). The following metaclasses defined in complete OCL are not part of the EssentialOCL: *MessageType, StateExp, ElementType, AssociationClassCallExp, MessageExp,* and *UnspecifiedValueExp*. Any well-formed rules defined for these classes are

The system includes a small set with around fifty rules. It was built by means of an iterative approach through successive refinements. The set of rules was validated by analyzing the

As an example we show a few rules of the system. A detailed description of the system may be found at (Favre, 2010). In each rule the shaded text denotes an OCL expression that can

consequently not part of the definition of the transformation rule system.

different OCL expression attached to the UML metamodels, MOF and QVT.

operation(*Translate*NEREUS(v),*Translate*NEREUS (parameters))

operation(*Translate*NEREUS(v),*Translate*NEREUS (parameters))

be translated by the non-shaded text in NEREUS:

**Rule OCL** 

**R3** v.attribute

**NEREUS** 

**R1** v. operation(parameters)

**R2** v->operation (parameters)

attribute (v) **R4 context** Assoc

> object.rolename *Let a:Assoc*

 *g*et\_rolename (a, object)

Mosses, 2004).

metamodels is constructed.

Sequence are subtypes of Collection.

**3.2 Transforming metamodels into NEREUS** 


As an example, we show the formalization in NEREUS of a simplified QVT Core metamodel (Figure 2). The Core language is as powerful as the Relation language and may be used as a reference for the semantics of relations, which are mapped to Core. The complete diagram may be found at (QVT, 2008, pp.15). Figure 2 shows a simplified metamodel including transformation and rules classes.

Fig. 2. A simplified metamodel

A transformation defines how one set of models can be transformed into another. It is composed by a set of rules that specify its execution behavior. The following constraints (*extendingRule* and *transitiveRule*) may be attached to Figure 2 specifying that the rules of the extended transformation are included in the extending transformation and the extension is transitive:

**extendingRule** = Transformation.allInstances -> forAll (t |t.extends.size = 1 implies t.extends.rule -> include (t.rule)) **transitiveRule** = Transformation.allInstances -> forAll (t1, t2, t3 | t1.extends.size = 1 and t2.extends.size = 1 and t3.extends.size = 1 and (t1.extends.rule -> includes (t2.rule) and t2.extends.rule -> includes (t3.rules)) implies t1.extends.rule -> includes (t3.rule)

The OCL specification, *extendingRule* and *transformationRule* can be translated into the shaded axioms of the following specification:

**PACKAGE** QVTBase **CLASS** Transformation **IMPORTS** EMOF::Tag **INHERITS** EMOF::MetaClass, EMOF::Package

MDA-Based Reverse Engineering 69

particular. Static analysis extracts static information that describes the structure of the software reflected in the software documentation (e.g., the text of the source code) while dynamic analysis information describes the structure of the run-behavior. Static information can be extracted by using techniques and tools based on compiler techniques such as parsing and data flow algorithms. On the other hand, dynamic information can be extracted

Figure 3 shows the different phases. The source code is parsed to obtain an abstract syntax tree (AST) associated with the source programming language grammar. Next, a metamodel extractor extracts a simplified, abstract version of the language that ignores all instructions that do not affect the data flows, for instance all control flows such as conditional and loops. The information represented according to this metamodel allows building the OFG for a given source code, as well as conducting all other analysis that do not depend on the graph. The idea is to derive statically information by performing a propagation of data. Different kinds of analysis propagate different kinds of information in the data-flow graph, extracting

The static analysis is based on classical compiler techniques (Aho, Sethi & Ullman, 1985) and abstract interpretation (Jones & Nielson, 1995). The generic flow propagation algorithms are specializations of classical flow analysis techniques. Because there are many possible executions, it is usually not reasonable to consider all states of the program. Thus, static analysis is based on abstract models of the program state that are easier to manipulate, although lose some information. Abstract interpretation of program state allows obtaining automatically as much information as possible about program executions without having to

The static analysis builds a partial model (PIM or PSM) that must be refined by dynamic analysis. Dynamic analysis is based on testing and profiling. Execution tracer tools generate execution model snapshots that allow us to deduce complementary information. Execution models, programs and UML models coexist in this process. An object-oriented execution model has the following components: a set of objects, a set of attributes for each object, a location for each object, each object refers to a value of an object type and, a set of messages that include a name selector and may include one or more arguments. Additionally, types are available for describing types of attributes and parameters of methods or constructors. On the other hand, an object-oriented program model has a set of classes, a set of attributes for each class, a set of operations for each class, and a generalization hierarchy over classes. The combination of static and dynamic analysis can enrich the reverse engineering process. There are different ways of combination, for instance performing first static analysis and

The concepts and algorithms of data flow analysis described in (Aho, Sethi & Ullman, 1985) are adapted for reverse engineering object-oriented code. Data flow analysis infers information about the behavior of a program by only analyzing the text of the source code. The basic representation of this static analysis is the Object Flow Graph (OFG) that allows tracing information of object interactions from the object creation, through object assignment

run the program on all input data and then ensuring computability or tractability.

then dynamic analysis or perhaps iterating static and dynamic analysis.

**4.1 Static analysis** 

by using debuggers, event recorders and general tracer tools.

the different kinds of diagrams that are included in a model.

**ASSOCIATES** <<Transformation-Tag>> <<Transformation-Transformation>> <<Transformation-Rule>> <<Transformation-TypeModel>> **AXIOMS** ass1: <<Transformation-Transformation>>; ass2: <<Transformation-Rule>> ; t: Transformation ;… size (get\_extends (ass1, t)) = 1 implies includes (get\_rule (ass2, get\_extends (ass1, t)), get\_rule (ass1, t)) **END-CLASS CLASS** TypedModel **IMPORTS** EMOF::Package **IS-SUBTYPE-OF** EMOF::NamedElement **ASSOCIATES** <<Transformation-TypeModel>> <<TypeModel-Package>> <<Domain-TypeModel>> <<TypeModel-TypeModel>> **END-CLASS CLASS** Domain **IS-SUBTYPE-OF** EMOF::NamedElement **ASSOCIATES** <<Rule-Domain>> <<Domain-TypeModel>> **DEFERRED ATTRIBUTES** isCheckable: Domain -> Boolean isEnforceable: Domain -> Boolean **END-CLASS CLASS** Rule **IS-SUBTYPE-OF** EMOF::NamedElement **ASSOCIATES** <<Rule-Domain>> <<Rule-Rule>> <<Transformation-Rule>> **END-CLASS ASSOCIATION** Transformation-Transformation **IS** Unidirectional-2 [Transformation: class1; Transformation: class2; extendedBy: role1; extends: role2; \*: mult1; 0..1: mult2; +: visibility1; + : visibility2] **END-ASSOCIATION ASSOCIATION** Transformation-Rule **IS** Composition-2 [Transformation: class1; Rule: class2; transformation: role1; rule: role2; 1: mult1; \*: mult2; +: visibility1; +: visibility2] **END-ASSOCIATION... END-PACKAGE** 

NEREUS can be integrated with object-oriented languages such as Eiffel. The article (Favre, 2005) describes a forward engineering process from UML static models to object-oriented code. More information related to the NEREUS approach may be found at (Favre, 2010) and (Favre, 2009). However, we would like remark that here NEREUS is used as an intermediate formal notation to communicate the essential of an MDA reverse engineering approach.
