This chapter is from the book
This chapter is from the book
This chapter is from the book
Examples
Let's first have a look at a couple of examples where the DSL Tools have been applied in practice. The first example comes from an Independent Software Vendor (ISV) called Himalia. Himalia has created a set of DSLs for implementing complex graphical user interfaces without doing any coding. The Himalia Navigation Model, shown in Figure 1-3, defines the navigation through the user interface.
)
Figure 1-3 Himalia Navigation Model
Use Cases, regarded as heavyweight flows of control consisting of activities and transitions, are explicitly defined in a state machine view in order to address their complexity. Use Case states and transitions are related to Navigation Model elements and actions, respectively. The Use Case Model is shown in Figure 1-4.
)
Figure 1-4 Himalia Use Case Model
The User Profile Model shown in Figure 1-5 defines user states that affect the behavior of the user interface.
)
Figure 1-5 Himalia User Profile Model
The complete Himalia system integrates these models with others into Visual Studio 2005 to implement complete user interfaces based on Microsoft technology, including Windows Presentation Foundation (WPF).
The second example is a Systems Integrator (SI) called Ordina that is based in the Netherlands. Ordina has built a complete model-driven software factory within its Microsoft Development Center, called the SMART-Microsoft Software Factory. This factory uses four connected DSLs. To enable these DSLs to collaborate, Ordina has created a cross-referencing scheme that allows elements in one DSL to refer to elements in another DSL.
The Web Scenario DSL is used to model web pages and user actions, and to generate ASP.NET web pages. An example is shown in Figure 1-6.
)
Figure 1-6 Ordina Web Scenario DSL
The Data Contract DSL is used to define the data objects that are transferred between the different layers in the architecture. An example is shown in Figure 1-7, which illustrates several different kinds of data objects.
)
Figure 1-7 Ordina Data Contract DSL
The third DSL in the Ordina factory is the Service Model shown in Figure 1-8, which is used to generate service interfaces and skeletons of the business processes that implement the services.
)
Figure 1-8 Ordina Service DSL
The final DSL in the Ordina factory is the Business Class Model that is used to generate code for the Business Class and Data layers. This model is shown in Figure 1-9.
)
Figure 1-9 Ordina Business Class DSL
These two examples from Himalia and Ordina are for "horizontal" DSLs, where the intended customer for the resulting software does not belong to any particular industry. Here are some other more "vertical" examples of where domain-specific development might be applied.
Software Defined Circuitry
Many electronic products have circuitry that is programmed using software. For example, FPGAs (Field Programmable Gate Arrays) are programmable chips used in areas such as software defined radio, digital signal processing, medical imaging and speech recognition. Programming such chips directly in their Hardware Description Language (HDL) is a very low-level and painstaking task. A Domain-Specific Development approach can be used to raise the level of abstraction until it represents much more directly the domain being implemented; for example, a DSL approach to software defined radio is discussed in the paper by Bruce Trask of PrismTech at www.mil-embedded.com/articles/authors/trask/.
Embedded Systems
Many real-time embedded systems can be conceptualized as a set of communicating finite state machines. Separating the design of these systems into explicit state machines, plus a generic platform for executing state machines, can greatly simplify thinking about such systems. In this case, the DSL is the language for expressing state machines consisting of states and the transitions between them, while the execution platform is most likely built using custom code.
Device Interfaces
Many modern devices, such as mobile phones, HiFi equipment, and so on, have complex user interfaces. These interfaces are typically organized via rules that make the interface predictable, such as a rule that pressing a cancel button always takes you back to a known state, or inputting text always follows the same set of predictive rules. A DSL can be created for designing such systems, where the graphical appearance of the language corresponds accurately to the appearance of the actual interface being designed, and the interaction rules of the interface are captured in the structure of the language. Good examples of this approach can be found at the Domain-Specific Modeling Forum website at www.dsmforum.org.
Software Development Process Customization
The example that is used throughout this book to illustrate the DSL Tools shows how to use DSLs to define aspects of a software development process, such as the processing of bugs and issues, and how to use the models to configure the tools used to enact the process.
All of these examples and many others share the same approach: (1) identifying aspects of the problem that are fixed for all occurrences and capturing those aspects in a common framework or platform, and (2) identifying the other aspects that vary between occurrences and designing a Domain-Specific Language whose expressions or models will specify a solution to the problem.