re: DSL tools availableI'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:
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:
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.