Steven Kelly on DSM

What could be better than combining two great buzzwords? :-) Using Domain-Specific Modeling to build applications in a Service Oriented Architecture is of course a good approach, bringing the normal DSM benefits of 5-10x better productivity and significantly better quality. But if you start by thinking about creating a modeling language for SOA, you may be going down the wrong parth. Let me explain why.

In general I’d suggest basing the modeling language on the concepts of the problem domain, not the solution domain. SOA is really more on the solution domain side of things, and that side is handled by the generators, not the modeling language. If many of the solution domain details are visible in the models, they are no longer at the high level of abstraction expected from DSM. This reduces the productivity of the modeler, and forces them to think on two levels simultaneously. It also makes the DSM solution brittle with respect to changes in the solution domain. Normally with DSM, if you change the solution domain (e.g. to switch to a different framework or architecture), only the generator needs to change (requiring work by one person), not the models (which would require work by many people). If implementation details are visible in the models, a change in the solution domain requires changes to all models, meaning extra work for many people.

The Digital Watch example in MetaEdit+ illustrates DSM principles quite nicely here. Initially we were only targeting an object-oriented, browser-based implementation: Java applets. We were able to keep the implementation details out of the models, though, so later we have been able to add new generators for an object-oriented mobile device implementation (MIDP on mobile phones -- see Section 4 here), and a low-level procedural language for embedded devices (C), all without any changes to the models.

We also have another example, not yet released, of database applications with a web page interface. One generator can produce applications running locally in a browser using Google’s Gears, with JavaScript and an SQLite database inside the browser; another generator will produce Python for the Google App Engine using a Python DataStore on Google’s server in the cloud. So there’s a desktop database application, or a client-server application -- and the models need say nothing about those implementation details.

A customer from Norway heard from a friend of a project with software dating back several decades (not as uncommon as you might think). He sent me a link to, and a request to blog about, an article on Software that Lasts 200 Years, written by Dan Bricklin. Since Dan is one of the creators of VisiCalc, he ought to know a thing or two about the topic. His main thesis is that software for certain tasks in society (libraries, public records etc.) needs to be built, maintained and indeed thought about in a different way from today's software: as infrastructure akin to roads or bridges.

Dan Bricklin is always interesting, I've found myself coming across his site several times. I don't really have any great insights on what he says in the article, so I'll just add some thoughts on a few bits. I like his comment that open source fans should concentrate on getting trains to run on time rather than persuading railways to run on Linux. The basis of open source was that it's nice if people who write software have access to the source code of other software, not so much about making software and giving it away for free to people who will never look at the source code. Both are fine aims, but sometimes these days the focus is only on the secondary aim and people forget about the primary aim.

Dan is refreshingly realistic in accepting that there will be multiple ways to achieve "software as infrastructure": companies, government, open source communities. Some of his views seem a little naïve, e.g. the idea that licensing professionals is just to improve quality: I think economists generally say an important function of licensing is to restrict entry, thus increasing scarcity and helping justify high prices for existing practitioners. Similarly his thoughts on standards bodies assume they only work for the common good, not to restrict competition or force competitors to compete on existing companies' terms. (I'm deliberately pointing out only the other side of the coin here; the truth includes both sides.) In contrast to what he says (admittedly back in 2004), major enquiries have indeed been held when software has failed, but since the parties involved are mostly private companies rather than government (unlike for bridges), they aren't often public.

Those are some of my opinions, but I'm sure Dan has better grounds for his: read the article to get the full picture. (Mind you, I suspect a good economist or analyst could do a lot better than either of us: if any readers have good links, add a comment!).

