International Journal on Software Tools for Technology Transfer
https://doi.org/10.1007/s10009-024-00735-4

FOUNDATION FOR MASTERING CHANGE
Regular

A process for creating KDM2PSM transformation engines
Guisella Angulo1 · Daniel San Martín2 · Fabiano Ferrari1 · Ignacio García-Rodríguez de Guzmán3 ·Ricardo Perez-Castillo3 · Valter Vieira de Camargo1
Accepted: 2 January 2024
© The Author(s), under exclusive licence to Springer-Verlag GmbH Germany, part of Springer Nature 2024

Abstract

Architecture-Driven Modernization (ADM) is a special kind of reengineering that employs models along the process. The
main ADM metamodel is the Knowledge Discovery Metamodel (KDM), which is a platform-independent metamodel able
to represent several views of a system. Although a lot of research is currently focused on the reverse engineering phase of
ADM, little has been devoted to the forward engineering one, mainly on the generation of Platform-Speciﬁc Models (PSMs)
from KDM. The forward engineering phase is essential because it belongs to the end of the horseshoe model, completing
the reengineering process. Besides, the lack of research and the absence of tooling support in this phase hinder the industrial
adoption of ADM. Therefore, in this paper, we present a process for creating Transformation Engines (TEs) capable oftransforming KDM instances in a chosen PSM. We highlight two main contributions in this work. The ﬁrst is a process thatsoftware engineers can follow for building TEs capable of generating PSM instances (e.g., Java model, Python model, etc.)from KDM instances. Having that on their hands, modernization engineers can then use generators for generating languagespeciﬁc source code from the PSM. The second is delivering a speciﬁc TE called RUTE-K2J, which is able to generateJava models from KDM models. The transformation rules of RUTE-K2J have been tested considering sets of common code
structures that normally appear when modernizing systems. The test cases have shown that in this version of RUTE thetransformation rules are able to correctly generate 92% of the source code submitted to the transformation.
Keywords Model transformation · KDM · PSM · Java model · Software modernization · Code generation

1 Introduction

 G. Angulo

guisella.angulo@estudante.ufscar.br
D. San Martín
daniel.sanmartin@ucn.cl
F. Ferrari
fcferrari@ufscar.br
I. García-Rodríguez de Guzmán
Ignacio.GRodriguez@uclm.es
R. Perez-Castillo
Ricardo.PdelCastillo@uclm.es
V. Vieira de Camargovaltervcamargo@ufscar.br1

Computing Department, Federal University of São Carlos, SãoCarlos, SP, Brazil

2

Engineering School, Catholic University of the North, Coquimbo,
Chile

3

Institute of Technology and Information Systems, University ofCastilla – La Mancha, Ciudad Real, Spain

Software systems are acknowledged as legacy when they exhibit two main characteristics: (i) high maintenance costs(eﬀort/time/resources) and (ii) being still essential to support current business processes. These systems cannot be
discarded since they retain mission-critical business knowledge incorporated along years of maintenance [1]. For many
years, traditional software reengineering has been used as asolution to this challenge, since it retains all the knowledgeof these systems. However, it is well known that 50% of thereengineering projects fail, and one of the main reasons is thelack of standardization, which hinders the reusability of solutions and interoperability among reengineering tools [2, 3].
In 2003 the Object Management Group (OMG) started
the elaboration of the Architecture-Driven Modernization(ADM). The main idea was to deﬁne standards for the reengineering process to promote industry consensus on modernization solutions and elevating the success in modernization
projects.
Many companies have demonstrated interest in the ADM
philosophy, as can be seen in the ADM vendor directory
SpringerG. Angulo et al.

listing website [4]. There are several IT companies listed as
ADM partners. Some companies are specialized in modernizing systems, whereas others oﬀer this type of service intheir portfolio of solutions.
The most important ADM metamodel is the Knowledge
Discovery Metamodel (KDM) [5]. Its goal is to capture
and represent system architecture details in a platform andlanguage-independent way. One of the main problems KDM
intends to solve is avoiding the proliferation of diﬀerent metamodels for representing legacy systems. It intends to be astandardized form of representing legacy systems, instead ofletting modernization engineers free for employing diﬀerent
metamodels.
Figure 1 shows the horseshoe reengineering cycle andhow KDM can be applied in three steps. In the reverse engineering, a legacy system is parsed into a KDM instance that
represents it. In the restructuring phase the KDM instance isrefactored to solve some identiﬁed problems or even to haveits structure improved, resulting in a new modernized KDM
instance. In the forward engineering phase the modernized
KDM is used as input for generating the system, completingthe modernization cycle. Within this last phase, there are still
two steps, the generation of a PSM instance from the KDM
and the generation of the source code from the PSM. In thispaper, we focus on the former.
As previously said, most of current research on ADM
has concentrated on the reverse engineering phase of ADM.
Some examples are MoDisco [6], Gra2Mol [7], and ThreePhase Approach [8]. However, little research has been conducted on forward engineering from KDM. There is someresearch on the entire modernization process, so they haveaddressed the forward engineering phase somehow. However, the focus of these initiatives was not on bringing contributions to the forward engineering phase; thus they do notprovide enough details about it [9, 10].
Therefore, to ﬁll this research gap, we have developed aprocess for supporting modernization engineers in the creation of transformation engines (TE) that transform KDM
instances to instances of some PSM, such as Java models,
Python models, and others. In this work, we consider that“modernization engineers” are responsible for creating tools
for supporting software modernization processes. In contrast,a software engineer is responsible for using the created tools.
The proposed process has ﬁve iterative and incremental
phases, where in each cycle, one transformation rule is developed or evolved. This process emerged from the experiencein creating a TE called RUTE-K2J that takes a KDM instanceas input and automatically generates a Java model from it.
An important point is that RUTE-K2J contributes from thesecond to the last step of ADM horseshoe model, opening
many research possibilities for researchers and also companies in the industry to assess the potential of ADM regarding
reusability, eﬀectiveness, etc.
Springer

RUTE-K2J was evaluated with test cases in order to guarantee the correctness when performing the transformations.
During the execution of the test cases, we used the support of Modisco tool to generate a KDM instance (input of
the RUTE-K2J engine) and the Acceleo tool for generating
source code from the Java model (output of the RUTE-K2J
engine). So, we compare the code generated by Acceleo
allowed to the original source code with aims at evaluating
the correctness of the transformation. Our evaluation showedthat 92% of the original source code submitted was preserved
through the transformation.
In this paper, we present the following additional contributions compared to our previous conference paper [11](Angulo et al. 2018): i) a complete rewriting of the whole
paper; ii) inclusion of new activities and phases; and iii) extension of the related work and discussion sections.
The remainder of this paper is organized as follows. Section 2 presents necessary background information related to
ADM and KDM and model transformations. Then Sect. 3
presents the guidelines for creating KDM2PSM transformation engines. In Sect. 4, we present the RUTE-K2J Transformation Engine. In Sect. 5, we present the validation of
RUTE-K2J. Section 6 brings some discussions about our approach and our results, and Sect. 7 summarizes related work.
Finally, Sect. 8 draws some conclusions and describes plans
for future work.

