The UML / DSL debate

There's been some debate between some of my MSFT colleagues (Alan Wills, Steve Cook, Jack Greenfield) and Grady Booch and others over at IBM around UML and DSLs. For those interested, Grady actually posted an article on UML and DSLs back in May last year - seems to have gone unnoticed. It touched on some of the themes that have been under discussion. My first blog entry was a response to this article.

A particular theme that crops up in the discussion is the issue of tools versus language. Grady seems to want to keep the two separate, whereas we believe that the two are closely linked - a language designed to be used in a tool is going to be different to a language designed to be used on paper.

I touched on this line of discussion in an article a few months back: https://blogs.msdn.com/stuart_kent/articles/181565.aspx

An example I used was that of class diagrams, and I pointed out a couple of aspects of class diagrams which may have been designed differently had the original intention been to use them within a tool rather than on paper. Now I can point you at an example notation that addresses some of these issues. It is the notation we use for defining domain models in our DSL Tools. Here's a sample:

Nodes are classes, lines are relationships or inheritance arrows. Nodes are organized into relationship and inheritance trees, which can be expanded or collapsed, making it easy to navigate and drill into large models (not something you do on paper).

A relationship line has the role information (would be association end information in UML 2) annotated in the middle of the line rather than at the ends: a role is represented as a triangle or rectangle containing a multiplicity, and the name of a role is annotated using a label (in the diagram above reverse role names have been hidden as they are usually less interesting).

Annotating role information in the middle of the line not only makes it easier to automatically place labels, it also means that relationship lines can be chanelled together enabling an expandable relationship tree to be automatically constructed and layed out. An example of channelling is given by the diagram below, where you can see all the relationship lines sourced on Page channelled together so that they connect to Page at the same point:

The point here is that this notation was designed from the start using criteria such as 'must support autolayout' and 'must support easy navigation of large models'. If the criteria were 'must be easily cut up into page size chunks', must be easy to sketch on a whiteboard' then the notation may well have turned out different.

Comments

• Anonymous
  January 04, 2005
  I don't see anything in your examples that would preclude the DSL domain notation from being anything more than a visual transformation of data that could just as easily have been modelled in UML. Is this what the argument is mostly about? The visual representation? Is there a common ground that could be extracted from UML and DSL domain modelling? Is that already MOF? Could DSL be represented with XMI? This is the most important thing to me -- what the pretty pictures represent, not the pictures (and even the UI) themselves.
• Anonymous
  January 05, 2005

1. The illustrations above are screenshots of the definitions of domain models in our tools. For those familiar with OMG terminology, a domain model is like an OMG metamodel. Metamodels are expressed using MOF. And yes, the notation used for MOF is UML class diagrams.
   2. There is some information defined in our domain models which is different to the information that can be expressed in MOF, so if we were to capture our domain models in a UML tool, then we would at the very least need to use stereotypes and tagged values.
   3. No doubt there is some common ground between the format of MOF models and the format of our domain models that could be extracted. There is probably some XSLT that could be written that would extract the common stuff in one format and convert it to the other format. However, there is information that we need for building designers that can not be captured directly in a MOF model.
   4. The debate is really about whether, in order to use DSLs effectively, it is sufficient to take an off-the-shelf UML tool and use stereotypes and tagged values to bend it to your needs, or whether you need to invest in building specialized languages and tools focused on the domain in question. We would argue the latter course is required, whilst recognizing that it will only happen if you bring down the cost of developing such tools. Grady seems to be arguing that the former is sufficient, on the basis that most DSLs you'll need are close enough to UML. Some of the reasons for holding our position are that UML wasn't really designed as a language to be used in tools (it's heritage is sketching OO designs on a whiteboard); nor was it designed to be particularly customizable or extensible.
   5. However, you don't want to start from scratch when developing a DSL and so our approach is to start the development of a DSL from a template, which allows you to start from a ready-made language that you can then customize.

• Anonymous
  January 06, 2005
  Hmm, I also have a question. Why the emphasis in these diagrams on structuring it as a tree? Certainly, some language domain models are tree like, but not all. If they were, we could just use tree-browsers to structure models. Aren't you putting a lot of effort into something that places a constraint on the designer: personally I would find it hard being forced to structure my models in this way.

• Anonymous
  January 06, 2005
  I've responded to this in a further posting: http://blogs.msdn.com/stuart_kent/archive/2005/01/06/347725.aspx

• Anonymous
  May 31, 2008
  There's been some debate between some of my MSFT colleagues ( Alan Wills , Steve Cook , Jack Greenfield ) and Grady Booch and others over at IBM around UML and DSLs. For those interested, Grady actually posted an article on UML and DSLs back in May las

• Anonymous
  June 05, 2008
  There's been some debate between some of my MSFT colleagues ( Alan Wills , Steve Cook , Jack Greenfield ) and Grady Booch and others over at IBM around UML and DSLs. For those interested, Grady actually posted an article on UML and DSLs back in May las