Let’s start with an example for a web driven instrumentation. Natural language first.
Given that John has an administrator account
When John logs in
Then John can edit the configuration page
Now let’s look at the same logic using the Coffeescript DSL I have created for uSDLC.
assert administrators contains JohnWhen
browse '/login'enter Name: 'John' Password: 'secret' click 'Log In' Then
click 'Configuration' check title: 'Site Configuration'
Or given that Coffeescript backs the DSL, I could wrap details up in functions and have s result like:
Given John has administrator rights
When we authorize John
Then we can go to the configuration page
So, what is the difference? More than immediately meets the eye. Let’s investigate by discussing benefits and disadvantages of both approaches.
Natural Language Benefits
- concise: most natural languages use fewer words than the explicit definitions required by a DSL.
- open: there are very few limitations in the words or sentence structure. As long as the parser can understand a sentence using regular expressions to extract variable data, then all is good.
- powerful: an internal DSL has all the power of its parent language when it is needed.
- flexible: domain specialists can look at existing statements and work out how to do something similar but different. Also parts of a statement can be used in more than one place.
- detail agnostic: provide behavior level descriptions only or provide more detail if your domain specialists want it.
Natural Language Disadvantages
- inflexible: only the exact statements defined at the developer level can be used.
- limited: to high level behavior descriptions.
- word limitations: internal DSLs must respect the structure of the parent language. I use Coffeescript because it gives me the best compromise available. It still takes effort to not use words like is, if and while out of context. This leads to more stilted sentences when trying for a natural language solution.
I am sure my preference shows – although I was still considering the options when I started this article. Domain specialists and business analysts will have no trouble reading DSL implementations like the first one above. They will appreciate the level of detail they need to be happy the system will work as needed. It is only when we have lots of technical scaffolding, dependency injection, object inheritance and all the other techniques in the software development world that we lose them.
uSDLC currently supports the DSL approach, but I will implement a pattern matching natural language actor in the near future as I see a case for choosing the best for a situation.
I am currently refactoring the uSDLC site to separate ready for use and incomplete features. Once done I will public the examples from this article so that you can see the implementations.