2 Background
2.1 ADM & KDM
In 2003, OMG proposed the Architecture-Driven Modernization (ADM), an eﬀort to standardize the process of modernization of legacy systems using models [3]. ADM promotes system modernization based on the use of models at
diﬀerent abstraction levels [12]: CIM (Computation Independent Model, PIM (Platform-Independent Model), and PSM(Platform-Speciﬁc Model). CIM focuses on the business environment, describing requirements at a very abstract level,
without any reference to implementation aspects. In addition, PIM is a representation of a system from the platformindependent viewpoint. It focuses on the operation of a system while hiding the details necessary for a particular platform. Finally, PSM is a technological view of a system fromthe point of view of a platform at a low level of abstraction. In
this context, ADM proposes the use of automated transformations between the models to generate new systems fromlegacy systems by following a horseshoe process.
The ADM modernization cycle involves three phases
shown in Fig. 1: (i) reverse engineering, (ii) restructuring,and (iii) forward engineering. In the reverse reengineering
phase the knowledge is extracted from source code, and a

RUTE-K2J
Fig. 1 Horseshoe software
modernization model

PSM is generated. The PSM model serves as the basis forgenerating a KDM considered as PIM and CIM. Then in the
restructuring phase refactorings are performed in the KDM
instance that represents the legacy system to get an improved
version of the system. Finally, in the forward engineering therefactored instance is transformed into source code again.
The proposed process focuses on the forward engineering
phase, speciﬁcally in the last two steps. Figure 1 shows thefocus of this work marked with a square with dashed line
border.
ADM considers seven standard metamodels, but currently only four of them have been released: Abstract Syntax Tree Metamodel (ASTM), Software Metrics Metamodel(SMM), Structured Patterns Metamodel Standard (SPMS),
and KDM [3]. KDM is an OMG metamodel adopted as
ISO/IEC 19506 [13, 14] capable of representing a complete
software system. It can be seen as a family of metamodels
that share the same vocabulary and terminology, facilitating
the relationships among metaclasses in diﬀerent abstractionlevels. The speciﬁcation is organized in four layers: Infrastructure Layer, Program Elements Layer, Runtime Resource
Layer, and Abstractions Layer, where each layer is basedon the previous one. These layers are further organized into
packages, and each one corresponds to a certain independent facet of knowledge about the software, such as the CodeView, Structure View, Data View, among others.
Figure 2 shows the layers and packages in KDM. The
Infrastructure Layer consists of the following three packages:
Core, “Kdm”, and Source. The Core and “Kdm” packages
deﬁne together common metamodel elements that constitutethe infrastructure for other packages. The Source package
deﬁnes the Inventory model, which enumerates the artifactsof the existing software system and deﬁnes the mechanismof traceability links between the KDM elements and their
original representation in the source code of the existing
software system.

Fig. 2 Layers and packages in KDM [5]The Program Elements Layer consists of the Code and Action packages. These packages collectively deﬁne the Codemodel that represents the implementation level assets of theexisting software system, determined by the programming
languages used in the developments of the existing software system. The Code package deﬁnes metamodel elementsthat represent low-level building blocks of software, such asprocedures, data types, classes, and variables. Examples ofthese elements are ClassUnit, MethodUnit, StorableUnit, InterfaceUnit, and PrimitiveType. The Action package deﬁnes
metamodel elements that represent statements as the relationship endpoints and most low-level KDM relationships, suchas ActionElements, ActionFlow, and DataRelations. Examples of these elements in the package are ActionElement,
Datatype, TryUnit, and CatchUnit.
The Runtime Resources Layer represents higher-levelknowledge about existing software systems; this layer has
the following four packages: Platform, UI, Event, and Data.
Finally, the Abstractions Layer represents even higher-level
SpringerG. Angulo et al.
Fig. 3 Model transformation

abstractions about existing software, such as domain-speciﬁcknowledge, business rules, implemented by the existing software system, and architectural knowledge about the existing
software system.

2.2 Model transformations
Model(-to-model) transformation is a core asset in modeldriven engineering (MDE), where models are ﬁrst-class entities. It is the process of converting models into other models
for the purposes of supporting rigorous model evolution,
veriﬁcation, reﬁnement, and code generation [15, 16].
As the work presented in this paper is totally based onmodel transformation, we use Fig. 3 for explaining the models and metamodels involved in this process. The ﬁgure isdivided into two parts separated by a dashed line. In thelower part of the ﬁgure, it is the transformation itself wherea Transformation Engine takes a model instance M A as input, executes some transformation rules (TAB ) over it, andwrites a new model instance MB . That is the process that our
Transformation Engine RUTE-K2J performs.
The upper part of the ﬁgure represents the metamodels,i.e., the model instance M A conforms to a metamodel M M A ,the transformation rule conforms to a metamodel M MT , andthe model instance MB conforms to a metamodel M MB . It
is also shown that all these metamodels (MMa, MMT, andMMb) also conforms to a metametamodel (MMM).
An important element in model transformations is thetransformation rules (TRs). TRs describe how elements of a
Springersource model should be translated into elements of a target
model. A transformation rule has two parts, a left-hand side(LHS) and a right-hand side (RHS). The LHS accesses thesource model, whereas the RHS expands in the target model.
To develop a transformation rule, it is necessary to establish a mapping between the source metamodel and the target
metamodel aiming at specifying the way that target model
elements must be generated from source model elements;
this logic must be speciﬁed using a transformation language
such as ATL and QVT (Query/View/Transformation). The
process we show in this paper guides modernization engineers in creating a set of transformation rules.
Another important element is the transformation engine
that executes the set of transformation rules. Each transformation rule has a purpose, i.e., transforming a speciﬁc
structure. Therefore the set of transformation rules allow acomplete transformation of all the structures present in the
input and create an equivalent output model. At the bottom of
Fig. 3, we can observe the transformation engine that reads
the instance M A , executes the set of transformation rules,
and writes an instance MB that conforms to M MB .
Model transformation can be classiﬁed according to themetamodels that the input and output models are conformed
to. Under this criterion, there are two types of transformation, exogenous and endogenous. An endogenous transformation, also called an inplace transformation, translates thesource model into a target model that conforms to the source
model’s metamodel, e.g., a refactoring of a KDM instance.
In contrast, an exogenous transformation, or out-place trans-

RUTE-K2J

Fig. 4 Phases of the process for creating KDM2PSM transformation engines

formation, uses diﬀerent source and target metamodels, e.g.,transforming a KDM instance to Java model instance [17],as we did here in this work. According to the transformation
directions, a transformation can be unidirectional or bidirectional. A unidirectional model transformation has only
one execution direction, that is, it always modiﬁes the target
model according to the source model. In case of bidirectionalmodel transformation, the source model may be changed
along with the target model if the transformation is executedin the direction of target-of-source.

is completed, a transformation rule is created or evolved, incase it already exists. As a result, the created rule is added
to the existing set of developed rules, complementing thetransformation engine.
Figure 5 shows the process in a deeper way, showing thephases, activities, and the main artifacts used to complete
each activity. Each following subsection details one of thephases of our process.

3 A process for creating KDM2PSM
transformation engines

The ﬁrst phase shown in Fig. 4 has two goals. The ﬁrst
one is to deﬁne which PSM (Java Model, C# Model, etc.)
will be generated. It is advisable that the chosen PSM has
complete and available documentation that explains its metaclasses, relationships, and all other structural details of themetamodel. This is important because these details will beneeded along the process. In fact, the choice of the PSM depends on the target programming language. However, mostof the time, modernization engineers know in advance inwhich language the source code must be generated.
The second goal is to elect a reverse engineering toolcapable of generating instances of the chosen PSM fromthe source code. An important point here is regarding thequality of the PSM and the reverse engineering tool chosen.
Regarding the PSM, there may exist diﬀerent versions withThis section presents our process for creating KDM2PSM
transformation engines. The process is represented in Figs. 4
and 5 in diﬀerent abstraction levels and in Table 1, whichsummarizes textually all the phases and activities. In thecase of the table, it shows a more concise way to check theactivities and input/output artifacts.
Figure 4 shows a more general view, focusing on thephases of the process. The return arrow (at the bottom) indicates the iterative and incremental nature of the process. It
is iterative because the phases can be repeated several times
until there are no more transformation requirements to beresolved. It is incremental because every time an iteration

3.1 Phase 1 – deﬁning the target PSM andreverse engineering toolSpringerG. Angulo et al.
Fig. 5 Phases and activities ofthe process for creating
KDM2PSM transformationengineTable 1 Summary of the phases and activities of the process

Phase name

Activities

Input

OutputPhase 1––

Target PSM and Reverse
Engineering tool chosen

Phase 2

Activity 2.1 Eliciting theTransformation Requirement andCode Snippets–

Transformation Requirement andSource Code Snippet

Activity 2.2 Generating theTarget PSM InstanceSource Code Snippet

Target PSM instance

Activity 2.3 Generating the
KDM instanceSource Code Snippet

KDM instance

Activity 3.1 Creating
KDM2PSM Mapping

KDM instance Target PSM
Instance

KDM-PSM mapping

Activity 3.2 Elaborating theTransformation Rule

KDM-PSM mapping

Transformation Rule

Phase 4–

Transformation Rule

Tested transformation Rule

Phase 5

Activity 5.1 Creating the
Dependency Matrix

Transformation Rules

Dependency Matrix

Activity 5.2 Identifying andPrioritizing Leaf Rules

Dependency Matrix

Leaf Rule Matrix

Activity 5.3 Deﬁning Test Data

Leaf Rule Matrix

Test Cases

Activity 5.4 Running Test Case

Test Cases

list of diﬀerences

Phase 3

Springer

RUTE-K2J

diﬀerent characteristics and metaclasses. In the same way,
there may also exist diﬀerent reverse engineering tools thatare able to generate PSM instances with subtle diﬀerences.
So, it is important for modernization engineers to be awareof these diﬀerences and choose the one that best ﬁts with therequirements. The output of this phase is the PSM metamodeland the reverse engineering tool chosen.

3.2 Phase 2 – elaborating the initial artifacts
The second phase has three activities shown in Fig. 5. This
phase aims at eliciting the transformation requirement andelaborating the PSM and KDM instance. The activities aredescribed in detail in the next subsections.
Activity 2.1 – Eliciting the transformation requirement
and code snippets
The main purpose of this activity is to elicit transformation
requirements. In the context of this work, a transformation
requirement is a textual sentence of a needed transformation,i.e., it is a textual sentence of the kind of source code elementthat the transformation engine must be able to generate in thetarget PSM. An example of a transformation requirement is
the following: “The transformation engine must be able togenerate If statements with N conditions”. Another example is “The Transformation engine must be able to generate
While statements”. In addition, eliciting the transformation
requirements is a way of documenting the transformationengine, facilitating future maintenance and evolution tasks.
After deﬁning the transformation requirement, the modernization engineer must implement or obtain a code snippetthat represents the requirement. Sometimes it will be necessary to elaborate a complete and detailed code snippet taking
into account the body, types, and relationships of the methods. In other cases, it may be necessary only to generatesignatures of methods, classes, attributes, and parameters.
Therefore this activity depends on the purpose of the code
generation. The output of the activity is the transformation
requirement and a source code snippet that represents that
requirement.
Activity 2.2 – Generating the target PSM instanceThis activity aims at generating a PSM instance froma code snippet obtained or elaborated in the previous activity, which is called here “Target PSM”. To do that, themodernization engineer needs to use the reverse engineering
tool, chosen in Phase 1, and to provide as input the codesnippet developed in the previous activity. It is important toemphasize that a metamodel involves a lot of metaclasses,
and in the case of the PSM instance, only few metaclasses
are instantiated since they represent only the transformation
requirement.
The PSM instance is an important artifact for two reasons. First, in Activity 3.1, it helps in the creation of the

mapping, i.e., in the identiﬁcation of the equivalent metaclasses between the KDM and the PSM metamodel. Second,in Activity 4.2 the PSM is used as a target to verify the integrity of the output PSM. Note that this PSM instance serves
as an oracle, since the ideal is that the transformation rulewould be able to generate an instance equivalent to the one
generated here.
To facilitate the understanding of the process, we present
a concrete example that involves the use of a speciﬁc PSM
model. So we deﬁne the Java model as the PSM and deﬁne
the following transformation requirement: “The transformation engine must be able to generate the If statements with
one condition plus the Else block”.Thus the modernizationengineer must generate a code snippet from this requirement,
and then a Java instance (PSM) is generated from this codesnippet.
Listing 1 shows part of the Java instance. In line 5, we
can observe the beginning of the If-then-else structure represented with the IfStatement metaclass in the Java instance.
In line 8, we can notice that the Boolean expression of thestructure is represented with the InﬁxExpression metaclass.
At last, in lines 11 and 14, we can observe that the Then statement and the Else statement are represented with the ThenStatement and ElseStatement, respectively; both elements areof Block metaclass type.
Activity 2.3 – Generating the KDM instanceThe goal of this activity is the generation of the KDM
instance from the source code snippet developed in Activity 2.1. To create the KDM instance, the modernization engineer must use existing modernization tools. In the literature,
there are some tools that can automate this process such as:(i) Modisco [6], which is able of generating KDM instancefrom Java source code; (ii) the tool proposed by Feliu Trias
et al. [18], which is able of obtaining the KDM instancefrom PHP source code; (iii) an approach of Christian Wulf
et al. [8], who proposed to transform C# programs to KDM;
and (iv) the commercial software BLUAGE [19], which cantransform Cobol code to KDM.
The KDM instance is an important artifact, because in
Activity 3.1, it is used (with the target PSM) in the identiﬁcation of equivalent-metaclasses. In addition, the KDM
instance is the input of Activity 4.1, and it is used as test data
to execute the transformation rule.
At this point of the process, the modernization engineer
would get the code snippet that represents the transformation requirement “If-then-else” structure, and he will use theModisco tool to generate a KDM instance.
Listing 2 shows part of the KDM instance. To recognize
their elements with the help of the KDM metamodel documentation, we can realize that, in line 6, the beginning of
the If-then-else structure is represented with the ActionElement metaclass with kind equal to If. In line 9 the Boolean
SpringerG. Angulo et al.

3.3 Phase 3 – developing transformation rule
Phase 3 has two activities shown in Fig. 5. This phase has
two goals: (i) to create the mapping between the KDM andPSM metamodels and (ii) to develop one transformation rule(TR). The created TR will be responsible for transforming
the KDM instance that represents the transformation requirement in a PSM instance representing the same requirement.
To achieve the goals, ﬁrst, the modernization engineer
needs to establish a mapping between the elements (metaclasses and attributes) of the metamodels, registering each
equivalence in the KDM2PSM mapping artifact. Then themodernization engineer develops the transformation rule
based on this knowledge. The activities of this phase areshown in Fig. 5 and are described in more detail below.

Listing 1 Target PSM of If-then-else structure

Listing 2 KDM instance of If-then-else structure

expression is represented with the ActionElement metaclasswith kind equal to Inﬁx expression. At last, we can recognize
in lines 12 and 15 the Then statement and the Else statement of the structure that are represented with the BlockUnit
metaclass in the KDM instance.
Springer

Activity 3.1 – Creating KDM2PSM mappingThis activity aims at establishing the mapping between the
PSM and KDM metaclasses. Note that the instances used forthe mapping represent the same transformation requirement.
Thus the output of this activity is the artifact that represents
the mapping between the two diﬀerent metaclasses.
To elaborate the mapping artifact, ﬁrst, the modernization engineer must look for all available information with the
purpose of obtaining in-depth understanding of the metaclasses, some information sources are the metamodel documentations, rules in the stage of reverse engineering (transformation from KDM to PSM), and scientiﬁc papers. The
modernization engineer must review all the information byfocusing on the metaclasses to increase his knowledge in themetamodels.
Second, the engineer should perform a comparative analysis between the KDM instance, output of Activity 2.3, andthe target PSM instance, output of Activity 2.2. To do this,he/she must make a list of metaclasses and attributes present
in the model instances. Then, with the documentation support, the modernization engineer must determine the semantic equivalence between the metaclasses and attributes in thelist, establishing the correspondence between the elements.
To automatize the equivalence task, the engineer may use
some available tools in the literature. For example, PérezCastillo et al. [20] presented an ontology-based clustering
technique to determine the similarity between the essential
concepts in a discourse.
Finally, the modernization engineer must identify the attributes of the PSM instance that do not have an equivalentelement in the KDM instance and vice versa. Due to the different levels of abstraction, the PSM model may require moredetailed information than that provided by KDM. Likewise,
the KDM model may contain redundant information that is
not required for the PSM model. The result of this activity is
the artifact called KDM2PSM mapping, which registers theequivalence between the KDM and PSM elements for theRUTE-K2J
Table 2 Mapping for If-then-else structure

KDM instance
Metaclass

JAVA model
Attribute

Metaclass

BlockUnit

–

Block

ActionElementkind = “if”

IfStatementkind = “inﬁxExpression”

InﬁxExpression

source code structure under analysis. This artifact is actively
queried and updated in each iteration.
Back to the If-then-else example, we compare Listing 2
that represents the KDM instance to Listing 1 that represents
the PSM instance. In line 6 of the Java model, we identify the equivalence between ActionElement metaclass withkind=if of the KDM instance and the IfStatement metaclasspresent in line 5 of the PSM instance. In line 9, we can establish the equivalence between the ActionElement metaclasses
with kind=“Inﬁx Expression” of the KDM instance and theInﬁxExpression metaclass in line 8 of the PSM instance. Inline 11 the BlockUnit metaclass of the KDM instance has its
equivalent in thenStatement with type=Block in line 12 of
the PSM instance. In line 14, similarly, the BlockUnit metaclass of the KDM instance has its equivalent in elseStatement
metaclass with type=Blockunit present in line 15 of the PSM
instance.
As a result, Table 2 shows the equivalence between the
KDM and PSM metaclasses for the If-then-else transformation requirement.
We must keep in mind that the proposed process is iterativeand incremental. This means that, ﬁrst, we need to create
basic structures and then continue with the creation of more
complex ones. For example, ﬁrst, we need to create the Classand then create the nested methods and attributes of theClass.
Activity 3.2 – Elaborating the transformation ruleThis activity aims at developing a transformation rule
responsible for transforming the structure present in KDM
instance to PSM instance, preserving the relationships embodied between the elements.
To develop the rule, ﬁrst, the modernization engineer
needs to develop the rule header. To do that, he/she needs
to use the KDM2PSM mapping artifact and the metamodel
documentation. Then he/she has to deﬁne the source andthe target of the transformation, as well as the conditions todelimit the source. It is important to note that he/she must
know a transformation language syntax to perform this task.
Second, the modernization engineer has to develop therule body. To do that, he/she must place on the left side
each attribute of the identiﬁed PSM metaclass assigning theequivalent KDM metaclass (on the right side), according to

Listing 3 KDM2Java Transformation rule

the KDM2PSM mapping artifact. Finally, one or many functions must be implemented to complete the information thatcannot be obtained directly from the source KDM instance.
Note that because of the low-level abstraction of the PSM
model, this model needs more speciﬁc information than isprovided by the KDM instance.
Continuing with the if-then-else example, Listing 3 shows
the created KDM2Java transformation rule. In line 2, weestablish as source the ActionElement metaclasse with theattribute kind=if. In line 3, we establish as target the IfStatement metaclass of the Java model. With the two ﬁrst lines,
we guarantee that each instance of the ActionElement withkind=if will have an instance of the IfStatement metaclassin the output Java model. In line 4 the attribute OriginalCompilationUnit is ﬁlled with a function that extracts thelogical location of the Java class that contains the analyzed
IfStatement structure.
In line 5, in the Java model the Expression attribute is
assigned with the CodeElement element. According to theJava metamodel documentation, the Expression attribute canreceive a set of element types including the Inﬁx Expression,and for this reason, no ﬁlter is placed in the assignment. Inline 6 the ThenStatement with Block metaclass type is assigned with the ﬁrst CodeElement with BlockUnit metaclasstype. At last, in line 8 the elseStatement with the Block metaclass type is assigned with the second CodeElement with
the BlockUnit metaclass type. It is important to note that in
the last two assignments, we need to put the CodeElement
elements respecting the order of appearance given that theKDM model does not present a diﬀerentiation between thetwo elements, i.e., which element belongs to then part andwhich element belongs to the else part in the structure.
SpringerG. Angulo et al.

3.4 Phase 4 – testing the developed ruleThis phase aims at testing the developed transformation ruleand verifying the output model completeness. To achieve thisgoal, the modernization engineer has to execute the createdtransformation rule using some transformation tool available
in literature, such as the ATL toolkit [21]. The tool must be
conﬁgured to receive the KDM instance as input. Then therule is executed obtaining as output the output PSM instance.
To verify the model completeness, the output PSM iscompared with the PSM instance generated in Activity 2.2.
So modernization engineers must compare both instancesline by line looking for diﬀerences between the ﬁles. If any
diﬀerence is found, then a structure is absent, and this will
be an indicator that the transformation rule is not correctly
developed, and it will be necessary to reﬁne it by returning to
Activity 3.2. The output of this activity is a list of diﬀerences
between the models.

3.5 Phase 5 – appending the transformation ruleand evaluating the transformation ngine
This phase aims at appending the just created transformation
rule to the set of transformation rules created in previous
iterations. Furthermore, this phase also aims at evaluating
the transformation engine to verify if all the created TRs
meet their purpose and to evaluate whether the combinationof rules results in correct transformations.
Figure 5 shows Phase 5 and its four activities. These activities help to build the test cases for evaluating the transformation engine as a whole. Activity 5.1 aims at creating
a matrix with all transformation rules to identify the dependencies between them. In Activity 5.2 the rules called leaf
are identiﬁed and prioritized. In this work, a leaf rule is a rulethat does not depend on other rules, but other rules dependon it. In Activity 5.3 the leaf rules are combined to select thetest cases. Finally, in Activity 5.4 the test cases are executed.
The activities are described with more detail below.
Activity 5.1 – Creating the dependency matrix
This activity aims at creating a dependency matrix for
identifying the dependencies between transformation rules.
To do that, it is necessary to create a matrix putting the rules in
the rows and columns. Then in the matrix the engineer must
identify the types of dependencies between the rules. The
types of dependencies in this work are mandatory, optional,
and indirect, as explained further.
• Mandatory dependency. It is a relationship between one
rule with other rules responsible for generating the basic
skeleton of the model where the new structure will beplaced. Therefore the modernization engineer selects eachrule in the row of the matrix and mark with the symbol “*”
the mandatory dependency with the rules in the columns.
Springer

Table 7 shows part of the dependency matrix; all the rules
have a mandatory dependency with the rule R01, because
this rule is responsible for generating the skeleton of theJava model. Another example is the rule R13, in chargeof creating Fields, that has a mandatory dependency withthe rules R01, R05, and R11. These rules are responsible
for creating the PSM instance, the package, and the Class
where the Fields will be placed.
• Optional dependency. It is a relationship between one rulewith other rules responsible for creating nonbasic structures. By the term nonbasic structure we mean structuresthat are created nested within the main structures of themodel. To recognize this kind of relationship, the engineer
needs to use all the code snippets developed in Activity 2.1(Phase 2). Then, focusing on the generated structure by therule under analysis, he/she must identify in the code snippets all the structures that nest the structure under analysis.
This kind of relationship is marked with “**”.
For example, if the rule under analysis generates the if
structure and in the codes snippets the if structure is nested
within the For, Switch, and While structures, then he/she
can mark with “**” the optional dependency between
the rule that generates the if structure and the rules thatgenerate the For, Switch, and While structures. We cannotice that there are many combinations of transformation
rules as source code structures to represent them. So themore examples we use, the more relationships between therules will be identiﬁed.
• Indirect dependency. The indirect dependency is a relationship between one rule with other rules related to therule under analysis. This scenario is caused because there
are rules that need to be executed with others rules to create a single structure. For example, the SwitchStatement
Structure needs the execution of the “Switch-Case” ruleand the “Break” rule to complete it. Therefore this type of
dependency is marked with ID-Rule, where Rule indicatesthe rule under analysis.
The result of this ﬁrst activity is the dependency matrix withall the dependencies between the rules identiﬁed.
Activity 5.2 – Identifying and prioritizing leaf rules
This activity aims at identifying and prioritizing leaf rulesof the matrix elaborated in the previous activity. A leaf rule isa rule that does not depend on no one else. Making an analogy
with a graph structure, it is a node that has no children.
Leaf rules are important to be identiﬁed because they represent a path in which these rules are the end of the path.
Therefore, when we are selecting a leaf rule, we are also
selecting all the other rules that belong to its path. The purpose of using Leaf rules is ensuring that all transformation
rules are executed at least once. In other words, executing aleaf rule implies the execution of a large set of other rules
beforehand.

RUTE-K2J

To identify the Leaf rules, the modernization engineer
must count the number of dependencies (marks) in each column in the matrix and select the rules with result equal tozero. Then a new matrix is generated with the identiﬁed Leaf
rules, putting them as rows and keeping all the transformation rules in the columns. Then, for the prioritization part,considering the created Leaf rule matrix, the modernizationengineer has to count the dependencies (marks) for eachrow and order them by highest to lowest. The output of thisactivity is the prioritized Leaf rule matrix.
Activity 5.3 – Deﬁning test data and test cases
The goal here is selecting data to test the transformationengine. For this work, test data are small programs containing
the source code structure that is addressed by the transformation rule (or a set of them) we want to test. For example, for
testing a transformation rule that deals with an if-then-else
structure, we must choose a piece of code that involves thisconditional structure.
Our testing strategy is to work with all the identiﬁed andprioritized leaf rules. The execution of one prioritized leaf
rule will also result in the execution of all the rules that
depend transitively on it. Thus the combination of prioritizedrules ensures that all the developed transformation rules are
executed using the smallest number of test cases.
Therefore, when searching for source code to serve as test
cases, every program must met the following criteria:• Containing the target code structure. The source code programs must contain the code structure that are addressedby a leaf rule;• Combining leaf rules when possible, the candidate sourcecode program must contain more than 1 code structurewith aims at testing more than one leaf rule at the sametime.
• Being an open-source program. Randomly selected opensource programs hosted in GitHub repositories.
• Being simple but a representative program. Because it isan incremental process, programs must contain only the
structures for which there are transformation rules. The
complexity level of the chosen program should increase as
the process continues to iterate.
After having elected the small programs that compose thetest data, we need to create the set of test cases. In this work,
each test case involves:(i) The input, composed by one Java program Jio and one
KDM instance KDMi generated from this Java program.
Notice that this Java program serves also as the expected
result (oracle);(ii) One leaf rule TR to be tested;(iii) The oracle, the same Java program elected as input Jio.
Activity 5.4 – Running test cases

This activity aims at running each created test case toevaluate the transformation engine. In general, the testing
cycle is the following:
1. Electing a test case TCi to run;
2. Running the transformation engine given as input to the
KDM instance that corresponds to the chosen program(KDMi) and obtaining a PSM as output.
3. Generating a Java source code from the PSM by using acode generation tool to do that (e.g., Acceleo tool);
4. Comparing the original program (which is also the oracle)with the source code generated by the code generation
tool. If the output is equivalent to the oracle, then thetest case succeeds. Here the user can also use the tools tocompare the source code to semiautomate the task.
This cycle repeats until all the prioritized leaf rules arecovered by test cases. The execution of the test cases shows
the degree of preservation of the information expressed inlines of code, raising indications of the quality of the transformation and, consequently, the quality of the transformation
rules that make up the created engine.

4 RUTE-K2J: a transformation engine from
KDM to Java models
In this section, we present RUTE-K2J, a transformation engine for generating Java models from KDM models. The
experience of building this tool was fundamental for creating and documenting the process presented in Sect. 3.
To develop RUTE-K2J, we used the following technologies: a the ATL transformation language [21]; b) OCL(Object Restriction Language) for data types and declarative expressions; c) Eclipse Modeling Framework (EMF);d) Modisco and the discoverers that allow the generationof the Java Model and KDM from the source code; and e)
Modisco-Add, which includes improvements made in the
ATL rules to generate a reﬁned KDM instance. This ﬁrst
version of the RUTE-K2J is composed for 55 transformation
rules, 28 Helpers, and 10 Lazy rules. These and other artifacts that compose RUTE-K2J are described in what follows.
i) The KDM-PSM mapping artifact. This artifact shows
the mapping between the metaclasses of KDM and Javamodel. This mapping guides the development of the transformation rules, because it describes the input KDM metaclassand the equivalent Java metaclass. Table 3 shows part of
KDM-PSM mapping artifact. The ﬁrst and second columns
refer to the KDM metaclass and the condition used as ﬁlter,
and the third column refers to the equivalent Java metaclass. In Table 3, we can realize that the Action Element
KDM metaclass can be transformed into several Java metaclasses (IfStatement, InﬁxExpression, SwitchStatement, etc.).
For this reason, we must use as a condition the Kind attribute
SpringerG. Angulo et al.
Table 3 Partial KDM2Javamodel mapping

