- Introduction
- Domain-Specific Development
- Examples
- Benefits
- Languages
- Textual DSLs
- Graphical DSLs
- Aspects of Graphical DSLs
- DSLs in Visual Studio
- The Customization Pit
- UML
- Summary
This chapter is from the book
This chapter is from the book
This chapter is from the book
Aspects of Graphical DSLs
A graphical DSL has several important aspects that must be defined. The most important of these are its notation, domain model, generation, serialization, and tool integration.
Notation
In the previous section we talked about the notation of the language and how it can be built by reusing basic elements, often derived from well-established conventions, particularly those that originate in UML. For the kinds of graphical DSLs that we support, the basic building blocks are various kinds of shapes and connectors laid out on a two-dimensional drawing surface. These shapes and connectors contain decorators, which are used to display additional information such as text and icons attached to the shapes and connectors in particular places. In Chapter 4 we'll see full details of how to define these shapes and connectors and how to associate them with the other aspects of the language.
Domain Model
The domain model is a model of the concepts described by a language. The domain model for a graphical language plays a rather similar role in its definition to that played by a BNF grammar for a textual language. But for graphical languages, the domain model is usually itself represented graphically.
The basic building blocks for a domain model are domain classes and domain relationships. Each domain class represents a concept from the domain; each domain relationship represents a relationship between domain concepts. Typically, domain concepts are mapped to shapes in order to be represented on diagrams. Domain relationships can be mapped to connectors between those shapes or to physical relationships between shapes, such as containment.
Another important aspect of the domain model is the definition of constraints, which can be defined to check that diagrams created using the language are valid. For example, the class diagram in Figure 1-13 uses the correct diagrammatical conventions but defines a cyclic class hierarchy that is semantically invalid. Chapter 7 describes how to define constraints in the DSL Tools and discusses the differences between hard and soft constraints.
)
Figure 1-13 Invalid class diagram
Generation
You define a language because you want to do something useful with it. Having created some models using the language, you normally want to generate some artifacts: some code, or data, or a configuration file, or another diagram, or even a combination of all of these. You'll want to be able to regenerate these artifacts efficiently whenever you change a diagram, causing them to be checked out of source control if necessary.
Chapter 8 explains the DSL Tools generation framework, which enables the language author to define how to map models into useful artifacts.
Serialization
Having created some models, you'll want to save them, check them into source control, and reload them later. The information to save includes details about the shapes and connectors on the design surface, where they are positioned, and what color they are, as well as details of the domain concepts represented by those shapes.
It's often useful to be able to customize the XML format for saving models in order to help with integrating these models with other tools. This flexibility increases interoperability between tools and also makes it possible to use standard XML tools to manage and make changes to the saved models. Using an XML format that is easy to read also helps with source control conflicts. It is relatively straightforward to identify differences in versions of an artifact using textual differencing tools and to merge changes to artifacts successfully at the level of the XML files.
Chapter 6 explains how to define and customize the serialization format for a graphical DSL.
Tool Integration
The next important aspect of a graphical DSL design is to define how it will show up in the Visual Studio environment. This involves answering questions such as:
- What file extensions are associated with the language?
- When a file is opened, which windows appear, and what is the scope within Visual Studio of the information that is represented?
- Does the language have a tree-structured explorer, and if so, what do the nodes look like—with icons and/or strings—and how are they organized?
- How do the properties of selected elements appear in the properties browser?
- Are any custom editors designed for particular language elements?
- What icons appear on the toolbox when the diagram is being edited, and what happens when they are dragged and dropped?
- Which menu commands are enabled for different elements in the diagram and the associated windows, and what do they do?
- What happens if you double-click on a shape or connector?
Chapters 4, 5, and 10 describe how to define these behaviors and show ways of customizing the designer by adding your own code.
Putting It All Together
From the previous sections you can see that there are a lot of aspects to defining a DSL. This might seem rather daunting. Thankfully, the DSL Tools make it easier than you might think. Many of the aspects are created for you automatically, and you only need to worry about them if you want to change the way that they work. Complete languages are provided as starting points so that you don't need to start from scratch. Having defined your DSL, the DSL Tools are also used to generate code and artifacts that implement, test, and deploy the DSL as a designer fully integrated into Visual Studio. If you want to step outside of the set of features easily supported by the DSL Tools, we've provided many code customization options for that purpose.
The DSL Tools have even been used to define and build themselves. The DSL designer that is used to define domain models and notations is itself a DSL. Just like a compiler that can be used to compile itself, the DSL designer was used to define and generate itself.