Domain-Specific Languages are used in software engineering in order to enhance quality, flexibility, and timely delivery of software systems, by taking advantage of specific properties of a particular application domain. This survey covers terminology, risks and benefits, examples, design methodologies, and implementation techniques of domain-specific languages as used for the construction and maintenance of software systems. Moreover, it covers an annotated selection of 75 key publications in

more »

... he area of domain-specific languages. ACM Computing Classification System: D.3 Note: Work carried out under project SEN 1.5, Domain-Specific Languages, sponsored by the Telematica Instituut. Terminology The question what exactly is a domain-specific language is subject to debate. We propose the following definition: 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. The key characteristic of DSLs according to this definition is their focussed expressive power. Our definition inherits the vagueness of one of its defining terms: problem domain. Rather than attempting to define this volatile notion as well, we list and categorize a number of domains for which DSLs have actually been built in Section 4. Moreover, we refer to [70] , which contains an interesting discussion contrasting a "domain as the real world" point of view as adopted in the artificial intelligence community, with a "domain as a set of systems" approach, as used in the systematic software reuse research community. DSLs are usually small, offering only a restricted suite of notations and abstractions. In the literature they are also called micro-languages and little languages [7]. Sometimes, however, they contain an entire general-purpose language (GPL) as a sublanguage, thus offering domain-specific expressive power in addition to the expressive power of the GPL. This situation occurs when DSLs are implemented as embedded languages (see Section 6). Languages such as Cobol or Fortran, which could be viewed as languages tailored towards the domain of business and scientific programming, respectively, are generally not regarded as DSLs, because they are not small and because their expressive power is not restricted to these domains. Domain-specific languages are usually declarative. Consequently, they can be viewed as specification languages, as well as programming languages. Many DSLs are supported by a DSL compiler which generates applications from DSL programs. In this case, the DSL compiler is referred to as application generator in the literature [17], and the DSL as application-specific language. Other DSLs, such as YACC [7] or ASDL [77], are not aimed at programming (specifying) complete applications, but rather at generating libraries or components. Also, DSLs exist for which execution consists in generating documents (T E X), or pictures (PIC [7]). A common term for DSLs geared towards building business data processing systems is 4th Generation Language (4GL). Related to domain-specific programming is end-user programming, which happens when end-users perform simple programming tasks using a macro or scripting language. A typical example is spreadsheet programming using the Excel macrolanguage. Risks and Opportunities Adopting a DSL approach to software engineering involves both risks and opportunities. The well-designed DSL manages to find the proper balance between these two. The benefits of DSLs include: DSLs allow solutions to be expressed in the idiom and at the level of abstraction of the problem domain. Consequently, domain experts themselves can understand, validate, modify, and often even develop DSL programs. DSL programs are concise, self-documenting to a large extent, and can be reused for different purposes [50]. DSLs enhance productivity, reliability, maintainability [24, 47], and portability [38]. DSLs embody domain knowledge, and thus enable the conservation and reuse of this knowledge. DSLs allow validation and optimization at the domain level [6, 13, 55]. DSLs improve testability following approaches such as [71] . The disadvantages of the use of a DSL are: The costs of designing, implementing and maintaining a DSL. The costs of education for DSL users. The limited availability of DSLs [49]. The difficulty of finding the proper scope for a DSL.