Alan Cameron Wills - Domain Specific Languages

Models, domain-specific languages, code generation, ....

Costs of designing a DSL – UML the answer?

RobR > Tools built on the type of meta-technology you talk about are not new.

Agreed!  Of course, I’m working at Microsoft rather than at a university, so utter novelty is not a claim. In fact, we hope to use the best ideas and experience that have been developed over the years, combining them with some ingenuity of our own.  In particular, we want to aim for industrial-scale application of these ideas.

RobR> textual languages, like programming languages and expressions languages are so essential. I simply don’t believe that you can generate real systems from visual representations without the visual representation becoming hugely complicated.

Absolutely agreed! 

RobR> This is again where standard expression languages like OCL and ASL can fit in

An excellent general purpose constraint language, and an excellent general purpose imperative language (with interesting mechanisms for ‘bridging’ between levels of abstraction). But again, they’re general-purpose, and so it’s inevitable that they will be too heavyweight for many of the domain-specific purposes we might want to put them to.

RobR> When using a textual DSL, you then have to consider the needs of end users: will they be able to learn it?

Yes, the initial costs, learning included, are among the drawbacks of real DSLs, whether textual or graphical.  It’s only worth inventing a new DSL if we think we’ve got a big enough application domain that it will be worth the cost of our users learning it; and, of course, worth the cost of developing and maintaining it.

To mitigate the costs of learning, here’s a bright idea: when we invent a DSL, let’s try and stick to a small set of grammatical styles, merely varying the parameters of those styles from one language to another. Our language-designing users would start by selecting from a bag of templates. We could have one style with boxes and lines, say, and another with vertical bars and arrows between them, and another with nested boxes and arrows; and some textual basics. Hey, wait a minute — doesn’t that all sound familiar — hey, that’s just like UML! Well, whaddya know — maybe we should be using UML as the basis for all our DSLs?

Well, unfortunately, I don’t believe so. UML and its tools weren’t designed with that approach in mind — that its role should be to provide a set of templates for a wide range of DSLs. Its envisaged roles are for specifying and designing software, and so it has all sorts of constraints that make perfect sense for that domain; and it has no features for cutting the language down. If I do want to invent a totally new style of syntax — like math formulae, or block diagrams — there are no facilities. Only by going into MOF can I get near doing that kind of stuff: and MOF is not for beginners, and not well-supported by tools.