In my previous job, I used to go around showing people some rather neat techniques for doing requirements analysis (and in particular the Catalysis method I created with Desmond D’Souza). One of the big frustrations was that we didn’t have any tools to support our methods — always the most difficult thing that clients would ask about.
Well, now I’m building tools, and the first sampler of our technology can be downloaded today. The toolkit will support the development and application of domain-specific languages in your project. At http://lab.msdn.microsoft.com/vs2005/teamsystem/workshop/dsltools/, you can get a preview of part of the kit, our metamodel (= abstract syntax) editor. It isn’t the complete kit, and most of what you see will change; but from it, you can get some idea of where we’re headed. In a couple of months, you will be able to download enough bits to create and use a basic graphical DSL.
Let’s suppose your company develops software that operates the bag-handling systems in airports. Hitherto, you handled each new airport project by adapting the software you wrote for past projects. Now with our toolkit, you will be able to:
- Define the ‘object model’ ( = abstract syntax or metamodel) of your language — that is, the concepts and relationships you want to handle in it. In our example, you might create a language about the configuration of check-in desks, conveyor belts and loading bins in airports — these are the things that vary from one project to the next.
- Define a graphical concrete syntax for the language — the boxes, lines, etc that represent the concepts on-screen — e.g. diagrams containing things that look like checkin desks, belts, etc.
- Create, at a mouse-click, a graphical editor for your language, that your colleagues will use to design a specific airport.
- Develop code generators that will create software, configuration files, reports and other artefacts from the graphical model. That is, the software that runs the bag-handling equipment, the user interface for the operators, as well as lists of hardware parts. This is the most application-specific part of the job, and depends heavily on a framework developed — and that continues to develop — from your existing software.
The preview you can get from our website now demonstrates an editor for the first part, the object model. It is in itself a domain-specifc language, created specifically for this purpose. It has similarities to UML class diagrams, but the layout is specifically targeted at the tree-like structure of language definition. (You might recall BNF?)
The toolkit for all of the above steps will be available shortly: we demonstrated it on the MS stand at OOPSLA, and want to make it a bit more robust before publication.
The great benefit of a DSL is that once you’ve got it (and the framework the generated code runs atop), developing new applications is a much more agile process than before. The DSL can focus almost entirely on the requirements of each problem: the implementation patterns for the domain are encapsulated in your framework; so that it’s possible to adopt a process like eXtreme Programming, even for large sophisticated projects. (The same is true to some extent of any software-product-line method; DSLs have the advantage that you’re working in a syntax close to what people in the domain understand, rather than coupling pieces of code or composing in XML.)
This doesn’t mean that we can throw away our other software development tools and processes of course: building the framework that implements the DSL isn’t usually just trivial. But we think that choosing a DSL as the top layer of an architecture makes the whole project more agile.