More evidence that DSLs beat UML
It’s always a nice when I run across software development gurus that are praising the merits of Domain-Specific Modeling and Languages—particularly when they are converts. Over the weekend I spotted a posting from Ivar Jacobson that was just that. As most of you are probably aware, he is one of the original creators of the UML. In the posting, Mr. Jacobson emphasizes the importance of reuse and comments that domain-specific languages (not UML) are the key. This is the message that DSM tool providers (e.g. MetaCase) have been saying for years now and it sure is great that even the founders of the UML are stating the same.
http://ivarjacobson.wordpress.com/2004/02/08/software-reuse/
March 6th, 2008 at 6:50 am
Hey, your conclusions goes to far.
DSL’s can be created by using UML. There are many such good examples.
Now, I don’t want you to believe I think everything with UML is good. See my blog http://www.ivarblog.com and go to the UML category.
What I think is really good is what we call Essential UML. Essential UML is enough for more than 80% of all applications but just less than 20% of UML.
Moreover, DSL’s are not new. They have been there for more than twenty years. Like everything in software we swing from one position to the other. DSL’s were very popular in the telecom space back in the late 80s and they came as a revolt to a unifying approach called SDL. SDL was created by the telecom industry in 1976 and it can be described as a predecessor to UML.
Ten years later we got UML. Maybe it is time for another swing to DSL’s. I would welcome it, if we did it well.
The problem with DSL’s has been to guarantee consistencies between different models of the same system. The problem is called DSL fragmentation. This is a problem that has fascinated many computer scientists but I don’t know if they have found a solution yet. I doubt it.
I will use what works. I know UML works very well in many cases. I am sure some DSLs also works in some domains.
We just need to relax and not be so fundamentalistic about these things.
March 7th, 2008 at 1:55 pm
Thanks for your comments Ivar.
As you poignantly stated, DSLs need to guarantee consistency between different models of the same system. I completely agree with this, and think it’s great that you took the time to point this out. The reason I say this is because while inconsistency can potentially be a problem, the problem can be avoided (and has been in numerous industry experiences – Nokia, EADS, Panasonic, USAF) if the language is designed in the first place so that the various views can be integrated. Then, any modification in one diagram element can be automatically propagated elsewhere, or inconsistencies can be reported. This naturally requires that the capabilities to define languages (metamodeling language) are present. For example, I’m happy to report that DSLs created with MetaEdit+ (based on GOPPRR) do not have the challenges with fragmentation you mentioned. There are numerous academic papers which discuss this accomplishment, but probably the best reference I can point to is the book “Domain Specific Modeling: Enabling Full Code Generation”, which was published last month by Wiley.
In terms of your comment about Essential UML, I have to agree that the bloat that UML has experienced since its inception is, for the most part, unnecessary. Consequently, I would certainly agree with your 80/20 logic on this point. The issue for me becomes what we mean by “enough”. If by “enough” we simply mean the ability to sketch out the code in a visual format of class diagrams, state diagrams, etc., then yes, 20% of UML is enough for most. But, if by “enough” we mean the ability to generate full code–and substantially make an impact on the productivity of an organization–then 100% of the UML, combined with an army of profiles, will not be enough. And attempts to extend it further with more profiles, OCL constraints, and action languages is simply too much for most. By focusing on essential concepts within a particular domain both benefits can be achieved: the simplicity you are targeting along with reuse support, plus the capability to generate code.
Thanks again for your insightful comments Ivar, I appreciate you sharing your thoughts.
March 8th, 2008 at 12:52 am
Now we are speaking the same language — the same DSL - and I like it.
If “the language is desiged in the first place so that the various views can be integrated”, then we basically have some core of the language that forms the base for all the domain-specific languages you can build. This is major simplification and frankly not so interesting. This basically means you have a unifying language as a base, not very different from the UML idea. The difference is just cosmetic, but I agree it can make a huge difference to developers. This idea is not much different than the idea of creating an Essential UML.
UML also has profiles allowing you to create your own domain-specific language. The challenge is that the profile is built on something big — UML — instead of a core.
So, what you discuss as successes with DSLs are not substantially new compared to UML. What I really like about the research on DSL’s is that you can create useful DSLs not intended to have a common base or core, but where you still can create formal transformations between these DSLs. I had lengthy discussions on thsi subject with Jean Bézevin, professor at Université de Nantes in France. He claims that he and his colleagues have come a long way to sort out this problem. I am by nature a bit sceptical but if there is a practical approach I would certainly welcome it.
Regarding your comment that Essential UML or entire UML for that matter would not be enough if we want to generate full code, I basically fully agree with you. However, the models would not need to generate code, the models would be the code. And frankly, today I think we are furher away from making this happen than we were 5-10 years ago. However, one day I think we will bring it up again. It is all about what is fashion.