On the automation of the horse-shoe model for software modernization

Software modernization processes usually follow the well-known horse-shoe model [1], which provides a framework to integrate different abstraction levels and reengineering tools. In today’s guest post, Jesús Sánchez Cuadrado, Orlando Ávila García, Javier Luis Cánovas Izquierdo and Adolfo Sánchez-Barbudo Herrera propose a reinterpretation of the horse-shoe model (or better said, a back-to-the-roots approach) based on their experience in applying software modernization in industrial scenarios.

The horse-shoe model promotes representing the software system at a progressively higher levels of abstraction in order to facilitate the different modernization tasks. To do so, the transformations between software artefacts can be horizontal (i.e., artefacts at same abstraction level) or vertical (i.e., artefacts at different abstraction levels). The Architecture-Driven Modernization (ADM) is an OMG’s initiative which aims at defining and standardizing techniques, methods and tools for software modernization. It incorporates the horse-shoe framework as its reference model and uses MDE techniques as the implementation foundation (i.e., MOF-based meta-models, or model-transformation). An ADM-based modernization process consists of three main phases: (1) a reverse engineering phase to obtain models (typically KDM models) describing the source system at a high level of abstraction; (2) a restructuring phase to transform those source models into target models; and (3) a forward reengineering phase to generate the new system from the target model.

Figure 1. (a) Traditionally applied horse-shoe model. (b) The more practical approach

We believe that, to some extent, the ADM initiative has misinterpreted the original horse-shoe model. Let us explain: this approach, although ideal, does not seem to be practical since the so-called models of high level of abstraction do not normally include all the information required to generate the target system. Indeed, by definition, the abstraction process implies losing information (e.g., design decisions), which hampers the application of only one horizontal transformation at a high level of abstraction.

Instead, it seems more natural to apply several horizontal transformations at different levels of abstractions, as shown in Figure 1b. In fact, from our point of view, this is the horse-shoe model presented originally in [1]. When interpreted in this way, the challenge is how to synchronize the higher-level transformations with the lower-level ones.

The case study which triggered this debate is based on a core banking migration process which required some refactoring tasks in its source code. In this case, several models were extracted to understand the code and identify the elements to be modified. The migration process was then performed by a source-to-source transformation (i.e., low level of abstraction), which uses the information discovered through those models to drive the source code refactoring. Thereby, a transformation at a high level of abstraction was no necessary and even would have complicated the modernization process.

Following our experience, we have identified two possible techniques to automate the horse-shoe model so far, which are shown in Figure 2: (1) explicit parameterization, in which horizontal transformations receive information from models at higher levels of abstraction, as the case study described before; and (2) implicit parameterization, where horizontal transformations receive information from traces of transformations performed at higher levels of abstraction.

Figure 2. (a) Explicit parameterization. (b) Implicit parameterization

This work was firstly presented in the position paper titled “Parametrización de las transformaciones horizontales en el modelo de herradura” (“Parameterization of horizontal transformations in the horse-shoe model” in English), which won the best paper prize in the Model-Driven Engineering (MDE) track at the JISBD Spanish conference. The work is still a starting point which we would like to contrast and discuss with the community. One of the things we firstly want to establish is whether the “ideal” horse-shoe model (i.e., the one with only one horizontal transformation at the highest level of abstraction) is practically applied in the industry. We would also like to gather information about industrial experiences applying any of the two parametrization techniques we have identified so far in order to fully automate the horse-shoe model.

[1] R. Kazman, S. G. Woods, and S. J. Carrière, “Requirements for Integrating Software Architecture and Reengineering Models : CORUM II,” in WCRE conf., 1998, pp. 154–163.