KDM instance

JAVA model

MetaclassFilter

Metaclass

CodeModel

name=’Nome_projeto’

Model

CodeModel

name=’External’

Package–

ClassUnit

name <> ‘Anonymous type’

ClassDeclaration

name = ‘Anonymous type’

AnonymousClassDeclaration

MethodUnit
StorableUnit

kind = constructor

ConstructorDeclaration

kind = method

MethodDeclaration

kind <> local

FieldDeclaration

kind=local

VariableDeclarationFragment

BlockUnit

–

Block

ActionElementkind = ‘if’

IfStatementkind =’inﬁx expression’InﬁxExpression

kind=’postﬁx expression’

PostﬁxExpression

kind=’switch’

SwitchStatementkind=’while’

WhileStatementkind=’method invocation’

MethodInvocation

kind=’class instance creation’ClassInstanceCreation

kind=’return’

ReturnStatementof the KDM metaclass. KDM presents many elements where
the only distinction between them is the value of the kind attribute.
ii) The KDM2JAVA Transformation Rules Inventory. This
artifact shows the inventory of 55 ATL transformation rules.
The set of rules composes the core of the RUTE-K2J tool andallows the transformation of KDM instances to Java models.
Table 4 shows part of the KDM2JAVA Transformation Rules
inventory artifact. We can observe that the rule name makes
reference to the origin and destination metaclass of the transformation. For example, the rule CodeModelToJavaModel
has a goal to transform the CodeModel metaclass to the Javamodel metaclass. This rule is the principal for structuring themodel and to articulate the other rules.
iii) The ATL Helper Inventory. In the ATL context thehelpers can be viewed as functions when compared withtraditional programming. The helpers allow us to factorize
code out and develop a clean code. They can be called by rules
or by other helpers from diﬀerent points of the ATL code. For
this work, we developed 28 ATL helpers. Table 5 shows partof the Helper inventory. In Table 5, we can observe the Helper
getOrphanTypes, which allows us to obtain a sequence ofdatatypes elements present in the source Model.
iv) The Lazy Rules Inventory. In our project the lazy rules
are used in the characterization of element collections; itmust be explicitly invoked by the transformation rule. For
this work, we developed 10 ATL lazy rules. Table 6 showspart of the lazy rules inventory. In the table, we can see, forSpringer

