=Paper=
{{Paper
|id=Vol-2510/sattose2019_paper_1
|storemode=property
|title=Migrating GWT to Angular 6 using MDE
|pdfUrl=https://ceur-ws.org/Vol-2510/sattose2019_paper_1.pdf
|volume=Vol-2510
|authors=Benoît Verhaeghe,Nicolas Anquetil,Stéphane Ducasse,Abderrahmane Seriai,Laurent Deruelle,Mustapha Derras
|dblpUrl=https://dblp.org/rec/conf/sattose/VerhaegheADSDD19
}}
==Migrating GWT to Angular 6 using MDE==
https://ceur-ws.org/Vol-2510/sattose2019_paper_1.pdf
Migrating GWT to Angular 6 using MDE
Benoît Verhaeghe1,2,3 , Nicolas Anquetil1,3 , Stéphane Ducasse3,1 , Abderrahmane Seriai2 ,
Laurent Deruelle2 , Mustapha Derras2
1
Univ. Lille, CNRS, Centrale Lille, Inria, UMR 9189 – CRIStAL, 59650 Villeneuve d’Ascq, France
{firstname.lastname}@univ-lille.fr
2
Berger-Levrault, France
{firstname.lastname}@berger-levrault.com
3
RMod team, INRIA Lille Nord Europe, Villeneuve d’Ascq, France
{firstname.lastname}@inria.fr
evolve at a fast pace. For example, in 2018 there were
two major versions of Angular, three major versions of Re-
Abstract act.js, four versions of Vue.js, and three versions of Em-
ber.js. This forces companies to update their software sys-
In the context of a collaboration with Berger- tems regularly to avoid being stuck in old technologies.
Levrault, a major IT company, we are working Our work takes place in collaboration with Berger-
on the migration of a GWT application to Angu- Levrault, a major IT company selling Web applications de-
lar. We focus on the GUI aspect of this migration veloped in GWT. However, GWT is no longer being up-
which, even if both are web frameworks, is made dated with only one major release since 2015. As a con-
difficult because they use different programming sequence, Berger-Levrault decided to migrate its GUI to
languages (Java for one, Typescript for the other) Angular 6.
and different organization schemas (e.g. different
The company developes 8 applications using GWT.
XML files). Moreover, the new application must
Each application has more than 1.5 MLOC and represents
mimic closely the visual aspect of the old one so
more than 400 web pages. The applications are built from
that the users of the application are not disturbed.
more than 45 kind of widgets and 29 kind of attributes.
We propose an approach in three steps that uses a
The company estimated the migration for one application
meta-model to represent the GUI at a high abstrac-
to 4 000 man-days. So, migrating automatically the visual
tion level. We evaluated this approach on an ap-
part of an application would already be a useful step for the
plication comprising 470 Java (GWT) classes rep-
modernization of the company’s applications. Because of
resenting 56 screens. We are able to model all the
fast evolution of GUI framework, the company also needs
web pages of the application and 93% of the wid-
a reusable solution for the migration to the next program-
gets they contain, and we successfully migrated
ming language.
(i.e., the result is visually equal to the original) 26
out of 39 pages (66%). We give examples of the There are many published papers on supporting GUI mi-
migrated pages, both successful and not. gration (e.g. [11, 22, 24]). None of them discuss the case
of GUI migration of web-based applications.
1 Introduction We present an approach to help developers migrate the
GUI of their web-based software systems. This approach
During the evolution of an application, it is sometimes includes a GUI meta-model, a strategy to generate the
necessary to migrate its implementation to a different pro- model, and how to create the target GUI. To validate this
gramming language and/or Graphical User Interface (GUI) approach, we developed a tool which migrates Java GWT
framework [2, 27]. Web GUI frameworks in particular applications to Angular. Then, we validated our approach
on an industrial project that is used to present all the wid-
Copyright © 2019 for this paper by its authors. Use permitted under
Creative Commons License Attribution 4.0 International (CC BY 4.0).
gets and their usage. It is composed of 470 Java classes and
In: Anne Etien (eds.): Proceedings of the 12th Seminar on Advanced
56 web pages. Our approach imported correctly 93% of the
Techniques Tools for Software Evolution, Bolzano, Italy, July 8-10 2019, widgets and 100% of the pages. Since not all the existing
published at http://ceur-ws.org/ widgets are re-implemented in Angular, we tried to migrate
1
39 pages and were successful (same visual appearance) for from the classical problem of showing all the potential facts
26 of them (66%). rather than only the real one, another limitation appears for
First, in Section 2, we review the literature on GUI meta- example, with a client/server application, when a part of
modeling. We describe the context of our project in Sec- the graphical interface depends on the result of a request to
tion 3. In Section 4, we describe our migration approach. a server.
We present our implementation in Section 5. Section 6 de- Dynamic. The dynamic strategy consists in the analy-
scribes the experiment we made to validate our approach. sis of the graphical interfaces of an application while it is
In Section 7, we present our results. Finally, in Section 8 running. It explores the application state by performing all
and Section 9 we discuss the results obtained with our tool the actions on the user interface of the software system and
and future work. extracting the widgets and their information.
Memon et al. [15], Samir et al. [22], Shah and Tilevich
2 State of the Art [24] and Morgado et al. [20] developed tools that imple-
ment a dynamic strategy. However, the solutions proposed
Section 2.1 presents the techniques used to migrate an ap- are only available for desktop rather than Web applications.
plication. In Section 2.2, we describe the user interface
The dynamic analysis allows one to explore all the win-
meta-models found in the literature.
dows of an application and to gather detailed information
about them. However, automatically running an application
2.1 Existing migration strategies
to methodically capture all its screens might be a difficult
To define a migration strategy, we identified research work task depending on the technology used. Also, if a request is
related to application migration. Some of the proposed ap- done to build a GUI, the dynamic analysis does not detect
proaches do not perform a full migration, but only a part of this information which may be essential for a full represen-
it. Also, there are numerous publications dealing with pro- tation of a GUI.
gramming language migration. We do not, however, con- Hybrid. The hybrid strategy tries to combine the advan-
sider them if they do not explicitly discuss the GUI migra- tages of the static and dynamic analyses.
tion. This is the case, for example, with the work of Brant Gotti and Mbarki [9] used a hybrid strategy to analyze
et al. [2] that reports on a large Delphi to C# migration. Java applications. First they create a model from a static
We identified three techniques to create a representation analysis of the source code. The static analysis finds the
of the GUI: static, dynamic, or hybrid. widgets and attributes of a user interface and how they are
Static. The static strategy consists in analyzing the structured. Then, the dynamic analysis executes all the pos-
source code and extracting information from it. It does not sible actions linked to a widget and analyze if a modifica-
execute the code of the analyzed application. tion occurs on the interface.
Cloutier et al. [3] analyzed directly the HTML, CSS, Despite the usage of both static and dynamic analysis,
and JavaScript files. The analysis builds a syntax tree of the the hybrid strategy does not solve the request problem in-
source code of the website and extracts the widgets from herent to client/server applications. It also has the same
the HTML files. The work consists mainly in the identifica- issues as the dynamic analysis of running automatically an
tion of links between code source elements of the program application and capturing its screens.
(JavaScript classes, HTML tags, etc.). The work presented Fleurey et al. [7] and Garcés et al. [8] worked on full
does not tackle the full migration of the GUI. migration of software systems. They developed a tool that
Lelli et al. [13], Silva et al. [25] and Staiger [26] used semi-automatically performs the migration. To do so, they
tools that analyze source code of desktop applications. The used the horseshoe process (Kazman et al. [12]). The mi-
tools look for widget definition in the source code, then gration is divided into the following four steps:
they analyze the methods that invoked or are invoked by
the widgets and identify the relationships between widgets 1. Generation of the model of the original application.
and their visual properties.
Sánchez Ramán et al. [23] and Garcés et al. [8] devel- 2. Transformation of this model into a pivot model. This
oped approaches to extract the GUI of Oracle Forms appli- includes data structure, actions and algorithms, user
cations. With this framework, developers define the user interface, and navigation.
interfaces in external files where the position of each wid- 3. Transformation of the pivot model into a target lan-
get is specified. Their approaches consist in the creation guage model.
of the hierarchy of widgets from their position. However,
the case studies are simple with only few forms or labels. 4. Generation of the target source code.
The page layout is also simple because all the elements are
displayed below one another. None of the authors considered the migration from web
The static strategy allows one to analyze an applica- GUI to web GUI. Also, none had the constraint of keeping
tion without having to execute it or even compile it. Apart similar layout except Sánchez Ramán et al. [23]; however,
2
they worked on Oracle Forms applications which are very +viewElements <>
IFML::CORE::
different from a web GUI. As a consequence, their work is +viewContainer
0..* ViewElement
+parentViewComponentPart
0..1
not directly applicable to our case study. 0..*
<> <> <>
0..*
IFML::CORE:: IFML::CORE:: IFML::CORE::
ViewContainer ViewComponent ViewComponentPart
2.2 User Interface representation +subView
ComponentPart
+ isLandmark : Boolean
+ isDefault : Boolean
In the previous section, many abstract representations of + isXOR : Boolean
<>
IFML::Extensions::
a GUI are used. We looked to the proposed representa- <> <>
Field
<>
tions and compared them. We now present the two GUI IFML::Extensions::
IFML::Extensions::
Menu
IFML::Extensions::
List
Window <>
meta-models defined by the OMG. The Knowledge Dis- + isModel : Boolean <> <>
IFML::Extensions::
Slot
covery Metamodel (KDM) allows one to represent any kind + isNewWindow :
Bollean
IFML::Extensions::
Details
IFML::Extensions::
Form
of application. The Interaction Flow Modeling Language
(IFML) is specialized in applications with a GUI. Sec-
tion 2.2.2 presents other representations described in the Figure 2: IFML - View Elements
literature and compare them to the ones of the OMG.
ViewElement. A ViewElement can be refined as a ViewCon-
2.2.1 OMG standards tainer or a ViewComponent.
The OMG defines the KDM standard to support the evo- A ViewContainer represents a container of other View-
lution of software. The standard defined a meta-model to Containers or ViewComponents. For example, it can be a
represent a piece of software at a high level of abstraction. window, an HTML page, a panel etc. The composition be-
It includes a UI package which represents the components tween ViewContainer and ViewElement is used to define the
and behavior of a GUI. DOM.
+UIElement A ViewComponent corresponds to a widget which dis-
0..*
AbstractUIElement plays its content, e.g. a form, a data grid, an image gallery
etc. It can be linked to multiple ViewComponentPart. A
0..1 ViewComponentPart represents an element of a ViewCom-
+owner
UIResource ponent. For example, an input field inside a form, a text
UIAction 0..1 which is displayed inside a data grid, or an image element
UIDisplay UIField + kind : String +owner
of a gallery.
2.2.2 GUI meta-models
UIEvent
Screen Report + kind : String 0..*+UIElement Other GUI meta-models have been proposed in the litera-
ture. We compare them to the OMG standards.
All the meta-models use the Composite pattern to rep-
Figure 1: KDM - UIResources Class Diagram resent the DOM of a GUI and define a kind of UIResource
entity to represent a graphical element of the interface.
Figure 1 represents the core of the UI part called UIRe- Gotti and Mbarki [9] and Sánchez Ramán et al. [23] pro-
sources Class Diagram. The main entity is UIResource. posed a meta-model inspired by the KDM models. The
It can be refined as UIDisplay or UIField. UIDisplay corre- meta-model has the main entities defined by KDM. Both
sponds to the physical support on which the interface will authors added the Attribute entity to the meta-model. They
be displayed, e.g. a computer screen, a printed report, etc. also define different kinds of widgets such as Button, La-
UIField corresponds to a user interface widget, e.g. a form, bel, Panel, etc.
a text field, a panel, etc. The composition between UIRe- Fleurey et al. [7] did not explicitly describe the GUI
source and AbstractUIElement is used to define the DOM meta-model, but we extracted information from their nav-
(Document Object Model). Each UIResource can contain igation model. They have at least two elements in their
another one to represent a widget that contains another wid- UI model that represent a Window and a GraphicElement.
get. The Window corresponds to the Display entity of the KDM
A UIResource can have, through composition, an UIAc- model. And because the GraphicElement and the Window
tion to represent the behavior of the user interface. are not linked, we can suppose that the GraphicElement is
The aim of IFML [1] is to provide tools to describe the a UIRessource. The GraphicElement has an Event.
visible parts of an application, with the components and Morgado et al. [20] used a UI meta-model but did not
the containers, the state of the components, the logic of the describe it. We only know that the UI is represented as a
application and the binding between data and GUI. tree which is similar to the DOM.
Figure 2 represents the meta-model of the visual part of The UI meta-model of Garcés et al. [8] differs a lot from
an application. The visible elements of the GUI are called the previous ones. There are the attributes, the events, and
3
the screen but the notion of widget is present as a field In Section 3.3 we present a categorization of the front-end
which displays data of a table. They also used an Event source code.
entity to represent the interaction of the user with the user
interface. The Event entity corresponds to the Action and 3.1 Constraints
the Event entities of the KDM model. From the previous works of Moore et al. [18] and
Memon et al. [15] represented a user interface with only Sánchez Ramán et al. [23], we identify the following con-
two entities. A UI window which is composed of a set of straints for our case study:
widgets that can have attributes. Representing the DOM
was not in the scope of their work. It is not possible to • From GWT to Angular. In the context of the collabo-
represent it with their meta-model. ration with Berger-Levrault, our migration approach
Samir et al. [22] worked on the migration of Java-Swing must work with Java GWT as source language and
applications to Ajax Web applications. They created a TypeScript Angular as target one.
meta-model to represent the UI of the original application. • Approach adaptability. Our approach should be as
This meta-model is stored in a XUL (XML-based User in- adaptable as possible to different contexts. For ex-
terface Language) file and represents the widgets with their ample, it can be used with different source and target
attributes and the layout. Those widgets belong to a Win- languages. This constraint includes the Source and
dow and can fire events when a UI input is performed. The target independence and the Modularity constraints.
input and the event correspond to the Action and the Event
entities of the KDM model. The XUL format has been dis- • Keep visual aspect. The migration must keep the vi-
continued. sual aspect of the target application as close as pos-
Shah and Tilevich [24] used a tree architecture to repre- sible to the original. This constraint includes the
sent the UI. It allows them to model the DOM. The root of Layout-preserving migration which it is in opposition
the tree is a Frame. It corresponds to the UIDisplay entity. to the GUI Quality improvement.
The root contains components with their attributes. • Code quality conservation. As a relaxed Code Qual-
Joorabchi and Mesbah [11] represented a user interface ity improvement constraint, our approach should pro-
with a set of UI elements. Those elements correspond to the duce code that looks familiar to the developers of the
definition of a UIField. For each UI element, the authors’ source application. As far as possible, the target code
tool is able to handle the detection of multiple attributes should keep the same structure, identifiers and com-
and actions. ments. However, we will see in the next section that
Memon [16] used a UI Model to represent the state of there are strong differences in GWT and Angular or-
an application. A state is defined as the GUI’s widgets and ganization schemas.
their properties.
Mesbah et al. [17] did not present directly their meta- • Automatic. An automatic solution makes the approach
model for the user interfaces. However, they explain that more accessible. It would be easier to use an auto-
they use a DOM-tree representation to analyze different matic approach on large system [18]. This constraint
web pages. They also used the notion of events that can corresponds to the Automation constraint of the litera-
be fired. They used different instances of their UI meta- ture.
model to represent the web pages of the application. Those
3.2 Comparison of GWT and Angular
instances can be compared to multiple UIDisplay entities.
All the authors used the notion of widget that represents In this project, the source language and the target language
a visual entity of the user interface. Most of them have an impose two different organization schemas. Their differ-
entity attribute that represents a characteristic of a widget. ences are syntactic and semantic.
Finally, the navigation links are represented with an action GWT is a framework that allows developers to write
entity. a web application in Java. The GUI code is compiled to
HTML, CSS and JavaScript code. Angular is a front-end
web application platform that allows developers to write a
3 Context of the migration project
web application with the TypeScript language. It is used to
The goal of our work is to migrate the user interfaces from a create Single-Page Applications1 .
given graphical interface framework to another. This is an Table 1 summarizes the differences between GWT ap-
industrial project, migrating web applications from GWT plications and Angular ones, concerning: web page defini-
to Angular. The objective is to produce a running user in- tion, their style and the configuration files. Before explain-
terface in the target framework. We now present the condi- ing these three differences, we note one major similarity:
tions of the projects. In Section 3.1 we list some constraints 1 Single-Page Applications (SPAs) are Web apps that load a single
that we must fulfill. In Section 3.2 we describe the main HTML page and dynamically update that page as the user interacts with
differences between GWT applications and Angular ones. the app.
4
Table 1: Comparison of GWT and Angular organization schema
GWT Angular
Web page definition One Java class One TypeScript file and one HTML file
Main visual aspect of the application One CSS file One CSS file
Specific visual aspect of a web page Included in the Java file One optional CSS file
Number of configuration files One file Two files
both GWT and Angular applications have a main CSS file and, routing, defines for each web page, its associated
to define the general visual aspect of the application. URL.
• Web Page Definition. In the GWT framework, only
3.3 Front-end application structure
one Java file is necessary to define a web page (an
excerpt is proposed in Figure 5, page 7). The Java As proposed by Hayakawa et al. [10], we divided the mi-
(GWT) file includes the main graphical components gration project in multiple sub-problems. To do so, we de-
(widgets) of the web page, their positions and hierar- fine three categories of source code: the visual code; the
chical organization. In the case of an actionable wid- behavioral code; and the business code.
get (as a button), the action is implemented in the same
file. In Angular, there is a file hierarchy for each web • Visual Code The visual code describes the visual as-
page. Each web page is considered as a sub-project pect of the GUI. It contains the elements of the in-
independent of the others. A sub-project contains two terface. It defines the inherent characteristics of the
files: an HTML file, containing the widgets of the components, such as the ability to be clicked or their
web page and their organizations; and a TypeScript color and size. It also describes the position of these
file, containing the code to execute when an action is components compared to others.
performed.
• Behavioral code The behavioral code defines the ac-
• Visual Aspect. The visual aspect of a web page in- tion/navigation flow that is executed when a user inter-
cludes color or dimension of specific displayed ele- acts with the GUI. The behavioral code contains con-
ments. In the case of GWT, the specific visual aspect trol structures (i.e. loop and alternative).
is defined in the Java file of the web page definition.
In Angular, there is an optional distinct CSS file. • Business code The business code is specific to an
application. It includes the rule of the application,
1 < a p p l i c a t i o n name ="CORE−I n c u b a t o r " > the distant server address and the application-specific
2
3 < p h a s e c o d e P h a s e ="KITCHENSINK_HOME"
data.
4 c l a s s N a m e =" f r . b l . c l i e n t . k i t c h e n s i n k .
PhaseHomeKitchenSink " Because of the size and diversity of source code, mi-
5 t i t l e ="Home " / > grating one of this code category is already an important
6
7
problem.
8
4 Migration Approach
Figure 3: Example of a GWT configuration file in XML This section presents the migration approach we designed.
In Section 4.1, we describe the migration process we de-
• Configuration Files. For the configuration files,
signed. Section 4.2 presents our GUI meta-model.
GWT uses one XML file that defines the binding
between a Java file, a web page and the URL of the
4.1 Migration process
web page. Figure 3 presents a snippet of the XML
file of a Berger-Levrault application. The tag phase From the state of the art, the constraints and the decompo-
(line 3) defines a web page of the GWT applica- sition of the user interfaces, we designed an approach for
tion: The web page title is “Home”; it is defined the migration.
by the Java class PhaseHomeKitchenSink (in The process, represented in Figure 4, is divided into the
package fr.bl.client.kitchensink); three following steps:
and the URL to access the web page is
http://myserver.com/KITCHENSINK_HOME. 1. Extraction of the source code model. We build a
For Angular, there are two configuration files: mod- model representing the source code of the original
ule, defines the components of the application, e.g. application. In our case study, the source program
web pages, distant services and graphical component; is written in Java GWT. The extraction produces a
5
GUI model of a widget, this is the case of the attribute enable. A but-
Source code model GUI model
extraction ton with the enable attribute set to false represents a button
on which one cannot click. Finally, the widgets can have
Source code model extraction Export
attributes that impact the visual aspect of the application.
This type of attribute allows us to define a layout to be re-
Source Migrated
application application spected by the widgets contained in the main one and po-
tentially the dimensions of the latter to respect a particular
layout.
5 Implementation
Figure 4: Our GUI migration process
To test our approach, we implemented a migration tool. It is
implemented in Pharo2 and the meta-model is represented
FAMIX model [5] of the application using a meta- using the Moose platform3 .
model capturing Java concepts. We also need to parse
the XML configuration file described in Section 3.2. 5.1 Case Study
2. Extraction of the GUI model. We analyze the source Applications at Berger-Levrault (our industrial partner) are
code model to detect the Visual code elements describ- based on the BLCore framework. This framework consists
ing the GUI and we build a GUI model from these ele- in 763 classes in 169 packages. It is developed by the com-
ments. The GUI meta-model is described Section 4.2. pany on top of GWT and defines the widgets that develop-
ers should use, the default visual aspect of the applications,
3. Export. We re-create the GUI in the target language. and Java classes to connect the front-end of the application
This step exports the user interface files and the con- to the back-end. It also encourages some coding conven-
figuration files of the application. tions.
For the Berger-Levrault applications, we add a new en-
Note that currently we treat neither the Business code tity (Business Page) to the GUI meta-model presented Sec-
nor the Behavioral code of the application. This will be the tion 4.2 to fit the company’s specific organization. It is a
focus of future work. kind of Container. One convention is that each Page has
one or more Business Pages represented as tabs in the
Page. The widgets (buttons, text fields, tables, . . . ) are
4.2 GUI meta-model
included in the Business Pages, never directly in the Page.
To represent the user interfaces of desktop or web-based
applications, we designed a GUI meta-model from the ones 5.2 Import
presented in Section 2.2.2. In the rest of this section, we In part because of the complexity of setting up a tool to
present the entities of the meta-model. run automatically and capture all screens of such large web
Our meta-model is an adaptation of KDM meta- applications, we rely on static analysis to create our model.
model(see Figure 1). As many others, we separate the The results so far seem to indicate that it will be sufficient.
graphical resources corresponding to the DOM from the As presented Section 4.1, the creation of the GUI model
actions and events. In our meta-model, graphical resources is divided in two steps: the source code model extraction
are called Widget. They can be refined as Leafs or Contain- and the GUI model extraction. For the source code meta-
ers
model, we use the Java meta-model of Moose [5, 21] which
In our context, the user interface will always be dis- comes with a Java extractor4 . Figure 5 presents a snippet of
played on a screen. So we do not represent all the kind of the source code of a Berger-Levrault application. It shows
UIDisplay and define an entity Page. The Page represents the method buildPageUi(Object object) that builds the GUI of
the main container of a graphical interface. It is either a the business page SPMetier1 (a “simple business page”).
window of a desktop application or a web page. The Page For the second step of the extraction, our tool creates the
is a kind of Container. GUI model from the source code model and an analysis of
As proposed by many other authors, we added the entity the XML configuration file. The entities we want to extract
Attribute in our GUI meta-model. An Attribute represents are, first, the Pages. We parse the XML configuration file
the information of a widget and can change its visual aspect in which is defined the information about the pages (see
or behavior. Some common attributes are the height and
2 Pharo is a pure object-oriented programming language inspired by
the width to precisely define the size of a widget. There
Smalltalk. http://pharo.org/
are also attributes that contain data. For example, a widget 3 Moose is a platform for software and data analysis. http://www.
representing a button may have a text attribute that contains moosetechnology.org/
the text of the button. An attribute can change the behavior 4 verveineJ : https://github.com/moosetechnology/verveineJ
6
1 c l a s s SPMetier1 extends AbstractSimplePageMetier the DOM thanks to the Composite pattern used by the GUI
{ meta-model (see Section 4.2). Each widget provides its at-
2 @Override tributes and actions to the exporter.
3 public void buildPageUi ( Object o b j e c t ) {
4 BLLinkLabel l b l P g = new BLLinkLabel ( " Next " ) ;
5 l b l P g . a d d C l i c k H a n d l e r ( new C l i c k H a n d l e r ( ) { 6 Validation
6 public void onClick ( ClickEvent event ) {
7 S P M e t i e r 1 . t h i s . f i r e O n S u c c e s s ( " param " ) ; In this section, we describe the industrial application on
8 } which we used our tool to validate our approach. Sec-
9 }) ; tion 6.1 presents the industrial application. Section 6.2
10 lblPg . setEnabled ( false ) ;
11 vpMain . add ( new L a b e l (" < B u s i n e s s c o n t e n t > " ) ) ; presents the metrics we used to evaluate our approach.
12 vpMain . add ( l b l P g ) ;
13 super . setBuild ( true ) ; 6.1 Industrial application
14 }
15 } We experimented our strategy on Berger-Levrault’s
kitchensink application. This software system, dedicated to
Figure 5: User interface creation in GWT developers, aims to gather inside a single simple applica-
tion all the components available for building a user inter-
Section 3.2). It provides for each Page (called phase in the face. This application is smaller than a production one but
XML file, Figure 3) its name and the name of the Java class still uses the BLCore framework. The company framework
that defines it. Then, the tool looks for Widgets. guarantees us the kitchensink application works exactly the
First, the tool determines the available widgets. To do same way as the industrial applications. It contains 470
so, it collects all the Java subclasses of the GWT class Wid- Java classes and represents 56 web pages. Although it is
get. For the Buisiness pages, the tools looks for the classes the sample and demo for developers, the kitchensink appli-
that implement the IPageMetier interface. Then, the tool cation contains code misuses.
looks where the Widget constructors are called and creates Note that the kitchensink application, as the other in-
the links between the Widgets and their parent Widget. In dustrial applications of the company, does not have test.
Figure 5, there are two calls to Widget constructors: line Therefore, there is no possibility to use tests to validate the
4, the constructor of BLLinkLabel is called, and line 11, the migration.
constructor of Label. The variable vpMain corresponds to
the main panel of the Business page. Lines 11 and 12 cor- 6.2 Validation metrics
respond to adding a widget inside a panel widget thanks to
The validation is done in three steps: First, we check the
the method add().
constraints defined in Section 3.1; Second, we validate that
Finally, to detect attributes and actions which belong to
all GUI entities of interest are extracted and correctly ex-
a widget, the tool detects in which Java variable the wid-
tracted; Third, we validate that we can re-export these enti-
get has been assigned. Then, it searches the methods in-
ties in Angular and that the result is correct.
voked on this variable. If a widget invokes the method “ad-
For the first validation, we manually identify and count
dClickHandler”, it creates an event. If it invokes a method
the entities in the kitchensink application and compare the
“setX”, it creates an attribute. These heuristics were found
results of the tool to this count. Our analysis focuses on
in the literature [22, 25]. In Figure 5, the BLLinkLabel,
the migration of three entities: Pages, Business Pages and
whose variable is lblPg, is linked to one event and one at-
Widgets
tribute. Lines 5 to 9 correspond to the creation of one event
with the executable code. Line 10 corresponds to adding • Pages. From the XML configuration file of the appli-
the attribute enabled with the value false. cation we manually count 56 pages. This configura-
tion file also provides the name of each page.
5.3 Export
• Business Pages. As explained before, the business
Once the GUI model is generated, it is possible to export pages correspond to a concept specific to Berger-
the application. To generate the code of the target appli- Levrault. They are defined in the BLCore frame-
cation, the tool includes an exporter. The exporter creates work as a Java class which implements the interface
the folders of the target application and the configuration IPageMetier. Thanks to this heuristic, we manually
files. Then, it visits the pages. For each Page, the exporter count 76 Business Page instances in the original ap-
creates an Angular sub-project in the form of a directory plication.
containing several configuration files and a default blank
web page. Then, for each business page of the current vis- • Widgets. In the literature survey, we did not find an
ited Page, the exporter generates one HTML file and one automatic way to evaluate the detection of widgets.
TypeScript file. For the HTML file, the exporter builds Checking all widgets in the application would be long
7
and error-prone as there are thousands of them. As import or the export phases. We shortly describe a small
a fallback solution, we take a sample of the pages of experiment in that sense in Section 8.5. Those possibilities
the kitchensink application and count the widgets in satisfied the adaptability constraint.
the DOM of these pages. We consider a sample of 6 The Code quality conservation and Keep visual aspect
Pages which represents a bit more than 10% of the constraints are discussed in Section 7.3, in the third valida-
Pages of the application. These Pages are of different tion results.
sizes and contain different kinds of widgets. In total, Finally, the results described here were obtained auto-
we found 238 Widgets in these 6 Pages. To get a more matically from application of our tool to the subject appli-
exact idea of the representativeness of our sample, we cation. This validates the last constraint.
also count the number of Widget creation (i.e. new
AWidgetClass()) in the code. There are 2,081 7.2 Extraction results
such creation. This may not represent the exact num-
Table 2 summarizes the extraction results.
ber of widgets in the entire application, but it is a good
estimate. We note that the number of Widgets in our Table 2: Extraction results
sample (slightly more than 10% of the pages) is also Widgets
Pages Business Pages
slightly more than 10% of our estimate of the total (sample)
number of widgets. Number 56 76 238
For the evaluation, we also check that the Widgets are Correctly imported 100% 100% 89%
correctly placed in the DOM of the interface (i.e., they
belong to the right Container in the GUI model).
The tool extracted 56 Pages from the original GUI. This
In our results we consider only the recall of the tool be- corresponds to the number of pages defined in the configu-
cause the precision is always 100% (there are no false pos- ration file of the kitchensink application.
itive). This is a sign that the BLCore framework provides The tool extracted 76 Business pages. This value cor-
clear (if not complete) heuristics to identify the entities. responds exactly to the number of business pages in the
For the second validation, we check that the entities are original application. Moreover, the tool correctly assigned
exported correctly. In the Angular application, each Page each Business page to its proper Page.
corresponds to a sub-project and is represented by a folder. We got 100% of the Widgets on the evaluated sample
The name of the folder must correspond to the name of the were correctly detected. However, 27 out of the 238 Wid-
Page. The Business pages are represented by a sub-folder gets of our sample (11%) were not correctly assigned to
inside the Page project. The names must also match at this their parent container. All these problems come from one
level. single Page (containing 75 Widgets in total).
We also check visually that the exported Page “looks
like” the original one. This is a subjective evaluation, and 7.3 Export results
we are looking for options to automate it in the future. We manually checked the name of all the 56 exported
pages. They all conserve their original name.
7 Results
This section presents the results of the migration validation
on Berger-Levrault’s kitchensink application. Section 7.2
summarizes the extraction results. In Section 7.1, we con-
front the exported result with the constraints defined in Sec-
tion 3.1. (a) GWT original (b) Angular migration
7.1 Satisfaction of constraints Figure 6: Visual comparison of a Page migration
We set the following constraints in Section 3.1: From GWT Figure 6 presents the visual differences between the
to Angular, Approach adaptability, Code quality conserva- original (GWT) version, left hand, and the migrated (An-
tion, Keep visual aspect, and Automatic. gular 6) one, right-hand. We can see that there are only
Our tool can use Java code as input and generate Angu- minimal differences. In the exported version, the color of
lar code. The exported code is compilable and executable. the header is a bit clearer, and the lines are a little more
The target application can be displayed. We can thus con- distant.
firm that our tool fulfill the GWT to Angular constraint. Figure 7 presents the visual differences for the Page
Our tool is applicable on other source target technolo- Input box. Again on the left-hand side there is the orig-
gies. Our heuristics have been designed to be easy to adapt, inal Page and on the right-hand side the same Page af-
a user of our tool can thus add a new kind of widget for the ter the migration. Because the two images are large, we
8
(b) Angular migration
(a) GWT original
Figure 7: Visual comparison of a Page migration: All the Widgets are migrated but with a wrong layout.
trimmed them to display this area of interest. Even though 8.2 Managing behavioral and business code
the two images look completely different, all the widgets
Currently, only the visual part of the GUI is migrated. To
are present in the migrated version. The visual differences
take into account the whole application, the migrations of
are due to a problem in the layout management. The visual
the Behavioral and Business code (see Section 3.3) are
constraint is thus partially satisfied. This point is discussed
needed. The Behavioral represent the user interactions (i.e.
Section 8.1.
click, drag-and-drop, hover, ...) and the control structures
(i.e. loop and alternative). In the case of a client/server
8 Discussion application, requesting a server is part of Behavioral code,
whereas the query in itself and the data belongs to Business
Section 8.1 and Section 8.2 presents two parts of the user code.
interface we did not work on. Section 8.3 discusses the
impact of the choice of the kitchensink application as case 8.3 Demo application
study. Section 8.4 highlights the difficulties in large scale
Although the results are encouraging, we only evaluated
validation of our tool. Finally, Section 8.5 discusses the
our tool on the kitchensink application. The kitchensink ap-
impact of the BLCore framework.
plication is a good training ground for our tool as it contains
all kinds of widgets that developers have at their disposal
8.1 Layout management and the way to use them. However, it might diverge from
production applications as it should contain less irregulari-
As shown in Section 7.3, the export may give incorrect ties or coding tricks than the later.
results because of layout issues (Figure 7). It is due to
the representation of the layout in our GUI meta-model. 8.4 Validation tools
Currently, layouts are represented in our GUI meta-model
as an attribute on a Container widget defining if the chil- The automatic validation of the screens migration is cur-
dren of this widget are placed ones beside the other or one rently an unsolved problem. It is possible to manually
below the other (i.e. vertical or horizontal flow layouts). check the result of the migration for a few pages but it
However, many other layouts exist [14]. For example, the would be better to do it automatically for hundreds of pages
BLCore framework offers BLGrid, a Widget inheriting (more than 400 on Berger-Levrault applications).
from the GWT Grid class and implementing a grid lay- We found, in the literature, only few approaches consid-
out. Currently, complex layouts are not considered in our ering automatic visual validation. In two papers [11, 23],
GUI meta-model. the authors simply count the number of widgets in the
A solution is proposed by Sánchez Ramán et al. [23]. source application and target applications. But we saw in
They designed a layout meta-model. The idea consists in Figure 7 that this not guarantee visual similarity. An other
linking widgets with a layout and combining the layouts article [19] propose to compare screenshots of the origi-
to create a precise representation. The authors defined a nal and the exported applications pixel by pixel. However,
subset of possible layout to connect to widgets. we saw in Figure 6 that barely distinguishable screens may
have differences at the level of pixels.
Moreover, with such layouts, the position of the children
Widgets might be computed at run time. For example, in
8.5 Impact of BLCore
a grid layout, the children may be positioned according to
the values of some row and col variable. Guessing these As explained in Section 5.1, the Berger-Levrault applica-
values with a static analysis is not practical, and this is a tions are based on the BLCore framework. By specializing
case where an hybrid approach might be necessary. GWT, BLCore provides specific widgets and a dedicated
9
API. This may have an impact on our approach or not. To 9.2 Future work
evaluate this possible impact, and also to validate the gener-
To improve the migration of an application user interface,
ality of our approach, we performed two small experiments
we will enhance our meta-model and our tool to support the
considering (i) Spec (a desktop UI framework in Pharo [6])
management of the layout and the behavioral and business
as the source framework and, (ii) Seaside (a web frame-
code.
work in Pharo [4] – also described at seaside.st) as the tar-
We did not find an approach or metrics to automati-
get framework. These experiments thus consider different
cally evaluate the validity of the migrated screens. So, it
programming languages (Pharo instead of Java (GWT) and
is important to find a new way to evaluate that the migrated
TypeScript), different GUI frameworks, and desktop and
screens conserve the visual aspect of the original ones.
web applications. We experimented migrating the GUI of
small demo application from Spec to Angular, and migrat- Having a good GUI meta-model also opens the door for
ing the Berger-Levrault kitchensink application to Seaside. a generic GUI builder that could export the GUI in several
Some conclusions are: different GUI frameworks.
• It was harder to import Spec code than GWT because References
of a larger variability in defining the GUI. We con-
[1] Marco Brambilla and Piero Fraternali. Interaction flow modeling
clude that the BLCore framework eased our work on language: Model-driven UI engineering of web and mobile apps
the import by standardizing how to build the pages. with IFML. Morgan Kaufmann, 2014.
• For Seaside, it was easy to migrate simple widgets [2] John Brant, Don Roberts, Bill Plendl, and Jeff Prince. Extreme
(e.g. Label, Button, Panel), but the BLCore frame- maintenance: Transforming Delphi into C#. In ICSM’10, 2010.
work also defines complex widgets with no direct [3] Jonathan Cloutier, Segla Kpodjedo, and Ghizlane El Boussaidi.
equivalent in Seaside. A library similar to BLCore WAVI: A reverse engineering tool for web applications. In 2016
should be defined in Seaside to ease the migration. IEEE 24th International Conference on Program Comprehension
(ICPC), pages 1–3. IEEE, 2016.
• the power of our GUI meta-model and the two steps
[4] Stéphane Ducasse, Lukas Renggli, C. David Shaffer, Rick Zaccone,
extraction (first, source code model extraction, then and Michael Davies. Dynamic Web Development with Seaside.
GUI model extraction, see Figure 4) are validated by Square Bracket Associates, 2010.
the fact that we were able to migrate a Pharo desktop
application with little extra work. [5] Stéphane Ducasse, Nicolas Anquetil, Usman Bhatti, Andre Caval-
cante Hora, Jannik Laval, and Tudor Girba. MSE and FAMIX 3.0:
an Interexchange Format and Source Code Model Family. Technical
9 Conclusion and Future works report, RMod – INRIA Lille-Nord Europe, 2011.
We created a tool with promising results on the representa- [6] Johan Fabry and Stéphane Ducasse. The Spec UI Framework.
tion of GUI to migrate GWT applications toward Angular. Square Bracket Associates, 2017.
In the following, we conclude the presentation of this work
[7] Franck Fleurey, Erwan Breton, Benoit Baudry, Alain Nicolas, and
and propose some future research directions we want to ex- Jean-Marc Jezéquel. Model-Driven Engineering for Software Mi-
plore. gration in a Large Industrial Context. In Gregor Engels, Bill
Opdyke, Douglas C. Schmidt, and Frank Weil, editors, Model
9.1 Conclusion Driven Engineering Languages and Systems, volume 4735, pages
482–497, Berlin, Heidelberg, 2007. Springer Berlin Heidelberg.
In this paper, we exposed a preliminary work on the prob-
lem of visual preservation and respect of the target archi- [8] Kelly Garcés, Rubby Casallas, Camilo Álvarez, Edgar Sandoval,
Alejandro Salamanca, Fredy Viera, Fabián Melo, and Juan Manuel
tecture during the GUI migration of an application. We Soto. White-box modernization of legacy applications: The oracle
proposed an approach based on a GUI meta-model and a forms case study. Computer Standards & Interfaces, pages 110–122,
migration process in three steps. We implemented this pro- October 2017.
cess in a tool to perform the migration fof GWT applica-
[9] Zineb Gotti and Samir Mbarki. Java swing modernization approach
tions to Angular 6. Then, we validated our tool with an - complete abstract representation based on static and dynamic anal-
experiment on a kitchensink application. We were able to ysis:. In Proceedings of the 11th International Joint Conference on
extract correctly all pages of the application and 89% of Software Technologies, pages 210–219. SCITEPRESS - Science and
Technology Publications, 2016.
the widgets. The migration results are visualizing equiva-
lent as long as complex widgets (e.g. GridLayout) are not [10] Tomokazu Hayakawa, Shinya Hasegawa, Shota Yoshika, and Teruo
used. Dealing with these layouts is our next challenge. Hikita. Maintaining web applications by translating among different
Our solution also allows us to respect the naming con- ria technologies. GSTF Journal on Computing, page 7, 2012.
ventions used in the source application as well as the struc-
[11] Mona Erfani Joorabchi and Ali Mesbah. Reverse engineering iOS
ture of the code as far as the differences in the GUI frame- mobile applications. In 2012 19th Working Conference on Reverse
works allow it. Engineering, pages 177–186. IEEE, 2012.
10
[12] R. Kazman, S.G. Woods, and S.J. Carriére. Requirements for inte- [27] Christian Zirkelbach, Alexander Krause, and Wilhelm Hasselbring.
grating software architecture and reengineering models: Corum ii. On the modernization of explorviz towards a microservice architec-
In Proceedings of WCRE ’98, pages 154–163. IEEE Computer So- ture. In Combined Proceedings of the Workshops of the German
ciety, 1998. Software Engineering Conference 2018. CEUR Workshop Proceed-
ings, 2018.
[13] Valéria Lelli, Arnaud Blouin, Benoit Baudry, Fabien Coulon, and
Olivier Beaudoux. Automatic detection of GUI design smells:
The case of blob listener. EICS ’16 Proceedings of the 8th ACM
SIGCHI Symposium on Engineering Interactive Computing Sys-
tems, page 12, 2016.
[14] Simon Lok and Steven Feiner. A survey of automated layout tech-
niques for information presentations. Proceedings of SmartGraph-
ics, 2001:61–68, 2001.
[15] Atif Memon, Ishan Banerjee, and Adithya Nagarajan. GUI ripping:
reverse engineering of graphical user interfaces for testing. In Re-
verse Engineering, 2003. WCRE 2003. Proceedings. 10th Working
Conference on, pages 260–269. IEEE, 2003.
[16] Atif M. Memon. An event-flow model of GUI-based applications for
testing. Software Testing, Verification and Reliability, 17(3):137–
157, 2007.
[17] Ali Mesbah, Arie van Deursen, and Stefan Lenselink. Crawling
ajax-based web applications through dynamic analysis of user inter-
face state changes. ACM Transactions on the Web, 6(1):1–30, 2012.
[18] Moore, Rugaber, and Seaver. Knowledge-based user interface mi-
gration. In Proceedings 1994 International Conference on Software
Maintenance, pages 72–79. IEEE Comput. Soc. Press, 1994.
[19] Kevin Moran, Cody Watson, John Hoskins, George Purnell, and
Denys Poshyvanyk. Detecting and Summarizing GUI Changes in
Evolving Mobile Apps. arXiv:1807.09440 [cs], July 2018.
[20] I Coimbra Morgado, Ana Paiva, and J Pascoal Faria. Reverse en-
gineering of graphical user interfaces. In ICSEA 2011 : The Sixth
International Conference on Software Engineering Advances, 2011.
[21] Oscar Nierstrasz, Stéphane Ducasse, and Tudor Gîrba. The story of
Moose: an agile reengineering environment. In Michel Wermelinger
and Harald Gall, editors, Proceedings of the European Software En-
gineering Conference, ESEC/FSE’05, pages 1–10, New York NY,
2005. ACM Press.
[22] Hani Samir, Amr Kamel, and Eleni Stroulia. Swing2script: Migra-
tion of Java-Swing applications to Ajax Web applications. In 14th
Working Conference on Reverse Engineering (WCRE 2007), 2007.
[23] Óscar Sánchez Ramán, Jesús Sánchez Cuadrado, and Jesús Gar-
cía Molina. Model-driven reverse engineering of legacy graphical
user interfaces. Automated Software Engineering, 21(2):147–186,
2014.
[24] Eeshan Shah and Eli Tilevich. Reverse-engineering user inter-
faces to facilitate porting to and across mobile devices and plat-
forms. In Proceedings of the compilation of the co-located work-
shops on DSM’11, TMC’11, AGERE! 2011, AOOPES’11, NEAT’11,
\& VMIL’11, pages 255–260. ACM, 2011.
[25] João Carlos Silva, Carlos C. Silva, Rui D. Goncalo, João Saraiva,
and José Creissac Campos. The GUISurfer tool: towards a lan-
guage independent approach to reverse engineering GUI code. In
Proceedings of the 2Nd ACM SIGCHI Symposium on Engineering
Interactive Computing Systems, pages 181–186. ACM Press, 2010.
[26] Stefan Staiger. Reverse engineering of graphical user interfaces us-
ing static analyses. In 14th Working Conference on Reverse Engi-
neering (WCRE 2007), pages 189–198. IEEE, 2007.
11