BT

InfoQ Homepage News Article: Staying Safe and Sound Thanks to MDSD

Article: Staying Safe and Sound Thanks to MDSD

Bookmarks

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. 

Rate this Article

Adoption
Style

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Community comments

  • COPE framework - Coupled Evolution of Metamodels and Models

    by Cédric Vidal /

    Your message is awaiting moderation. Thank you for participating in the discussion.

    COPE is a framework which helps with model migration and adaptation.

    Regards,

    Cédric Vidal
    MDSD Architect at ProxiAD
    proxiad.com

  • Diff Model

    by bruce b /

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Does the described diff model tool exist in practice? I haven't seen any evidence of a tool that can code generate a backward compat layer from model deltas.

  • Re: Diff Model

    by Karsten Klein /

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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.

  • Re: Diff Model

    by Andreas Kaltenbach /

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

BT

Is your profile up-to-date? Please take a moment to review and update.

Note: If updating/changing your email, a validation request will be sent

Company name:
Company role:
Company size:
Country/Zone:
State/Province/Region:
You will be sent an email to validate the new email address. This pop-up will close itself in a few moments.