DomainSpecificLanguages
From SPA Wiki
Original abstract at 3
Some interesting points that came up, one way or another, in the discussion and exercises:
- DSLs and Software Product Line techniques are good for the architecture of a large system even if it isn't a product family:
- Inventing a language helps componentize an application. The way you divide up an application into pluggable components is different, when you're trying to make it generic, than when you're just trying to split a large design into modules. Thinking of the language first helps you do that.
- SPLs reduce dependencies between applications and components, thereby turning large projects into multiple smaller and independent ones (unlike conventional modularization, which leaves strong dependencies of overall design on component designs).
- Because within a specific domain, the solutions are generally well mapped out, it is sufficient for a DSL to talk about the requirements rather than the solutions. The generator/interpreter can select solutions matching the requirements. (E.g. you don't have to understand database implementation (much) to write SQL.)
- A DSL statement -- for example the phone billing example -- might cover multiple substantial parts of a business domain employing multiple machines, and might include some manual processes. Generating software from it is just one thing you could do with it. Ordering the hardware and configuring staff training manuals might be others; as well as creating animations for prototyping purposes.
- MDA (tm) doesn't cover the use of models for non-software purposes. (Andrew Watson was asked about this in another session, and stuck to the purely software line.)
Designing a DSL :
- It's important to think of your language as such from the beginning -- too many projects have started with a table of configurable parameters which has been extended and extended, and become a mess. Sendmail was an example.
- People generally design languages by first inventing sample statements, then abstracting the grammar.
- Most people find it easier to invent a draft concrete syntax first, then abstract; but of course it's also possible to write an abstract model and then clothe it in concrete syntax. The two techniques can be parallel and complementary.
- First write down the points of variability between members of the family of products (or business domains).
- Common pitfall: write sample statements that describe what's common to all specializations of the product family; rather than statements that distinguish one member from another.
- Common pitfall: degenerate into tables.
- There may be a relationship between the DSL and the language used in the GUI to report the state of the system. For example in railway control, the plan of the lines, switches and signals would be an input to software generation; it would also be the basis of the plan seen by the controllers at runtime.
- UML (with suitable icons) covers the syntax of many of the diagrams that are mostly used. Not sure about grammars.
- Languages come with tools: editors, checkers, animators, generators, debuggers.
- Most models will be partial, expressing the point of view of one class of user requirements from particular sources, often expressed in their own terms -- legal & regulatory constraints, main users, monitoring and admin, ... different kinds of requirement: functional, deployment, performance, .... These models can be composed at the implementation level; but it's much more useful if they can be composed at the more abstract level, and tested for consistency at that level.
See also articles in
Back to OtTwoThousandAndFourOutput.
