Automatically propagating changes from reference implementations to code generation templates

Abstract

Context

Code generators can automatically perform some tedious and error-prone implementation tasks, increasing productivity and quality in the software development process. Most code generators are based on templates, which are fundamentally composed of text expansion statements. To build templates, the code of an existing, tested and validated implementation may serve as reference, in a process known as templatization. With the dynamics of software evolution/maintenance and the need for performing changes in the code generation templates, there is a loss of synchronism between the templates and this reference code. Additional effort is required to keep them synchronized.

Objective

This paper proposes automation as a way to reduce the extra effort needed to keep templates and reference code synchronized.

Method

A mechanism was developed to semi-automatically detect and propagate changes from reference code to templates, keeping them synchronized with less effort. The mechanism was also submitted to an empirical evaluation to analyze its effects in terms of effort reduction during maintenance/evolution templatization.

Results

It was observed that the developed mechanism can lead to a 50% reduction in the effort needed to perform maintenance/evolution templatization, when compared to a manual approach. It was also observed that this effect depends on the nature of the evolution/maintenance task, since for one of the tasks there was no observable advantage in using the mechanism. However, further studies are needed to better characterize these tasks.

Conclusion

Although there is still room for improvement, the results indicate that automation can be used to reduce effort and cost in the maintenance and evolution of a template-based code generation infrastructure.

Introduction

Code generators can be of great help to software engineers. Given some input, which can be a high-level model or some configuration parameters, a code generator can automatically produce a high amount of code. With this approach, some tedious and error-prone implementation tasks can be automated, increasing productivity and quality in the software development process.

The template-based technique is a practical way to generate code. Templates are the most used model-to-text transformation approach [1], having become a standard by OMG (Object Management Group) [2]. But the development of code generation templates can be a great challenge. Compared to regular code, templates have extra complexity, because they mix generated code with generation code. They also have to deal with the variability in the input and produce code that implements all the functionality required by a possibly wide range of applications.

In this context, a reference implementation may help to reduce these problems [3]. Regular, non-generated code, built and tested using any software engineering approach, may serve as example of code to be produced by the templates. Different versions of the code may represent the variability at the implementation level. In most cases, assuming that the reference implementation is correct, the developer may focus on code generation alone, treating the code to be generated as simple text. Cleaveland [4], an early advocate of template-based code generation, suggests that generators should be built in this way. He states that by analyzing existing code in search for repeating patterns, it is possible to discover code generation potential. This process is known as code migration [3], or templatization [5], and can consume up to 25% of the time spent in regular development [3], [5].

This cost is not restricted to initial development, since evolution and maintenance can introduce the need for changes in the templates. Changing the templates directly may be difficult for the same reasons exposed before, and therefore the software engineer can also use the reference implementation, where errors are more easily detected and fixed, and enhancements are easier to implement [3]. Therefore, we can distinguish between two levels of templatization:

• Initial templatization: the process of creating the templates based on a reference implementation; and

• Maintenance/evolution templatization: the process of modifying existing templates based on changes made on a reference implementation.

However, this raises a problem of duplication. If the reference implementation is being maintained together with the templates, the same functionality appears at least twice: once in the reference implementation, as regular non-generated code, and once (or more) in the templates, as code to be generated. Due to this duplication, everything that is done in the reference implementation has to be copied into one or more templates. This involves determining the exact location in the templates where changes must be made, and a careful copy-and-paste operation. This extra effort may not reach 25% of regular development as reported for initial templatization [3], [5], however there is still code migration work that needs to be done during evolution/maintenance.

Given the repetitive nature of templatization, automation appears to be a viable path to reduce this effort. However, full automation is not trivial to achieve [3], as the developers’ creative thinking is often necessary for the development of template logic and proper copying of reference code into the templates. But we believe that for some simpler tasks, especially during maintenance and evolution, where the creative job of the template developer is already done, automation becomes a matter of synchronization, and can be achieved. In other words, maintenance/evolution templatization is simpler than initial templatization. Further discussions regarding these concepts and a more detailed problem characterization are presented in Section 2.

To test this hypothesis, we developed a mechanism that performs partially automated templatization for the maintenance/evolution of code generation templates. It allows changes made in a reference implementation to be automatically copied into one or more templates. Its purpose is to help to determine if maintenance/evolution templatization can be made automatic, at least partially, and to try to measure if the extra effort can indeed be reduced.

During implementation, we had to make some design decisions that imposed limitations to the mechanism. For example, it only works with a reference implementation that can be fully generated, i.e. the developer must use some generated code as reference implementation. Also, it only works in a single step, copying all changes at once, after user request. More details about the mechanism are presented in Section 3.

We also performed an empirical evaluation involving the maintenance/evolution of code generation templates (Section 4), to compare manual templatization with (partially) automatic templatization as implemented by our mechanism. We devised some evolution and maintenance tasks, involving required changes in the templates. The results showed that, even with the limitations described before, in most tasks the mechanism helped to reduce effort. We also observed that in some tasks the mechanism might not be helpful at all, as some of the changes were migrated manually in similar amounts of time.

There is not much related work attempting to achieve this goal, although there are many authors who propose interesting approaches for similar problems. We present these briefly in Section 2.2, as part of problem characterization, and in more details in Section 5.

The overall results are encouraging, motivating us to further improve the mechanism to perform better tests, not limited by practical restrictions. We highlight the main contributions and discuss future work in Section 6.