Article: 8 Reasons Why Model-Driven Approaches (will) Fail

Posted by Jean-Jacques Dubray on Jul 30, 2008 10:16 PM

Community

Architecture

Topics

Model Driven Engineering

Tags

MDD ,

MDA

Model-Driven approaches have been used for several decades now. Over the last 10 years we have experienced an acceleration of the development of a strong theoretical background, frameworks and tools dedicated to Model-Driven-Engineering (MDE). Yet, MDE is difficult and projects yield sometimes disappointing results. Fernando Cardenas comments:

My take on modeling is that it is too complicated for all but larger projects/companies. Only they can afford to make the investment of time, expertise, and tooling.

Johan den Haan, Head of Research and Development at Mendix recommends that when you want to build model-driven software you'll need to devise a methodology based on ideas and experiences from others. He shared with us his extensive expertise in the field by focusing on 8 gotchas of Model Driven Engineering (MDE).

• Not targeting all goals of Model-Driven Engineering
• Only using one modeling dimension: the dichotomy between PIM and PSM
• Focusing on generating new artifacts
• Using general purpose languages
• Using custom defined domain specific languages
• Using model transformations which are not fully executable
• Not testing the model
• Insufficient tooling

One of the key point discussed in the article is the applicability of tools vs general purpose languages in MDE. Dean Wampler argues that graphical languages are guaranteed to fail:

I worked on modeling tools in a previous life and quickly realized that attempting to write software with graphical tools is misguided, for the following reasons:

• While diagrams are great for capturing the "gestalt" of a design, none of the graphical languages I have seen can capture the details of programs except in very tedious ways, which leads to the observation that...
• Textual representations are inherently more productive to use by the developer and also by tools.

I found the second point to be true even if I didn't attempt to capture all the details of methods, for example, in diagrams. I still "model", but using high-level DSL's in whatever programming language I happen to be using (Ruby, Java, Scala, ...).

Are you using model-driven approaches in your organization? what are your conclusions? Do you prefer graphical tools or general purpose languages?

1. Back to top

   MDA != MDD

   Jul 29, 2008 7:29 AM by Catalin Strimbei

   As I know, MDA and MDD are different things. MDA - Model Driven Approach - focus on something like model-translation (especially from independent form to a platform specific one), and MDD has its place in Domain Driven Design context (see Eric Evans book) and is more like a software design approach and NOT a "model-translation" technique ...

   Reply

2. Back to top

   Re: MDA != MDD

   Jul 29, 2008 8:56 AM by Johan den Haan

   MDA (as defined by the OMG) also focusses on domain models. They define a CIM (computation independent model) which should be transformed into a PIM, which on its turn should be translated into a PSM. Problem is that a lot of definitions are going around, which is very confusing.
   
   As I said in the introduction, I prefer the term MDE, but in principle all definitions have commonalities, e.g. model the domain and translate that model into working software. The important questions are: how to define such models and how to make them executable. I hope this article gives some thoughts as a starting point for answering these questions.

   Reply

3. Back to top

   Graphical languages are guaranteed to fail

   Jul 29, 2008 10:50 AM by Dean Wampler

   Good analysis, for the most part. However, you make this statement

   The language should offer graphical constructs in the cases that the concepts represented are more concise and intuitive in graphical form compared to a textual one;

   I worked on modeling tools in a previous life and quickly realized that attempting to write software with graphical tools is misguided, for the following reasons:

   • 1) While diagrams are great for capturing the "gestalt" of a design, none of the graphical languages I have seen can capture the details of programs except in very tedious ways, which leads to the observation that...
   • 2) Textual representations are inherently more productive to use by the developer and also by tools.

   I found the second point to be true even if I didn't attempt to capture all the details of methods, for example, in diagrams. I still "model", but using high-level DSL's in whatever programming language I happen to be using (Ruby, Java, Scala, ...).

   Reply

4. Back to top

   Re: Graphical languages are guaranteed to fail

   Jul 29, 2008 1:17 PM by Johan den Haan

   I think we should separate at least two different roles in working with modeling tools: developers and business/domain experts.
   
   For developers textual DSL's are in most cases more productive. For domain experts I think graphical DSL's can be very useful, by example for modelling workflows, GUI's or a domain model (the information objects). In these cases graphical models can give more insight and the models can be more easy to understand.
   
   I do agree with you that graphical models shouldn't be used for each DSL. DSL's aimed at more technical parts of an application (like validation rules, queries, etc.) should make use of textual DSL's.

   Reply

5. Back to top

   Re: Graphical languages are guaranteed to fail

   Jul 30, 2008 9:14 AM by Steve Macdonald

   Johan, Good article (if a bit dense for those of us trying to learn the concepts). You mention the importance of tooling, but no actual tools. Is there a resource you would recommend that can serve as an unbiased introduction to what tools currently exist? My primary environment is .Net/SQL Server, however am branching out into Ruby et al.

   Reply

