Now that you've installed the DSL tools, it's time to create a sample domain specific language.  The first step is to create the domain model.  The domain model represents classes that will be generated by a user of your domain specific language designer.  These classes are used in the templates to drive code generation.

In order to allow us to focus on the specifics of the DSL tools, I've created a very simple example.  This DSL will allow developers to build a simple guessing game.  The developer will specifiy a start-up step, followed by one or more hints or guess steps.  So, with this DSL, a developer could create a program where all the user does is guess, where they are given a hint and then an opportunity to guess, where they guess, and then if they are wrong, are given a hint, etc.  In the future, I will discuss examples that represent real business problems.


When creating the domain model, the first step is to define the classes.  You will have one class for each item which can be placed on the design surface.  This means that we need classes for SetUp, Hint and Guess.  In addition, we need a parent class which will contain all of the other classes.  You can think of this class as representing the diagram itself.  We will use Game for this class.  Right-clicking on this class and selecting "Make XmlRoot" tells the designer that this class is the parent class for the diagram.

Finally, you'll notice that Guesses and Hints can be used interchangeably.  SetUp can be followed by a Guess or a Hint.  A Guess or a Hint, itself, can be followed by another Guess or a Hint.  In other words, both Guess and Hint are an example of a more general game move.  We will therefore create a class called GameMove.  This way, we can refer to this class wherever we mean "Guess or Hint".

(Note:  One trick in working with the tools is to pick names that aren't likely to be used by the code that is automatically generated.  Move is a common method name, so the class name I chose was GameMove.)


Next we need to create the relationships between our classes.  The domain model designer supports three types of relationships: Embedded, Inherited and Reference.  We will use each type.


We use the embedded relationship to connect the classes which will be displayed in the designer to the parent class.  So, we will create an embedded relationship between Game -> Setup and Game -> GameMove.

- Inherited

We use the inherited relationship to show that Guess and Hint are both GameMoves. 

- Reference

The reference relationship corresponds to the lines we will draw in our finished designer.  We can draw a line between SetUp and a Guess or Hint, and between a Guess or Hint and another Guess or Hint.  This means that we need to create a reference relationship between SetUp -> GameMove and GameMove -> GameMove


On the same tab as Solution Explorer, there is a new tool called Domain Explorer.  We will use this tool to make a couple of necessary property changes.

When a shape is going to be dropped onto the design surface, the role associated with the embedded relationship between the shape's class and the parent class needs to have the "Accepts" property set to all.  Change this property on:



When you created the reference relationship between GameMove and itself, a role named GameMove was created. This creates a reference property in GameMove which is also called GameMove.  This double naming is not allowed and will generate an error.  So, the role needs to be renamed.  While we are at it, we will rename the GameMove1 role:

GameMoveHasGameMove\GameMove -> Target

GameMoveHasGameMove\GameMove1 -> Source

Finally, in order for relationship references to map to lines in our DSL designer, both roles in the relationship need to be property generators.  This property is not set by default on the reverse role.  So, set this property to true in:




At this point, you have completed the domain model.  It won't compile yet because you still need to update the XML fle associated with the diagram itself.  I will describe how to do that in the next post.  In the meantime, if you want to see the completed domain model, you can create a new DSL project named GuessingGame1, with a file-extension of .gg1.  You can then right-click on DomainModel.dsldm, open it with the XML editor, and then copy and paste the code from here.