Over the last decade, open source frameworks for creating domain-specific language workbenches have improved significantly. Thereby, it has become easier to utilize model-driven software engineering based on domain-specific languages (DSL). However, many companies already adopted model-driven engineering at the beginning of the 21st century. 

Typically, Unified Modeling Language (UML) models are the basis for these approaches. In most cases, these models are created and maintained with expensive proprietary tools such as Rational Software Architect or Enterprise Architect.

Migration Approach: From UML to DSL

To illustrate the migration process the data layer of an application written in Java will be migrated to an instance of an Entity DSL. The language workbench for the Entity model was created using the Xtext framework. Based on a grammar written in the Xtext-specific Extended Backus-Naur Format the editor, parser, and abstract syntax tree for the Entity DSL is generated.

The figure above shows the process of migrating existing source code written in Java to a textual representation of an Entity DSL model. Since Java input and Entity DSL are both managed within the Eclipse IDE, the migration utilizes further Eclipse plugins. First, the Java sources of a project to be migrated are parsed by the Eclipse Java Tools.
Based on the instantiated Java abstract syntax tree (AST) the DSL Migrator creates elements of the Entity AST.  For every Java class extending the DataObject interface, the DSL Migrator creates a new instance of the Entity class. Moreover, for every field or operation in such a class, a new attribute or operation is created, respectively.
In addition, to the AST elements shown in the simplified example, the DSL Migrator also creates more detailed artifacts such as data types, parameters or exceptions. Although the migration approach relies on the source code, this source code has to abide by a particular structure regarding available class files, implemented interfaces, etc. to be successful. 

After the Entity DSLs AST has been created, the DSL Serializer serializes the content of the AST. The DSL Serializer has been inferred from the Xtext-specific grammar and will create a text file accordingly. The whole migration process is integrated into the Eclipse IDE and can be triggered on the project level.

Testing the migration approach

After implementing the migration process, automated tests verified that the generated Java files are equivalent to the previous source code. The tests were implemented using the Xpect framework which is dedicated to testing Xtext domain-specific languages. Besides support for parser, formatting and proposal tests, Xpect also offers functions for setting up complete Eclipse workspaces.

The figure above shows the test process implemented using Xpect. In the setup phase of the test, Xpect creates an empty workspace and imports a predefined sample Java project. The first step of the actual test routine starts the migration process. In the next step, the generator turns the migrated Entity DSL model into Java code. 
Finally, the test verifies that the generated source code is equivalent to the code used as input for the migration.

The test case described above is suitable for testing if from a known input to the migration process the expected output is generated. However, to test the migration approach thoroughly source code from existing software components should be used as input to the process.

Scaling the Migration Approach

Although the migration process is fully automated, there are still some things to do. First, the migration process is based on reverse-engineering Java source code. Even if the source code abides by certain proprietary framework rules, there is still an unpredictable number of variants in which the source code might be implemented. Second, it must be verified that the code generated from the DSL is equivalent to the source code used as input for the migration.

In order to achieve those goals, a process was introduced to perform the migration automatically for each project on a daily basis. The figure above shows the extended process to run the migration test for multiple existing software components. The elements highlighted in green were changed in comparison to the process described in before. First, the workspace setup imports multiple software components. Second, an additional step in the process creates a detailed report on the migration. Finally, the process persists every migration report per component as a file.

Technically the migration is executed on a dedicated continuous integration environment, migrating the more than 600 software components. Depending on the software component size each migration takes between 20 seconds and several minutes. To efficiently migrate all software components, they are migrated in parallel doing 100 components per workspace. In this setup, the overall migration takes approximately 4 hours and is executed once a day. Thereby, effects of changes in the DSL Migrator or the software components on the migration is reported on a daily basis. Further, the continuous test environment can be used in the future to test the impact of changing the DSL or the generators.

Conclusion

The Eclipse ecosystem offers powerful tools to fully implement a UML to DSL migration. However, the UML-agnostic approach heavily depends on the source code abiding a particular structure. The migration process mainly benefits from the JDT parser and the DSL Serializer. While those two handle parsing and serializing, the DSL Migrator can completely focus on the model-to-model transformation on the meta-model level.

Additionally, it has been shown that testing the approach with artificially created projects is an important first step of verification. However, to ensure that the migration is working, it must also be tested with existing software components. To summarize, the extended testing approach offers many benefits: first, the migration can be tested automatically for all existing software components. Second, the generated migration report is easily accessible and gives a quick overview of problems during the migration. Finally, the automated test environment can be used in the future to detect the impact of changing the DSL and its generators.