6. Back to top

   Re: Graphical languages are guaranteed to fail

   Jul 30, 2008 7:12 PM by Fernando Cardenas

   I really enjoyed this article, so thank you Johan! I think your article does a great job of discussing the current state of the MDx stuff. My take on modeling is that it is too complicated for all but larger projects/companies. Only they can afford to make the investment of time, expertise, and tooling.

   To your last point in your article, our company is making tools to address many of the shortcomings you mention (although some of those features are still one to two years out on our roadmap). Over the next few weeks, I will be blogging about our approach to MDx, which is meant to give developers a streamlined modeling, generation, and custom coding experience along with a deeper dive if you so choose. You can check us out at AppVenture.com and read our blog. We just launched, so the content will be there soon.

   Reply

7. Back to top

   If you model the wrong thing you're starting with 2 strikes against you.

   Jul 30, 2008 7:38 PM by John Reynolds

   My recent experiences have confirmed to me the dramatic improvements in productivity and maintainability that can be achieved by using a model driven environment... but we don't model the OBJECTS - we model the PROCESS. I know this isn't applicable to all domains, but if you are implementing managed business processes you'd be foolish not to use a modelling environment. As to your point about tooling... It's only a matter of time.

   Reply

8. Back to top

   Re: Graphical languages are guaranteed to fail

   Jul 31, 2008 3:15 AM by Johan den Haan

   My take on modeling is that it is too complicated for all but larger projects/companies. Only they can afford to make the investment of time, expertise, and tooling.

   That's exactly why we at Mendix created an MDE platform for Service-Oriented Business Applications - SOBA. I think building your own DSL's and combining them into a software factory will cost you a lot of effort which can only be paided back when using it multiple times for different projects.

   Reply

9. Back to top

   Re: If you model the wrong thing you're starting with 2 strikes against you

   Jul 31, 2008 12:20 PM by Francois Ward

   To John: Technically, I've always heard approaches where the processes are the focus point of the development as being the anti-thesis of model driven approaches. Like, its polar opposite. Sure, you can twist the "real" model driven approaches to make it work, but in the end, its not really MDA/MDD. And its why it works so darn well :)

   Reply

10. Back to top

    Re: If you model the wrong thing you're starting with 2 strikes against you

    Aug 1, 2008 4:29 PM by John Reynolds

    Francois...

    And its why it works so darn well :)

    Yes indeed... and it point out that Graphical Programming is the best way to approach specific aspects of a project. Process diagrams are one example... Page Flow is another. Graphic Only programming may fail... but in many cases Text Only programming is just plain dumb.

    At one time folks thought that GUI screen designers were a bad idea... but now most folks would agree that they have their place.

    New approaches won't be as "supported by tools" as the established approaches (in the beginning)... but if they are good approaches they'll rapidly catch up.

    Reply

11. Back to top

    Re: Graphical languages are guaranteed to fail

    Aug 5, 2008 10:29 AM by Frans Bouma

    Is it just me or is this article an infomercial for Mendix's stuff?

    Reply

12. Back to top

    MDA is good if we understand its limitations and advantages

    Aug 5, 2008 11:04 PM by Kalyan Lanka

    Definitely this article emphasis on how MDA/MDD can fail. But I have been working on projects where MDA has been successful. It depends on what we are supposed to do with tools available on hand. All tools (Custom DSLs) have their own limitations. If a project has enough expertise and the learning curve is less for MDD, then that project can be successful. How many projects use the tools they have to the full potential. Again, a success of a project is mostly depended on people (Stake Holders and Good Architects) who know their stuff and limitations and managing the scope and changes. Tools play a role to a small extent in supporting architects and developers implementing the solution.

    Reply

13. Back to top

    Re: Graphical languages are guaranteed to fail

    Aug 6, 2008 10:09 AM by Johan den Haan

    Is it just me or is this article an infomercial for Mendix's stuff?

    Far from that. For the sake of concreteness, I just show two examples from my experience at Mendix. Is that a bad thing?

    Reply

14. Back to top

    Re: MDA is good if we understand its limitations and advantages

    Aug 7, 2008 6:05 AM by Vinay Kulkarni

    I have worked on several projects where MDE has been successful - albeit with varying degrees. In essense, MDD (or MDE or MDA - choose your pick) is all about raising the level of abstraction, and abstractions when used judiciously lead to less clutter in specification. But, MDE is not a panacea. Good design, sound architecture and common sense play as much a role in development using MDE as in traditional style. In fact, more, as mistakes introduced at a higher level of abstraction can be costlier. But, MDE can help detect mistakes early and help prevent some from occuring altogether. Moreover, being inherently better structured, models are more amenable for analysis, verification and translation to an execution platform of choice. Therein, I think, lies the true value of MDE.

    Reply

15. Back to top

    Re: Graphical languages are guaranteed to fail

    Sep 13, 2008 3:55 PM by Angelo Hulshout

    > DSL's aimed at more technical parts of an application (like validation rules, queries, etc.) should make use of textual DSL's. I tend to agree, if you take 'technical' in the broadest sense. I've recently seen an example of a textual DSL created for use by payroll experts. It's a textual language that helps them create formulae to calculate salaries based on tax rules, insurance policies, union agreements and so on. It's not coding (they're not software people), and it's hard to make graphical - but it is technical from their point of view.

    Reply

• Older >