Role of Domain Specific Languages in Domain Analysis

By Andrey Volkov (aavolkov_3@edu.hse.ru)

The domain analysis is a process by which information used in developing software systems is identified, captured, and organized with the purpose of making it reusable when creating new systems [1].

During the process of domain analysis domain models are produced. One of the main methodologies for producing domain models is domain-specific language.

A Domain-Specific Language (DSL) is a programming language or executable specification language that offers, through appropriate notations and abstractions, expressive power focused on, and usually restricted to, a particular problem domain [2]. This is in contrast to the General Purpose Language (GPL), which is widely applicable across all domains.

Domain Specific Languages are used in software development to improve quality, flexibility, and on-time delivery software systems, taking advantage of certain properties of a specific area of the application.

In this essay the role of domain specific languages on domain analysis will be discussed.

Using a DSL approach for software engineering provides both opportunities and risks. The well-developed DSL aims to find the appropriate balance between the two [2].

The benefits of DSLs include:

• The possibility for solutions to be expressed at the level of abstraction of the problem domain. Therefore, it allows domain experts to understand, validate, modify, and develop DSL programs.
• DSL programs are concise, self-documenting to a large extent, and can be reused for different purposes [3].
• DSLs enhance productivity, reliability, maintainability [4, 5], and portability [6].
• DSLs embody domain knowledge, and thus enable the conservation and reuse of this knowledge.
• DSLs allow validation and optimization at the domain level [7, 8, 9].
• DSLs improve testability following approaches such as [10].

The disadvantages of the use of a DSL are:

• DSL programs rather costly in terms of design, implementation and maintenance.
• DSL users need to be specially educated to know specific language.
• The DSL is limited in terms of availability [11].
• The difficulty of finding the proper scope for a DSL.
• The difficulty of balancing between domain-specificity and general-purpose programming language constructs.
• The potential loss of efficiency when compared with hand-coded software.

The development of a domain-specific language includes the following steps [12, 13]:

• Analysis
  1. Identification of the problem domain.
  2. Gathering all relevant data and knowledge for particular domain.
  3. Grouping the knowledge in a handful of semantic notions and operations on them.
  4. Design a DSL that precisely describes applications domain.
• Implementation
  1. Develop a library that implements the designed DSL.
  2. Design and implement a compiler that converts DSL programs to a sequence of library calls.
• Use
  1. Write DSL programs for all desired applications and compile them.

The goal of analysis steps (1) through (4) is to create a complete understanding of the application domain. Guidance for gaining this understanding is provided in the area of subject analysis research, which explores ways of modeling subject areas. According to [14], a subject analyst is a person who examines the needs and requirements of a set of systems that appear to be “similar”. Neighbors emphasize that this is a job that can only be done by a person who has built many systems for different clients in the same problem area. A domain analyst is similar to a systems analyst, except that his goal is to support the development of families of related systems, not just one-of-a-kind manufacturing [16].

Domain engineering [15] refers to systematic domain modeling activities. Domain design comes from research into software reuse and can be used to create reusable libraries, frameworks, or languages for specific domains.

The implementation steps (1) and (2) of the previous section can be carried out using several approaches:

Interpretation or compilation

This is the classic approach to implementing a new language. The main advantage of creating a compiler or interpreter is that the implementation is fully DSL-specific, and there are no concessions regarding notation, primitives, etc. not required. In addition, error detection, static analysis and optimization can be performed at the level of the subject area, for example, using the system of effects, as in [13].

Obviously, an important issue is the cost of building such a compiler or interpreter from scratch and the lack of reuse from other (DSL) implementations.

As an alternative to implementing a DSL from scratch, a DSL can be implemented by extending a given base language.

Embedded languages / domain-specific libraries

In this approach, existing mechanisms such as function definitions or user-defined syntax definitions are used to create a library of domain-specific operations. Base language syntactic mechanisms are used to express the domain idiom.

The advantage of this approach is that the base language compiler or interpreter is reused, just like a DSL. The main limitation is the expressiveness of the syntactic mechanisms of the base language. In many cases, the optimal domain-specific notation must be compromised to comply with the constraints of the host language.

There are hundreds of DSLs currently in existence. Of these, only a fraction is actually described in the literature on software engineering or programming languages. The best known are such classic examples as PIC, SCATTER, CHEM, LEX, YACC and Make, which are described in [17]. Other well-known examples are SQL, BNF, and HTML.

Domain analysis uses domain-specific language as a methodology for producing domain models. The domain-specific language allows programs to be concise, enhance productivity, reliability, maintainability, and portability. On the other hand, DSL programs come with costs of design, implementation and maintenance. The entry threshold to working with DSL is also higher then in general purpose languages. Overall, in some cases it seems a decent solution for producing domain models in domain analysis.

1. Ruben Prieto-Diaz. Domain analysis: an introduction, Apr 1990.
2. Paul Klint, Joost Visser. Domain-Specific Languages, June 2000.
3. D. A. Ladd and J. C. Ramming. Two application languages in software production. In USENIX Very High Level Languages Symposium Proceedings, pages 169–178, October 1994.
4. A. van Deursen and P. Klint. Little languages: Little maintenance? Journal of Software Maintenance, 10:75–92, 1998.
5. R. B. Kieburtz, L. McKinney, J. M. Bell, J. Hook, A. Kotov, J. Lewis, D. P. Oliva, T. Sheard, I. Smith, and L. Walton. A software engineering experiment in software component generation. In Proceedings of the 18th International Conference on Software Engineering ICSE-18, pages 542–553. IEEE, 1996.
6. R. M. Herndon and V. A. Berzins. The realizable benefits of a language prototyping language. IEEE Transactions on Software Engineering, SE-14:803–809, 1988.
7. A. Basu, M. Hayden, G. Morrisett, and T. von Eicken. A language-based approach to protocol construction. In Kamin [43], pages 1–15.
8. D. Bruce. What makes a good domain-specific language? APOSTLE, and its approach to parallel discrete event simulation. In Kamin [43], pages 17–35.
9. V. Menon and K. Pingali. A case for source-level transformations in MATLAB. In DSL-99 [27], pages 53–66.
10. E. G. Sirer and B. N. Bershad. Using production grammars in software testing. In DSL-99 [27], pages 1–14.
11. C. W. Krueger. Software reuse. ACM Computing Surveys, 24(2):131–183, June 1992.
12. J. C. Cleaveland. Building application generators. IEEE Software, pages 25–33, July 1988.
13. A. van Deursen and P. Klint. Little languages: Little maintenance? Journal of Software Maintenance, 10:75–92, 1998
14. J. M. Neighbors. The Draco approach to constructing software from reusable components. IEEE Transactions on Software Engineering, SE-10(5):564–74, September 1984.
15. G. Arango. Domain analysis: From art form to engineering discipline. In Fifth International Workshop on Software Specification and Design, pages 152–159, May 1989. Appeared as ACM SIGSOFT Engineering Notes 14(3).
16. R. N. Taylor, W. Tracz, and L. Coglianese. Software development using domain-specific software architectures. ACM SIGSOFT Software Engineering Notes, 20(5):27–37, 1995.
17. J. L. Bentley. Programming pearls: Little languages. Communications of the ACM, 29(8):711–721, August 1986