A Domain Specific Language (DSL) is targeted with respect to a very specific application area - the application domain. With the background of specific language elements and the conceptual world of the application domain, typical tasks from this domain can be realized. The notation
can be textual or graphical.Domain Specific Languages are in contrast to universal programming languages like C++, Java and modeling languages like the Unified Modeling
Language(UML) or the Fundamental Modeling Concepts (FMC). By using a Domain Specific Language, the effort in specifying and implementingsoftware
can be significantly reduced. In addition, theexpert knowledge of the application domain is expressed in a more comprehensible way, the business requirements are better met, and the error-proneness of software is significantly improved.
Thetraditional way of developing software involves specifying, implementing, and testing an application, each of these phases
beingassociated with a particular set of problems. Addressing these at their core is the fundamental idea of domain-specific languages. In this process, previously identified parts of the software are no longer developed using general-purpose 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 easily transformed into the source code of a universal programming language. These cover a multitude of application possibilities due to their expressive power; the domain-specific language concentrates exclusively on the posed subproblem, so that the language scope of the DSL
issignificantly reduced in comparison with the universal programming language.
The Concept of theDomain-Specific
The concept of Domain-Specific Languages distinguishes between internal and external DSLs: InternalDSLs
arecharacterized by the direct use of the expressive means of a language. With internal DSLs, the syntactic checking of the code is performed by the compiler or interpreter, so they do not need a special parser. Modern languages like Groovy or Ruby support the writing of DSLs by their flexible syntax
. But also the UML 2.0 with corresponding coupled code generation can be classified hereExternal DSLs are those DSLs that require the conversion into 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 considerable code overhead when implemented in a universal programming language.Domain Specific Languages, supported by the growing number of corresponding tools, are becoming increasingly important
. There are a large number of different application areas for DSLs, for example:
- AUI and SWUL for GUI modeling,
- MSC for telecommunication system specification,
- 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 toolsets 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 code effort is reduced,
- the concepts of the language are native to the problem domain,
- there is a defined syntax and semantics,
- DSL programs are very clear and easy to understand, and
- that productivity and maintainability are improved
- the high effort of familiarization with tools and methods, especially 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 an increased code effort can lead to less efficient code, which in extreme cases has an impact on the performance of the software.
usage scenarios of domain-specific languages, 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 by DSLs. In particular, the use of DSLs is useful for software parts with frequent changes. Furthermore, the aspect of performance has to be considered when using DSLs. DSLs are also the subject of current research topics - in this context, we also talk about 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.