http://www.spinellis.gr/pubs/jrnl/2009-IEEESW-DSLM/html/SMTS09.htm
This is an HTML rendering of a working paper draft that led to a publication. The publication should always be cited in preference to this draft using the following reference:

Citation(s): 107 (Google Scholar), 63 (selected).

This document is also available in PDF format.

The document's metadata is available in BibTeX format.

Find the publication on Google Scholar

This material is presented to ensure timely dissemination of scholarly and technical work. Copyright and all rights therein are retained by authors or by other copyright holders. All persons copying this information are expected to adhere to the terms and constraints invoked by each author's copyright. In most cases, these works may not be reposted without the explicit permission of the copyright holder.

Diomidis Spinellis Publications


© 2009 IEEE. Personal use of this material is permitted. However, permission to reprint/republish this material for advertising or promotional purposes or for creating new collective works for resale or redistribution to servers or lists, or to reuse any copyrighted component of this work in other works must be obtained from the IEEE.

Guest editors’ introduction

What Kinds of Nails Need a Domain-Specific Hammer?


Jonathan Sprinkle, University of Arizona

Marjan Mernik, University of Maribor
Juha-Pekka Tolvanen, MetaCase
Diomidis Spinellis, Athens University of Economics and Business


 

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.

More Reading

1.     News Release. “Future Combat Systems Program Completes Integrated Mission Test-1”, Feb. 26, 2009. http://www.boeing.com/news/releases/2009/q1/090226b_nr.html

2.     Press Release. “The MathWorks and Vector Integrate Tools for Model-Based Design and AUTOSAR Applications”, Mar. 25, 2009. http://www.mathworks.com/company/pressroom/articles/article33724.html

3.     Schulte, M., "Model-based integration of reusable component-based avionics systems - a case study," Object-Oriented Real-Time Distributed Computing, 2005. ISORC 2005. Eighth IEEE International Symposium on, pp. 62-71, 18-20 May 2005.

4.     Roselli R.J., Gilbert S.B., Howard L., Blessing S.B., Raut A., Pandian P.,  "Integration of an Intelligent Tutoring System with a Web-based Authoring System to Develop Online Homework Assignments with Formative Feedback",  Proceedings of the American Society for Engineering Education Annual Conference, Pittsburgh, PA, USA, July, 2008.

5.     Karsai G.,  "Automotive Software: A Challenge and Opportunity for Model-Based Software Development", Lecture Notes in Computer Science, vol. 4147: Springer, 2006.

6.     Sprinkle J., et al. "Model-based design: a report from the trenches of the DARPA Urban Challenge." Software and Systems Modeling, Online First, 2009.

7.     MetaCase, Nokia Mobile Phones Case Study, 2007. http://www.metacase.com/papers/

8.     Kieburtz, R. et al., “A Software Engineering Experiment in Software Component Generation,” Proceedings of 18th International Conference on Software Engineering, Berlin, IEEE Computer Society Press, March, 1996.

9.     MetaCase, EADS Case Study, 2007. http://www.metacase.com/papers/

10.  Weiss, D., Lai, C. T. R., Software Product-line Engineering, Addison Wesley Longman, 1999.

11.  Safa. L., The Making Of User-Interface Designer, A Proprietary DSM Tool. In Proceedings of the 7th OOPSLA workshop on Domain-Specific Modeling (eds. Sprinkle, J., Gray, J., Rossi, M., Tolvanen, J.-P.), Technical Reports, TR-38, University of Jyväskylä, Finland 2007, ISBN 978-951-39-2915-2

12.  DSMForum, Case studies and examples, www.dsmforum.org/cases.html