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
- Anonymous
June 03, 2005
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. - Anonymous
June 05, 2005
Steve,
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.
Rob - Anonymous
June 07, 2005
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.
Rob
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. - Anonymous
June 11, 2005
The comment has been removed - Anonymous
July 04, 2005
On Language Workbenches:
Martin Fowler’s original post x and additional readings x
Brad Appleton’s... - Anonymous
July 04, 2005
On Language Workbenches:
Martin Fowler’s original post &oplus; and additional readings &oplus;... - Anonymous
July 06, 2005
On Language Workbenches:
Martin Fowler’s original post ⊕ and additional readings ⊕
Brad Appleton’s... - Anonymous
June 06, 2008
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