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): 5 (selected).

This document is also available in PDF format.

The document's metadata is available in BibTeX format.

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

Reliable software implementation using domain-specific languages

Diomidis Spinellis
Department of Information and Communication Systems
University of the Aegean


The safety and reliability of products, processes, equipment, and installations is often critically affected by the software that controls their design and operation [WCD+98]. Software engineering stands out among other engineering disciplines because of its tight, haphazard, and fluid coupling with other elements of its operating environment. Mechanical, civil, or electrical engineers can base their designs on standardised and well understood specifications and constraints, and can design their implementations based on materials and components of known modalities and properties. In contrast to that, software engineers have to rely on specifications often expressed in the notation most suited to the application domain, design an artefact whose application changes significantly the environment it was designed for [Leh91], and rely on implementors whose output quality can vary up to a factor of 10 [SEG68]. These problems are of particular importance for safety critical applications where human life can be put at risk from malfeasant software designs and implementations.

Our approach for overcoming those problems is a software process architecture based on domain specific languages (DSLs). These allow the specification of critical parts of a software subsystem in the most appropriate formalism for the application domain, thus bridging the gap between the domain expert specifications and the software implementation, providing maintainability, and -- once a particular DSL has been correctly implemented -- ensuring consistent quality throughout the system's lifecycle. In the following paragraphs we illustrate this concept by detailing the usage of DSLs in the design and implementation of a civil engineering CAD application. The application is typical for the class described so far: it embodies a large amount of domain knowledge and its failures can lead to reliability and safety problems.


A domain-specific language (DSL) [USE97] is a programming language tailored specifically for an application domain: rather than being general purpose it captures precisely the domain's semantics. Examples of DSLs include lex and yacc [JL87] used for program lexical analysis and parsing, HTML [BLC95] used for document mark-up, and VHDL used for electronic hardware descriptions. Domain-specific languages allow the concise description of an application's logic reducing the semantic distance between the problem and the program [BBH+94,SG97].

Figure 1:  UML diagram of a DSL-based system architecture.

DSLs are, by definition, special purpose languages. Any system architecture encompassing one or more DSLs is typically structured as a confederation of modules; some implemented in one of the DSLs and the rest implemented using a general purpose programming language (Fig. 1). As a design choice for implementing safety-critical software systems DSLs present two distinct advantages over a ``hard-coded'' program logic:

Concrete Expression of Domain Knowledge
Domain-specific functionality is not coded into the system or stored in an arcane file format; it is captured in a concrete human-readable form. Programs expressed in the DSL can be scrutinised, split, combined, shared, published, put under release control, printed, commented, and even be automatically generated by other applications.
Direct Involvement of the Domain Expert
The DSL expression style can often be designed so as to match the format typically used by the domain expert. This results in keeping the experts in a very tight software lifecycle loop where they can directly specify, implement, verify, and validate, without the need of coding intermediaries. Even if the DSL is not high-level enough to be used as a specification language by the domain expert, it may still be possible to involve the expert in code walkthroughts far more productive than those over code expressed in a general purpose language.


FESPA for Windows [LH 98] is an integrated software system used to analyse, dimension, display, verify, and draw three dimensional building structures (Fig. 2). A building is designed along the following steps:
specification of the building in terms of slabs, pillars, bars, and other nodes,
template-based production of additional floors,
calculation of pillar loads and creation and dimensioning of the building foundations, footings, and connecting rods,
solution of the space structure and plotting of member distortions, forces, and moments,
calculation of section reinforcements, and
derivation and plotting of the wood mould.
All calculations described above are based on hundreds of parameters that determine inter alia the material and ground properties, the expected seismic environment, and the building's intended usage.

Figure 2:  FESPA for Windows featuring a building overview and a three dimensional model displaying beam tension moments.


Around 5% of the 210000 lines of code representing the user interface of FESPA are written in one of the ten DSLs designed for concretely expressing important elements of the system's specification.

This concept can be illustrated considering the specification of the system's entity properties. Every one of the 42 different entities (such as slabs, beams, pillars, etc.) has a set of properties associated with it. In total 1181 properties have to be specified. The type of each property, the permitted value range, and the set of allowable values form important parts of the specification, have little meaning for the software implementor, and are critical for the reliable and safe operation of the system; a situation which calls for the application of a DSL. A language was designed to bind together the type of every parameter, the name presented to the user, the associated variable and function call-backs within the program, the value range, explanatory diagrams, and the selection values.

