MoDELS’08: Panel discussion on the past & future of MDD

Moderator: Robert B. France

  • Richard M. Soley, Chariman and CEO, Object Management Group, USA
  • Jeff Kramer, Professor of Distributed Computing, Dean of the Faculty of Engineering, Imperial College, UK
  • Bran Selic, Retired IBM Distinguished Engineer, Canada
  • Grady Booch, IBM Fellow and Chief Scientist, IBM Rational, USA
  • Patrick Farail, Airbus, France

To give you an idea of the ambiance I’ll start by listing some quotes from this panel discussion, the question to you: who has pronounced each one?

  1. UML is the worst modeling language except for all the others.
  2. The difference between terrorists and modeling experts: you can negotiate with terrorists.
  3. Java is not a bad Lisp, if it were not for the lack of parentheses.
  4. UML is both a blessing and a curse.
  5. An UML tool has a far more complex interface than a modern aircraft cockpit.

The panelists did all receive the opportunity to start with a seven minute explanation of their view on the past and future of MDD. That was really educational, let’s just not talk about the seven minutes time limit…

Grady Booch

Since Grady wasn’t able to come to Toulouse, he did his part of the game via Second Life. However, the connection didn’t help and in real life we didn’t understand anything of it.

Bran Selic

Bran did use the term Model-Based Software Engineering (MBSE) (another abbreviation to add to my collection) instead of Model-Driven Engineering. His reason: models don’t drive anything, they’re just part of the process.

In principle MBSE is an approach to software development in which computer-based models play an indispensable role. Models can be refined continuously until the application is fully specified, i.e. the model becomes the system it was modeling. The two proven ideas of MBSE are

  • Abstraction (the realm of modeling languages)
  • Automation (the realm of tools)

According to Bran the two major successes of MBSE are:

  1. Executable modeling languages and supporting tools, which have increased productivity and quality (proven in industry). For example executable UML.
  2. Standardization of UML. This process raised the awareness of MBSE in the greater community.

The question Bran asks whether we need a language aimed at design, analysis and documentation, an executable language, or a language supporting both. He thinks MBSE can only successfully be done using viable executable models. For him it is no question that Domain-Specific Languages (DSLs) are the way to go.

Bran sees a maturity model for MBSE with a movement in the last phases from a model-centric approach to a model-only approach. He closes his speech with the remark that maybe the current generation of MBSE will not be the winner/survivor.

Richard Soley

Looking at the past Richard mentions that the OMG has moved from distributed computing standards to modeling standards. The OMG is now active in more than 80 vertical markets in which they are very successful because they start from a modeling perspective instead of starting from a programming perspective (as they did with UML).

According to Richard the most important thing to recognize is that we have to deal with people, even more than with technology. People are used to tool, languages, etc. and they often don’t change that in an easy way. Even if the notation of languages is the same, people want to have languages which (they think) are specialized to their needs. Richard gives the example of BPMN. Although the UML has models looking a lot like BPMN, most people prefer BPMN.

Richard also explains why he sees directly executable models as the future. If you specify a system using some language, which will be transformed in some other executable language, there often is a difference in computational models between these languages. In debugging such a system you need to understand both computational models AND the transformation. If we directly execute the model we can debug at the model level. Richard needs a language which means something by itself, without a lot of transformations. He compares a visual model which is transformed into code with C macro’s.

Patrick Farail

Patrick did give a nice overview of the past and future of Model-Driven Engineering within Airbus. However, I think it’s a bit to specialized to repeat it at this place.

Jeff Kramer

Jeff only had three adds to the previous speakers:

  • Don’t underestimate the adoption of Models, MDD, MDE, MDA, etc. into Software Engineering. There really is some adoption. Of course quality is still an important issue, but Jeff states that the industry should demand for that. Unless they do so, it won’t become any better.
  • Don’t forget software architecture. Architecture Description Languages (ADL) are almost not used in industry.
  • UML is both a blessing and a curse. It’s great to have a common language, but in research we shouldn’t only focus on UML parts. He recalls his keynote on abstraction, we have to ensure that models fit their purpose. Models must support and encourage experimentation.


Why the presumption that models are pictures and not text? Fortran was mentioned as a textual modeling language. This triggered a long discussion on graphical versus textual languages. I’ll list some remarks of the panel members.

Richard: if you design something, do you draw boxes and lines or write Fortran? Graphical languages are more expressive, and we can use them, we don’t have terminals anymore.

Bran: but we need expertise on graphical/visual syntax. We have no theory behind and now we just model how we like it.

Jeff: the structure of languages isn’t the most important point. It’s about finding the right abstraction. The purpose of a model is to reason, argue, and discover new facts.

Bran: a language can be both graphical and textual at the same time. Writing is sometimes easier in text, but other models, like a hierarchical state machine are very difficult to express using a textual language.

Robert: graphical doesn’t automatically mean visual!

Another discussion was about tools. Some panel members indicate that usability is a problem. Most tools are build for developers themselves and not for the users. Tool developers are too much thinking in computer science terms. The result: most of the time users are busy learning the tool, fight against it, and it will cost years to become an expert in a certain tool. Why not learn from the user, i.e. build a model of the user using expert systems and game theory.

1 Comments Added

Join Discussion
  1. Ersin Er January 6, 2009 | Reply

    Regarding modeling with graphical elements:
    In engineering disciples other than software engineering, models are less detailed views of a real system, really, literally, naturally. That means for example when you model a machine or building with a drawing you really sketch a simple view of it. That model really mimics the real world system that it represents. (You may still have more "technical" models but there are natural models in most cases.)
    In software engineering, however, we do not work with real world systems that can easily be visually identified. May be the business processes are the real world systems and they can be modeled with some figures/pictures/drawings which will make it as expressive and natural as possible. When you draw a UML diagram it has nothing to do with any real world concept. In my opinion, UML makes more sense as a meta-modeling tool/language, not really as a source language.

Leave a Reply