BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

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

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

Bookmarks

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?

Rate this Article

Adoption
Style

BT