http://www.spinellis.gr/pubs/conf/1999-ESREL-SoftRel/html/dsl.html
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:
- Diomidis Spinellis.
Reliable
software implementation using domain specific languages.
In G. I. Schuëller and P. Kafka, editors,
Proceedings ESREL '99 — The Tenth European Conference on Safety and
Reliability, pages 627–631, Rotterdam, September 1999. ESRA, VDI,
TUM, A. A. Balkema.
Citation(s): 5 (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
|
Reliable software implementation using domain-specific languages
Diomidis Spinellis
Department of Information and Communication Systems
University of the Aegean
Greece
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:
- 1.
- specification of the building in terms of slabs, pillars, bars, and other
nodes,
- 2.
- template-based production of additional floors,
- 3.
- calculation of pillar loads and creation and dimensioning of the
building foundations, footings, and connecting rods,
- 4.
- solution of the space structure and plotting of member distortions,
forces, and moments,
- 5.
- calculation of section reinforcements, and
- 6.
- 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:
- Commands
- The grouping, functionality, and explanatory details of
the 450 available commands.
- Toolbars
- The functionality, icons, and explanatory details of
the system's toolbars.
- Menus
- The names, associated commands, allowable execution context,
and initialisation sequence for the system's menu structure.
- Reports
- The specification of the report generator.
- Layers
- The grouping, functionality, and interactions between
the system's 68 layers of entities.
- Persistency
- 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:
- Expressiveness
- 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.
- Reliability
- 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.
- AKW79
-
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.
- BBH+94
-
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.
- BLC95
-
T. Berners-Lee and D. Connolly.
RFC 1866: Hypertext Markup Language -- 2.0, November 1995.
- CHHP91
-
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.
- FNP97
-
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.
- JL87
-
Stephen C. Johnson and Michael E. Lesk.
Language development tools.
Bell System Technical Journal, 56(6):2155-2176, July-August
1987.
- Leh91
-
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.
- PH95
-
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.
- PST91
-
Ben Potter, Jane Sinclair, and David Till.
An Introduction to Formal Specification and Z.
Prentice-Hall, 1991.
- SEG68
-
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.
- SG97
-
Diomidis Spinellis and V. Guruprasad.
Lightweight languages as software engineering tools.
In USENIX Conference on Domain-Specific Languages
[USE97], pages 67-76.
- Som89
-
Ian Sommerville.
Software Engineering.
Addison-Wesley, third edition, 1989.
- TM87
-
Wladyslaw M. Turski and Thomas S. E. Maibaum.
The Specification of Computer Programs.
Addison-Wesley, 1987.
- TY92
-
Shmuel Tyszberowicz and Amiram Yehudai.
OBSERV -- a prototyping language and environment.
ACM Transactions on Software Engineering and Methodology,
1(3):269-309, July 1992.
- USE97
-
USENIX.
USENIX Conference on Domain-Specific Languages, Santa Monica,
CA, USA, October 1997.
- WCD+98
-
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.
- WS90
-
Larry Wall and Randal L. Schwartz.
Programming Perl.
O'Reilly and Associates, Sebastopol, CA, USA, 1990.