In Search of the Holy Grail of Software Development

Jessica Thornsby

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 development?

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 modeling technologies………

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 used?

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 different technologies.

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 clicks.

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 business domain.

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!

Inline Feedbacks
View all comments