Figure 3:  DSL specification of building parameter properties.
#define SL_STEEL 220:500:220;400;420;500
big_pressure:Rod stirrup steel:rod_steel_stirrup:-:regulation_new:SL_STEEL

Figure 4:  Domain-expert view of building parameter properties.

Thus, DSL expressions of the form shown in Figure 3 are presented to the domain expert (civil engineer) in tabular form as exemplified in Figure 4 and are compiled into efficient C++ code for incorporation into the CAD system by a small DSL compiler coded in Perl [WS90]. The presentation of values illustrated above allows the domain expert to directly specify and verify important aspects of the system's implementation without relying on intermediaries.

A similar methodology was followed for expressing other elements of the system's operation. Representative examples include the specification of the system's:

The grouping, functionality, and explanatory details of the 450 available commands.
The functionality, icons, and explanatory details of the system's toolbars.
The names, associated commands, allowable execution context, and initialisation sequence for the system's menu structure.
The specification of the report generator.
The grouping, functionality, and interactions between the system's 68 layers of entities.
Data allowing the automatic persistent storage of the user property selections within the data files. The input source for this DSL is actually a suitably annotated version of the system's source code.

Figure 5:  Size metrics of the system's DSL-based implementation

For every one of the above DSLs we implemented a specialised compiler which read its domain-specific input source and transformed it into efficient C++ code. The relationship between the lines of code needed to implement the compiler, the domain-specific data, and the resulting target code is illustrated in Figure 5.


The object of a DSL-based software architecture is to minimise the semantic distance between the system's specification and its implementation. Although the concept bears similarity to executable specification languages [Som89, p. 125], [TM87, p. 135] such as [PH95] the DSL approach exhibits some important advantages:

Executable specification languages taking a Swiss army knife approach towards the problem of specification offer facilities for specifying all types of systems, but often at a cost of clearness of expression. As an example OBSERV [TY92] provides a multiparadigm environment allowing the system specification using object-oriented constructs, finite state machines, and logic programming. In contrast, DSLs being tailored towards a narrow, specific domain can be designed to provide the exact formalisms suitable for that domain.
Runtime Efficiency
The possible interactions between different elements of a general purpose specification language such as its type system and its support for concurrency result in runtime inefficiencies. A narrowly focused DSL can employ the most efficient implementation strategy and specialised optimisations for satisfying the expressed specification.

Modest Implementation Cost
DSLs are typically implemented by a translator that transforms the DSL source code into source or intermediate code compatible with the rest of the system. All DSL translators we used in the FESPA for Windows implementation transform DSL source code into C++ source code. Such an approach can often be implemented using string processing languages such as awk [AKW79] and Perl, language development tools such as lex and yacc, specialised systems such as TXL [CHHP91] and KHEPERA [FNP97], or declarative languages such as Prolog and ML. The DSL implementation cost is -- and should always be -- modest; in our case we implemented ten DSL translators in a total of 4000 lines of Perl.

As described in the previous paragraph, the limited scope of a DSL often allows a source-to-source transformation type of implementation. The small scale of the required implementation effort often results in a translator whose correctness can be trivially verified. The size of typical executable specification languages means that the implementor must often take the correctness of the language's implementation on trust.

On the other hand, the system architect contemplating the use of a DSL architecture should also have in mind the following potential shortcomings of this approach:

Tool Support Limitations
CASE and integrated software development tools offer only limited support for integrating DSLs into the development process. Ad hoc solutions are often required to smoothly integrate DSL code with existing revision control systems, compilers, editors, source browsers, and debuggers.
Training Costs
In contrast to established specification languages such as Z [PST91] system implementors and maintainers will by definition have no prior exposure to the DSL being used. This problem is somehow mitigated by the fact that a correctly chosen DSL will be familiar to other participants of the implementation effort such as those involved in the specification, beta testing, and final use. These participants will be able to perform DSL code walkthroughs -- a task normally reserved for experienced software engineers.

