Abstract: Domain-specific techniques provide a high-level specification for software systems. Foundations of the technology have been developed over the last few years. But domain-specific techniques are not a panacea, and deciding whether investment in domain-specific approaches is merited is an important step in understanding how domain-specific techniques can be beneficial.

The landscape of software engineering is littered with languages that were the next great thing, but which failed to take the development world by storm. In contrast, there are many tools that actually have changed the technical space in which certain domains expect to operate. The Simulink and LabView tools are a touchstone for designers in signal processing, and control. SolidWorks is the lingua franca of mechanical engineers and roboticists building physical devices. Embedded hardware developers are passionate about their support of either VHDL or Verilog. Some of these tools use textual languages, while others follow graphical notations.

Most of us outside these domains have never used these tools or languages, and a more than a few of us may never have heard of them. Yet these tools are successful in their niches, because each one satisfies the requirements of its domain, and streamlines development by restricting the user’s input to parameters within the domain while providing easy access to artifacts (e.g., files, plots, generated code) that aid in the design or implementation of these systems.

Domain-specific techniques, languages, tools, models are not new: in fact, FORTRAN and COBOL can easily be viewed as domain-specific languages for scientific and business computing, respectively. Their domain is just very wide. What has changed is the technology for creating DSLs: Now it’s easier to define languages and get tool support for narrower domains: specifying insurance products, or home automation systems. Such focus offers an increase in abstraction, making development faster and easier.

In domain-specific approaches the solution is constructed using concepts that represent things in the problem domain, not concepts of a given general-purpose programming language. Ideally, a DSL follows the domain abstractions and semantics as closely as possible, allowing developers to perceive themselves as working directly with domain concepts. The created specifications may then represent simultaneously the design, implementation and documentation of the system, which can be generated directly from them. The mapping from the high-level domain concepts to implementation is possible because of the domain-specificity: the language and code generators are fit to the requirements of a narrowly defined domain.

Characteristics of problems deserving a DSL&M approach

Here is a checklist for determining whether a problem merits a DSL&M approach.

· Well-defined domain

· Domains with repetitive elements or patterns, such as multiple products or features, targets

· A growing developer community (which usually means a maturing business area and the need for domain-specific notations)

· A clear path from requirements/analysis specification to execution

· Importance of accuracy, expert involvement, and flexibility of the specification; verification and validation of design

· An intuitive or well-accepted representation is already defined

· The implementation or specification must serve as documentation

· The implementation details may be subject to change, but semantics of specification is clear

· Use by a domain-expert (not necessarily a software expert) is intended

· Amortization of effort justifies investment in DSL&M creation

Amortization of effort

Domain-specific languages and models allow raising the level of abstraction to hide today's programming languages, in the same way that today's programming languages hide an assembler. One issue, though, is how much effort goes into developing the domain-specific infrastructure, and how long you can use it with your domain.

When amortizing the effort of using DSL&M solutions, the entire lifecycle must be considered.

· Effort to create and maintain the language and related code generators

· Effort and cost to obtain and maintain tool support for the language

· Effort for domain-experts to learn the language

These are weighed against the following issues:

· Productivity increase compared to general-purpose solutions

· Quality improvement compared to general-purpose solutions

· Number of expected users or implementations

How to leverage benefits

The key way to leverage the benefits of DSL&M approaches is to look out for opportunities to employ them. Refuse the bland conformity of a general-purpose language, and always examine whether there could be a better way to code a specific requirement. If you find that the general-purpose language’s abstractions can’t provide the expressiveness you need, it’s probably because a DSL is trying to get your attention. Similarly, for domain-specific modeling, if you find that you frequently describe your designs using visualizations that are clear to implementers, but are not part of the UML standard, you are itching for a domain-specific solution.

Several tools that are commonly used in DSL&M include

· GME, www.isis.vanderbilt.edu/projects/gme

· GMF, www.eclipse.org/gmf

· LISA, marcel.uni-mb.si/lisa

· MetaEdit+, www.metacase.com

· The Meta-Environment (ASF+SDF), www.meta-environment.org

· Microsoft DSL tools, code.msdn.microsoft.com/DSLToolsLab

It’s often quite easy to design and implement a small domain-specific language from scratch. Scripting languages make it easy to parse a simple line or XML–based format into a general-purpose language (or another DSL), for existing compilers. In the right hands, this approach can be extremely powerful.

Are DSL&M technologies ready for large-scale problems?

Talking about how good a technology could be is nothing compared to showing results. DSL&M solutions are widely used in various domains, including automotive manufacturing , digital signal processing, mobile devices, telecommunication, home automation and electrical utilities with significant results. In terms of quantifiable improvements, Nokia has stated that productivity improvement from coding to DSM is 10x [7], Panasonic has reported 5x improvement [11], Lucent 5-10 fold depending on the domain [10] and empirical studies [8] have reported 3x improvements - with a significance level of 99%.

DSL&M technologies are also qualitatively improving design and implementation, by reducing development resources, increasing capability, and changing how systems interact. This record extends past academic problems, to include large-scale US Government acquisitions [1], automotive [2][5] and avionics [3] software, command and control systems [8], secure networks [9], information-integrated education [4], medical treatment (cite the Sepsis paper from this issue), autonomous vehicle development [6], and many other domains [see 12]. This extends the information technology impact of DSL&M approaches, which has spawned innovations in software product lines.

Not every nail needs this hammer...

...but when DSL&M approaches are applicable, they can have tremendous impact on the cost of developing software and systems. DSL&M technologies are not a panacea, and in many cases the initial effort required to create a DSL&M solution may exceed the effort to apply the general-purpose solution. However, the effort that goes beyond the code’s development, including maintenance and documentation, often outweighs initial cost estimates. While calculating the costs of a DSL&M solution the whole development lifetime need to be considered. Such issues need careful examination, to determine whether the contributions of the DSL&M infrastructure can be amortized past the initial development.

As new application areas embrace the impact of software, there is a need for more and different kinds of nails. This opens the door to different kinds of languages, models, and tools, which can make an immediate impact in the area. Given the low overhead needed to create these kinds of language, it can enable innovative designers to rapidly develop high-impact solutions.

Characteristics of problems deserving a DSL&M approach

Amortization of effort

How to leverage benefits

Are DSL&M technologies ready for large-scale problems?

Not every nail needs this hammer...

More Reading