In the context of a collaboration with BergerLevrault, a major IT company, we are working on the migration of a GWT application to Angular. We focus on the GUI aspect of this migration which, even if both are web frameworks, is made difficult because they use different programming languages (Java for one, Typescript for the other) and different organization schemas (e.g. different XML files). Moreover, the new application must mimic closely the visual aspect of the old one so that the users of the application are not disturbed. We propose an approach in three steps that uses a meta-model to represent the GUI at a high abstraction level. We evaluated this approach on an application comprising 470 Java (GWT) classes representing 56 screens. We are able to model all the web pages of the application and 93% of the widgets they contain, and we successfully migrated (i.e., the result is visually equal to the original) 26 out of 39 pages (66%). We give examples of the migrated pages, both successful and not.
During the evolution of an application, it is sometimes
necessary to migrate its implementation to a different
programming language and/or Graphical User Interface (GUI)
framework [
Our work takes place in collaboration with BergerLevrault, a major IT company selling Web applications developed in GWT. However, GWT is no longer being updated with only one major release since 2015. As a consequence, Berger-Levrault decided to migrate its GUI to Angular 6.
The company developes 8 applications using GWT. Each application has more than 1.5 MLOC and represents more than 400 web pages. The applications are built from more than 45 kind of widgets and 29 kind of attributes. The company estimated the migration for one application to 4 000 man-days. So, migrating automatically the visual part of an application would already be a useful step for the modernization of the company’s applications. Because of fast evolution of GUI framework, the company also needs a reusable solution for the migration to the next programming language.
There are many published papers on supporting GUI
migration (e.g. [
We present an approach to help developers migrate the GUI of their web-based software systems. This approach includes a GUI meta-model, a strategy to generate the model, and how to create the target GUI. To validate this approach, we developed a tool which migrates Java GWT applications to Angular. Then, we validated our approach on an industrial project that is used to present all the widgets and their usage. It is composed of 470 Java classes and 56 web pages. Our approach imported correctly 93% of the widgets and 100% of the pages. Since not all the existing widgets are re-implemented in Angular, we tried to migrate 39 pages and were successful (same visual appearance) for 26 of them (66%).
First, in Section 2, we review the literature on GUI metamodeling. We describe the context of our project in Section 3. In Section 4, we describe our migration approach. We present our implementation in Section 5. Section 6 describes the experiment we made to validate our approach. In Section 7, we present our results. Finally, in Section 8 and Section 9 we discuss the results obtained with our tool and future work. 2
Section 2.1 presents the techniques used to migrate an application. In Section 2.2, we describe the user interface meta-models found in the literature. 2.1
To define a migration strategy, we identified research work
related to application migration. Some of the proposed
approaches do not perform a full migration, but only a part of
it. Also, there are numerous publications dealing with
programming language migration. We do not, however,
consider them if they do not explicitly discuss the GUI
migration. This is the case, for example, with the work of Brant
et al. [
We identified three techniques to create a representation of the GUI: static, dynamic, or hybrid.
Static. The static strategy consists in analyzing the source code and extracting information from it. It does not execute the code of the analyzed application.
Cloutier et al. [
Lelli et al. [
Sánchez Ramán et al. [
The static strategy allows one to analyze an application without having to execute it or even compile it. Apart from the classical problem of showing all the potential facts rather than only the real one, another limitation appears for example, with a client/server application, when a part of the graphical interface depends on the result of a request to a server.
Dynamic. The dynamic strategy consists in the analysis of the graphical interfaces of an application while it is running. It explores the application state by performing all the actions on the user interface of the software system and extracting the widgets and their information.
Memon et al. [
The dynamic analysis allows one to explore all the windows of an application and to gather detailed information about them. However, automatically running an application to methodically capture all its screens might be a difficult task depending on the technology used. Also, if a request is done to build a GUI, the dynamic analysis does not detect this information which may be essential for a full representation of a GUI.
Hybrid. The hybrid strategy tries to combine the advantages of the static and dynamic analyses.
Gotti and Mbarki [
Despite the usage of both static and dynamic analysis, the hybrid strategy does not solve the request problem inherent to client/server applications. It also has the same issues as the dynamic analysis of running automatically an application and capturing its screens.
Fleurey et al. [
None of the authors considered the migration from web
GUI to web GUI. Also, none had the constraint of keeping
similar layout except Sánchez Ramán et al. [
The OMG defines the KDM standard to support the evolution of software. The standard defined a meta-model to represent a piece of software at a high level of abstraction. It includes a UI package which represents the components and behavior of a GUI.
+UIElement 0..* 0..1 +owner
UIResource UIDisplay
UIField Screen
Report
UIAction + kind : String 0..1
+owner
UIEvent + kind : String 0..*+UIElement
ViewElement. A ViewElement can be refined as a ViewContainer or a ViewComponent.
A ViewContainer represents a container of other ViewContainers or ViewComponents. For example, it can be a window, an HTML page, a panel etc. The composition between ViewContainer and ViewElement is used to define the DOM.
A ViewComponent corresponds to a widget which displays its content, e.g. a form, a data grid, an image gallery etc. It can be linked to multiple ViewComponentPart. A ViewComponentPart represents an element of a ViewComponent. For example, an input field inside a form, a text which is displayed inside a data grid, or an image element of a gallery. 2.2.2
Other GUI meta-models have been proposed in the literature. We compare them to the OMG standards.
All the meta-models use the Composite pattern to represent the DOM of a GUI and define a kind of UIResource entity to represent a graphical element of the interface.
Gotti and Mbarki [
Fleurey et al. [
Morgado et al. [
The UI meta-model of Garcés et al. [
Memon et al. [
Samir et al. [
Shah and Tilevich [
Joorabchi and Mesbah [
Memon [
Mesbah et al. [
All the authors used the notion of widget that represents a visual entity of the user interface. Most of them have an entity attribute that represents a characteristic of a widget. Finally, the navigation links are represented with an action entity. 3
The goal of our work is to migrate the user interfaces from a given graphical interface framework to another. This is an industrial project, migrating web applications from GWT to Angular. The objective is to produce a running user interface in the target framework. We now present the conditions of the projects. In Section 3.1 we list some constraints that we must fulfill. In Section 3.2 we describe the main differences between GWT applications and Angular ones.
In Section 3.3 we present a categorization of the front-end source code. 3.1
From the previous works of Moore et al. [
In this project, the source language and the target language impose two different organization schemas. Their differences are syntactic and semantic.
GWT is a framework that allows developers to write 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 web application with the TypeScript language. It is used to create Single-Page Applications1.
Table 1 summarizes the differences between GWT
applications and Angular ones, concerning: web page
definition, their style and the configuration files. Before
explaining these three differences, we note one major similarity:
1Single-Page Applications (SPAs) are Web apps that load a single
HTML page and dynamically update that page as the user interacts with
the app.
As proposed by Hayakawa et al. [
• Visual Code The visual code describes the visual aspect of the GUI. It contains the elements of the interface. It defines the inherent characteristics of the components, such as the ability to be clicked or their color and size. It also describes the position of these components compared to others. • Behavioral code The behavioral code defines the action/navigation flow that is executed when a user interacts with the GUI. The behavioral code contains control structures (i.e. loop and alternative). • Business code The business code is specific to an application. It includes the rule of the application, the distant server address and the application-specific data.
Because of the size and diversity of source code, migrating one of this code category is already an important problem. 4
This section presents the migration approach we designed. In Section 4.1, we describe the migration process we designed. Section 4.2 presents our GUI meta-model. 4.1
From the state of the art, the constraints and the decomposition of the user interfaces, we designed an approach for the migration.
The process, represented in Figure 4, is divided into the three following steps: 1. Extraction of the source code model. We build a model representing the source code of the original application. In our case study, the source program is written in Java GWT. The extraction produces a Source code model Source code model extraction
Source application
GUI model extraction
GUI model 2. Extraction of the GUI model. We analyze the source code model to detect the Visual code elements describing the GUI and we build a GUI model from these elements. The GUI meta-model is described Section 4.2. 3. Export. We re-create the GUI in the target language.
This step exports the user interface files and the configuration files of the application.
Note that currently we treat neither the Business code nor the Behavioral code of the application. This will be the focus of future work. 4.2
To represent the user interfaces of desktop or web-based applications, we designed a GUI meta-model from the ones presented in Section 2.2.2. In the rest of this section, we present the entities of the meta-model.
Our meta-model is an adaptation of KDM metamodel(see Figure 1). As many others, we separate the graphical resources corresponding to the DOM from the actions and events. In our meta-model, graphical resources are called Widget. They can be refined as Leafs or Containers
In our context, the user interface will always be displayed on a screen. So we do not represent all the kind of UIDisplay and define an entity Page. The Page represents the main container of a graphical interface. It is either a window of a desktop application or a web page. The Page is a kind of Container.
As proposed by many other authors, we added the entity Attribute in our GUI meta-model. An Attribute represents the information of a widget and can change its visual aspect or behavior. Some common attributes are the height and the width to precisely define the size of a widget. There are also attributes that contain data. For example, a widget representing a button may have a text attribute that contains the text of the button. An attribute can change the behavior of a widget, this is the case of the attribute enable. A button with the enable attribute set to false represents a button on which one cannot click. Finally, the widgets can have attributes that impact the visual aspect of the application. This type of attribute allows us to define a layout to be respected by the widgets contained in the main one and potentially the dimensions of the latter to respect a particular layout.
To test our approach, we implemented a migration tool. It is implemented in Pharo2 and the meta-model is represented using the Moose platform3. 5.1
Applications at Berger-Levrault (our industrial partner) are based on the BLCore framework. This framework consists in 763 classes in 169 packages. It is developed by the company on top of GWT and defines the widgets that developers should use, the default visual aspect of the applications, and Java classes to connect the front-end of the application to the back-end. It also encourages some coding conventions.
For the Berger-Levrault applications, we add a new entity (Business Page) to the GUI meta-model presented Section 4.2 to fit the company’s specific organization. It is a 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 included in the Business Pages, never directly in the Page.
In part because of the complexity of setting up a tool to run automatically and capture all screens of such large web applications, we rely on static analysis to create our model. The results so far seem to indicate that it will be sufficient.
As presented Section 4.1, the creation of the GUI model
is divided in two steps: the source code model extraction
and the GUI model extraction. For the source code
metamodel, we use the Java meta-model of Moose [
For the second step of the extraction, our tool creates the GUI model from the source code model and an analysis of the XML configuration file. The entities we want to extract are, first, the Pages. We parse the XML configuration file in which is defined the information about the pages (see 2Pharo is a pure object-oriented programming language inspired by Smalltalk. http://pharo.org/
3Moose is a platform for software and data analysis. http://www. moosetechnology.org/ 4verveineJ : https://github.com/moosetechnology/verveineJ Section 3.2). It provides for each Page (called phase in the XML file, Figure 3) its name and the name of the Java class that defines it. Then, the tool looks for Widgets.
First, the tool determines the available widgets. To do so, it collects all the Java subclasses of the GWT class Widget. For the Buisiness pages, the tools looks for the classes that implement the IPageMetier interface. Then, the tool looks where the Widget constructors are called and creates the links between the Widgets and their parent Widget. In Figure 5, there are two calls to Widget constructors: line 4, the constructor of BLLinkLabel is called, and line 11, the constructor of Label. The variable vpMain corresponds to the main panel of the Business page. Lines 11 and 12 correspond to adding a widget inside a panel widget thanks to the method add().
Finally, to detect attributes and actions which belong to
a widget, the tool detects in which Java variable the
widget has been assigned. Then, it searches the methods
invoked on this variable. If a widget invokes the method
“addClickHandler”, it creates an event. If it invokes a method
“setX”, it creates an attribute. These heuristics were found
in the literature [
In this section, we describe the industrial application on which we used our tool to validate our approach. Section 6.1 presents the industrial application. Section 6.2 presents the metrics we used to evaluate our approach.
We experimented our strategy on Berger-Levrault’s kitchensink application. This software system, dedicated to developers, aims to gather inside a single simple application all the components available for building a user interface. This application is smaller than a production one but still uses the BLCore framework. The company framework guarantees us the kitchensink application works exactly the same way as the industrial applications. It contains 470 Java classes and represents 56 web pages. Although it is the sample and demo for developers, the kitchensink application contains code misuses.
Note that the kitchensink application, as the other industrial applications of the company, does not have test. Therefore, there is no possibility to use tests to validate the migration. 6.2
The validation is done in three steps: First, we check the constraints defined in Section 3.1; Second, we validate that all GUI entities of interest are extracted and correctly extracted; Third, we validate that we can re-export these entities in Angular and that the result is correct.
For the first validation, we manually identify and count the entities in the kitchensink application and compare the results of the tool to this count. Our analysis focuses on the migration of three entities: Pages, Business Pages and Widgets • Pages. From the XML configuration file of the application we manually count 56 pages. This configuration file also provides the name of each page. • Business Pages. As explained before, the business pages correspond to a concept specific to BergerLevrault. They are defined in the BLCore framework as a Java class which implements the interface IPageMetier. Thanks to this heuristic, we manually count 76 Business Page instances in the original application. • Widgets. In the literature survey, we did not find an automatic way to evaluate the detection of widgets. Checking all widgets in the application would be long and error-prone as there are thousands of them. As a fallback solution, we take a sample of the pages of the kitchensink application and count the widgets in the DOM of these pages. We consider a sample of 6 Pages which represents a bit more than 10% of the Pages of the application. These Pages are of different sizes and contain different kinds of widgets. In total, we found 238 Widgets in these 6 Pages. To get a more exact idea of the representativeness of our sample, we also count the number of Widget creation (i.e. new AWidgetClass()) in the code. There are 2,081 such creation. This may not represent the exact number of widgets in the entire application, but it is a good estimate. We note that the number of Widgets in our sample (slightly more than 10% of the pages) is also slightly more than 10% of our estimate of the total number of widgets.
For the evaluation, we also check that the Widgets are correctly placed in the DOM of the interface (i.e., they belong to the right Container in the GUI model).
In our results we consider only the recall of the tool because the precision is always 100% (there are no false positive). This is a sign that the BLCore framework provides clear (if not complete) heuristics to identify the entities.
For the second validation, we check that the entities are exported correctly. In the Angular application, each Page corresponds to a sub-project and is represented by a folder. The name of the folder must correspond to the name of the Page. The Business pages are represented by a sub-folder inside the Page project. The names must also match at this level.
We also check visually that the exported Page “looks like” the original one. This is a subjective evaluation, and we are looking for options to automate it in the future. 7
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 confront the exported result with the constraints defined in Section 3.1. 7.1
We set the following constraints in Section 3.1: From GWT to Angular, Approach adaptability, Code quality conservation, Keep visual aspect, and Automatic.
Our tool can use Java code as input and generate Angular code. The exported code is compilable and executable. The target application can be displayed. We can thus confirm that our tool fulfill the GWT to Angular constraint.
Our tool is applicable on other source target technologies. Our heuristics have been designed to be easy to adapt, a user of our tool can thus add a new kind of widget for the import or the export phases. We shortly describe a small experiment in that sense in Section 8.5. Those possibilities satisfied the adaptability constraint.
The Code quality conservation and Keep visual aspect constraints are discussed in Section 7.3, in the third validation results.
Finally, the results described here were obtained automatically from application of our tool to the subject application. This validates the last constraint. 7.2
Table 2 summarizes the extraction results.
The tool extracted 56 Pages from the original GUI. This corresponds to the number of pages defined in the configuration file of the kitchensink application.
The tool extracted 76 Business pages. This value corresponds exactly to the number of business pages in the original application. Moreover, the tool correctly assigned each Business page to its proper Page.
We got 100% of the Widgets on the evaluated sample were correctly detected. However, 27 out of the 238 Widgets of our sample (11%) were not correctly assigned to their parent container. All these problems come from one single Page (containing 75 Widgets in total). We manually checked the name of all the 56 exported pages. They all conserve their original name. (a) GWT original (b) Angular migration Figure 6 presents the visual differences between the original (GWT) version, left hand, and the migrated (Angular 6) one, right-hand. We can see that there are only minimal differences. In the exported version, the color of the header is a bit clearer, and the lines are a little more distant.
Figure 7 presents the visual differences for the Page
Input box. Again on the left-hand side there is the
original Page and on the right-hand side the same Page
after the migration. Because the two images are large, we
Section 8.1 and Section 8.2 presents two parts of the user
interface we did not work on. Section 8.3 discusses the
impact of the choice of the kitchensink application as case
study. Section 8.4 highlights the difficulties in large scale
validation of our tool. Finally, Section 8.5 discusses the
impact of the BLCore framework.
As shown in Section 7.3, the export may give incorrect
results because of layout issues (Figure 7). It is due to
the representation of the layout in our GUI meta-model.
Currently, layouts are represented in our GUI meta-model
as an attribute on a Container widget defining if the
children of this widget are placed ones beside the other or one
below the other (i.e. vertical or horizontal flow layouts).
However, many other layouts exist [
A solution is proposed by Sánchez Ramán et al. [
Moreover, with such layouts, the position of the children Widgets might be computed at run time. For example, in a grid layout, the children may be positioned according to the values of some row and col variable. Guessing these values with a static analysis is not practical, and this is a case where an hybrid approach might be necessary.
Currently, only the visual part of the GUI is migrated. To take into account the whole application, the migrations of the Behavioral and Business code (see Section 3.3) are needed. The Behavioral represent the user interactions (i.e. click, drag-and-drop, hover, ...) and the control structures (i.e. loop and alternative). In the case of a client/server application, requesting a server is part of Behavioral code, whereas the query in itself and the data belongs to Business code. 8.3
Although the results are encouraging, we only evaluated our tool on the kitchensink application. The kitchensink application is a good training ground for our tool as it contains all kinds of widgets that developers have at their disposal and the way to use them. However, it might diverge from production applications as it should contain less irregularities or coding tricks than the later. 8.4
The automatic validation of the screens migration is currently an unsolved problem. It is possible to manually check the result of the migration for a few pages but it would be better to do it automatically for hundreds of pages (more than 400 on Berger-Levrault applications).
We found, in the literature, only few approaches
considering automatic visual validation. In two papers [
As explained in Section 5.1, the Berger-Levrault
applications are based on the BLCore framework. By specializing
GWT, BLCore provides specific widgets and a dedicated
API. This may have an impact on our approach or not. To
evaluate this possible impact, and also to validate the
generality of our approach, we performed two small experiments
considering (i) Spec (a desktop UI framework in Pharo [
Some conclusions are: • It was harder to import Spec code than GWT because of a larger variability in defining the GUI. We conclude that the BLCore framework eased our work on the import by standardizing how to build the pages. • For Seaside, it was easy to migrate simple widgets (e.g. Label, Button, Panel), but the BLCore framework also defines complex widgets with no direct equivalent in Seaside. A library similar to BLCore should be defined in Seaside to ease the migration. • the power of our GUI meta-model and the two steps extraction (first, source code model extraction, then GUI model extraction, see Figure 4) are validated by the fact that we were able to migrate a Pharo desktop application with little extra work. 9
We created a tool with promising results on the representation of GUI to migrate GWT applications toward Angular. In the following, we conclude the presentation of this work and propose some future research directions we want to explore. 9.1
In this paper, we exposed a preliminary work on the problem of visual preservation and respect of the target architecture during the GUI migration of an application. We proposed an approach based on a GUI meta-model and a migration process in three steps. We implemented this process in a tool to perform the migration fof GWT applications to Angular 6. Then, we validated our tool with an experiment on a kitchensink application. We were able to extract correctly all pages of the application and 89% of the widgets. The migration results are visualizing equivalent as long as complex widgets (e.g. GridLayout) are not used. Dealing with these layouts is our next challenge.
Our solution also allows us to respect the naming conventions used in the source application as well as the structure of the code as far as the differences in the GUI frameworks allow it. 9.2
To improve the migration of an application user interface, we will enhance our meta-model and our tool to support the management of the layout and the behavioral and business code.
We did not find an approach or metrics to automatically evaluate the validity of the migrated screens. So, it is important to find a new way to evaluate that the migrated screens conserve the visual aspect of the original ones.
Having a good GUI meta-model also opens the door for a generic GUI builder that could export the GUI in several different GUI frameworks.