One problem in science is getting communities to question their base assumptions. I’m talking about the introductory remarks in a paper, things like “since software development is so hard, it is agreed that a model-driven approach (MDA) is needed”. These remarks go unnoticed in reviews because the reviewers must agree with that remark, otherwise why participate in the community? And the people who disagree aren’t reviewing these papers to question the assumptions. I’m not picking on MDA, it happens in every community – e.g. mining software repositories.

I’ll just add a contradictory data point to the hype surrounding MDA and DSLs. My chief complaint is that an MDA solution, at least the one I tried, shifts the burden of accidental complexity to a new toolchain, but does little or nothing to address the essential complexity. It does seem axiomatic in software research that what we ought to focus on is the essential complexity.

Our experience was with developing a custom user interface for an open-source modeling tool we use as a base for our research – OpenOME. Originally OpenOME code was completely customized, initially using Java and low-level libraries like Swing. Later, we determined that the four/five year old code base was too cluttered to support new improvements, so, in fine software developer fashion, we determined to rewrite the entire thing.

We wanted to leverage the Eclipse ecosystem, so we committed to the Eclipse platform and tooling. By itself, though, Eclipse is just a plugin architecture, so we had a good deal of flexibility in development choices. Had we wanted, we could have written a tool based solely on the plugin extensions and registries, using something like SWT to customize the entire GUI, develop our own data store, etc. This is the approach similar tools like TAOM4E and jUCMNav took.  Instead we used the GMF model solution. GMF asks you to create a domain model in EMF and then a graphical (UI) model to manipulate these domain elements. This is intuitively appealing, and indeed, in just a few minutes you can get a pretty slick UI working, complete with layout, export, zooming, etc. Writing this from scratch would take a lot longer, I think it is safe to say.

The problem is that if you have a UI that is not similar to the one GMF comes with (e.g., manipulating simple boxes and arrows), you suddenly find yourself in the perilous situation of one foot in the canoe and one on the dock. You must make customizations (e.g., adding arrows between elements *within* other elements) deep inside the generated code, and signal this with compiler directives. There isn’t (or wasn’t, anyway) a good way to show only the customized code, requiring you to wade through thousands of lines of boilerplate to find the line you need to change. And finally, you must adopt the GMF architecture whole-sale, and all its cognitive mismatches.

I suspect the non-GMF solution is much more amenable to extension and customization. In hindsight, although initially I was keen on the MDA approach, I think MDA is best suited to developing domain elements — e.g., generating data objects with getters and setters. The complexity of i* syntax is just to great to be accommodated.

Nowadays, my preferred approach is to leverage component-based software engineering. In this paradigm, which admittedly might also be amenable to model-driven code generation, the developer is just weaving components (libraries, services, what have you) together. Python is a great example of doing this. You leverage someone else’s GUI code by providing an output format it understands, someone’s data storage engine, someone’s logic for calculating graph traversals, etc. I think GMF would have been much more useful if it was (architecturally) closer to OSGI than a true MDA approach.

One of the problems with designing your system with a model-driven (MDD) approach is tracing back the source of the errors (and let’s be honest, there will always be an error, if not a bug).

Often, the MDD tool is very opaque as to what is happening during the transformation. My best example is the Eclipse GMF toolset. While it hides a lot of unnecessary code, typically low-level UI and abstraction handling code, it can also hide code that might be relevant if your system doesn’t work as expected.

Here’s a simple example: I need to add a custom function to my graphical element. I’ve searched the poorly documented GMF builder, and there’s no way to make this change in the models (graphical, tooling, domain, mapping). I read up on GEF and make the change in the generated code.  Later, my colleague re-generates the code, without being aware of my changes. Eclipse preserves them, because I used the @generated NOT keyword, but now he wants to find any of this code. There’s no good way to tell my IDE to only show code that isn’t generated. But that might acutely important if I’m maintaining a MDD-constructed system.

Another example is LISP macros. In LISP there are two compile steps. One step expands all the macros one defines into their normal LISP form. This is similar to the preprocessing step in C, but much more powerful. The code is then compiled (or evaluated) as appropriate. However, the macro expansion step is (to my limited knowledge) opaque. It isn’t easy to debug what is going on when the macro expansion is performed (other than trying it out). And I expect debugging the final program would leave lots of references to the eventual, generated code, rather than the actual macro responsible (which is what you want to see). A tool that could trace from final form to macro form would be invaluable.

I think a lot of this is similar to Greg Wilson’s “cognitive gap between what programmers write and what they have to debug” (ACM Queue).  There’s plenty of logic wrapped up in an ANT build script that is difficult to parse with the current tooling. That is even more so for model-driven development tools. And most research into these tools ignores these practical problems in favour of recondite mathematical theorizing about model merging and model translation. This is not merely a matter of implementation details!