One approach I'm keen on for software architecture is the use of Domain Specific Languages (DSL). If you aren't familiar with the concept, there is a good introduction by Martin Fowler.
In a nutshell, a domain-specific programming language is not a general-purpose programming language, it's the opposite. DSLs are focussed on the needs of a specific task. A good DSL allows you to do just the things you need to do for a particular task, without giving you lots of options to have to choose between, and without providing lots of extra (confusing) functionality that isn't required for the task.
In the 70s and 80s, DSLs were typically text-based mini-languages that required someone to write a textual parser to process them. Since the 90s, XML has become a common format for DSLs (perhaps even the dominant format, if my empirical experience is any guide).
A key advantage of XML for DSLs is that an XML schema is a simple way to write an unambiguous format for a DSL, because much of what XML does is to set up an underlying textual format with rules that avoid ambiguous syntactical constructs (the "grammar rules" of your DSL, if you like). It's not that you can't write plain text formats that are unambiguous and produce parsers for them, it's just that it's a lot more work to make sure that your plain text format doesn't contain any potential ambiguities. The bigger and more complex your format is, the more of an issue this becomes. For a really small and simple DSL it isn't an issue at all, and a text format is fine; it then depends more on whether your users have XML editors or not (and if they know how to use them or not).
DSLs have come back into the news in recent years, largely because Microsoft has been championing them. In particular, Microsoft has produced tools for quickly producing visual editors for DSLs, and it has integrated the DSL concept into its Visual Studio products so that that the IDE is aware of DSLs, and doesn't assume that projects contain only code written in a general-purpose programming language.
My speciality is financial data models, and so the DSLs I deal with are used to describe data models; they don't describe how to process the information, they just describe data structures, allowed value ranges, relationships/associations between data items, and business/consistency rules. A particular data DSL may contain all or just a subset of this information for a data model, depending on how the DSL is used.
As an example, for the Market Data Definition Language (MDDL), we started in version 1.0 with a hand-edited W3C XML Schema (subsequently post-processed to add some features that were difficult to maintain by hand). The problem with this approach is that W3C XML Schema gives you multiple ways of achieving the same result, and different authors would use different techniques. This made the Schema difficult to work with, since there wasn't a single consistent style.
For MDDL 2.0, I created a DSL in the form of a small W3C XML Schema that encoded the simple data model that underlies MDDL (i.e. the metamodel). The Schema tightly restricts the XML document that now defines MDDL, and gives authors only one way to add or modify content. When the author is using a decent XML editor, the Schema also allows the editor program to prompt the author about what elements/attributes are allowed at each point in the XML document. The MDDL Schema (and other artefacts) are then generated from this simple XML representation. This works so well that the FISD has continued managing the content of MDDL this way for some years now.
However, for all that XML DSLs lend themselves to use with structured XML editors (i.e. editors that actively enforce the allowed XML structure while the user is editing), there is ample evidence that average business users don't like them. You want your DSL documents to be written by your domain experts, but these are typically business experts rather than programmers, and that means their creative processes don't work in a structured manner that lends itself to the use of a structured editor. Sean McGrath gave a great talk about this at last year's CSW XML Summmer School (oh, and both Sean and I will be speaking again at this year's XML Summer School in Oxford in July).
Sean's point was that non-programmers prefer to work as they would with a word processor or a spreadsheet, where they can write the content in any order at all, without the editing software repeatedly beeping at them. So what is needed is an unstructured approach to editing structured data.
Sean's approach was to let users use an unstructured format (e.g. a word processing format), and then convert the unstructured format into a DSL format. During this conversion, any errors (or unconvertible content) are flagged to the user. This doesn't give immediate feedback to the user, but it seems that most users don't want immediate feedback; they would rather just get on with their writing/editing, and then check for issues at the end.
When the DSL is not the editing format, but is used as an intermediate format between the user and the back-end applications that process the DSL format, I call it a Domain Specific Intermediate Language (DSIL). A DSIL is a DSL, but it doesn't have to designed so that users can edit it directly. What is important is that a DSIL is a structured format that is straightforward for back-end applications to process.
I have used the same approach for an application I have written (should be released later this year) which implements the ISO 20022 rules for generating data-oriented W3C XML Schemas from UML models. In my case, UML is the general-purpose format that users edit using a graphical UML editor. The DSIL is a small format described by a W3C XML Schema, not unlike the DSL I created for MDDL. In fact, the FISD is looking at moving to UML as its content editing format for MDDL, in which case the MDDL DSL will become a DSIL.
So why use a DSIL? Two key things. It protects the back-end applications from having to deal with a user-friendly but unnecessarily complex general-purpose editing format. It is much easier to write a back-end application that processes a minimal structured format that is tailored to the task at hand. At the same time, the intermediate format is a filter that makes it straightforward to validate the content that user has edited. Anything from the general-purpose editing format that doesn't fit into the DSIL can be flagged to the user with a warning that something the user wrote is going to be ignored. This feedback helps users to learn quickly which things do and don't work.
In summary, DSILs and DSLs really work. Keep them in mind for your next software application!
RSS 1.0
Follow me on Twitter
Recent Comments