This chapter is from the book
This chapter is from the book
This chapter is from the book
Graphical DSLs
So far we have looked at some of the background behind Domain-Specific Development and discussed its benefits. We have also looked briefly at textual DSLs. Let's start our exploration into graphical DSLs by looking at an example that captures data for deploying and managing distributed applications.
Figure 1-10 shows a simple model built using a graphical DSL for designing logical data centers. This DSL is part of Visual Studio 2005 Team Architect. The elements of this language include zones, depicted by rectangular areas surrounded by dashed lines; hosts, depicted by rectangular areas surrounded by solid lines; endpoints, depicted by small shapes (squares, circles, and hexagons) placed on the edges of hosts; and connections, depicted by arrows between endpoints. This model corresponds exactly to an XML file that contains information according to the rules of the System Definition Model (SDM), which is used for configuring and managing data centers.
)
Figure 1-10 Data center design
We can build up graphical DSLs like this one from a set of simple diagrammatic conventions such as the following. Many of these conventions are derived from UML, which we discuss in more depth later.
Conventions for Representing Structure
See Figure 1-11 for examples of structural conventions, including:
- Nested rectangle or rounded rectangles, to represent structural containment
- Rectangles with headers, sections, and compartments, to represent objects, classes, entities, devices, and so on
- Solid and dashed connectors with multiplicities, names, arrowheads, and other adornments, to represent relationships, associations, connections, and dependencies
- Connectors with large open triangular arrowheads, to represent generalization, inheritance, and derivation
- Ports on the edges of shapes, to represent connectable endpoints
Figure 1-11 Structural conventions
)
Conventions for Representing Behavior
See Figure 1-12 for examples of behavioral conventions, including:
- Lifelines and arrows, to represent sequences of messages or invocations with a temporal axis
- Rounded rectangles, arrows, swimlanes, diamonds, transition bars, and so on, to represent activities and flows
- Nested ovals and arrows, to represent states and transitions
- Ovals and stick people, to represent use cases and actors
)
Figure 1-12 Behavioral conventions
Using the DSL Tools, it is possible to build your own graphical language that combines conventions like these in a way that matches your particular problem (although version 1 of the Tools does not fully support all of the conventions listed). You can map them onto the concepts of your own domain and construct a customized graphical modeling language that solves your own problem. We saw an example in the data center design language shown in Figure 1-10, and we'll see many other examples as we proceed.
Building your own graphical language on top of a given set of notational elements and conventions is analogous to building an embedded textual DSL, where instead of writing type wrappers and methods to make the language convenient to your domain, you define a mapping from the notational elements to your own domain concepts. If you want to define a graphical language that uses different notational elements and conventions, you have to be more expert and know how to create new diagrammatic elements from lower-level constructs. This is analogous to building your own parser for a textual DSL.