Packageinstance, setOrphanTypes lazy rule that helps to assign values
for each attribute returned by the getOrphanTypes Helper.
The complete RUTE_K2J artifacts1 are complete andavailable for review or extension.

5 RUTE-K2J evaluation
In this section, we present an evaluation of RUTE-K2J according to the Phase 5 of our approach (Sect. 3.5). The goal
was to check the correctness of the set of transformation
rules and whether the combination of them results in correcttransformations, i.e., whether they are correctly transforming
KDM model elements into Java model elements.

5.1 Scoping
We employ the GQM (Goal–Question–Metrics) [22] template to deﬁne the scope of this evaluation. Therefore thescope of our study can be summarized as follows:
Analyze all the transformation rules of RUTE-K2J
for the purpose of evaluation,with respect of the correctness of generated model elements,from the point of view of software engineers conducting
modernization projects, andin the academic context.
1 https://github.com/Advanse-Lab/RUTE-K2J/tree/master/Artefactos%20RUTE_K2J.

RUTE-K2J
Table 4 Partial transformation

rules

No

Rule name and purpose

1

CodeModelToJavaModel:
Main rule for structuring the Java model from the KDM instance2

PackageToJavaPackage:
Transform the Package metaclass of the KDM to Package metaclasses of the Java
metamodel

