Finalizing your Language Spec
You finalize your language by formalizing it into a metamodel. The form of the metamodel depends on the DSM tool you use, but at a minimum it should allow you to define the concepts of your language, their properties, the legal connections between elements of your language, model hierarchy structures, and correctness rules. In all but the smallest cases, support for reuse and different model integration approaches is also essential.
Metamodeling simply means modeling your language: mapping your domain concepts to various language elements, such as objects, their properties, and their connections, specified as relationships, and the roles that objects play in them. You will find you can specify some of the language concepts directly and others by combining some domain concepts. In making a decision about which concepts to include, it helps to use your language and generate artifacts from it. Therefore it is best to try out your language immediately after you have defined some of the concepts. Here tools can help you, as ideally they should allow you to focus on language definition only and provide various modeling editors for your language instantly and automatically. This makes language creation agile: you can easily test and learn what the language looks like in practice, how easily it allows you to make and reuse models etc. This really minimizes the risks of making a bad language, or a good language but for the wrong task, and greatly helps in finding good mappings for code generation.
Keeping the language running
Changes to your DSM language will be more norm than exception. Your understanding of a domain, even if you are an expert in it, will improve while you define a language for it. Even after you take your language into use, your understanding of your domain will improve through modeling or from getting feedback from other users of the model. Partly you will understand the domain better, and partly you will see possible improvements for your language.
I believe it is vital for any DSM language creator to be able to make and test a language quickly. You need to be able to focus on making a good language and not be distracted by details of how you need to implement it in a DSM tool. Best is if you can test your language the instant you define it. This makes language creation agile and has a major influence on how quickly you can build the language. More importantly, it improves the quality of your language, and any improvement there will be multiplied many times when developers start using the language.
Giving the language to candidate users early gets them involved and ensures you get feedback early. Just like your domain, your language will evolve over time and you need to be able to adjust it whenever you need to. The moment your language stops evolving is the moment it starts to lose its usefulness.
Freedom of Choice
Defining a whole new language is often considered a difficult task. However, once you realize that it means you get to apply the knowledge you already have about your domain you will perceive this task as considerably easier. DSM means you no longer have to force your application or system designs into several prescribed diagrams or a "de-facto" syntax that does not suit your design requirements, and leaves models as no more than mere documentation. DSM gives you the freedom of choice regarding what design language fits your requirements best at what time.
Besides providing a real opportunity to raise the level of abstraction that developers work on, DSM also allows you, the language definer, to encapsulate your expert knowledge about your evolving domain in the language, so that others automatically follow best practices without having to remember them.
When you give your team a good DSM language, they will become faster and automatically follow best practices. They will not have to learn a third party one-size-fits-all "standard" notation that offers 700 additional concepts to the 100 they might use. Instead, they get to use one that reflects the concepts and rules of the domain they know and already work with. Perhaps most importantly you can move your models from being throwaway documentation of one stage of the design process, to being actual executable specifications. That last part requires defining your code generators, the topic of my next article on DevX.