Doug Schmidt on DSM

Software Engineering Radio recently interviewed Doug Schmidt, a professor of computing at Vanderbilt University. The interview became interesting for me from minute 33:30 onwards, where Doug explains DSM, as he also did in his article on Model-Driven Engineering last year.

Doug clearly is an expert in this area and I enjoyed hearing how much his thoughts are similar to the ones I have about Model-Driven Development.

What my experiences with the media and many developers on conferences are, is that further introductions of the idea however, are no longer really necessary. I do not think anyone is anxiously awaiting another book or another article that introduces Domain-Specific Modeling or modeling with DSLs. Instead, we need the minds, expertise and experience of people like the Schmidts, Tolvanens, Kelly's, Dimitrievs, Greenfields, Cooks, Fowlers and so on to focus on:

HOW

Mainly:
How do I best create a DSM language?
How do I make sure I can easily update it later?

But definitely as important are:
How does the DSM tool best support updating the language?
How does it best update and distribute changes?
How does it best integrate generators with metamodels?
How do we best exchange metamodels?

Juha-Pekka has made a significant contribution here in his recent articles on DevX and he will no doubt touch the subjects during his classes on Architecture and Design World. Many of his ideas are naturally part of MetaEdit+ of which the 4.5 version is scheduled for later this year.

"What Scale is worth the effort?"

In his blog "ISerializable", Roy Osherove talks about modeling with domain-specific languages and the ongoing "Software Factories" project in the healthcare sector. Besides the debate on whether the project is a failure or not - (Could it be the type of area Microsoft picked out? My thoughts earlier were that it seems that team Redmond is going far too generic with their Factories) - Roy wonders about "What scale is worth the effort?"

I believe it depends on many factors, such as complexity of the software you are creating, functionality, number and skill of the developers you have, number of possible variants or the amount of reuse of components and libraries you are planning (i.e. in product-platform-based approaches), and therefore it is difficult to answer.

Maybe we should look at the problem of "when does it make sense to apply domain-specific modeling" in the same way as "when does it make sense to apply modeling techniques?".

Currently many developers like it better to write code whenever they can do so, since it is faster than first modeling and then writing code. Complexity of the software forces you to make a model of it prior to coding but in itself thus forces you to solve the same problem on three levels: First in the problem domain, then in the domain of the modeling language and finally in the domain of the programming language. DSM attempts to bring the first two as close together as possible and automate the third step with generators. That way, they have to solve the problem only once. Much faster than writing it in code.

The other reason for modeling may be merely for documentation reasons where, as Roy mentions in his earlier post, models are usually out of date. If models however form the main artefacts of your development effort then both code and documentation will always be up to date as both are generated from the models.

OMG does it again: SysML

Two OMG key committees unanimously approved the ONLY submission it received on a RFP for a systems modeling language. I guess there was a real market need for it....

The submission came from "the usual suspects": Their own member organizations like Telelogic, IBM, Artisan...all UML tool vendors and guess what...SysML is a subset AND and extention to the UML --> a profile!!!

It took the tool-folks little over 2 years to come to an agreement on how to bend the UML in such a way that it supports systems modeling better AND that it still can be supported by their own existing UML tools: drop a few diagrams and add a few.... pretty easy from a tool vendor perspective. No real changes to the metamodel of course. God forbid that these vendors need to make a real change to their tools in order to improve the practice of modeling systems. Why in fact would you? We all know that the standard UML is already good enough for anything!

Besides, with a modeling language that's really close to UML you can be sure the OMG will approve it in record time and make sure the new standard gets appropriately hyped.

Software im Automobil 2006

I participated the annual "Software im Automobil" conference in wonderful Stuttgart last week. Naturally, the issue of autosar had a lot of emphasis in many of the talks. The automotive industry is fighting with complexity issues: Not only is the software getting more and more complex in functionality, it also has to be implemented in an environment that is influenced by many environmental and political issues, that is distributed, needs to be able to be updated, is hardware-expensive, has to run on hardware from different suppliers AND is often developed by different suppliers. The standard, low-level architecture and runtime that autosar envisions will no doubt be a big step toward more control over the spiralling costs involved with software and hardware development in this sector.

Next to autosar, I was surprised to see domain-specific modeling as the next-hottest topic during the conference. A growing number of players in this area start to understand that they cannot build the software or software product lines the build with standard, off-the-shelf development tools and languages like UML or C. UML lacks the preciseness they need and C or similar languages simply are the wrong tool: No one really wants to write 10 million lines of code manually and maintain them on that level. A raise in abstraction, where possible, is a logical next step and this is what DSM provides. In doing so, DSM will provide a proven solution to exactly those issues the automotive sector is struggling with.