IT Modernization < V. Hanniet

software model driven approaches

MDE shuffled again

Some background
Almost nine months after my last post on this blog. What happened? I got a baby! She’s ten months old now and she has taken a big place in my “spare life”. Also I started others blogs. So, I take this long break as an opportunity to think again about what Model Driven Engineering does mean in day-to-day IT life-cycle.
First of all, thanks mainly to this blog, I met some people to talk with about modeling. Some of them are still pure spirits floating in internet’s limbo and among them: Meinte Boersma, @modelpractice, Tongying Yu, Rafael Chavez, Marco Brambilla.
Some others have materialized in my real world: Ed Seidewitz – met during a nice lunch in Paris where we talked fast and a lot cause life is short, Rémy Fannader – whose Caminao’s way is for sure a worldclass UML understanding site, Jordi Cabot – a modeling technology partner in his INRIA lab in Nantes, Jean Bézivin – one doesn’t introduce Jean who “created” the MDE term in France, Philippe Desfray – one doesn’t neither introduce Philippe who knows the OMG’s UML full story. And I don’t forget my first mentor in MDE field: Frédéric Madiot now gone working for OBEO.
By the way, Marco and Jordi just published a promising “Model-Driven Software Engineering in Practice” book. I’ll buy it!

These last months I successfully set up a government-funded R&D project named IT Modernization Factory. Is it still relevant to work on MDE solutions today? In a time when Jean Bézivin tweets:

Let’s go on with some MDE related acronyms trying to settle them quietly in today MDE’s panorama.

MDE: Model Driven Engineering = applying engineering to the use of models

  • Not specific to our IT playground, if we put apart that models are information and that the shortest way to automate or instrument engineering with information is to use some programs…
  • MDE is business goal neutral: what you will make depends on what you put into models and what engineering operations you will apply on them

MDA: OMG’s Model Driven Architecture = here is the (quite recent) FAQ

  • Tells how we can specify, and even write, applications though platform independent models (PIM) eventually using some model transformations until a last one targeting a platform specific model (PSM) which may bring the application to real application life (ie usable by human using computers)
  • In fact MDA doesn’t tell how to design nor to write applications. In a way, and in the end, one can view this MDA as a meta-meta programming language: a theory on elaborating meta-programming languages named models which allow us to specify applications and have the ability to be ultimately transformed into a “normal” programming language and all its infrastructure represented through a model (PSM) which has in turn the ability to materialize into real applications life
  • Wahou! Hopefully, I don’t think I’m wrong in this long sentence. But summarized this way we, for sure, better understand Jean’s tweet ;D
  • However, nobody tells that MDA has no virtue. I think that its best, almost usable, culmination form is fUML (see here how fUML is related to the more theoretical Executable UML). And its best achievement would have been to bring back modeling and code generation into the toolbox used by IT teams.

MDD/MDSD: Model Driven (Software) Development = using MDE for software development

  • Thanks to MDA, MDE is now again explicitly used to help software development. Software development has to directions: creating new pieces of software and maintaining pieces of existing software. MDD is usually saw as an approach for the creating direction.
  • MDD is usually a blurred copy kind of an instance of “The” MDA. One uses models to specify some business level exigences, some logical functional architecture choices and some business object details, then we build or adapt code generators which can understand the models and which hold implementation details. Then we still have to human code what has not been modeled then generated. Not necessarily simple but it works and there are many reported cases where this approach has a good ROI compared to not using models at all. And nothing deny to mix up this approach with other ones.

Reverse modeling = using MDE to maintain or make evolving existing software

  • Needless to say it: maintain and make evolving existing pieces of software is THE big problem faced by each organization. Not simple, even when this software has been developed using an MDD approach, maintaining “legacy” software is a tough job. And, my opinion, a software becomes “legacy” as soon as it has been deployed.
  • I guess the big MDE’s business deposit is here. Not an exciting promise for a student who just comes onto the market and wants to show to the world how brilliant he is for mastering promising new programming languages to enter into the Web.2020 area. But a real pain relief for CEO who just discovered TOGAF, have derived from it their own Architecture Development Method and now face to million of legacy source code lines.
  • How to? There is a lot of buzz but no standard yet. OMG has begun to work on it but it’s a shy beginning. There is also the Eclipse’s Modisco project but yet a shy move for now.
  • That’s the goal of the IT Modernization Factory R&D project I mentioned above. Will we give Modisco and OMG a boost? Still to be seen ;D