3

ClassUnitToClassDeclaration:
Transform the ClassUni metaclass of the KDM to the ClassDeclaration metaclassof the Java metamodel4

ActionElementToInﬁxExpression:
Transform the ActionElement metaclass of the inﬁx expression type of the KDM
instance to the InﬁxExpression metaclass of the Java model

5

ActionElementToIfStatement:
Transform the ActionElement metaclass of the preﬁx expression type of the KDM
instance to the PreﬁxExpression metaclass of the Java model

6

ActionElementToForStatement:
Transform the ActionElement metaclass of type for from the KDM instance to the
ForStatement metaclass of the Java Model

Table 5 Partial helpers

Table 6 Partial lazy rules

No

Helper name and purpose

1

getOrphanTypes: Helper that returns a sequence of datatypes elements

2

getCompilationUnit: Helper that returns the inventory of the physical artifacts ofthe system

3

getParametersMethod: Helper to get the parameter sequence of the method

4getReturns: Helper to get the sequence of return elements of the method

5checkElementoExternal: Helper recursive to verify if the element belongs to theExternal Model in the KDM instance in order to put the attribute ‘proxy = true’ in
the Java modelNo

Lazy rule name and purpose

1

setOrphanTypes: Deﬁnes the attributes of the orphanTypes metaclass of the Java
model

2

setCompilationUnit: Deﬁnes the attributes of the CompilationUnit metaclass of
the Java model3

SetParametros: Deﬁnes the parameters attributes of the method in the Java model

4

SetTypeParametrosRetorno: Deﬁnes the data type of the return parameter of themethod

5.2 Conducting the evaluation
The evaluation we have conducted followed the four activities
shown in Sect. 3.5:
• 1 Creating the dependency matrix
As previously commented, the dependency matrix aims
at supporting the identiﬁcation of the dependencies among
the existing rules. This matrix helps in the identiﬁcation ofpaths of transformation rules to be executed.

