Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage News Microsoft Joins the OMG: UML or DSL?

Microsoft Joins the OMG: UML or DSL?

This item in japanese

Microsoft, who has heavily invested in the past in a modeling architecture with BizTalk, Software Factories and VSX Tools, announced yesterday that it was joining the OMG as it readies the release of the CTP (community technology preview) of its next generation modeling architecture: Oslo.

With project Oslo, Bob Muglia, SVP for Servers and Tools, explains Microsoft is:

incorporat[ing] models deep in the system, such that the operation of a system itself is model driven.

The Object Management Group controls several elements of a modeling architecture, UML, a general purpose modeling language, MDA, the Model Driven Architecture approach of the OMG, BPMN, the business process modeling notation and a large number of industry vertical groups (Domain Task Force) which define industry specific models.

Most recently, Microsoft had announced that it was going to support five UML 2.1 diagrams in Rosario, the next release of Visual Studio Team System. This renewed interest in UML sparked a debate on the relationship between UML and DSL. Cameron Skinner explains:

some articles have been written in a way to lead the reader towards a perception that Microsoft is moving away from DSLs and towards UML. Not at all correct! I wanted to take a moment and set the record straight on this, and start a broader conversation.

He emphasizes that:

Microsoft is very committed to our DSL strategy, and in particular to the DSL toolkit that ships as part of the VS SDK. In fact, our UML designers are built on top of that toolkit.

supporting both approaches to modeling gives developers and Architects alike the "right tool for the right job". For those folks who want to analyze and design their architecture using a standard notation that does not imply an implementation decision, use some UML diagrams. UML is great for describing higher level concepts and for defining the initial glossary that can be used to describe the concepts necessary to facilitate broader communication. For those folks who have decided on an implementation strategy, and do not want to be encumbered by the more general nature of the UML to describe that implementation choice, use DSLs.

He concludes:

We are really trying to promote a clean separation between the two approaches, while at the same time, attempt to maintain an understanding of how one can inform the other, and vice versa.

So this is not a "DSL vs. UML" conversation. This is a "DSL + UML" conversation. And more importantly, this is about meeting our customers where they are and giving them tools that allow them to get to where they need to be.

Johan den Haan recently commented on the topic:

This sounds familiar? Just compare it to the concepts of the MDA! In principle Cameron states that UML should be used as the language for defining the PIM (Platform Independent Model) and DSLs should be used as the language for defining the PSM (Platform Specific Model).

He also notes that:

Steven Kelly doesn't like this approach: "The DSLs are thus not specific to the problem domain, as they should be, but to the solution domain: they have the implementation concepts of a particular Microsoft framework or library". He adds firmly "Putting UML before DSLs in this way isn't just putting the cart before the horse: it's putting the horse firmly into the cart -- and pulling it yourself".

Johan's is however a bit skeptical about the OMG MDA for two reasons:

First, they use UML as language, which is big and complex and therefore difficult to learn and use. Second, they only focus at one modeling dimension (abstract/concrete).

Johan explains that there are two types of DSL which aim at the problem domain and the solution domain. He calls them respectively: Subject-Area DSLs and Framework-Based DSLs. He cautions however that:

Subject Area DSLs do have a higher level of abstraction, hence you should use them if it is cost effective to design and implement them. But don't forget: depending on the size of the user community, development of training material, language support, standardization, and maintenance may become serious and time-consuming issues.

Johan concludes:

I definitely agree with Steven (see the citations above) that using UML and DSLs as presented by Cameron isn't a very good idea.

And he adds:

I think that using generic / common standards can help in defining DSLs and making them executable and (maybe) even portable. Not by using all kind of model transformations, but by using a common meta-(meta-) model defining the generic concepts (i.e. ontology) to be used in the DSL.

InfoQ also spoke with Jack Greenfield, Senior Director of the Platform Architecture Team at Microsoft, who is preparing a second book on Software Factories: "Software Factories Applied". He explains:

A Domain Specific Languages (DSL) is a language that targets a specific concept, task or platform. By contrast, a general purpose language (GPL) is designed to describe a wide variety of concepts, tasks or platforms. Each type of language has value.

and he adds:

GPLs are useful primarily in the early stages of working with a given class of problems, when the problem domain is not yet well understood, or is changing rapidly. Their power comes from their ability to describe many different problem domains. Because they seek to be broadly applicable to a wide variety of problem domains, however, GPLs generally admit a wide variety of interpretations, and must therefore specify information with a limited degree of precision.

DSL are useful primarily in the later stages of working with a given class of problems, when the problem domain is well understood, or is changing slowly. Because they seek to provide maximum leverage in describing a specific problem domain, DSLs generally allow less room for interpretation, and capture information with a high degree of precision. In fact, most DSLs embody precise semantics, so that they can be used reliably to generate valid code in a specific programming or specification language. However, because of this specificity, the applicability of a given DSL is generally limited.

and concludes:

In practice, the distinction between GPLs and DSLs is not black and white. In other words, the transition from general purpose to domain specific languages is not necessarily a step function. GPLs can usually be customized to some degree using extension mechanisms (e.g., stereotypes in UML) to improve the precision of the information about the target domain captured by the model. In addition, GPL tools can usually be extended to take advantage of the language extensions (e.g., by writing a custom code generator). At some point, however, the disconnect between the expressive requirements of the viewpoint and the expressive power of the GPL becomes too large. It then becomes difficult to realize the required degree of precision using the GPL. Beyond that point, the language extensions tend to become cumbersome for the user, and the tool extensions have trouble providing the desired behavior within the constraints of the GPL metamodel and the underlying tool architecture. The viewpoint designer may then do better to define a DSL.

Is UML becoming more a notation than a language? Are we at the onset of a broad adoption of Model Driven Engineering concepts? What's your take on it?

Rate this Article