Steve Cook is a software architect for Microsoft, Gareth Jones is a professor of management at Texas A&M University, Stuart Kent is a program manager at Microsoft, and Alan Cameron Wills is technical director of TriReme International. This article was excerpted from their book Domain-Specific Development with Visual Studio DSL Tools. Copyright (c) 2007 Addison Wesley Professional. All rights reserved.
After designing and using a Doman-Specific Language (DSL) for a while, you will inevitably want to change it, and you will not want to lose the language instances that you have already created.
Changes in a DSL take one of the following forms:
- Additions. New properties in a class or relationship; new classes; new relationships. The deserializer will take care of these, filling in default values when reading objects from older files.
- Deletions. Properties, classes, or relationships removed. In this case, the deserializer will ignore the deleted elements.
- Refactoring. A structure is replaced by something that represents the same information in a different way. For example, we might replace the Issue State Transition by a class with a pair of relationships on either side. Here, the deserializer will see some additions and some deletions but will not be able to do the translation automatically. Changes of property and relationship types come under the refactoring heading.
Of these, the language author needs to worry about refactorings. The following tactics mitigate the pain of change to some extent:
- Separate refactorings. Identify and localize each refactoring, and plan separately how you will deal with each one. For example, one version change of the Issue State DSL might introduce a domain class to replace the Transition relationship, and might also introduce multiple issue types per project. As far as possible, we should keep those changes independent of each other.
- Don't delete anything. Instead of deleting the old structure, just add the new one; for example, have both the Transition relationship and the domain class replacing it coexist in the same model. Deprecate the old structure by removing its tools from the toolbox, and any merge directives or connection builders that might deal with its creation, so that new instances can't be created. Then use one of the tactics that follow this one.
- Ensure the tools work with both structures. During a migration period, ensure that the generating templates and other tools can work with both structures as much as possible. If the change is prompted by a changed requirement in what the tools generate, at least allow language users to edit and work with the old instances until they need to generate material from them.
- Provide translation tools. One way is to provide a command that scans a store and updates the model in place. It is possible to make this happen on opening a file of an older version. Another convenient method of translating instance models is to write a generating template that creates the serialized form of the new version of the DSL from models of the older version. XSLT can also be used to translate one model file into another, given that they are both XML files.
- Validate required fields. If you translate on opening an old file, make sure that your validation methods check any new fields so that the user is prompted to provide the required extra information.
- Delete obsolete domain classes when you're sure all the instances are updated.
- Publish the update plan to your language users so that they know when older structures will be obsolete.
Migration between language versions is an important and common problem. Having a forgiving file reader (deserializer) certainly relieves some of the pain, but you could do more. It is possible to conceive of tools that automate some of the above tactics. For example, one could maintain the history of changes to a domain model between versions and then use this information to generate a tool that does the conversion automatically.