Part of the dependency matrix can be seen in Table 7, as well as some dependencies. For instance, Rule
R30 has mandatory dependencies with R01-JavaModel,
R05-JavaPackage, R11-ClassDeclaration, R15-Method
Declaration, and R16-BlockUnit. These rules are responsible for the creation of the Java model structure.
Moreover, R30 also has an optional dependencywith R14-Constructor, R18-ReturnStatement, or R21SwitchStatement. Finally, R30 has indirect dependencies
with R22-BreakStatement and R23-SwitchCase marked
SpringerG. Angulo et al.
Table 7 Dependency matrix

Rule

R01

R05

R11

R14

R15

R16

R18

R20

R21

R22

R23

...

R131

*

*

*

–

–

–

–

–

–

–

–

...

R292

*

*

*

**

*

*

–

–

–

–

–

...

R303

*

*

*

**

*

*

**

–

**

ID-R21

ID-R21

...

...

...

...

...

....

...

...

...

...

...

...

...

...

Total

51

47

42

34

38

38

5

4

8

7

7

...

1 TrasformStorableUnitToFieldDeclaration
2 TransformWritesToSingleVariableAccess
3 TransformReadsToSingleVariableAccess

Table 8 Leaf rule prioritization

Rule

R01

R05

R11

R471
R302

R14

R15

R16

*

*

*

**

*

*

*

*

*

**

*

*

R483

*

*

*

**

*

*

R504

*

*

*

**

*

*

R495

*

*

*

**

*

*

R316

*

*

*

**

*

*

R517

*

*

*

**

*

R528

*

*

*

**

R469

*

*

R1010

*

*

R1311

*

*

**

R18

R20

R21

R22

R23

...

O
25

ID-R23

ID-R23

**

...

**

ID-R21

ID-R21...

22

ID-R23

ID-R23

**

...

22

ID-R23

ID-R23

**

...

22

ID-R23

ID-R23

**

...

20

...

15

*

...

11

*

*

...

10

*

*

*

...

7

*

*

...

6

...

6

**
**

**

1 TransformValueToNumberLiteral
2 TransformReadsToSingleVariableAccess
3 TransformValueToStringLiteral
4 TransformValueToBooleanLiteral
5 TransformValueToCharacterLiteral
6 TransformateAddressesSingleVariableAccess
7 TransformActionElementToNullLiteral
8 TransformActionElementToThisExpression
9 TransformActionElementToSuperMethodInvocation
10 TransformInterfaceUnitToAnnotationTypeDeclaration
11 TrasformStorableUnitToFieldDeclaration

with ID-R21. This means that if R30 depends on R21,
then it would indirectly depend on the execution of R22
and R23. R21, R22, and R23 together compose the SwithStatement structure.
The complete dependency matrix2 is complete andavailable for review or extension.
• 2 Identifying and prioritizing leaf rules
2 https://github.com/Advanse-Lab/RUTE-K2J/tree/master/
Test%20Data.

Springer

This activity focuses on the identiﬁcation of the leaf
rules. As previously commented, leaf rules help in theexecution of many other rules that belong to the path thisleaf rule belongs to. For our evaluation, we identiﬁed 11
leaf rules. Table 8 shows the prioritized leaf rules, which
are listed in the ﬁrst column of the table. It is possible tosee in the last column that the execution of the rule R47
leads to the execution of 25 transformation rules (in thebest case) including R01, R05, and R11, among others.

RUTE-K2J
Table 9 Test cases X leaf rules

Test Cases

R47

R30

I

10

7

II

3

III
IV

R48

R50

R49

R31

R51

R52

R46

R13

2
5

2

3

2

2

2

1

V

2

VI
VII

R10

5
3

1

• 3 Deﬁning test data and test cases
In this activity, we need to select a set of small programs
to serve as our test data. This selection was guided by theeleven leaf rules that prioritized in the previous activity(Table 8). Therefore we selected, in most of the cases, one
program per a combination of leaf rules. As a result, weended up with seven test cases following the deﬁnition we
have presented in Activity 5.3 of Sect. 3.5.
Table 9 shows the relationship between test cases, leaf
rules, and the total number of rules executed by the test
case. For example, test case I executes part of the leaf rule
R47, i.e., 10 rules from the set of rules that depend on thisleaf rule. Also, it executes part of R30 (7 rules) and R51(2 rules). This means that this test case executes 19 rules(36.54%) out of the 52 available.
Note that the test cases execute the same set of mandatory rules to conform the software program skeleton, as
well as they can execute already exercised structures. In
that context, we count the executed rules only once. For
example, test case VII executes only four new rules.
The complete test data3 are available for review or extension.
• 4 Executing test cases
The execution of the test cases followed the testing cycle we have deﬁned previously. Therefore we have generated the KDM instance for each program. After that, we
executed the transformation engine RUTE-K2J having as
input each KDM instance and obtaining as output the Javamodel (XMI File). Next, with the aim of verifying thecompleteness of the model, we used the Acceleo plug-in
to generate Java source code from the Output Java model.
Finally, the free tool Pretty Diﬀ helped us to compare theoriginal Java code and the Java code generated by Acceleo.
The result of this comparison is expressed in diﬀerencesin lines of code between the programs.
3 https://github.com/Advanse-Lab/RUTE-K2J/tree/master/
Test%20Data.

2

C

P%

19

36.54

8

15.38

7

13.46

5

9.62

4

7.69

5

9.62

4

7.69

5.3 Evaluation results
Table 10 shows the seven test cases. The ﬁrst column shows
the identiﬁer of the test cases, and the second one shows thename of the Java class. The third and fourth columns show
the LOC (lines of code) of the program and the LOC-D (lines
of code – diﬀerences) after the generation, respectively.
The ﬁfth and sixth ones show the original and generatedlines of the code with diﬀerences. Note that the detailed
lines of code correspond to the quantity indicated in the
fourth column (LOC-D). The goal of these two columns is toexhibit the errors in the generation of the source code, whichallows us to correct them. The last column summarizes thekind of mistakes found.
As result of the test cases execution, considering the 217
lines of the code of the all chosen programs, 201 lines weregenerated correctly, and 16 lines presented diﬀerences, i.e.,
92% of the code was generated successfully. The lines of thecode generated with diﬀerences are discussed next.
• For all test cases, the reserved word Static is not being
generated. Keeping track of the data preservation during
the transformations, we found out that these data are notbrought by the input KDM instance.
• Test case I. The error is related to the order of the elementsin the conditional part of the if structure. The KDM model
does not have an indication of the correct position of theelements in the structures.
• Test case III. The System.in parameter is absent in thecreation of the Scanner class. This is due to the lack of
information in the KDM model.
• Test case V. An unnecessary parenthesis is being generated(i.e. “()”). We realized that this error is displayed when an
anonymous class structure is present in the source code.
This is a bug in the transformation rule when working in
conjunction with other rules.
• Test case VI. When creating a Array [] structure, the “[]”element is absent. By tracking the data during generation
we found that the KDM input model does not have thisinformation.
SpringerG. Angulo et al.

Table 10 Rute-K2J evaluation

No

File name

LOC

LOC-D

Original Source Code

Generated Source CodeComparison Result

I

ControlFlowStatements

61

4

public static int
getMonthNumber

public int
getMonthNumber

