BT

InfoQ Homepage Presentations What's Needed to Make 'Model-Driven' Mainstream?

What's Needed to Make 'Model-Driven' Mainstream?

Bookmarks
01:12:58

Summary

Jürgen Mutschall ponders what is to be done to make MDSD a mandatory development methodology for every large scale project.

Bio

Jürgen Mutschall has been CEO of Distributed Engineering Systems Software GmbH since 1996 and took part in multiple large scale international projects as project manager, architect and consultant. He has designed and developed model driven software tools and visual programming languages for more than 25 years.

About the conference

Code Generation conference is the leading event on the practical applications of Model-Driven Software Development (MDSD). It offers a high quality learning experience through discussions, debates, a diverse range of practical tutorials and workshops. Now in its 7th year, it is known for providing a high-value learning experience and attracts industry-recognised experts to share their experiences.

Recorded at:

Aug 23, 2013

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

  • The answer is: nothing can make MDD go mainstream

    by Dean Wampler /

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

    I've been in this business a long time and I once believed in the promise of MDD/MDA. However, experience in a wide variety of contexts has taught me that the best way to generate code... is to write code. Nothing is as concise, expressive, evolvable, productive, and usable in rapidly-evolving industries as plain-text source code (at least when written in a "good" language). I've seen very few MDD approaches, visual or otherwise, and other attempts to replace source code come close to what's possible with coding itself. There have been special-case successes, such as LabView for instrumentation. For the general case, I wonder where Google would be today if MDD were the mandated approach internally?

    Another fundamental flaw is the over-emphasis on domain modeling. Perhaps the biggest failure of OOSD/OOP, at least the way it is actually practiced, is the unquestioned assumption that building a model of the domain in code is a GOOD THING. In fact, it has created the bloatware we find everywhere. Of course, we need to understand the domain in order to build software that meets its needs. However, that software needs to be a minimally-sufficient calculation of the data the domain needs, not be a model of the domain itself. MDD only exacerbates this misdirected focus on realizing the domain in software.

    In part, MDD is too grand in its scope. Far more successful are focused APIs that encapsulate boilerplate in particular scenarios. For example, well-written code DSLs (domain-specific languages) are highly successful. If that's what people really mean by MDD these days, then great, but this presentation appears to be making the old, and in my view obsolete, arguments.

  • What if the code was the model.

    by Jeff Hain /

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

    Someone left just after the presenter said "Every manual written line of code is bad!", and it sounds like he almost fell out off his chair (15m35).

    I think the actual model/design is the code, and the compiler the blue-collar worker that translates it into the binary executable product (cf. Jack W. Reeves essay, 1992).
    The code is the only formal description of what the software does (discarding compiler optimizations).
    The model (as presented here) is just a simplified overview of it, useful for introduction to the code, or some big-picture and superficial considerations (especially the "boxes and arrows" part). It should rather be generated from the code (which happens in practice), than the opposite, for you can't automatically generate precisions and details that require further business and technical considerations and tradeoffs.

    That said, I would welcome the appearance of higher level languages in which you could elegantly express and represent nearly all desirable features, and which would then execute nearly as efficiently as possible, but to me modeling as described here doesn't seem to go one inch into that direction.

    Agree with D. Wampler about code DSLs.

    B. Russel said : "Everything is vague to a degree you do not realize till you have tried to make it precise." This applies very well to MD*.

    PS: A link to an interview of R. C. Martin where he talks about MDA :
    blog.xebia.fr/2011/05/25/interview-avec-robert-...
    (start reading at "Model driven architecture is a wonderful idea, a grand idea that has never worked and probably never will.")

  • Re: The answer is: nothing can make MDD go mainstream

    by Faisal Waris /

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

    I was once sold on MDD as well and wrote several thousand lines of java code to transform UML models of business-to-business collaboration to BPEL and WSDL artifacts. I don't want to go through that experience again (plus its painful to do anything complex in java).


    Modern IDEs and tooling that offer domain-specific code generation (for service interfaces, RDBMS, etc.) are still useful as long as one can easily mix generated and hand-crafted code (e.g. partial classes in .Net).

    More recently I have found that functional programming languages are MUCH better than OO languages for building DSLs. Languages that support metaprogramming well are really quite ideal for building DSLs.

    I am mostly experienced in F# which offers all of the DSL crafting facilities mentioned plus the innovation of TypeProviders. With TypeProviders, the IDE, compiler and language features work together to present external metadata as ordinary language types - at coding time!

    Just yesterday I came across a very interesting paper on type providers in Idris - a Haskell-like language which supports dependent types (itu.dk/people/drc/pubs/dependent-type-providers...).

    I will summarize by saying that much of the original need for MDD is being met by better languages; innovative new language features; and better IDEs/tooling.

  • The lady said that she has been doing 100% code generation for 20 years

    by James Zhuo /

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

    How about show us how she does it?

    PS: At this point, I think code generation is the wrong way to do model driven development. The model should execute itself for MDD to work, it shouldn't be generating code. But what the model can't represent you should be able to write some code for it. The question is what tools are out there that allows you to execute models instead of code? Also I don't think any of the modelling notation is descriptive enough to execute and if they do become descriptive enough, they will probably be way too complicated.

  • It will happen!

    by Arturo Hernandez /

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

    Thanks Infoq for delivering such interesting content.

    This reminds me of how many physicists were more excited at the prospect of not finding the Higgs. Because I think the "right" tool does not exist yet. I do believe there are benefits to be gained in using existing tools. But for many reasons they are not for everyone, so the potential is still there.

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.