Why not base domain specific languages on UML?

New Team System Stuff - 2004-11-11

Rob Caron's Blog — Fri, 12 Nov 2004 12:33:00 GMT

re: Why not base domain specific languages on UML?

RobR — Sat, 13 Nov 2004 20:13:00 GMT

Thanks Alan,

I think for many language definition purposes, UML stereotypes are in fact much more useful than you think. In effect, they are extending the UML metamodel, and many UML tools these days provide reasonable access to scripting languages for both checking that they are used consistently and for generating code. So you can actively say "prevent the designer from connecting a conveyor belt to an airport lounge" or "don't use UML abstractions". The other advantage is that UML stereotypes are easy to use (remember that many users are not all language design gurus) yet they want the ability to quickly create new design abstractions that extend their tools' capabilities.

I'd also like to raise another issue regarding UML, which is actually quite important when you do language definition for real: you don't mention language design scenarios where you actually want to incorporate new abstractions within your pallete of existing UML abstractions. This happens all the time. Let's say I want to add the notion of a Component to UML. I certainly don't want to have to build a DSL tool for all of UML - yet my designers are conversant in UML and I want to maintain that knowledge. So really you *need* UML to make this all fly. Now, of course MS or its partners may be deciding to implement all of standard UML 2.0 in the technology ;)

A few more comments:

1. Tools built on the type of meta-technology you talk about are not new. Here are just a few: DOME, MetaEdit+, Xactium-XMF, EMF, DSTC's tool and Vanderbilt's tool. Much of what you are talking about as the big vision has already been done - today I can download free tools that help me create visual editors and transformation engines, all of which instantiate an underlying metamodel expressed in a common metamodelling language (usually MOF).

2. As you say, just dealing with the visual aspects of languages is not enough. Although you mention the GUI aspect of a language, there is surely something missing in that diagrams only capture half the story. Such visual only languages lack power (and are therefore of limited usefulness) because they cannot express the detail - that's where 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.

This is again where standard expression languages like OCL and ASL can fit in - enriching models so that they can capture the detail. Alternatively, something like a grammar modelling language (Xactium's XBNF grammar is something I recently came across - which captures a textual representation of a language as a mapping from a grammar to a MOF metamodel) would appear to be a very important part of what you need to do to model complete DSL tools.

3. When using a textual DSL, you then have to consider the needs of end users: will they be able to learn it? If you choose a non-standard langfuage you have a big training overhead. Will they be able to debug it, parse it, interpret and compile it? You might be interested in looking at work being done by Jeff Gray on the subject of extending the Eclipse debugger to support DSL's.

4. Finally, MDA has made some important strides towards developing the *standards* necessary to support DSL's: MOF is a central plank for enabling interchange of metamodels. QVT is a language for expressing model to model transformations. Diagram interchange is a standard for capturing models of diagrams. Is a MOF and QVT like language something that you at Microsoft will be supporting, and if so, do you see it becoming a way of exporting the designs of all your languages and mappings into the community, or is the intention to keep things under the bonnet? I also notice that although you mention the word "metamodel" - the * meta language* you do this in does not appear to be a central plank of the technology. Yet, to those who develop such tools, it is the foundation of everything and the means of achieving open and transparent interchange of models and metamodels.

Language-oriented or Metadata-driven?

GarethJ's WebLog — Tue, 30 Nov 2004 23:14:00 GMT

UML Semantics

Steve Cook's WebLog — Thu, 09 Dec 2004 00:01:00 GMT

re: Why not base domain specific languages on UML?

Lloyd Fischer — Thu, 09 Dec 2004 23:49:00 GMT

This DSL wave reminds me of work I did in a previous lifetime, although then we called it visual programming. I built the initial versions of a product used to specify simulations graphically. The product still exists http://www.cae.com/www2004/Products_and_Services/Power_Systems_and_Simulation/Technology/rose.shtml

Anyway, we spent a lot of time thinking about visual representations of software. it turned out that the times we were successful was when the system in question *already* had a visual representaion. Examples are piping and instrumentation diagrams, electronic schematic diagrams, ladder logic diagrams, etc.

In those cases where we tried to create new visual representations we failed. The "business users" invariably rejected our attempts to turn their knowledge into diagrams because they were unnatural to experts in the field. The fact that they had not yet created such diagrams was a telling sign that no such representation was possible. Those fields where such representations were useful had long ago created them.

Software people make the mistake of thinking that since they use UML to describe their software, and software can represent anything that they should use UML to represent anything. But in fact I find that UML is a lousy way to represent code at a level detailed enough to execute. A much better representation is high level source code. It's compact, expressive, and the result of generations of refinement - just like schematics and P&IDs.

Now don't get me wrong. I still think DSLs are a hoot. But they should be at a level of abstraction well above source code, and still contain enough information to be executable. This means that they should represent "business" entities, not software entities. Just as a schematic allows you you completely specify a circuit in terms of resistors, capacitors etc a banking DSL should allow you to completely specify a bank in terms of customers, accounts and processes. But the way to arrive at such a language is to go ask bankers if they have a typical way that they draw pictures on a whiteboard when they descibe their business, and then copy that. And I bet they don't use UML!

Domain Specific Languages (DSL)

Khurram Aziz — Fri, 10 Dec 2004 12:21:00 GMT

Booch on DSLs (Round 3)

Harry Pierson's DevHawk Weblog — Sat, 11 Dec 2004 01:50:00 GMT

The Pharonic Architect is Blogging

Harry Pierson's DevHawk Weblog — Tue, 21 Dec 2004 06:50:00 GMT

Back and Forth on UML and DSLs

Don Box's Spoutlet — Wed, 05 Jan 2005 08:38:00 GMT

Should DSL use UML

Bruce Johnson's SOA(P) Box — Wed, 05 Jan 2005 23:27:00 GMT

Software architecture, software engineering, and Renaissance Jazz

登陆楼顶听月--楼顶主人 — Thu, 03 Feb 2005 11:00:00 GMT

Ping Back来自：blog.csdn.net

??????????????? » ???????????? » UML???DSL?????????

??????????????? » ???????????? » UML???DSL????????? — Sat, 29 Mar 2008 20:03:11 GMT

PingBack from http://www.mingli-yuan.info/archives/128