Domain Specific Languages vs. UML

I’ve been keeping a sceptical eye on Software Factories and Model Driven Architecture (MDA) for some time so I was very interested to see a Domain Specific Language (DSL) API spring up in the latest drop of Visual Studio. I thought I’d better do some reading around the area to try and understand its goals. During my "travels" around the web I came across the following blog, Jack Greenfield’s Blog. Amongst other things it talks about an on going debate about using UML for MDA (and for Software Factories in general) vs. DSL. Now all the arguments for and against each one are all very interesting and exactly the sort of thing to get real-ale drinking software architectures in a bother, however for me there is one clear advantage for DSL…the average user. I don’t think I’d be burnt at the stake for suggesting that as good as UML is, the majority of people successfully cherry pick UML in order to describe/document their solution, very few would take it through every stage. Again I don’t really want to get into a debate about why people don’t use UML I just want to state that, rightly or wrongly, people don’t believe it is some kind of silver bullet/fits-all language. This brings me to my point (hurray), so far I’ve been talking about people in the software business what hope have we in convincing Joe public to use UML? As much as we like to make our solutions generic it often becomes more complicated for the average user. Did the average user welcome the fact that they could use VBA in Word and Excel? Sure the developers (and hackers) did but did the average user? I’d suggest not. What the user wants is something that talks in the language they understand. So for Word they’d probably want something that talks about text changes, font formatting, picture adjustments, spelling, etc. For Excel formulas, statistics, graphs, etc. Now sure there is some common ground that could be exploited but basically the domains are different. So assuming that I’ve established that the user wants domain specific tools how to best address that? This is where the arguments of DSL vs. UML step in. But wait, if we can’t convince the software development community about UML how on Earth are we going to convince Joe public, surely it will be better to provide specialised DSL for the users problem domain? "But they’d have to learn a new tool/language for every one", I hear you cry. True, partly. This brings me back the cherry picking of UML. Personally I feel UML is too verbose and clumsy to be used "correctly", but what it is great at is conveying ideas and requirements without necessarily concretely specifying them. E.g. I can draw an interaction diagram describing how to spell check and save a Word document, but I wouldn’t feel it necessary to write out a full class specification for a Word document so I could include it in the interaction. I realise this might shock the purists but I’d argue that the real goal of UML is to successfully convey the requirements and to describe the solution. I believe it is successful at this because the concepts of shapes and flow are pretty easy to understand even without formal training. Therefore I believe that providing you implement your DSL using fairly simple concepts but still talk in the context of the domain you can take the reusable parts of UML and still provide the average user with a toolset they can understand.
This entry was posted in Domain Specific Languages. Bookmark the permalink.

One Response to Domain Specific Languages vs. UML

  1. jackgr says:

    Your conclusion (last sentence) is right on the money. Our approach to modeling boils down to a pragmatic preference for focused custom langauges that serve very specific purposes. They may use pieces of notation from UML, or not. The goal is always to provide something simple, intuitive and effective. Since parts of the UML notation are intuitive, or at least widely understood, they\’re good candidates for use in such a language.
    As for the complaint that you have to learn a new language for every domain, the obvious answer is, "Of course". If you\’re using UML for the task, then one of two things is true: a) you have to learn a new language for every domain, or b) your models do not describe the domain precisely, making them difficult to use for tasks that require precision, such as effective code generation.
    Let\’s consider a). You observed that almost everyone cherry picks UML. If the UML user has identified the UML symbols that they plan to use, and has ascribed specific meanings to them, then they have created a domain specific language within UML. If they have designed the language well, then it will describe their domain precisely. They may use stereotypes, tags and icons to support their DSL, or they may merely interpret the unadorned UML diagrams a certain way. The effect is similar in either case. The tool doesn\’t really understand their DSL. They must supply the interpretation, perhaps using a tool plug-in, or perhaps using a post-processor, such as an XSL transform, or a template based code generator.
    Now, let\’s consider b). If the user is working with unadorned UML, and has not ascribed specific meanings to the symbols, then their models will not describe their domain precisely. Why? The UML is a general purpose language. This means that it can describe anything approximately. The corrollary must be that it can describe nothing precisely. There cannot be a universal language that can solve all problems effectively. To do so, it would have to perfectly describe both the computing platform and the real world problem domain with great precision. As we know, these domains are radically different. That\’s why it\’s so hard to map requirements to implementations.
    Clearly, whether you have a) or b) depends on how you choose to use the UML. Our approach is a bit like a), but more extreme. If you\’re going to create a custom language that describes your domain precisely, perhaps using some of the UML notation, and if you\’re going to build a custom tool to support it, then why not set out to solve exactly that problem? Of course, that\’s what we did.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s