Wolfgang’s presentation is the second one of the day that revolves around DSLs. DSLs have a lot of traction in the configurable applications world – it is not surprising that they get applied to the problem of expressing domain specific rules. Martin Fowler has sites and books on the subject and they tend to be the references.
The attributes of a DSL as viewed by Wolfgang – not a silver bullet, not a free lunch:
- not a programming language
- must be defined as a formal language
- required translation to target system and may not be as powerful and complete as a native language
- may require programming skills to use
- requires development efforts to create and maintain
Wolfgang walks through three different DSL notation cases.
First example: Decision Table
The use case revolves around supporting decisions based on complex settings for railway operation switches. The number of potential states for each one of these entities and the overall combinatorial complexity of the complexity make it very difficult to express the conditions for the logic. Wolfgang’s solution was to use a graphical representation for those states, and to leverage those graphical representations within a decision table notation to express the decision logic.
Second example: Data validation
This is a fairly traditional application of rules. Rules get essentially used to express constraints on data fields, and much more in fact. Rules companies have invested in full blown products supporting this kind of issues.
Wolfgang’s solution is to simply create validation configuration objects for each field, and have a simple rule that takes, for each field, the configuration object, evaluates the corresponding constraint, and triggers the corresponding warning or error message. Users end up using XML or Java in order to express these validation configuration objects.
Third example: Operating rules for a signal box
For this application, Wolfgang leveraged the Drools DSL translator, which uses regular expressions to detect and translate DSL phrases into DRL. The overall structure of the rules is kept, but the sections that matter to domain experts (premises, actions). It’s a simple system that allows Drools user to escape – a little bit – from the low level syntax the standard tool supports.
The DSL Wolfgang ended creating gives the sense of a “natural” language. Of course, building up “natural” language using regular expressions is a major undertaking (to say the least), but Wolfgang focused on a well bounded DSL with a limited set of potential constructs. He immediately hit (and recognized) the issue that the “natural” language in question ends up being too verbose for users that have gone through the initial learning curve: which he solved by starting to reduce the verbosity of the constructs by removing non essential syntax.
Wolfgang guided us through the various rule patterns that his system needs to cover, explaining the details on how he decided on the corresponding DSL and how he implemented used with Drools.
Wolfgang’s conclusion is that the investment in building a DSL to bridge the gap with domain experts is well worth the effort. His view is that “a DSL should always be considered as an option for the implementation of […] a decisioning system”.
Answering a direct question, Wolfgang did explain that the experts did not enter the DSL directly. The users of the DSLs he has created are programmers – they are provided with the possibility to express the logic in a representation that experts can access – although not manipulate – more easily.
Learn more about Decision management and Sparkling Logic’s SMARTS™ Data-Powered Decision Manager
