14 Mit einer DSL arbeiten customer -facing developer customer tablet PCprospectinitiatedprospective saleemptyoverflowSatweeklyaccumulator4£201 week delay£30cancelssalesperson’saccount31monthlybank a/cpay7animatorprototype for reviewcustomertablet PCgeneratorphone billsystemcustomer-facingdeveloperHere’s part of how we envisage a domain specific language being used.(This is a big topic! In fact, DSLs are just part of the Software Factory story. See the book by Jack Greenfield and Keith Short.)Firstly, DSLs enable us to develop some of our system with the customer. The DSL is based on notations they use within their branch of engineering or business. The customer-facing developer – what we might have called an analyst in the past – has the role of gathering the customers’ requirements statements, ensuring the customers understand their consequences, and making a consistent story out of them. We now provide this developer with an extra tool: one that helps express some aspects of the requirements and a high-level design.[click] One of the analyst/developer’s tools could be an animator that takes the model and runs a simulation or prototype – the best form for this would depend on the domain. This takes the development process rapidly round the requirements development loop, so that the customers gain a clear idea of what they will get, at an early stage.[click] One of the advantages of restricting our language to a particular domain is that it’s easier (than with general purpose specification languages) to generate executable code from a pure requirements statement. This is because there are well-understood implementation patterns within the domain. Consider for example SQL, a language specific to the horizontal domain of database management. Writers of SQL have to understand what the database does, but need know nothing of how the DBMS works internally. The language just expresses the semantics of a database query, but there’s no problem in executing it.[click] In general, a generator (or interpreter) is taking the DSL statement and using it to parameterise a generic implementation. So we could imagine that our phone-bill-software company develops its generator by generalizing one of its pre-existing billing systems. But one of the differences between long-established horizontal DSLs and the kind of in-house DSL that we envisage, is that the latter is unlikely ever to reach a point of being finalized: as the company’s market shifts, so must the language and its implementations. So we’re unlikely ever to produce a complete phone bill system just by pressing the button in the evening after the models have been drawn with the customer. Rather than tweak the end-result of generation, however, we should always tweak the generators themselves. That way, we avoid having to re-tweak every time the model is adjusted; and we stand some chance of generalising our tweaks to improve the generator for future uses.If you already have an existing system that is parameterised with a configuration file, then it’s not difficult to imagine a generator creating the config file from a model.tweakhack

15 DSL-Output list of parts business plan prototype for review animatorprospectinitiatedprospective saleemptyoverflowSatweeklyaccumulator4£201 week delay£30cancelssalesperson’saccount31monthlybank a/cpay7generatorlist of partsgeneratorbusiness planprototype for reviewanimatorgeneratorphone billsystem[click] We don’t just have to generate single files here of course. All sorts of configuration files etc can be created from the same model.And we’re not just talking about software of course:[click] Lists of hardware parts for the installation …[click] An intranet website for your customer telling their employees how they’re going to migrate to the new system …C#XMLC#, JavaSQLmixed codeand configfiles