In Search of the Holy Grail of Software Development
JAXenter speaks to Eike Stepper about the advantages of model-driven software development.
Today’s developer can either use a General-Purpose 3GL language
like Java to solve a problem programatically by means of the
language- or describe those problems with models at an abstract
level, which can then be used to automatically generate code. This
model-driven software development (MDSD) is making waves in Europe,
but developers in the U.S seem to be more sceptical when it comes
to MDSD. Is the notion of generating fully executable applications
in just a few mouse-clicks, the unattainable Holy Grail of software
In the sometimes heated code generation debate, the arguments
against MDSD are always the same: too steep a learning curve,
difficult to maintain, limited creativity, potential loss of
control over one’s project. Eike Stepper,
lead of the Eclipse Modeling Project CDO Model
Repository, and moderator of the Eclipse Modeling Day at
JAX 2010, challenges these allegations against MDSD
and explains why there’s no domain that can’t reap the benefits of
JAXenter: Hi Eike! Modeling is considered by
some as almost the Holy Grail of software development; considerably
simplifying the development process, while others perceive no
benefits to MDSD. Why is modeling such a contentious issue?
Eike Stepper: I think it’s related to the
expectations of the individual. If a proof of concept is made,
these expectations are either met, or not. For example, if the
focus is on the preservation of business expertise at a high
semantic level, it probably cannot be solved without modeling. If
the modeled concepts must furthermore be implemented across several
platforms, I see few alternatives to code generation.
You can’t deny that the introduction of modeling and code
generation can have an enormous impact on old and dearly loved
development practices. Without external support or experience with
MDSD, the chances of success are indeed questionable. And finally,
the choice of tools is not to be underestimated. Here, there is
some room for improvement in the Eclipse modeling technologies.
Recently, we have begun to discuss these needs in formal bodies
with industry representatives. I’m sure that some very interesting
products will come out of these initiatives, and Eclipse Modeling
will attain a new level of quality.
The Holy Grail debate often overlooks the fact that modeling is
not only an option during the development process, but that
modeling technologies are increasingly becoming integral elements
of runtime systems. In the CDO Model Repository, the project which
I have been leading for six years now, using model as a runtime
library is the norm. In my experience, the debate over modeling in
runtime systems is not so intense because the technological
advantages are easier to see.
JAXenter: What do you believe are the greatest
benefits of model-driven processes? And where shouldn’t models be
Eike Stepper: For me, the main advantage of
modeling is that the business knowledge of a particular domain can
be preserved at a very high level, and is therefore preserved for a
longer period of time than with low-level technologies such as Java
or EJB. Knowledge is thus consumable by more people, and by
Depending on how cleverly you handle the introduction of
modeling and code generation, you may also experience a decrease in
cost. At the beginning, successful projects may experience an
increase in cost, since it can be necessary to invest heavily in
the initial knowledge-building. But if this knowledge is then used
intelligently, the users end up with dramatically less code – and
normally this is the type of code that must be maintained for a
very long time.
Furthermore, there are certain requirements that make modeling
technologies almost indispensable. A familiar example is the need
to deal with enormous amounts of data. When you establish your
domain model with EMF, regardless of whether it’s used at design
time or runtime, you can add scalability or exchange the
data-backends with no impact on code, and with only a few mouse
I know of no area where it is explicitly not beneficial to use
models. Problems can simply be better described by models than by
code. And to solve these problems you can often, at least
partially, use code generation. This is MDSD.
JAXenter: In our JAXenter Quickvote, 30% said
the MDSD approach has failed, due to the substantial effort needed
to maintain the generated code. An additional 5% said the MDSD
learning curve was too steep. Is this just prejudice, or is there
some truth in it?
Eike Stepper: I don’t buy the argument of the
steep learning curve. Should you trust a person who believes
acquiring a lot of knowledge in a short space of time is a bad
thing? Everytime I hear this objection, I ask them to be more
specific: “what exactly are you struggling with?” If we know what
it is, then we can do something about it! But, believe me, I rarely
get a straight answer. The problem is that people expect a simple
solution to a complex problem. I know a lot of modeling users who
have overcome the MDSD learning curve within a few days. If only 5%
cannot do this, then this is no big deal – that 5% is probably the
proportion of developers who cannot solve challenging problems.
In many cases, ambitions to generate 100% of the target
application have turned out to be detrimental. Although this
sometimes works, it’s usually better to take a more pragmatic
approach and only model the parts of the system that are
best-suited to modeling. For example, the data structures of a
As for the effort needed to maintain the generated code, I would
like to know how this effort manifests itself. In my experience
with clients, the opposite is true: generated code should require
no additional maintenance. Only the integration of hand-written
business logic can cause a certain amount of overhead, but this is
mostly offset by savings on the lines-of-code-axis.
JAXenter: What role does the Eclipse platform
play in Modeling?
Eike Stepper: Apart from the fact that Eclipse
Modeling hosts the reference implementations of some of the OMG
specifications, there is nowhere else that offers such a wealth of
technologies with such a high degree of interoperability. Once you
get used to EMF as an integration technology, there is very little
Eclipse Modeling lacks. And the Eclipse Foundation and their open
source processes guarantee maximum transparency and openness. In a
reversal of the question, this probably explains why one of the
most important areas within Eclipse is Modeling, and why it is
constantly increasing in importance.
It is worth mentioning that most of the Eclipse modeling
technologies – which can also be used at runtime in end products –
can run outside of the Eclipse platform and without OSGi.
JAXenter: You are acting as moderator,
alongside Sven Efftinge, of the Eclipse Modeling Day of the JAX
Conference in Mainz, Germany. Can you give JAX attendees an
indication of what to expect?
Eike Stepper: We have tried to focus on some of
the key technologies of Eclipse Modeling (EMF, CDO, Xtext, Data
Binding and query) and also on field reports from exciting
application projects (eg, banking, Homeland Security). There will
be a controversial talk on the ups and downs of code generation,
and a final discussion on Modeling Versus Solving Problems. With
nine slots, there should be something for everyone!
JAXenter: What are the next steps for software
modeling? What problems need to be overcome?
Stepper Eike: Of course, each of the existing
building blocks at Eclipse Modeling has potential, be it large or
small. But I think one of the biggest challenges of the Modeling
project as a whole, is providing a consistent tool experience. As I
mentioned earlier, we have succeeded in creating a forum for the
needs of the industry and technology providers. I am curious as to
whether we can finally succeed in providing a coherent tooling
platform for modeling, with functionality, convenience, scalability
and extensibility equal to that of the Eclipse flagship JDT.
JAXenter: Thank you for this interview!