DSL Tools, UML and MOF

We’ve received a couple of questions on the DSL Tools Forum which I thought I’d expand upon here.  The questions are:
– Why don’t we use UML to define our metamodels?
– Why don’t we use MOF to define our metamodels?

To answer these effectively, it’s necessary to unpack them, because different people mean different things by these terms.  I think these are the basic questions:
a) Does our tool implement the MOF model?
b) Why don’t we use a UML tool to define our domain models?
c) Why don’t we use UML notation to define our domain models?
d) Can we interchange XMI?

Our Domain Specific Language tools are designed to create editors that are integrated into Visual Studio.  To do this, we have to define many concerns, including abstract syntax, notation, constraints, mappings to files, toolbox behaviour, explorer behaviour, properties browser behaviour, delete behaviour, copy/paste behaviour, rules, transactions, and events: and we do it in managed code, running on the .NET framework and the Visual Studio SDK.  This is the background against which our design decisions must be understood.

(a) The only concern that the MOF model would directly apply to would be the abstract syntax.  In fact our API for manipulating instances of domain classes in the store manipulates exactly the same kind of things as the MOF model defines: classes, properties, and relationships.  We differ from MOF terminologically, in order to be consistent with .NET; but conceptually we are dealing with the same stuff in a .NET context.
(b) A complete UML tool would be too heavyweight a solution for defining domain models.  We’d only use class diagrams, but we’d still have to add many extensions in order to address concerns other than abstract syntax.  Instead, we have built our own lightweight domain-specific tool, which is tailored for the purpose for which it is intended.
(c) One of our design decisions for creating domain models is that they should be completely automatically laid out: we did not want to carry around visual layout information in our domain model files.  To do this, we found it valuable to capitalize on the inherent tree structure of such models, and to design a notation that makes this layout easy.  It takes a little while to get used to this notation, but it does borrow quite heavily from UML e.g. in the way that it represents inheritance and multiplicity.  Decent autolayout of UML diagrams would involve much more complex algorithms, and we didn’t want to put our efforts there at present.
(d) Yes. See Stuart’s comments.

Comments (8)

  1. Doug Holland says:

    It seems that there is plenty of room for both DSL’s and the UML, after all it could be argued that the UML is simply a domain specific language where the domain is object orientation.

    Unfortunately the UML is often treated as though it is the "Universal" modeling language and not the "Unified" modeling language which depicts its origins in three separate notations.

    Unfortunately early statements from Microsoft, such as UML not supporting partial types, didn’t do the DSL team at Microsoft any favors.

    Especially as UML stereotypes could be used to denote <<partial>> types, or as in the Visual Studio 2005 class designer partial types are simply merged into a single type as they are within the resulting MSIL.

    I initially was very skeptical when Microsoft announced that it was not using the UML, especially given reasons like that above involving parital types, however I’m using the DSL tools and the VS2005 class designer now and I think Microsoft is on the right track.

    That said however the class designer in VS2005 has alot of opportunity for enhancements in Orcas and Hawaii and I for one would like to see support for Sequence Diagrams in much the same way as IBM/Rational XDE generated UML sequence diagrams through Visual Trace.

  2. Rob R says:


    I think you are missing the point when you talk about MOF only being used for abstract syntax. MOF provides a unified data representation for a wide variety of artefacts.

    I would have thought that all the models you use in your DSL environment (including those representing concrete syntax) could be viewed as instances of MOF. My impression from what you are doing at the moment is that you are representing this stuff as XML. However XML does suffer from being a relatively weak means of representing data, for instance you can’t express constraints on it. MOF would provide a richer representation, and you can see this happening quite rapidly in the context of EMF, which is being used to represent models and instances of all sorts of language artefacts, not just abstract syntax.


  3. Doug

    I’m pleased you think we are on the right track. I’m puzzled by your solutions to the problem of representing partial types, though. If you use <<partial>> stereotypes, you still have the problem of the UML constraint that specifies that classes must be uniquely named in a package. So you can’t have two <<partial>> classes with the same name in the same scope. That doesn’t seem such a good representation to me. Your second solution is to represent partial types by not representing them. Either way, I don’t think you’ve solved the problem.


    You misquote me. I said that the only concern that MOF might apply to *directly* is abstract syntax. What I mean by this is that the concepts we use to define abstract syntax are classes and relationships, which are also the language of MOF. Of course you could use these concepts to define languages to represent all of the other concerns, but that involves an additional level of interpretation (a metalevel, if you want). This can be costly.

    About XML – we use it as a way of saving our models to files. Inside our tools they are not represented as XML, they are represented as instances of classes and relationships, with additional metadata, including constraints.

  4. Fred Thwaites says:

    oooh now this is getting interesting!

    I’m a big fan of UML and this is likely to stay for some time to come. After using OOAD CASE tools for about 10 years, I long ago came to the conclusion that general toollike UML and great for architecture and non-implementation specific modelling, and give real value to development by allowing early alignment of business domain dynamics to seperated concerns within the model.

    I also came to the conclusion about 4 year’s ago that the tools just couldn’t hack code generation. The extra detail you have to add to a model to have it reliably produce decent code is prohibative, and cannot compete with a decent IDE like Visual Studio.

    DSL’s seem to offer a great was to achieve this without the need for complex extentions needed by the general tools.

    I currently mandatethe use of UML modelling within Requirements Modelling and Analysis. For design the developers dip into UML where it helps, but otherwise don’t use modelling. When VS2005 ships I’m expecting to use DSL’s for design and code gen.

    So that leaves me with two lots of models, UML for Buiness and Analysis, and DSL’s for Design. Reading between the lines I expect to see XMI to DSL mapping tools appear almost as soon as VS2005 does. At which point a lot of the fire will be taken out of this. Well except for those tools companies pinning there hopes on MDA.

  5. On Language Workbenches:

    Martin Fowler’s original post x and additional readings x

    Brad Appleton’s…

  6. On Language Workbenches:

    Martin Fowler’s original post &amp;oplus; and additional readings &amp;oplus;…

  7. On Language Workbenches:

    Martin Fowler’s original post ⊕ and additional readings ⊕

    Brad Appleton’s…

  8. Weddings says:

    We’ve received a couple of questions on the DSL Tools Forum which I thought I’d expand upon here. The questions are: – Why don’t we use UML to define our metamodels? – Why don’t we use MOF to define our metamodels? To answer these effectively, it’s necessar