- 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
Domain-Specific Development
Domain-Specific Development is a way of solving problems that you can apply when a particular problem occurs over and over again. Each occurrence of the problem has a lot of aspects that are the same, and these parts can be solved once and for all (see Figure 1-1). The aspects of the problem that are different each time can be represented by a special language. Each particular occurrence of the problem can be solved by creating a model or expression in the special language and plugging this model into the fixed part of the solution.
)
Figure 1-1 Domain-Specific Development
The fixed part of the solution is written using traditional design, coding, and testing techniques. Depending on the size and shape of the problem, this fixed part of the solution might be called a framework, a platform, an interpreter, or an Application Programming Interface (API). The fixed part captures the architectural patterns that make up the domain and exposes extension points that enable it to be used in a variety of solutions. What makes the approach applicable is the fact that you create the variable part of the solution by using a special-purpose language—a DSL.
As we observed in the introduction, the DSL might be textual or graphical. As the technology for domain-specific development matures, we expect to see tools that support the development and integration of both textual and graphical DSLs. People have a range of feelings about which kind of language they prefer. Many people, for example, prefer textual languages for input, because they can type fast, but graphical languages for output, because it is easier to see the "big picture" in a diagram. Textual expressions make it much easier to compute differences and merges, whereas graphical expressions make it much easier to see relationships. This chapter discusses both kinds, but the first version of DSL Tools and hence the remaining chapters of the book focus solely on graphical languages.
To create a working solution to the problem being addressed, the fixed part of the solution must be integrated with the variable part expressed by the model. There are two common approaches to this integration. First, there is an interpretative approach, where the fixed part contains an interpreter for the DSL used to express the variable part. Such an approach can be flexible, but it may have disadvantages of poor performance and difficulty in debugging. Second, the particular expression or diagram may be fully converted into code that can be compiled together with the remainder of the solution—a code-generation approach. This is a more complex conversion procedure, but it provides advantages in extensibility, performance, and debugging capability.
Graphical DSLs are not just diagrams. If you wanted just to create diagrams, you could happily use popular drawing programs such as Microsoft Visio to achieve a first-class result. Instead, you are actually creating models that conceptually represent the system you are building, together with diagrammatic representations of their contents. A given model can be represented simultaneously by more than one diagram, with each diagram representing a particular aspect of the model, as shown in Figure 1-2.
)
Figure 1-2 Two diagrams and one model