Hartmut's Box

Unified Modeling Language vs. Domain-Specific Modeling Language? Good question. After 10 years of UML it should be now clear that fixed metamodels are not adequate. This is nothing new, as the same happened with other standards of their time, EXPRESS-G, Merise, SSADM, IDEF etc. The problem of fixed metamodels we can detect today by just looking at ways to overcome the limitations of plain UML with profiles, OCL, action languages, model markings etc. This is bad news for developers: simply learning over 600 concepts of UML is not enough. And with profiles you can�t even take anything away as you build on top of existing. Profiles are also very limited on defining rules for model correctness. Similarly, if you inspect the documentation of the UML metamodel you can also see in the documentation explicitly stated how OCL can not express the modeling rules the UML itself states are required!

The idea of Domain-Specific Modeling languages is totally different: developers use those concepts that they are familiar with and already exist in their domain with known semantics. So, the models are made up of elements representing concepts that are part of the domain world, not the code world (as in e.g. UML). The final products can be generated from these high-level specifications because both the language and generators need fit the requirements of only one company and domain. It is obvious that one generator does not fit for all. The same applies for languages also.

When it comes to using models that contribute for implementation (other than documentation), vast majority of the industry solutions are domain-specific. We have very few industry examples of generating full code from UML � unless we define generating a class from a rectangle symbol to a file is code generation. DSMForum.org (www.dsmforum.org) has several cases on Domain-Specific Modeling languages for full code generation.

@Juha-Pekka Tolvanen:

You are certainly right concerning the strict UML metamodel. Stereotypes might be a solution in some cases. In my opinion MOF and an accompanying tool are an equivalent to DSLs. Because MOF has been around for a long time and already adopted by some and is a defacto standard, IMHO DSLs should have been based on MOF. It is always a good thing to base a concept on a proven and accepted standard. Web Services aren’t a breathtaking technology, but they are based on proven and accepted standards, SOAP and HTTP which is the basis for the world’s greatest application. New technolgies might be better, but having all major players agree on one standard is no minor feat. In addition a common basis helps interoperability. Just imagine modeling tools being based on MOF. All tools could interchange diagrams and languages. Edit an UML diagram and design DSLs within a single tool, any tool respectively. As I pointed out in my blog entries I’m glad that Microsoft is investing money in modeling tools. The idea of models being first class deliverables appeals a lot to me. I can’t wait to investigate the final release and in fact I’m spending some time on the current beta. I’m just a little bit sad that standards have been ignored, again…

I don’t see MOF adequate to build Domain-Specific Modeling languages. First, all those cases I’m aware trying to use the standard MOF have ended up implementing something else, calling it XMOF, MOF-like etc. Why this happens if there is a standard? Using names of standards might be enough for marketing people but inadequate in the reality. When looking for interchange of models for example, the details matter (look how well XMI works among different UML tools ;-(.

Secondly, MOF is only part of the DSM language tool implementation; you need to define also model correctness rules, concrete notation, tool behavior (toolbars, dialogs, browsers etc), model reuse rules, how to share the DSM language and how to update models made while the language change.

Thirdly, MOF is simply too complex and lacks some basics. At least in the past when I looked the standard there was no support for n-ary relationships. You get some hard figures of the complexity by looking at Eclipse EMF based UML implementations: 5000 man-days to get UML tool support (Str�bele, OOP, M�nchen, 2005). Doing that with a true DSM tool takes 5 days! Dr. Dobb�s had an article on DSM tools (http://www.ddj.com/articles/2004/0409/) showing a true DSM tool to be 2000 times faster than EMF and GEF.

Why not try implementing UML or Dobb’s logic example with the current Microsoft beta and tell us how long it takes? Are we talking about man-months or years like with Eclipse or man-days or hours like with MetaEdit+ (16MB from http://www.metacase.com, might be worth a look)

Thanks for the links! I’ll have a look at them, think about your comment, and finally try to give an answer. I might very well agree with you on many points :-).

Read your comment

Why not try implementing UML or Dobb�s logic example with the current Microsoft beta and tell us how long it takes? Are we talking about man-months or years like with Eclipse or man-days or hours like with MetaEdit+ (16MB from http://www.metacase.com, might be worth a look)

on http://www.innoq.com/blog/hw/2005/01/05/umlvsdsls.html.

At this time I�m learning DSL : http://www.xenopz.com/blog/bartdeboeck/CategoryView,category,Software%20Factory.aspx. I like your challenge though. What about organizing a �contest� ?

Hi Bart!

After toying with MS’s DSL Tools and reading articles and blogs about DSLs & Software Factories I start to like the ideas behind them. However I’m still convinced that basing the DSL appoach on MOF would have been a good idea. At present I’m spending nearly every single moment of my time working on a customer project, writing articles (in german, sorry) and learning WSE 3.0 & Indigo. This lack of time for any additional activities is also the reason for my blog inactivity. Therefore organizing a contest is out of scope. I’m sorry.