Article: Staying Safe and Sound Thanks to MDSD

In this article, Andreas Kaltenbach explains how Model-Driven Software Development (MSDS) can help solving backward compatibility problems when creating a newer version of a software which can mean a new API or a new database schema that old clients cannot use. MSDS is used to negotiate the differences between versions to ease the upgrading process.

Each new software product becomes old and legacy after is installed and used by clients. New versions of the software will need to consider the old one and the existing client base. There are two important areas subject to changes that need to be taken into consideration: API and database schema.

The article explains how MSDS helps creating API and database schema difference reports showing what has changed in the new version of a software thus keeping the change under control.

My believe is that such diff tooling will never exist. It is impossible to track the changes between the models and to derive a proper transition of the persistent data and backwards compatibility behavior.

I strongly believe that a "Change DSL" where you explicitly describe the changes to the model is the key here. The diff model can then be used as a validation that your change description is complete and that you can derive the new from the previous model.

From the "Change DSL" (can be OAW xText based) written transition the backward compatibility and database scripts can then be easily derived.

We have to distinguish between responsibilities here:1. We need a tool to estimate the diff between two models. With EMF Compare, this already exists. For sure, EMF Compare has its limitations - in the worst case it assumes that there is no similarity at all between two models. A robust solution has to absorb this case and has to react accordingly. 2. With the diff at hand we can do whatever we want. I highlighted two possible approaches (API compatibility & Schema Derailment) in the article.

Yes Karsten, it is important to confess that such solutions will never release developers from thinking about compatibility concerns of their products. A 100% generation of backwards compatibility artefacts is neither desired nor possible in my opinion. The sum of compatibility artefacts consists of generated and manually written code. I tried to indicate this in the pictures by using blue for generated and grey for manually written artefacts. For the manual part, such a "Change DSL" you mentioned seems to be the perfect match ;-)

The diff tooling has two strong benefits: First, it provides guidance and support for developers. It is able to detect deviances between model versions. Even the availability of system change information helps to make developers aware of incompatibilities. Second, such tooling covers changes which happen often and follow a certain pattern (e.g. the typical renaming of model elements). For such recurring patterns it is worth writing code once that produces the needed artefacts. Once, you described which artefacts should be derived for a certain change pattern, you could reuse it whenever a change, following the same pattern, is detected.