Article: Staying Safe and Sound Thanks to MDSD
- Share
-
- |
Read later
My Reading List
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.
Read: Staying Safe and Sound Thanks to MDSD
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.
COPE framework - Coupled Evolution of Metamodels and Models
by
Cédric Vidal
Regards,
Cédric Vidal
MDSD Architect at ProxiAD
proxiad.com
Diff Model
by
bruce b
Re: Diff Model
by
Karsten Klein
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.
Re: Diff Model
by
Andreas Kaltenbach
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.
Educational Content
Writing Usable APIs in Practice
Giovanni Asproni May 19, 2013
Concurrency in Clojure
Stuart Halloway May 17, 2013
Hello stranger!
You need to Register an InfoQ account or Login to post comments. But there's so much more behind being registered.Get the most out of the InfoQ experience.
Tell us what you think