RobR writes:

re: DSL tools available
I'd be interested to know how your tools differ from doing the following:

- creating a bunch of stereotypes in a UML tool (possibly with some icons to make it look prettier). So for baggage handling I could build various domain specific stereotypes: conveyor belts, etc.
- define some code mappings into a target language that generate code for specific stereotype instances
- start modelling!

Thanks Rob, this really is the $6.4e4 question!  (Well, one of them.)  Main thing is that it’s a lot simpler if you don’t bother with UML for this purpose: less for everyone to understand, fewer constraints, less clutter in the tools and language; set against no real drawbacks (when you think about it).  Here’s the long answer:

UML great for other things.

Firstly, just to reiterate – we do believe in UML’s usefulness for a variety of tasks. I sketch in UML for analysis purposes and for helping to think about the detailed design of code; I’ve written a book about it, developed some nice techniques, and given numerous courses over the years, and signing up with MS hasn’t changed my views; and my group colleagues have comparable histories, some of them making substantial contributions to where UML is today. Furthermore, I’ve happily used a variety of specialist tools that use UML as a view of code or configuration files. But we do think that when it comes to composing software product lines, UML is not the best answer. After all, there are no panaceas, and one language can’t be expected to do everything.

UML too limited for DSLs.

So here’s why we don’t want to limit ourselves to UML as a basis for our users’ domain-specific languages:

• A careful look at the specialization mechanisms for UML reveals their limitations.
• Stereotypes and tagged values allow you to change icons etc, although even simple alterations like decorating a box to show the state of some property isn’t within range. You can’t change the semantic constraints, or invent new sorts of diagram or new categories of element.
• You can’t take stuff away, so your users are always distracted by other options and elements and diagrams that aren’t relevant to your language.  Tools that use a UML editor as a front-end have to have a (very annoying) validation step before they generate their DB schema or whatever it is.
• Many of the current crop of tools don’t handle them very well anyway; let’s hope that will change.
• UML only includes certain types of graphical format – if you want your language to include tree-structured diagrams, or tables, or math formulae, or block-structured text, or prose, or if you want hyperlinks – well, I think you’d have a hard time. While our initial offering won’t include all those styles, we’d certainly like to support them at some stage in the future.
• An important aspect of the definition of a modern language includes how you interact with it: how you navigate and elide or elaborate and edit etc – think of your favorite GUI composing tool, in which the GUI-defining language is scarcely separable from its editor. You can’t do anything about these aspects in UML.
• What you get out the back of one of our tools says things like <CheckinDesk> and <ConveyorBelt>. What you get out the back of a UML tool says things like <Class> and <Stereotype> -- much more difficult to read. (Yes, of course you could write translators, but it’s an extra layer of hassle.)
• You have to understand all of UML (stereotypes etc) before you can create your language on top of it.
• Your users have to understand an editor that’s intended for something far more complex than they probably have in hand – or at least whose complexities are in a different direction.

No real drawback to not using UML.

What might users lose by not basing their DSLs on UML?  Interoperability with other tools? Well actually, basing your DSL atop any intermediate language makes things worse! Let’s think about a scenario:

• My baggage-handling-software company uses kit from International Business Software, yours uses MicroMachines. One day we get a joint contract, and so we want to swap designs between us. But oops – our languages are similar, but different: ours includes stuff about the colour of the checkin desks, because we’re kinda artistic, while yours is strong on the number of nuts and bolts in each one. So what do we do? Well, we’ll have to (a) make some sort of translator; (b) persuade our editors to deal kindly with the lack or superfluity of colour or nut-count information in documents originating with the other group. 
  
  Now notice that this problem has nothing to do with the brand of kit we’re using. If we both had IBS or MM kit, or both kits were UML-based with interchange in XMI, we’d still have exactly the same problem: the difference arises because we’ve each generated our own different language. What’s more, each of us wanted to be separate, because our own language is an essential part of our competitive edge: it would have to be a really good contract, to persuade us to interoperate in this way. 
  
  What we do want from our kit, is that our generated DSL-processing tools must to be tolerant of variations – which they’ll have to be anyway, to cope with inevitable changes in our languages. And we want some tools that help us build translators – necessary for the same reasons.

• Actually the problem’s worse if you do it all on top of UML: even if we’re agreed about the set of concepts we’re modelling, we might disagree about whether a ConveyorBelt should be a class or an association or an actor or …. There’s an extra layer of redirection that introduces a spurious source of variability.

So on the whole, I think interoperability of the generating kit is a red herring in the area of DSLs.

Domain-Specific Languages are just part of the Software Factory approach.

Finally, for a bit of perspective: the domain-specific language itself is only part of the story. The surrounding process and tools, we call the Software Factory – the vision is defined in the Greenfield and Short book recently out, and at http://msdn.microsoft.com/architecture/overview/softwarefactories/ . When you use any kind of software product line, you need to change your process: for example, to evolve the language and the framework that interprets or executes it. That framework will typically be a very substantial body of software – usually evolved from pre-DSL specific instances. For example, you might take the software you wrote for LAX and combine it with a few bits from the Heathrow job, add some parameters, and smarten up the separation of concerns.  (Again, it will embody all the expertise that gives your enterprise its competitive edge, so you won’t be thinking of sharing it with anyone.)  This effort is the most substantial part of your adoption of software factories, and we aim to cover these other aspects with our tools.

So (1) we think sticking to UML would limit what our users can do; (2) no-one loses anything by not using UML in this particular area; (3) designing the language is not the biggest part of the job.

Alan