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

by Jean-Jacques Dubray on Jul 30, 2008 |

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?

Related Editorial

Hello stranger!

You need to Register an InfoQ account or 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

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

Email me replies to any of my messages in this thread
Community comments

MDA != MDD 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 ...

Re: MDA != MDD 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.

Graphical languages are guaranteed to fail 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, ...).

Re: Graphical languages are guaranteed to fail 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.

Re: Graphical languages are guaranteed to fail 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.

Re: Graphical languages are guaranteed to fail 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.

If you model the wrong thing you're starting with 2 strikes against you. 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.

Re: Graphical languages are guaranteed to fail 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.

Re: If you model the wrong thing you're starting with 2 strikes against you 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 :)

Re: If you model the wrong thing you're starting with 2 strikes against you 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.

Re: Graphical languages are guaranteed to fail by Frans Bouma

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

MDA is good if we understand its limitations and advantages 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.

Re: Graphical languages are guaranteed to fail 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?

Re: MDA is good if we understand its limitations and advantages 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.

Re: Graphical languages are guaranteed to fail 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.

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

Email me replies to any of my messages in this thread

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

Email me replies to any of my messages in this thread

15 comments

Educational Content

General Feedback
Bugs
Advertising
Editorial
 InfoQ.com and all content copyright © 2006-2013 C4Media Inc. InfoQ.com hosted at Contegix, the best ISP we've ever worked with.
Privacy policy