UML or DSL for Embedded?

In his article "UML use" on Dr. Dobb's portal, Jack Ganssle wonders how much UML is really used in the embedded arena. Casually he remarks that when visiting the soon to be held Embedded Systems Conference in Boston, you see UML plastered on every expo booth. I am not surprised Jack, especially with a conference program so narrow-minded with 6 classes on just UML and SysML from 3 speakers, 2 of which are OMG members.

In my view, conferences like ESC should provide the platform for demonstrating new ideas and methods – once proven in industry, not for methods and notations (MDA, SysML) that are hyped by tool vendors and standardization organizations who, after modest success in the desktop and IT market now put their hopes on conquering the embedded market with some simple modifications to their standard and tools.

Modeling with UML is happening more in the embedded area, to me that is a sign that clearly the software is becoming more complex, not that embedded developers have - suddenly - started to love or even accept UML. The reactions at the bottom of the article are clear indications of the problem with a one-size-fits all language that a) never was designed for generating code from it and b) never was designed for developing non-object-oriented software or some form of hybrid: The large majority of all embedded development.

One comment describes the UML tool generating object-oriented languages like C++ while actual development is done in C :) as a problem. Actually the perceived problem is not such a problem here: Assuming the UML tool would generate C, you'd still have to throw the code away, trust me.

Another comment claims that non-UML-savvy developers can create diagrams that are "non UML-compliant". Aside from the fact that the "UML tool" here probably is a pen and a paper or some free tool that's the binary version of a pen and a paper, even if the diagrams were "UML compliant" then that really means zilch. UML compliant is not in any way related to quality-compliant, performance-compliant or just.....compliant! UML says nothing about any product, platform, framework or architecture, UML-compliant can actually be a lot worse than non-UML-compliant.

Of course there's the comment about understanding UML being hard. "it seems that engineers understand block diagrams and pretty pictures, with a bit of descriptive text....much better than a full blown UML diagram complete with interaction diagrams". Yes, code visualization (UML) is not exactly reducing complexity, it just presents complexity in another format. UML fails to raise abstraction is why.

And then the nicest, one that sums it all up to me:

"After having used UML based CASE tools for the past 6 years, I must say they are great for prototyping. Other than that, I'll never use them again. Merging changes from multiple developers into one graphical model? It never worked. Code generation? Only the framework and how much time will that save you."

Thank you Jos Dijkstra. UML-based CASE tools simply do not fit embedded development. The problem is not CASE......... the problem is UML.

I hope the highly esteemed program committee of the Embedded Systems Conference - claiming to offer "high-caliber, solutions-oriented technical sessions" and a "a fundamental educational tool offering practical, how-to classes designed to meet the needs of engineers developing embedded systems" - will aim to proivide something in next years' program that actually works.

SD Wild West Panel

Well, it's been a while but after a long holiday, during the dryest summer of the century here in Finland, I'm back behind my keyboard.

Currently at MetaCase we're working hard toward the release of the new MetaEdit+, which will be awesome. I had some time to go through old emails, stumbled on the panel script of SD West 2006 and my wooden shoe broke (old Dutch saying). In the annoucement to the panel I am sure the SD events group had announced "some heat" that could be expected. However, the script I read does not give any indication of "heat". Instead, it seems like the panelists were given ear plugs and asked to react to issues that were barely related to each other.

The best advice to attendees clearly came from Compuware's John Kern who wanted to point out that it matters who you hire for a software development project. I bet it does John, but don't you think that "Just hire the smart ones and you don't have to worry about getting them there" is simplifying it just a little too much? Comments like that should get you barred from any future panel if you ask me.

Jack Greenfield mentions that he does not believe in big red buttons that generate code he has to live with from high-level models. Well Jack, first, in MetaEdit+ that button is not big and not red, it's actually quite small and blue/whitish and people have been using it for over 13 years to generate full code that they can live with, and yes, from high-level models.

Scott Ambler reacts (according to the script) out of the blue that not everyone gets modeling. Correct Scott. Could it be that this is because UML, the most used modeling language - hyped since its inception by the OMG in every magazine, website and conference - is actually very complex? Would modeling not be simpler if developers can design with the concepts and rules that they are most familiar with - those from their problem domain - while the language makes sure that they follow the architecture and design rules that are valid in their problem domain?

Hopefully the next panel on MDD provides some real fireworks, cause there is enough reason to. A good moderator might help, one who doesn't let panelists get away with half answers or John-Kernisms.