6 comments on “MDE shuffled again

  1. Hugues Van Eylen
    22/10/2012

    Hi, Vincent,
    I’m always a little bit embarrassed when, in computer science, we talk about modeling as a good practise or an activity of her own. For me, programming, writing requirements with Word and PowerPoint and of course drawing UML diagrams are Modeling. MDA and MDE seems to consider Modeling as an activity which can help to construct programs. But, to be efficient, MDA and MDE need that people knows how to model. And drawing an UML Diagram doesn’t mean to me that people know how to model. Modeling is an intellectual activity which can be enhance by good cognitive practise. This is the first requirement for MDA and MDE to become one day a useful technology. This is perhaps because people doesn’t understand what is really modeling that successful appliance of MDA is hard and that finally interest in it seems to decrease.

  2. vhanniet
    22/10/2012

    Bonjour Hugues!
    I agree that modeling is hard, and programming too. And that modeling is a bit hardest as we can’t touch something material in the end, so proper feed-back isn’t easy to get. However, we should focus on how to leverage MDE to something usable by more people and have in mind that it never will be accessible to everyone. See also http://bit.ly/WCWlIl.

  3. Rui Curado
    22/10/2012

    “MDD is usually a blurred copy of “The” MDA.”

    I disagree. MDD is not a copy of MDA. MDA, just like EMF (Eclipse), GOPPR (Metaedit+), ABSE (AtomWeaver) and other are all forms of MDD. All of them have a meta-metamodel, that is, instructions on “how to model” for that particular approach. So, my opinion is that MDA is at the same level as other modeling approaches.

  4. vhanniet
    22/10/2012

    Hi Rui,
    My intent was to make a difference between a theorical model-driven development and practical ones. So I distinguish MDA, which is a standard specification without reference implementation, from MDD practices like working with a DSL, or an UML profile, and some code generators.
    In comparison, MOF is a standard but EMF is an implementation standard: that’s not the same usability degree. In this case there are also MOF implementations, usually non public, embedded in modeling tools. But EMF, as a standard, is kinf od an instance of MOF (with some extras).
    However, we could probably say that MDD solutions are instances of the MDA approach (I change the text of my post this way). Do we agree?

    • Rui Curado
      22/10/2012

      Vincent, I still think MDA and others have taken different ways. For instance, the PIM/PSM paradigm of MDA is not reflected on any other approach that I know of.

  5. vhanniet
    23/10/2012

    Rui, I think it’s only a matter of viewpoint.
    For instance (as stated by Ed Seidewitz, somewhere!), nothing in the MDA spec tells that PSM has to be an UML profiled model. As code can be seen as a model, we could see code generators used in MDD approaches as PSM!
    And the fact that the “PIM level” model used in all MDD practices, should it be a DSL, has better to be independent of the detailed coded implementation, say the version of a framework library, is substantially a matter of SW life-cycle good practises. Some MDD solutions I know doesn’t comply to this practice: they can be used for one shot work but aren’t sustainable.
    So, I just say that MDA is a standard (there is a spec) general direction, not to be taken word for word (even if it can be), and that MDD practices, which work well but unfortunately encounter growing resistance from software craftsmen (skilled developers), may be seen as pragmatic derived forms of MDA.
    Speaking of a way level: from above in the sky the way is to capture requirements in models and to use these models as input to get code in an automated way. On solid ground, for sure, there are many detailed ways to achieve this goal…

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Information

This entry was posted on 18/10/2012 by in MDD / MDA, Modeling, Modernization, Reverse modeling and tagged , , , , .

Enter your email address to follow this blog and receive notifications of new posts by email.

Join 188 other followers

Creative Commons License
IT Modernization < V. Hanniet by Vincent Hanniet is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.