Support for the automation of Web application interface migration: the case of GWT to Angular
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. Web GUI frameworks in particular evolve at a fast pace. For example, in 2018 there were two major versions of Angular, three major versions of React.js and four versions of Vue.js. This forces companies to update their software systems regularly to avoid being stuck in old technologies.At Berger-Levrault, we need to migrate our applications from the GWT framework to Angular. We have 8 applications that used GWT. Each application has more than 1.5 MLOC (Million Lines of Code) and represents more than 400 web pages. In this work, we propose an approach in four steps that uses meta-model to represent the GUI at a high abstraction level.
Meta models
Our constraints
We identify the following constraints for our case study:
- From GWT to Angular. In the context of the collaboration with Berger-Levrault, our migration approach must work with Java GWT as source language and TypeScript Angular as target one.
- Approach adaptability. Our approach should be as adaptable as possible to different contexts. For example, it can be used with different source and target languages and tuned by a developer to fit his requirement.
- Keep visual aspect. The migration must keep the visual aspect of the target application as close as possible to the original.
- Code quality conservation. Our approach should produce code that looks familiar to the developers of the source application. As far as possible, the target code should keep the same structure, identifiers and comments.
- Automatic. An automatic solution makes the approach more accessible. It would be easier to use an automatic approach on large system.
Import implementations
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 enough. 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 meta-model, we use the Java meta-model of Moose which comes with a Java extractor.
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. Then, the tool looks for the Business pages and the Widgets.
A Business page is defined by a Java GWT class which implements the IPageMetier interface. A Widget is defined by a class which is a subclass of the GWT class Widget. Then, for both Business pages and Widgets, the tool looks where their constructors are called and from that, it deduces and creates a link between the Widget and its container.
Finally, to detect attributes 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 it invokes a method “setX”, it creates an attribute.