Reserved word Static isabsentpublic static voidmain(. . .

public void main(. . .

Reserved word Static isabsentif (month == null)

if (null == month)Wrong order of theelements

if(returnedMonthNumber== 0)

if (0 ==
returnedMonthNumber)Wrong order of theelements

II

TestArray

20

1

public static voidmain(. . .

public void main(. . .

Reserved word Static isabsentIII

GetAge21

2public static voidmain(. . .

public void main(. . .

Reserved word Static isabsentsc = newScanner(System.in)

sc = new Scanner();Parameter is absent

public static voidmain(. . .

public void main(. . .

Reserved word Static isabsent

IV

V

VI

VII

Total

Springer

TestBikes

11

1

MountainBike

20

0

–

–

–

Bicycle

28

0

–

–

–

AnonymousDemo

132

public static voidmain(. . .

public void main(. . .

Reserved word Static isabsent}}();Unnecessary parentheses

Age

6

0

–

–

–

ArrayListToArray

18

2

public static voidmain(. . .

public void main(. . .

Reserved word Static isabsentString array[] = new . . .

String array = new . . .

Missing brackets in array
criation.

//Java program to . . .

–Missing comment

public static voidmain(. . .

public void main(. . .

Reserved word Static isabsentb = (byte)(b * 2);

b = (byte)(2 * b);

Wrong order of theelements

println(“Preﬁx = ” +++i);println(“Preﬁx = ”+++i);

Missing space

Test

19

217

4

16

RUTE-K2J• Test case VII. There is a missing comment in the transformation output. Currently, there is no transformation rulethat generates comments. Then in the multiplication statement (2 * b) the order of the elements is wrong; it is thesame problem already reported in the Test case I. Finally,in the expression “+++ i”, it can observe a lack of separation between the “+” with “++i”. We identiﬁed that the
problem comes in the code generation and the use of the
Acceleo Tool.
As result of the evaluation, 92% of the code was successfully generated. This shows that RUTE-K2J generates aJava model that preserves the information embodied in thesource code. We recognize that the current results can leadto semantic and syntactic problems if not corrected, so thisevaluation will help us to carry out two types of important
corrections: (i) internal, which means the correction of thetransformation rules that make up the transformation engine,and (ii) external, in relation to the tools we use to generate the KDM model from the source code and the tool togenerate the source from the model; these are the Modisco
and Aceleo tools, respectively. The Modisco project makes
publicly available the transformation rules used to generate
the KDM model. So to reﬁne the model for our purposes, we
can correct the rules that generate the structures with errors
identiﬁed in the evaluation. In that regard, we have alreadyidentiﬁed and corrected errors in their transformation rules
during the development of this project, which were acceptedby the Eclipse team.

5.4 Threats to validity
In this section, we describe some internal and external threatsthat can impact on the results of our evaluation.
Internal validity. All the combinations among rules were
not exercised. All the combinations we have created werebased on the dependency matrix. Therefore we created combinations that we consider the most used by developers andthose that involve basic structures. We believe that having
guaranteed the correctness for basic structures, more advanced ones can be conducted later.
The manual mapping among models. One of the main
steps of our approach is mapping the KDM against a PSM.
Currently, this is done manually, letting this process too muchdepend on the skills and experience of the engineer. So thisalso impacts on the quality of the generated rules and clearlyon the ﬁnal results.
External validity. The small number of source code examples we employed. Although we have used 10 examples
of source code, which can be considered a small number, weconcentrate on getting the most used source code structures,
which are largely employed by developers. More advanced
structures need to be investigated in future work.

The employment of Modisco-Add and Acceleo tools.
Modisco-Add aims at generating a complete KDM instance.
As we said before, this tool includes corrections of some bugs
found in the ATL rules of Modisco. Although the tool includes the improvements developed, it still does not generate
a complete KDM instance. Regarding Acceleo, we employed
it for the phase of source code generation from PSM Model(Java model); also, it was employed in the evaluation sectionof the RUTE-K2J tool. By using Acceleo we were able to notice that some elements in the model were not transformed.
So, in future works, we must consider other alternatives ofsource generation tools.

6 Discussion
During the process of construction of RUTE-K2J, we facedsome diﬃculties:
Abstraction level. Due to the lower level of abstractionof the target Java model, there are metaclasses that needmore information than the one provided by KDM instances.
For example, the CompilationUnit (Java metaclass) has theattributes name, originalFilePath, types, and imports. On
the other hand, the metaclass KDM equivalent, the InventoryItem metaclass, only has the attribute name and originalFilePath. The generation of a complete model is important
to avoid the loss of information along the process. Thus we
had to deal with the abstraction level problems.
Order of elements. KDM has metaclasses with attributes
that do not have an explicit assignment order. For example, the ActionElement metaclass has many codeElements
attributes with no label indicating the assignment order.
On the other hand, in the Java model the metaclasses present
attributes with explicit names that indicate the right assignment order. For example, the RightOperand and leftOperandattributes of the InﬁxExpression metaclass. Therefore, for the
KDM model, we deduce that the order of the elements in themodel agrees with the order of appearance.
External model. The KDM has a model called Externalthat stores the references of the external classes (importedclasses). In addition, this model stores the initial values of thelocal variables declared in the method body. The combinationof these diﬀerent elements in the external model makes it
diﬃcult to (i) retrieve the assigned value to the variable and(ii) recognize and transform each diﬀerent element in theExternal model.
Enumeration data type. One of the main problems facedwith KDM is that the metamodel stores constant values instring attributes, which must be stored in data type enumeration. This characteristic makes it diﬃcult to identify all values
in advance. For example, the ActionElement metaclasses has
a string attribute called Kind that stores the following values:
For, If, Switch, etc. We were not able to identify those values
SpringerG. Angulo et al.

beforehand; only they were identiﬁed during the mapping
performed.
Control ﬂow structure For. The KDM model uses the
ActionElement metaclass with type equal Variable Declaration for the declaration of local variables and for the variable initialization of the For control structure. On the other
hand, the Java model uses the “VariableDeclarationStatement” for local variables and “VariableDeclarationExpression” for variable initialization in the For structure. That is,a KDM metaclass (Variable Declaration) can turn in two
diﬀerent JAVA metaclasses (VariableDeclarationStatement
and VariableDeclarationExpression). The diﬃculty here isthat KDM metaclass (Variable Declaration) does not haveany other characteristic that helps in the diﬀerentiation for theelection of one metaclass or another. For this case, the implementation of a helper ATL that returns the container type ofthe variable helped us to choose the correct metaclass during
the development of the transformation rules.
Switch control ﬂow structure. In the KDM model the
Switch structure does not present diﬀerentiation between theCase and Default Case element, i.e., the Default Case does
not present any reserved word or some type or kind that
identiﬁes it as the default value of the structure. In this case,
we have to deduce that the last case element without internal
instructions is the Default Case element.

7 Related work
Most related works shown here focus on highlighting someparts of the entire modernization process. Thus we present
some works that present transformations from the KDM
model to other metamodels. However, several details of thetransformations or the process for elaborating the rules are
not clear.
Pérez-Castillo et al. [23] proposed a modernization process called the Data Contextualization technique that takes
as an input a legacy system with embedded SQL queries andgenerates as an output a model with the database schema. In
the ﬁrst step, several SQL queries embedded in the sourcecode written in Java programming language are represented
in an extended KDM instance for supporting SQL artifacts,
such as database model and SQL schemes. A static analysis
is performed in the KDM instance to recognize SQL queries
and generate an SQL statement model, which is an instanceof SQL-92 metamodel. Finally, several QVT rules generate
the output of the process because they transform the SQL
statement model into a Database schema model.
The authors propose an entire modernization cycle using
for the process an extension of the KDM model. In thiswork, it is not clear how the transformations between the
KDM model and the other metamodels are done.
Springer

Rodríguez-Echeverría et al. [9] proposed an outline framework for the systematic process for Web Applications (WA)to Rich Internet Application (RIA) modernization. The modernization process follows the ADM approach, and it is composed of ﬁve phases: (i) information extraction; (ii) the information extracted is stored in a KDM instance and reﬁned withdynamic information; (iii) model reﬁnement to RIA patterns,
the KDM instance is improvement by ﬁnding expressions of
RIA characteristics; (iv) model transformation, the KDM instance is now reﬁned into an RIA-extended Model-Driven
Web Engineering (MDWE); and, ﬁnally, (v) converting themodel instance in an executable web application.
As this approach is a proposal, neither the transformation
is implemented, nor the strategy is deeply discussed. The
authors argue that the possible solutions would be to reusesome existing techniques and tools, so the whole approach
does not propose a methodology to the M2M transformation.
Trias et al. [10] proposed ADMigraCMS that deﬁnes
guidelines to migrate CMS-based (CSM – Content Management Systems) Web applications to other CMS platforms
supported by a toolkit. It is composed of three reengineering
stages deﬁned in the ADM horseshoe cycle and structured infour diﬀerent modeling levels. The ADMigraCMS tool transforms automatically the transition between the levels, i.e.,from PHP code-to-PHP_Model(L0), from PHP_model(L0)to-ASTM_Model (L1), from ASTM_Model (L1)-to-KDM(L2), and from KDM (L2)-To-CMS(L3), and the inverse
transformations in the forward engineering stage.
The ADMigraCMS tool has a complete level of automation and completes the entire Modernization cycle for PHPimplemented CMSs. Although the author has shown the
mapping between the elements of diﬀerent abstraction levels,
it is not clear how the development of the transformation rules
were performed because the implementation is not present.
Pérez-Castillo et al. [24] proposed a declarative modeltransformation to transform KDM instances into BPMN
models. The ﬁrst step was to identify speciﬁc structures ofmetaclasses in the KDM instances and establish other speciﬁc structures of business metaclasses in output models.
The patterns are built by taking into account business patterns that are usually used by business experts for modelingbusiness processes. The patterns also add those structures ofsource code elements (deﬁned through KDM elements) thatoriginate the speciﬁc business structures in BPMN models.
The second step was to implement the model transformations
by means of QVT-relation declarative language.
The authors do not detail how the process to create thepatterns was and if their approach can be reused for othertypes of transformation. They paid more attention to the
QVT-r code that shows the implementation of the patterns.
Pérez-Castillo et al. [25] proposed a method for extractingEnterprise Architect (EA) models, represented using ArchiMate, from KDM models. ArchiMate metamodel allows theRUTE-K2J

representation of EA from diﬀerent viewpoints, considering
layers and aspects as the two main dimensions.The proposed
approach considers the extraction of KDM model from thesource code and the transformation between the KDM modelto ArchiMate Model.
The authors describe the main rules to transform the KDM
model to ArchiMate Model, showing part of the ATL code.
The proposal is located in the Reverse Engineering part,
increasing the abstraction level in each step. On the other
hand, our work focuses on Forward Engineering, reducing
the abstraction level in our transformations to obtain the PSM
model from the KDM model.

8 Conclusion
In this paper, we presented a process for creating transformation engines able to transform KDM into any other PSM. The
process aims at assisting modernization engineers to complete the forward engineering stage of the ADM horseshoe
model.
Our process is characterized by three main features: (i) it
uses an iterative and incremental process to develop the forward transformation rules; (ii) it relies on analysis and comparison of PSM instances as the main source of knowledge
to develop the rules; (iii) it uses the Mapping as the main
artifact, which registers the mapping between the KDM andPSM metamodel elements.
The generic process to create KDM2PSM transformationengines guided the construction of the RUTE-K2J transformation engine. The engine is composed of 55 transformation
rules, 28 helpers, and 10 lazy rules developed with ATL andprovides an instrument to transform the KDM instance toJava model. All the artifacts are complete and available4 forreview or extension.
To demonstrate the correctness of our tool, we elaborated
seven test cases that were the result of a detailed and manual
evaluation process with aims at executing each transformation rule at least once in a source code program. Our evaluation showed that 92% of the source code was preserved andthe information lost is mainly because the KDM instanceused as input did not conserve the complete information
along the modernization process.
In the future, we plan to automate the proposed processby building a support tool to make the mappings between
the diﬀerent metamodels and support in the semiautomatic
generation of the transformation rules. In addition, we plan
to improve the reverse PSM2KDM transformation engine
oﬀered by the Modisco tool to guarantee a complete KDM
instance with all the necessary information for use in our
process.
4 https://github.com/Advanse-Lab/RUTE-K2J.

Acknowledgement We would like to thank the ﬁnancial support pro-vided by FAPESP, SP, Brazil, process number (2016/03104-0) and by
the Coordenação de Aperfeiçoamento de Pessoal de Nível Superior –Brasil (CAPES) – Finance Code 001.
Author Contribution Daniel San Martín, Fabiano Ferrari, Ignacio

García-Rodríguez de Guzmán, Ricardo Perez-Castillo and Valter Vieirade Camargo contributed equally to this work.

References
1. Bennett, K.: Legacy systems: coping with success. IEEE Softw.
12(1), 19–23 (1995)
2. Sneed, H.M.: Estimating the costs of a reengineering project. In:
Reverse Engineering, 12th Working Conference on. IEEE, NewYork (2005)
3. Group, O.M.: Architecture-driven modernization standards
roadmap(2009).
https://www.omg.org/adm/
ADMTF%20Roadmap.pdf. Accessed: 2022-01-15
4. ADM vendor directory listing (2018). https://www.omg.org/adm/
vendor/list.htm. Accessed: 2023-01-10
5. About the knowledge discovery metamodel speciﬁcation version
1.3 (2011). http://www.omg.org/spec/KDM/1.3. Accessed: 202108-15
6. Bruneliere, H., Cabot, J., Jouault, F., Madiot, F.: Modisco: a genericand extensible framework for model driven reverse engineering.
In: Proceedings of the IEEE/ACM International Conference on
Automated Software Engineering, pp. 173–174. ACM, New York(2010)
7. Cánovas Izquierdo, J.L., Molina, J.G.: A Domain Speciﬁc Language for Extracting Models in Software Modernization pp. 82–97.
Springer, Berlin (2009)
8. Wulf, C., Frey, S., Hasselbring, W.: A three-phase approach toeﬃciently transform C# into KDM (2012)
9. Rodríguez-Echeverría, R., Conejero, J.M., Clemente, P.J., Preciado, J.C., Sánchez-Figueroa, F.: Modernization of Legacy Web Applications into Rich Internet Applications, pp. 236–250. Springer,
Berlin (2012)
10. Trias, F., de Castro, V., Lopez-Sanz, M., Marcos, E.: Migrating
traditional web applications to CMS-based web applications. Electron. Notes Theor. Comput. Sci. 314(C), 23–44 (2015)
11. Angulo, G., Martín, D.S., Santos, B., Ferrari, F.C., de Camargo,
V.V.: An approach for creating KDM2PSM transformation engines in ADM context: the RUTE-K2J case. In: Proceedings of
the VII Brazilian Symposium on Software Components, Architectures, and Reuse, pp. 92–101 (2018)
12. Wagner, C.: Model-Driven Software Migration: A Methodology:
Reengineering, Recovery and Modernization of Legacy Systems.
Springer, Washington (2014)
13. ISO/IEC 19506:2012 (2017). https://www.iso.org/standard/32625.
html. Accessed: 2021-08-15
14. Pérez-Castillo, R., de Guzmán, I.G.-R., Piattini, M.: Knowledge
discovery metamodel-ISO/IEC 19506: a standard to modernize
legacy systems. Comput. Stand. Interfaces 33(6), 519–532 (2011)
15. France, R., Rumpe, B.: Model-driven development of complex
software: a research roadmap. In: 2007 Future of Software Engineering. FOSE ’07, pp. 37–54. IEEE Computer Society, Washington (2007)
16. Júnior, J.U., Penteado, R.D., de Camargo, V.V.: An overview andan empirical evaluation of UML-AOF: an UML proﬁle for aspectoriented frameworks. In: Proceedings of the 2010 ACM Symposium on Applied Computing, pp. 2289–2296 (2010)
17. Mens, T., Van Gorp, P.: A taxonomy of model transformation.
Electron. Notes Theor. Comput. Sci. 152, 125–142 (2006)

SpringerG. Angulo et al.

18. Trias, F., de Castro, V., Lopez-Sanz, M., Marcos, E.: A toolkit for
ADM-based migration: moving from PHP code to KDM model inthe context of CMS-based web applications (2014)19. Barbier, F., Deltombe, G., Parisy, O., Youbi, K.: Model driven
reverse engineering: increasing legacy technology independence.
In: Second India Workshop on Reverse Engineering, vol. 125,
pp. 126–139 (2011)20. Pérez-Castillo, R., Caivano, D., Piattini, M.: Ontology-based similarity applied to business process clustering. J. Softw. Evol. Process26(12), 1128–1149 (2014)
21. Eclipse ATL project (2006). https://projects.eclipse.org/projects/
modeling.mmt.atl. Accessed: 2022-11-01
22. Wohlin, C., Runeson, P., Höst, M., Ohlsson, M., Regnell, B., Wesslén, A.: Experimentation in Software Engineering. Springer, Berlin(2012)
23. Perez-Castillo, R., de Guzman, I.G.-R., Avila-Garcia, O., Piattini,M.: On the use of ADM to contextualize data on legacy sourcecode for software modernization. In: Proceedings of the 2009

Springer16th Working Conference on Reverse Engineering. WCRE ’09,
pp. 128–132. IEEE Computer Society, Washington (2009)24. Pérez-Castillo, R., García-Rodríguez de Guzmán, I., Piattini, M.:
Implementing Business Process Recovery Patterns Through QVTTransformations pp. 168–183. Springer, Berlin (2010)
25. Pérez-Castillo, R., Delgado, A., Ruiz, F., Bacigalupe, V., Piattini,
M.: A method for transforming knowledge discovery metamodelto ArchiMate models. Softw. Syst. Model. 21(1), 311–336 (2022)
Publisher’s Note Springer Nature remains neutral with regard to ju-

risdictional claims in published maps and institutional aﬃliations.
Springer Nature or its licensor (e.g. a society or other partner) holds
exclusive rights to this article under a publishing agreement with theauthor(s) or other rightsholder(s); author self-archiving of the accepted
manuscript version of this article is solely governed by the terms ofsuch publishing agreement and applicable law.