domain specific language (DSL)
A Domain Specific Language(DSL) is designed for a specific application area - the application domain. With the background of specific language elements and the conceptual world of the application domain, one can realize the typical tasks from this domain. The notation can be textual or graphical.
The Domain Specific Languages stand in contrast to universal programming languages such as C++, Java and modeling languages such as the Unified Modeling Language( UML) or the Fundamental Modeling Concepts( FMC). By using a Domain Specific Language, the effort in the specification and implementation ofsoftware can be significantly reduced. In addition, the expert knowledge of the application domain is expressed more comprehensibly, the technical requirements are better fulfilled and the error-proneness of software is considerably improved.
The traditional way of developing software involves specifying, implementing and testing an application, each of these phases being associated with a particular set of problems. Addressing these at their core is the fundamental idea of domain-specific languages. Here, previously identified parts of the software are no longer developed with universal programming languages such as Java, C# or C++, but languages are used that are geared towards a specific solution to the problem. The program code developed with a DSL language can then - with the use of appropriate tools - be transformed without further ado into the source code of a universal programming language. These cover a multiplicity of application possibilities by their expression power; the domain-specific language concentrates exclusively on the posed subproblem, so that the language extent of the DSL is clearly reduced in the comparison with the universal programming language.
The concept of the domain-specific language
The concept of Domain Specific Languages distinguishes between internal and external DSLs:
Here, internal DSLs characterize the direct use of the expressive means of a language. With internal DSLs the syntactical examination of the code is accomplished by the compiler or interpreter, thus they need no special Parser. Modern languages such as Groovy or Ruby support the writing of DSLs through their flexible syntax. But also the UML 2.0 with accordingly coupled code generation is to be classified here.
External DSLs are those DSLs that require conversion to another language or a special interpreter for their execution. Examples of external Domain Specific Languages are the database language SQL or RegEx for the simple definition of string patterns, which would produce substantial code overhead implemented in a universal programming language.
Domain-specific languages, supported by the growing number of corresponding tools, are becoming increasingly important in software development.
There is a multiplicity of different ranges of application for DSLs, exemplarily are mentioned:
- AUI and SWUL for GUI modeling,
- MSC for the specification of telecommunication systems,
- NOWRA for software configuration,
- PLS-Da for database applications,
- RISLA for software development of financial products and
- ORM for describing relationships between database tables,
Again, some examples:
- GEMS and EMF as DSL toolset for Eclipse based on Xtext,
- MS Visual Studio includes DSL tools,
- Tangible architect is a DSL tool,
- Microsoft Oslo for textual and graphical DSLs,
- MPS from JetBrains for building and using textual DSLs and
- MetaEdit+ for graphical DSLs.
The main advantages of DSLs are that
- the code effort is reduced
- the concepts of the language originate from the problem domain
- a defined syntax and semantics are available,
- DSL programs are very clear and easy to understand, and
- that the productivity and maintainability are improved
However, there are also disadvantages such as
- the high effort required for familiarization with tools and methods, particularly in the case of external DSLs, in relation to a limited scope of application,
- additional management of the language scope of DSLs in order not to dilute them, and
- that increased code effort can lead to less efficient code, which in extreme cases can have an impact on the performance of the software.
Deployment scenarios of domain-specific languages
If one considers the use scenarios, a Domain Specific Language is generally not suitable for covering a complete application area. Here it makes more sense to cover self-contained aspects or parts of an application with DSLs. In particular, the use of DSLs makes sense for software parts with frequent changes. Furthermore, the aspect of performance must be taken into account when using DSLs.
DSLs are also the subject of current research topics - in this context, we also speak of language engineering. In this context, the environment of DSLs - such as processes, methods and techniques for building languages - is analyzed and further developed. An interesting approach in this context is to no longer consider DSLs as a problem solution for a specific application domain, but to implement a development paradigm such as aspect-oriented( AOP), context-oriented (COP) or feature-oriented (FOP) programming as a language extension. In particular, Groovy, among others, offers this concept of language extensions. Furthermore, concepts for multi-paradigm programming in Ruby are being worked on.