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.

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?

I think Microsoft have the right ideas in their Software Factories approach. Their tooling isn't ready for serious use yet (although that's easy for me to say, since we've been in this field 12 years longer than them!), but it will improve.

The larger question marks for me loom over Microsoft's model for creating and applying DSLs: they expect a middle level of companies to create the DSLs, and sell each to many lower-level companies. So far, that doesn't seem to be working. Our experience at MetaCase is that the organization that will use the DSL is the one that should create it. That keeps things agile, avoids lock-in, and makes the language and generated code a tighter fit with what that company needs.See DSLs: to buy, to build or to sell?.

The other big worry with Microsoft is that marketing people who don't understand will try to "improve" the Software Factories idea by making it more palatable - effectively repeating the errors of UML and CASE tools before it. When Cameron Skinner says "start with a logical class diagram, then transform that into a DSL [model]", you can see that something has gone badly wrong. That's like first writing your program in assembler, then transforming it into C#. Jack Greenfield gets it right: you may use UML when first dealing with a new class of problem, but once you've worked with problems in that field for a while, you can design a DSL to work on that class of problems.

I look forward to seeing Jack's new "Software Factories Applied" book. One of the problems with the original SF book was the lack of real world examples and practical instructions - motivating us to concentrate on those areas in our own Domain-Specific Modeling book. I've not seen many real-world cases using Microsoft's DSL Tools so far, so it will be great if there are some in the new book.

people on CASE-tools org say that yes, is a CASE Tool, but I think as the guy say on the comment is NOT a CASE Tool. Is a for dummies tool. I think is the right think to have M$ on omg maybe they will be able to learn about UML and maybe the respect some standard... but is possible too they take the traditional component stereotype and decide to star to use a shoes box as a stereotype :D

Is your profile up-to-date? Please take a moment to review and update.

Email Address

Note: If updating/changing your email, a validation request will be sent

Company name:

Keep current company name

Update Company name to:

Company role:

Keep current company role

Update company role to:

Company size:

Keep current company Size

Update company size to:

Country/Zone:

Keep current country/zone

Update country/zone to:

State/Province/Region:

Keep current state/province/region

Update state/province/region to:

Subscribe to our newsletter?

Subscribe to our industry email notices?

You will be sent an email to validate the new email address. This pop-up will close itself in a few moments.

We notice you're using an ad blocker

We understand why you use ad blockers. However to keep InfoQ free we need your support. InfoQ will not provide your data to third parties without individual opt-in consent. We only work with advertisers relevant to our readers. Please consider whitelisting us.