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.

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.

The User Profile Model shown in Figure 1-5 defines user states that affect the behavior of the user interface.

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.

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.

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.

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.

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.

Benefits

Now that we've looked at some examples, we can see the benefits of Domain-Specific Development.

• A DSL gives the ability to work in terms of the problem space, with less scope for making the errors that come from representing it in a general-purpose language.
• Working in terms of the problem space can make the models more accessible to people not familiar with the implementation technology, including business people.
• Models expressed using DSLs can be validated at the level of abstraction of the problem space, which means that errors in understanding or representation can be picked up much earlier in the development lifecycle.
• Models can be used to simulate a solution directly, providing immediate feedback on the model's suitability.
• Models can be used to configure an implementation consisting of multiple technologies of different types, which can reduce the skill and effort required to implement a solution using these technologies.
• Models can also be used to generate other models, and to configure other systems, networks, and products, perhaps in combination with other enabling technologies such as wizards.
• A domain-specific language provides a domain-specific API for manipulating its models, thus improving developer productivity.
• The artifacts generated from a DSL need not all be technological implementation artifacts; a suitable model can be used to generate build scripts, purchase orders, documentation, bills of materials, plans, or skeletons of legal contracts.

In combination, these factors can offer considerable increased agility. For example, in the software defined radio domain mentioned earlier, Bruce Trask reports that "users of the tool report a minimum of 500 percent increase in productivity."

Of course these benefits are not free. To get them, you must invest in designing and building a DSL and integrating it into your overall solution. This will involve the cost of development—which is considerably reduced using DSL Tools. But it will also include costs for testing, deployment, documentation, staff training, development process modifications, and so on. When setting out to implement a DSL you must balance these costs against the expected benefits. You'll get the benefits when the costs can be paid off from the benefits of applying the approach to lots of systems. Hence the approach is particularly attractive to Systems Integrators, who often have to carry out many similar software development engagements for one customer after another. For a small company that does not specialize in particular business areas, it may be worth investing in DSLs that describe technological domains, such as web services and databases; for a larger company that is vertically organized into industry specializations, it may also be worth investing in DSLs that describe corresponding business domains.