HomeBrainDump Build a Domain Specific Language with DSL ...
Build a Domain Specific Language with DSL Tools
This article, the first of two parts, will teach you how to build a visual designer with code generation. You will learn about the files that are used to define the concepts and notation for a Domain Specific Language, and many other details. In the second part, you will put the designer built in this part to work.
For the purpose of this walkthrough, you will use the Domain Specific Language Tools for Visual Studio 2005 to build a graphical designer integrated into Visual Studio for your own domain specific language. The Domain Specific Language Tools ship as a separate download for Visual Studio. The DSL Tools are an SDK that allows you to use Microsoft’s generic modeling platform to build visual modeling tools that run inside of Visual Studio. The SDK contains code generation tools that will generate a running designer based on an XML description.
This lab explores how the Microsoft DSL Tools for Visual Studio 2005 can be used to build a visual designer with code generation. In this lab, you will learn more about the files that are used to define the concepts and notation for a Domain Specific Language, and the process that takes these files and generates a complete Visual Studio designer for that language. You will learn some of the options for defining different aspects of the concepts and notation, and how the notation is mapped to the concepts. You will see the various components that make up a complete Visual Studio designer, how these components are generated from the definition files, and understand how the designer solution is built. Finally, you will run the generated designer, and learn how to generate code and reports from the models that you create with it.
Estimated Time to Complete This Lab
60 Minutes
Exercise 1
Using the Distributed System Designers to Build and Validate Service-Oriented Systems
Scenario
The Sample Domain Specific Language: A Business Entity Language (BEL)
Visual domain specific languages can be used to specify business requirements. A common diagram type used in this area is Business Entity Diagrams. These diagram show the entities involved in a business process. Let’s assume we define a small domain specific language to capture the information we get from a conversation with a subject expert of a banking application.
We define a shape called “Business Entity”. Each entity has a set of attributes. For example, the business entity “bank account” might have attributes like “amount” and “credit line”. Business entities are related to each other, and we represent these relationships by lines between the business entity shapes. For example, the business entity “bank account” will be related to the business entity “customer”.
In addition to the structure of the business entities we define another shape called “business rule”, which captures parts of the business logic. We use the rules to describe how business entities are used together. For example, we have a business entity called “account” and we have a business entity called “transaction”, and we describe the business rules about how a transaction, which involves two accounts, gets approved.
For the hands-on lab we define a very simple version of the Business Entity language. A real production version would of course be much more fully-featured and integrated into the overall development lifecycle. Different artifacts might be generated from the completed language, including database definitions, message formats, and user interfaces for the business entities, and skeletons for business logic from the rules. In the lab you’ll see how to use the business entity model to generate a simple HTML report and a WinForms-based user interface.
The domain model that the DSL tools wizard has put into your solution is a nearly empty one and looks like this:
The shapes in the domain model describe classes, and the lines between them describe relationships.
In order to allow you to finish the lab in the allotted time, we are going to load in a prepared domain model for the business entity designer.
Close the domain model by clicking on File | Close
In the Solution Explorer, right-click on the DomainModel project, and choose Add->Existing Item.
Set the Files of Type: filter to All Files.
In the File Name: box, type c:\dsl\BizEntity.dmd. Click the Add button.
Confirm you want to replace the existing file.
In the Solution Explorer, double-click on the BizEntity.dmd file you just added, which will be located in the DomainModel project. The domain model will look like this:
This diagram defines the structure of the domain model, which is made up of classes (grounded rectangles) and relationships between classes (lines). To get a better idea of what this notation means, let's take a closer look at the Entity class:
Open up the Entity shape by clicking on the little "+" sign. Note: three "Entity" shapes appear in the diagram because the Entity class is referenced by other classes; the shape you should click on is in the lower portion of the diagram, indicated by the red arrow in the image above.
Here we see that classes may contain value properties. The "Entity" class has two value properties, "Kind" and Description". You can click on the value properties to see details about them in the Properties window in the lower right corner of Visual Studio.
An entity may reference another entity. This is indicated by the dotted line labeled “ReferencedEntity”. You can select the relationship in the diagram by clicking on the dotted line to see its details in the Properties window again. Notice that the name of this relationship is “Association”; the names of its two roles (ends) are ReferencedEntity and ReferringEntities. The roles are represented in the diagram by the small triangular and rectangular shapes appearing on the line. You can also click on these to view properties about them.
An Entity contains Attributes. This containment is indicated by the solid line between the “Entity” class and the “Attribute” class, labeled “Attributes”. You can open up the Attribute shape and have a look at its value properties.
The notation which will be used in the designer for our domain specific language is described in a XML file. As with the domain model the black solution contains a default description, and for this lab we will load a prepared file to save time.
To have a look at the default XML file that was generated from the blank language template, click on the "BizEntity.dsldd" tab on the main window of Visual Studio. You'll notice that it refers to the classes from the original domain model, such as "ConceptA".
Close this file by clicking on File | Close
In the Solution Explorer, right-click on the Designer project, and choose Add->Existing Item from the context menu.
Set the Files of Type: filter to All Files.
In the File Name: box, type c:\dsl\BizEntity.dsldd. Click the Add button.
Confirm you want to replace the existing file.
Double-click on the BizEntity.dsldd file you just added, to open it in the XML editor. The file will be located in the Designer project in the Solution Explorer.
The first function of the dsldd file is to define the notation for our designer. This notation can include shapes which appear in the toolbox and can be dragged onto the design surface, connector lines which connect shapes, and more. To make this a little more concrete, let’s look at an example from our “BizEntity” domain. In the XML editor, browse down until you see a section marked with the <shapes> tag (line 185, about three quarters of the way through the file).
We won’t go into too much of the detail of this format in the lab, but notice that we define two shapes, a “BusinessRulesShape”, and an “EntityShape”. Note that the second shape is defined using the <compartmentShape> tag, because we want it to have a sub-compartment for displaying the attributes defined on the entity.
The second function of the dsldd file is to map the designer notation onto the domain. In general, this involves mapping shapes to classes and connector lines to relationships, so that as a user creates shapes and connectors in the designer, they are also creating the corresponding classes and relationships in the domain. Again, let’s look at the “BizEntity” example. Navigate to the <shapeMaps> tag in the XML editor, line 74, about one-third of the way through the file.
Notice the <class> element defined as a child the <shapeMap> element. This specifies the class in the domain model which the shape maps to. In this case it is the “Entity” class.
Skip the <compartmentMaps> and <iconMaps> sections for the moment.
Notice the <melCollectionExpression> element defined beneath the <iconMaps> element. This specifies a role in the domain model that an entity must play in order to have a shape created for it. Another way to think of this is that it is specifying the location in the domain model we can find the “Entity” classes we want to map to. In our case, we specify the “ER/Entities” role, which indicates that we want to create an “EntityShape” for all “Entity” instances in the model which are connected to the root element of our domain, which is named “ER”.
Notice the <shape> element defined beneath the <class> element. This specifies the shape in this mapping, in this case the “EntityShape”.
Finally, the <textMaps>, <comparmentMaps>, and <iconMaps> sections map parts of the domain model to text, compartments, and icons which appear on a shape. Notice the use of <expression> elements within these sections to define the mappings.
Because we have modified the domain model and notation, we must now regenerate code and build the solution in order to update the designer. First, there is one more file that needs to be added to the solution, which contains some required strings and icon resources used by the designer.
In the Solution Explorer, right-click on the Diagram folder in the Designer project, and choose Add->Existing Item.
In the File Name: box, type c:\dsl\BizEntityDesigner.Resource.resx. Click the Add button.
Confirm that you want to replace the existing file.
Now we are ready to generate code and build.
Click on the Transform All Templates button in the toolbar (shown below circled in red). Note that this command may take a little while to complete.
Now build the updated solution, by selecting the Build Solution command from the Build menu. Note that this command may take a little while to complete the first time.
Issue: There is a known issue which causes code generation to fail every so often. If you see failures in either the code generation step or the build step, try repeating these steps again.
BrainDump 
/ 10 
Build a Domain Specific Language with DSL Tools concluded
