The link between models and code is overdue on a serious revision. Hard core developers usually hate point-and-click IDE's. Managers make models that are not in sync with the software. The current perception that software artifacts is generated from models is seriously flawed.

This is my conclusion after several years of building the JBoss jBPM process engine, which targets business users *and* developers.

After messing with assembler, programming languages grew higher and higher level. Then UML went mainstream. In that context it was assumed that developing software would be done with models in a short future. This is the typical MDA vision.

Higher level abstract models improve communication with business users. But there is the tradeoff between flexibility and complexity. To be executable, software needs to be specified precise and with lots of details. Putting all these details in the model, makes the modelling language too complex for its purpose.

Models should be projections of software artifacts. This should replace the idea that software artifacts should be generated from models.

The argumention goes like this: First, we recognize that there are different types of authors involved in creating software: business users and developers. Business users can think along on the model level, but they don't know about the technical details. Developers are the power users. They can write the actual software artifacts and communicate through the models with the business users.

Also developers should be differentiated: Currently, developers are real powerusers. They type in straight Java code way faster then any point-and-click IDE could enable them. But i think that a whole bunch of less experiences technical people are impatiently waiting until they can use languages (or subsets of languages) that are less complex. They are willing to trade flexibility for simplicity.

If models are a projection of actual software artifacts, there is no need for the models to contain all the details. A very good example of this notion is the method implementation in UML class diagrams. In UML class diagrams, method implementations not available, which is good because that makes it possible to get the overview. The collapsable compartiments in class boxes are another illustration that sometimes you don't want to show all the details in your models.

Before 'markerless round trip engineering', we have been able to experience that keeping models and code in sync is not possible for the majority of software teams. So in this context, it also makes good sense to distill the models from the actual software artifacts. That way, they can't get out of sync. I'm not even close to a UML tooling connoisseur, but the best approach I have seen in UML class diagrams was the old Together IDE. In that tool, the models were generated from the code. The diagram file only contained the graphical information which was not part of the Java code.

So in my refined model software is composed of many software artifacts in various general purpose programming languages and a bunch of domain specific languages (DSLs). The value of models is that many of these deployable software artifacts --that contain great detail-- can be projected, resulting in a visual diagram that shows the higher level concepts without the details.

In the picture above, i have represented the actual software artifacts in the middle. These software artifacts are written in a general purpose programming language or a domain specific language. DSL artifacts are usually input for runtime frameworks. But the main point is that the software artifact layer contains all the details necessary that define an exect behaviour of a runtime environment.

Some (not all) of the software artifacts can be reprensented in models. These models can be generated from the actual software artifacts. Business processes are a great example of this.

So my conclusion is that models should be projections of software artifacts. Wether people use the model-editor or the text editor to author these artifacts doesn't matter. Of course, business users will more often use the model editors and developers (the power users) will use the text editors more often.

Another aspect that is highlighted here is that software is being build as a mixture of general purpose programming (e.g. Java) and a bunch of DSL's which serve as input for frameworks. So the thing that currently is mostly overlooked is refactoring over these language boundaries. The future IDE should be able to detect and execute refactorings over language barriers. That is when we'll get really agile development teams.

Note on relativity: I know I may sound like I just had a great innovative insight. It sure feels that way :-) But most probably, as with many things in life, this will be invented, described and analysed many times before in many different contexts... If that should be the case, I thing it was definitely worth bringing it again to your attention :-)

Regards,
Tom Baeyens
Founder and Lead of JBoss jBPM