I still occasionally use the first piece of commercial software I wrote (a sound editor for Casio's CZ range of synthesizers) and the first programmer's text editor I used at work (Intel's aedit) -- both from around 1986. People born in that year have now graduated from university -- a sobering thought. Not just because of how much it dates me, but because of how little has changed. That university graduate has certainly changed and matured a lot more in 22 years than our industry or the tools we use.

The book on Domain-Specific Modeling by myself and Juha-Pekka is now also available as a download for the Amazon Kindle. If you haven't looked for a while, you'll also notice that it's been added to Amazon's Search Inside, so you can browse through it for a little while for free online: on the DSM book page on Amazon, click the Search Inside logo above the book cover.

For an unusually calm and reasoned assessment of the demise of UML, read 13 reasons for UML's descent into darkness -- and the comments. I don't suppose there's much there that's earth-shatteringly new for most of us but it's refreshing to see accurate criticism of the problems many find with UML, without falling into the trap of tarring all graphical modeling or code generation with the same brush.

Trying to capture everything is an impossible task - even at 800 pages, UML covers only a small part of the complexity of software engineering needs. It is too big but still too generic and abstract.

That for me is the reason why UML couldn't succeed - many of the others are reasons why it fell from grace, and they might have been avoided.

Juha-Pekka tells in the Code Generation 2007 panel on UML vs. Domain-Specific Languages (mp3) how he was happy to implement the UML 0.8 specification in the mid-90's -- there were big gaps, some things were inconsistent, but it was manageable. A few versions later the attempt to build a universal language for all discrete software systems was already revealed as an impossible dream. The choices were either a language that was so low-level it could express everything, but too verbosely and with no visible understanding of the actual system; or a language that was so high-level that a diagram could mean widely different things to different people; or an unwieldy and unintegrable collection of languages for looking at a system from many different viewpoints. Or, as actually happened, all three.

One of the comments was particularly interesting, given my earlier entry on code generation performance:

I worked on a project that decided to generate all of its code from diagrams (not UML but Schlaer-Mellor) and it took two weeks to get the models processed and the code compiled. Given that the code generator was being tweaked often, this slow turn-around really impacted the project.

If your code generation takes two weeks, you might be glad to see it happen 30 times faster!

By the way, the Schlaer-Mellor mentioned there is the ancestor of "executable UML", whose promoters include Allan Kennedy, a panellist on the above panel. Allan's view was refreshingly simple, given his commercial background: if you can use domain-specific languages for any of your development, you should; for the bits left over, (x)UML can be useful. I heartily agree -- even the Digital Watch example in MetaEdit+, surely the most demonstrated example of DSM :-), includes a UML Class Diagram to document the little hand-written framework of Java code that runs below the generated code.

I've just finished booking our trip to Code Generation 2008, whose program is now published. One talk I'm particularly looking forward to is Bran Selic's keynote on how DSM can meet the highest standards of performance needed for generated code in Quality of Service constrained applications. Our experience too is that while generated code cannot outperform the best handwritten code (how could it?), with DSM and domain-specific generators it does outperform the average handwritten code, so the overall speed of the whole system is better.

Thinking back to Code Generation 2007 reminded me that the performance of the code generator itself can also be an issue. One company I talked to had a modeling tool generating code as part of a nightly build. The problem was, they kept running out of "night". They were already up to a four processor machine dedicated to running the generation, and that wasn't able to finish the job overnight. What really surprised me was that they only had a few hundred diagrams. I've seen organizations with many gigabytes of models - orders of magnitude more than this case - managing just fine

An article in IEEE Software (Cuadrado & Molina, Sep-Oct 2007) examined the performance of the Eclipse MDD tools for code generation, comparing it with DSLs made with Ruby. They took the same UML model as a starting point, and followed the common Eclipse practice of a model-to-model transformation first to make a "Java model", then a model-to-text transformation to make the .java code files. For the former they used ATL, and for the latter MOFScript; in Ruby there were two corresponding DSLs.

The model was very simple: 40 classes and 50 inheritance relationships, with each class defining around 6 attributes. The code generated was what you'd expect: a one-to-one mapping to .java files, with accessor methods for each attribute, giving a total of 2550 LOC.

Since I'm inherently incapable of resisting a competitive challenge, I imported the UML model from the Eclipse format into MetaEdit+, and made a code generator in MERL to output the same code. Here then are the results: times for Eclipse and Ruby are from the article, my MetaEdit+ time is on comparable hardware.

I guess the graph speaks for itself: MetaEdi+ is over 30 times faster than Eclipse, and over 20 times faster than Ruby. Even if we ignore all the reading and writing that Eclipse has to do, MetaEdit+ is still over 20 times faster. Since I imagine some people won't be too happy with those results, let's make some things clear:

• Having two phases, M2M then M2T, roughly doubles the times for Eclipse and Ruby. All the M2M phase really does is add a pair of accessor operations for each attribute, which in my opinion belongs in the code generation phase anyway. The MetaEdit+ generator is both faster and simpler than the combination of the ATL and MOFScript generators, and IMHO this would continue to be true even for much more complicated generators.
• A modeler in MetaEdit+ can just run the generator, which is executed on his model and corresponding metamodel in memory. In Eclipse, he must first save the model (I'm assuming above the time for that is zero), then the generator must parse that XML file, and the corresponding metamodel. For M2M stages (Eclipse and MDA proponents often envisage many), the generator must also read the metamodel for the output format, and perhaps serialize the result into XML to write a temporary model for input to the next stage. I believe the MetaEdit+ approach is better suited to what developers actually need.
• For a nightly build, or other occasions when the model is not already open in MetaEdit+, it would have to be read first. This adds 0.276ms, although that figure may be rather unfair to MetaEdit+. We are loading a full UML class with all its information, as opposed to just the class name and attribute names and types in the Eclipse XML file. If all the extra class and attribute information was filled in, MetaEdit+ would be hardly any slower, but the Eclipse and Ruby tools' time to parse the XML models would increase considerably.
• I could include the time to import the Eclipse XML file into MetaEdit+, but that seems unfair: it's the native format for the Eclipse tools and the Ruby DSLs here, so MetaEdit+ too should start from its native format, as a modeler would. If the Eclipse guys build an importer that reads MetaEdit+ repositories, we can include and compare the times for "import from other tool". For the record: reading the XML file took 5ms, executing the translation to MXM, which MetaEdit+ can import, took 146ms, and importing the MXM file to the MetaEdit+ repository took 1.72s. Building the translator from XMI to MXM took a little under an hour, and used MERL's reverse engineering features, new in 4.5 SR1.

Of course, the Eclipse tools will get faster -- as will MetaEdit+. I think the main difference is one of architecture, though, and internal data structures and algorithms. Changing some of those should be possible, but some -- like EMF -- will be hard to rip out of Eclipse modeling without breaking absolutely everything else.

It would be interesting to see the results for other tools like oAW or Microsoft's DSL Tools' T4. Any competitive natures in those teams? :-). Finally, many thanks are due to Jesús Cuadrado, who provided me the models and generators used in his article, as well as the details of the environment from their tests, to make mine as comparable as possible.

Alfonso Pierantonio contacted me about using our DSM book on an MDD course he is running at the University of L'Aquila, Italy. He's also researching important topics for DSM: model differencing, evolution and synchronization, and asked about our academic pricing for MetaEdit+. For some reason it only just occurred to me from that message that we should have a section on the DSM Forum site to list universities that teach or research DSM. I can find a lot of them from our customer list and my emails, but if you want to make sure you are included, please add a comment below or contact me.

Coincidentally the very next day I saw the following message in the comp.lang.smalltalk newsgroup, advertising for a PhD position in DSM:

"Supporting the Concept of Early Warning Analysis" (SCEWA) is a 5 year research project that began in January 2008. It is funded by the Irish Environmental Protection Agency.

The research will be focused on the development of methods and tools which are aimed at supporting the analysis, design, and development of early warning systems in engineering facilities and in critical infrastructures whose undisturbed operation is important for maintaining and improving the quality of our everyday life.

Currently, we are seeking to recruit one PhD student to work in the area of Domain Specific Modeling. The objective of the research is to define a domain specific modeling language for early warning systems.

More information about the project and the PhD position: SCEWA web site
PDF version of the announcement

Please forward this information to students who may be interested in this position.
Thank you in advance,
Dr. Ioannis Dokas, jdokas@gmail.com

Three years ago I posted about the lack of adoption and lack of tool interoperability for XMI:

The OMG has XMI versions 1.0, 1.1, 1.2 and 2.0, with 2.1 under development. Looking on Google, I note that there are 865 XMI files on the web using 1.0, 78 for 1.1, 64 for 1.2, and 34 for 2.0 (released in 2003). That gives some indication of the adoption of XMI as a format, and tallies with my own impression. Everybody was interested when it first came out, but most who actually tried to use it found it lacking. One can always hope the situation improves with newer versions...

So have things improved? In a word, no. Google finds 40 files for 2.1 (released in 2005), and the figures for 1.0 have dropped by over 90%. Now even the most used version, 1.2 from over five years ago, only has 136 files, and the figures decline from there. Yet still people I meet believe that XMI is a useful standard that will solve their problems.

What about tool interoperability then? In an article from the MODELS conference, Lundell et al. tested XMI with 14 UML tools. Obviously, the older tools can't load from the newer tools, but can the newer tools read models from the older tools? That's the important question after all, if you want to use XMI as insurance against your tool being discontinued: will this year's tools load last year's models? Here's the table, see the article for full details:

==>	Borland	Eclipse	Rational	MagicDraw	UModel
ArgoUML	Failed	Failed	Failed	Failed	Failed
Fujaba	Successful	Failed	Failed	Failed	Failed
Umbrello	Failed	Failed	Failed	Failed	Failed
Artisan	Failed	Failed	Failed	Failed	Failed
Poseidon	Failed	Failed	Failed	Successful	Failed
Rhapsody	Failed	Failed	Failed	Failed	Failed
Rose 1.0	Failed	Failed	Failed	Failed	Failed
Rose 1.1	Failed	Failed	Failed	Failed	Failed
Visio	Failed	Failed	Failed	Failed	Failed

Looking at the tools supporting the latest version, 2.1, the picture looks darker still. None of these tools were able to import even 2.0. If XMI were really being implemented by these tools to offer interoperability and insurance, why would they drop support for the previous version? That leaves you rather open to claims that the intention is to pretend there is a standard, and then spread FUD by claiming that other tools don't support it. If the only tools that can interoperate are jointly developing the same code base (Eclipse, IBM, Borland), it's hardly impressive if their parallel versions work well together.

In the DSM world, of course, all this is somewhat academic: the tests were of the simplest possible UML Class Diagrams. None of the tools support working with DSM languages from another tool. If you want to move your DSM models from one tool to another, the main cost is the same as the cost of building support for that DSM language in the new tool -- translating the models is easy in comparison. In that area I'd say MetaEdit+ wins hands down: nothing comes close in terms of ease and speed for the metamodeler or features provided automatically for the modeler. But don't listen to me -- listen to our customers, industry gurus and even competitors all saying the same thing.

Now that "domain-specific" has become something of a buzzword, people are eager to claim that what they do is domain-specific. For some, just naming a variable or XML tag "person" instead of "x" seems to be enough. For a great take on this from April 1st, see Anders' blog: "A framework for cross platform DSL development".

There's a serious side to it as well: if your DSL or DSM solution locks you in to a certain programming language, IDE, or operating system, that's plain wrong. A Domain-Specific Modeling language should fit tightly with a certain problem domain, but your tools for it should allow you to change the solution domain later, just by building a new generator that operates on the same models. If the tools are tightly coupled to a certain language, IDE, or OS -- or even worse and sadly all too common, to a particular version of a given IDE or OS -- that's hardly giving you the freedom of choice that DSM is meant to bring.

Yes, there is a cost to supporting multiple platforms, and I sometimes have to defend why MetaEdit+ platform support covers all the common cases, but in the long run it pays off. If you focus on just one platform, it's all too easy for the tool to become highly coupled to implementation details in the current OS or IDE version. Not only does that make the tool vendor's life harder when a new version comes out, but for tools that require metamodelers to program, the metamodelers too will find themselves stuck. Their modelers will want the latest version of the IDE for coding in, but the modeling tool will require them to stick with the old version -- or continually pay the cost of this tight coupling at every version upgrade.