UML & DSL: Simon says....

I find myself in agreement with the following points:developerWorks : Blogs:
My position is that the creation of domain specific languages that do not seamlessly support the ability to transform information along the refinement scale are not helpful to us. So, for example, a component designer that is a stand alone tool unconnected to the class designer that provides the next logical level of refinement (classes being used to construct components) is a pot hole in the road from concept to actual implementation. Now, this is not as I have said to indicate that domain specific languages are bad, just that many of us in this industry love to create new languages be they graphical, textual or conceptual. We have to beware of the tendency to build these disjoint languages that force the user to keep stopping and jumping across another gap.
My summary: present different views to different users, but in a way which keeps transformations (including mental ones) easy (e.g. all views based on common metamodel)

Now, does the UML help us in this? Well, actually as it stands no, it has many pot holes all of it’s own! But, one way to look at the UML is a pre-existing set of domain specific languages, with at least small and well understood gaps between them. For example most everyone is familiar with the class model, the component model, the state machine model – all of these can be treated as sub-languages, and have been successfully applied in projects.

My summary: common set of concepts which can be tailored

Now, the danger is then to say that the UML is enough surely for any problem (got a hammer here – anyone got a nail?). Well therein lies a big, big hole waiting for the unwary. The UML is a general purpose language, like English and as such can be vague in a particular domain, so we have created specific usages of the English language for engineering or science, even standardized the meanings of terms for defining specifications (RFC 2119). In this regard it is clear that the UML needs to have particular usage patterns documented as sub-languages, or domain specific usage.

But then, there are simply concepts in use today that do not map well to any UML sub-language or usage pattern. Well, the OMG has already thought of that and provided the Meta-Object Facility (MOF) which is the underlying language used to construct the UML – making MOF a domain specific language for constructing domain specific languages? Here at IBM the open source Eclipse Modeling Framework implements the MOF specification and provides both run time capabilities and tools for defining new modeling languages (and you can see examples in the XML Schema Tooling on eclipse.org).

My summary: UML can be extended, and if that isn't enough then new dialects based on MOF can be built. Still the transformation gap is small.

Anyone seen a scenario mapped out in the two approaches? When the terms and concepts seem so slippery a practical example always helps.

No comments: