Hans van Wezep, software architect at Philips Healthcare, talked about model-based migration at the Bits&Chips Software Engineering conference.
InfoQ did an interview with van Wezep about the challenges in maintaining legacy software, why manual refactoring is error prone, using models to refactor and migrate a codebase, and the benefits of using models when maintaining legacy software.
InfoQ: Maintaining legacy software can be challenging. Can you mention some of the main problems that you had?
Van Wezep: In our case we’ve actually seen two big problems: a growing codebase and as a result, a challenge in adding new functionality to the software quickly.
Although the core functionality didn’t change much in the last 15 years, people in the software teams changed. New engineers did not dare to risk breaking functionality of the core parts of the system and kept extending the code base instead of adapting and refactoring. As a result, we have seen parts of the code base to grow a factor 8.
Due to the growing codebase, innovation stalled. According to industry metrics one engineer can maintain about 50 to 100kLOC. This meant that a large part of the software teams were actually maintaining the existing codebase instead of creating new features.
InfoQ: Can you explain what in your opinion makes manual refactoring error prone?
Van Wezep: Although healthcare software engineers value quality highly, even we software engineers are fallible. Typical numbers of the initial mistakes that are made by engineers is about 2 bugs per 100 LOC, according to literature. As our systems need to keep a high quality standard, these bugs put burden on the test organization and create unnecessary rework.
InfoQ: You talked about a "model-based migration" approach that you use to maintain your legacy software. Can you briefly describe how this works?
Van Wezep: Actually, the model-based migration that we introduced is a refactoring of the old codebase into a model-based design approach. By analyzing the old code base and the old documentation, we found a model hidden inside the old libraries and frameworks that we used. Together with colleagues from TNO-ESI the model was extracted through software mining and reverse engineering, which described the behavior of the software and its variability.
On the other side of the equation, we created another model describing our preferred architecture. Using model-to-model transformations we transformed instances of the "old" model to instances in the new model.
From these instances in the new model we generated our code, reflecting our new architecture and at the same introducing new technologies. For example, we replaced several architectural control layers with one simple control layer and replaced the Philips proprietary UI framework with the Qt framework, an industry standard with vast documentation and support resources, to make life more simple and maintainable.
InfoQ: How did you introduce model-based migration at Philips Healthcare?
Van Wezep: Within Philips Healthcare we had a very interesting use-case. Our field service procedures to service our system were built on multiple frameworks. This created architectural overhead and additional work during testing.
As a manual refactoring was not an option due to the investment required, we partnered up with TNO-ESI to see whether this model-based migration approach was feasible and whether we could do it in a running project without harming the planning. We prototyped the approach and we were very happy with the outcome, both from a technical as well as a planning perspective. After consulting the architects and managers of the department, they got very excited by the approach and the benefits this approach would bring. And we decided to put it in the running project to capitalize on these benefits as soon as possible.
InfoQ: Which benefits did this approach bring?
Van Wezep:In the end, this approach really paid off for the field service procedures. The codebase of all the frameworks and the instances of the field service procedures amounted to a very significant code base. After the model transformation and code generation we reduced the codebase to only 70% of the legacy codebase, which is remarkable.
Also, based on a standard productivity metric of 6 LOC per hour, we were able to increase productivity to 36 LOC per hour. And because the manual migration was already planned for an upcoming project, we not only introduced it much earlier, the 80% reduction is an excellent cost-saving.
Furthermore, updates to code can be done more easily, because we only have a model to maintain and generation of the code is done with one push of a button. And we regained knowledge; the model we have describes the essence of the field service procedures and their interactions with the system, which is again a huge plus.
InfoQ: If people want to learn more about model based approaches for software redesign or refactoring, are there any resources that you can recommend?
Van Wezep: Actually, there are not that many resources about such a particular way of using model based approaches for refactoring and redesign. If people want to learn more about this approach, they are of course free to contact us. We will be delighted to share our experience like we did at the Bits & Chips Software Engineering conference 2015.