Design Experience
DSL-based system architectures are not widely adopted within the software industry. As a result, there is an evident lack of design experience, prescriptive guidelines, mentors, design patterns, and supporting scientific literature. Early adopters will need to rely more on their own judgement as they adopt the approach in a stepwise fashion.

Software Process Integration
The use of DSLs is not yet an integral part of established software processes. Therefore, the software process being used has to be modified in order to take into account the design, implementation, integration, debugging, and maintenance of the adopted DSLs.


DSLs offer an additional level of abstraction in the implementation of software-based systems. In the example we described, 11000 lines of DSL specifications written, reviewed, and maintained by domain experts are automatically translated into 87000 lines of C++ code. A DSL-based architecture can be utilised in all areas where there is a formal standardised specification particular to the application domain that can be relatively easily translated into a standard programming language. Where this part of the specification is large or fluid, significant increases in software reliability, maintainability, and cost can be achieved through the use of the proposed DSL approach.


Alfred V. Aho, Brian W. Kernighan, and Peter J. Weinberger.
Awk -- a pattern scanning and processing language.
Software: Practice & Experience, 9(4):267-280, 1979.

J. Bell, F. Bellegarde, J. Hook, R. B. Kieburtz, A. Kotov, J. Lewis, L. McKinney, D. P. Oliva, T. Sheard, L. Tong, L. Walton, and T. Zhou.
Software design for reliability and reuse: a proof-of-concept demonstration.
In Conference on TRI-Ada '94, pages 396-404. ACM, ACM Press, 1994.

T. Berners-Lee and D. Connolly.
RFC 1866: Hypertext Markup Language -- 2.0, November 1995.

James R. Cordy, Charles D. Halpern-Hamu, and Eric Promislow.
TXL: A rapid prototyping system for programming language dialects.
Computer Languages, 16(1):97-107, January 1991.

Rickard E. Faith, Lars S. Nyland, and Jan F. Prins.
KHEPERA: A system for rapid implementation of domain specific languages.
In USENIX Conference on Domain-Specific Languages [USE97], pages 243-255.

Stephen C. Johnson and Michael E. Lesk.
Language development tools.
Bell System Technical Journal, 56(6):2155-2176, July-August 1987.

M. M. Lehman.
Software engineering, the software process and their support.
Software Engineering Journal, 6(5):243-258, September 1991.

LH 98
LH Software.
FESPA for Windows.
Kleidarithmos, Athens, Greece, 1998.
In Greek.

Mohammad N. Paryavi and William J. Hankley.
OOSPEC: an executable object-oriented specification language.
In ACM 23rd annual computer science conference. CSC '95, pages 169-177. ACM, ACM Press, 1995.

Ben Potter, Jane Sinclair, and David Till.
An Introduction to Formal Specification and Z.
Prentice-Hall, 1991.

H. Sackman, W. J. Erikson, and E. E. Grant.
Exploratory experimental studies comparing on-line and off-line programming performance.
Communications of the ACM, 11(1):3-11, January 1968.

Diomidis Spinellis and V. Guruprasad.
Lightweight languages as software engineering tools.
In USENIX Conference on Domain-Specific Languages [USE97], pages 67-76.

Ian Sommerville.
Software Engineering.
Addison-Wesley, third edition, 1989.

Wladyslaw M. Turski and Thomas S. E. Maibaum.
The Specification of Computer Programs.
Addison-Wesley, 1987.

Shmuel Tyszberowicz and Amiram Yehudai.
OBSERV -- a prototyping language and environment.
ACM Transactions on Software Engineering and Methodology, 1(3):269-309, July 1992.

USENIX Conference on Domain-Specific Languages, Santa Monica, CA, USA, October 1997.

Victor L. Winter, John M. Covan, Larry J. Dalton, Leon Alkalai, Ann T. Tai, Rick Harper, Barry Flahive, Wei-Tek Tsai, Ramin Mojdehbakhsh, Sanjai Rayadurgam, Kinji Mori, and Michael R. Lowry.
Key applications for high-assurance systems.
Computer, 31(4):35-45, April 1998.

Larry Wall and Randal L. Schwartz.
Programming Perl.
O'Reilly and Associates, Sebastopol, CA, USA, 1990.