What is Domain Specific Language or DSL ?

What is Domain Specific Language or DSL?

In his book, Martin Fowler defines the DSLs as follows.

 “A computer programming language of limited expressiveness focused on a particular domain.” (Fowler, 2010)

“The basic idea of a domain specific language (DSL) is a computer language that’s targeted to a particular kind of problem, rather than a general purpose language that’s aimed at any kind of software problem.” (Fowler, 2010)

Summing up the above two quotes, a DSL can be define as follows

“A computer programming language of limited expressiveness that are specialized and focused to specify a particular aspect of a software system at a much higher level of abstraction than the general purpose programming language. It is capable of capturing the abstractions related to that particular aspect of the software system under development.”

In the literature, this particular aspect of the software system is also referred by the terms “viewpoint” or the “domain”. So in this context of DSLs, the viewpoint or the domain can be defined as follows

Domain or Viewpoint is the related set of concerns that represent the particular aspect of a whole software system under development that is important from the software development perspective. We can define the two types of domain or viewpoint for a software system, the horizontal and vertical domain (Maier, et al., 200X) (MDA Guide)

Horizontal Domain describes the technical aspects related to the software system like the architectural view, persistency view, user interface view, user interface look and feel view and user interface interaction view. (?)

Vertical Domain describes the functional aspects related to the software system like the insurance policy domain, banking domain, air traffic control domain, air flight reservation domain, medical domain, mobile software domain are the examples of few. (?)

DSLs do not live in isolation but they are integrated. As a DSL fulfils only a narrow purpose and specify a particular aspect of a software system. But the real world software has multiple aspects associated with it and all such aspects are overlapping and tightly integrated to each other. So a DSL in isolation is worthless. In order to specify all aspects of the software system we must have multiple integrated set of DSLs. (Fowler, 2010)

DSLs are not needed to be turing-complete languages like the GPLs. As the scope of these languages is much narrowed to specialized domain of a software system, therefore their capabilities are also limited as compared to the GPLs like Java and C#. A DSL is not needed to be a turing complete language like the GPLs having all kind of controls structures like conditional structures, looping structures. Also these languages are not necessarily to have the capability to create new abstraction styles. The narrowed capabilities are enough to fully specify the particular aspect of the software system. As these languages are more tilted toward the specialized domain, therefore they are expected to have more user-friendly syntax as compared to the GPLs. Due to this feature the programs or models specified in such languages are more expressive, more focused, more fluent and more readable as compared to the GPLs programs or models. (Fowler, 2010)

Examples of the DSLs include CSS, XML configuration files , regular expressions, make, rake, ant, SQL, HQL, many bits of Rails, expectations in JMock, graphviz's dot language, FIT, strut's configuration file.  (Fowler, 2010)

What is Language Oriented Programming

In his book, Martin Fowler defines the LOP as follows.

“The general style of software development which operates about the idea of building software around a set of domain specific languages” (Fowler, 2010)

“Language oriented programming is about describing the system through multiple DSLs.” (Fowler, 2010)

As discussed, a DSL is used to specify a particular aspect of the software system. But a real software system has multiple overlapping aspects associated with it. That’s why this is a new software development paradigm suggests the use of multiple integrated set of DSLs to fully describing a software system. In contrast to the GPLs, the DSLs specify the different aspects of the software system at much higher level of abstraction. Thus the resultant software specifications are very much easier to code for the programmers and very much easy to understand by the domain experts. This minimizes the communication gap between programmers and domain experts and helps resolve worst bottleneck that some of the main reasons behind the software failure. This style of development promises the order of magnitude improvement in software quality and productivity. Traditionally we have been doing LOP in the bits and pieces to get stuff done in the form of Unix little languages, lisp macros, active data models, adaptive object models, XML configuration files and GUI builders. (Fowler, 2010)

What is Domain in Domain Specific Language (DSL)

Various talks about Model Driven Software Development (MDSD)  and Domain Specific Languages (DSL) discuss the "Domain" witout elaborating their definition of domain. Domain is an overloaded terms that means different to different people. The following paragraph will try to elaborate this terms in the context of MDSD and DSL.

Horizontal domains are actually the solution space and the horizontal domains based efforts to raise the level of abstraction results in the horizontal abstractions. These abstractions do not deal with accidental complexity as they have nothing to do with the reusability of the conceptual structures. These abstractions ease the software development and make the expression of the design very much easy and deals only with accidental complexity. These technical abstractions can be well reused among the different technical domains. Their examples include (web applications, software architecture, deployment architecture, data persistency, concurrency, scalability and user interface).

Vertical domains are actually the problem space and the vertical domains based efforts to raise the level of abstraction results in the vertical abstractions. These abstractions deal with the essential complexity as they promote the reusability of the conceptual structures among the different software applications of that domain and also at the same time they make the expression of the design very much easy. But it is only the reusability of the conceptual structures that makes it relevant to deal with the essential complexity. Horizontal abstractions are prerequisite to the vertical abstractions and these vertical abstractions are built on the top of the horizontal abstractions. Therefore both kind of abstractions are important from the LOP perspective. 

Model Driven Software Development vs. Hand Crafted code

Many talks about the Model Driven Software Development (MDSD) portray it as the replacement of traditional hand crafted way of Software Development. By generating simple toy samples they try to convince that this is new style of software development. This idea seem OK on the paper but all practical experiences with the MDSD in the real life projects tell it is not true.

One way think MDSD is that it is a great assistance our hand crafted style of software development.

One may divide a software product under development in to two parts
1. One part of software that is repetitive and recurring
2. One part of software that is innovative and yield the real value of the software.

We can leverage the MDSD to deal with the first part. We specify that part of the software higher level of abstractions using Domain Specific Language (DSLs) and generated the repetitive stuff by code generation. This saves the developers time from doing the rote and menial tasks.

We should use manual style of software development to code the innovative part of the software. Fred Brooks refers this part of the software as the "Conceptual Constructs of the Software" that cause the Essential Complexity. MDSD leverage the abstraction and automation and yield more Developer's time and stamina to do deal with the Essential Complexity of software.

What is Model Transformation

Model transformations

Model transformation is the process in which the models or programs written in the source language are translated to the models or programs of the target language. Both input and output models or programs confirm to their respective language definition. That target language may be another modeling language or the programming language.

Why we need model transformation?

While developing software using the modern programming languages we write the software specifications in the form of programs. While doing so we are specifying software at much higher level of abstraction that is close to the human understanding. But the computer understands the programs in the form of 0s and 1s. Compilers translate these higher level software specifications to the low level instructions that are directly understandable and executable by the computers. In the same way when we are specifying software in the form of models, we are specifying it at further higher level of abstraction than the modern programming languages. We need to translate these models too into the intermediate models to the code of programming languages like Java or C# so that it could be further translated to the machine code.

Model to Model Transformation should be considered harmful

Model to Model Transformation should be considered harmful in the context of Model Driven Software Development and Code Generation.

MDA and other MDSD approaches preach Model to Model Transformation to add the Platform Specific Details and other CCC to the target applications. This approach seems OK on the paper but does not work
in practical software development using MDSD.

Some MDSD afforts do not use the Model to Model approaches. They only exploit Model to Text approaches. Model is transformed to Code in just one pass and platform specific details are added in that one pass. There is not multiple Model to Model transformation and having Model to Text in the end of pipe line. So, what about the CCC ? These approaches advocate the AOP to add the CCC functionality of the applications. This is only possible if our Model Transformation Language has AOP capabilities. 

What is Model Driven Software Development or Language Oriented Programming

The Language Oriented Programming (LOP) can be defined as follows.

The idea of developing software around the set of DSLs layered on the top of an application framework and auto-generate the framework completion code from the models/programs specified in DSLs using the Code Generator of LWB tools.

• So LOP include following aspects in its definition 
• Frameworks are core to LOP and software is developed by extending them. So, the frameworks provide foundation for the software developed by LOP.
• Intent or requirements of the software are specified at higher level abstractions, closer to the domain, using the integrated set of DSLs.
• The resultant higher level abstractions (models/programs in DSLs) are processed to generate the framework completion code.
• Specialized software development IDE, called Language Workbench (LWB), is used to develop software in LOP. Along with the all features of a modern IDE, LWB provides built-in mechanism to define and use the DSLs and Code Generator for any framework.
• The innovative parts of the framework completion code are hand crafted. The code generator support different mechanisms to preserve this hand crafted code during code regeneration process.

The last aspect clearly shows that LOP is preferred only for the patterned and familiar domains. By the previous software development experience in these domains, we have enough formalized knowledge about their domain concepts and how these concepts are represented in the software code. This domain knowledge will help us to define the DSLs and the Code Generator for the product families in that domain. Any attempts to applying the LOP to the innovative and least patterned domains will result in productivity loss and catastrophe and software failure is inevitable. The rule of thumb is that we must have experience of developing at least three products for a particular domain before we should go to set up a LWB for that domain and start LOP.


The LOP community differentiates between different types of DSLs like internal or external, graphical or textual or compiled or interpreted. The above notion of DSL refers to external compiled DSLs that may be graphical or textual but the textual DSLs are preferred as they are close to how we program software today and how our version control systems deals with 4GL source code now. In the same way most of the LWB tools use the template mechanism to implement their code generators.

Some misconceptions about Model Driven Software Development

There are some misconceptions about the MDSD that I want to clear before discussing about it.
 
· MDSD is definitely a new style of development, but is not going to replace our current style of software development, i.e. developing the every piece of software by hand crafted code.


· MDSD should considered as the great assistance to our current style of software development by doing the rote, repetitive menial tasks at higher level of abstraction by leveraging the power of automation.


· MDSD is not applicable to all kinds of software projects. It is about systematic reuse and applies to the software product lines or families of software products. These software families might be related to the horizontal domains like web applications, applications sharing common architecture, mobile apps etc or they could be related to vertical domains like insurance.


· This maturity of horizontal or vertical domain comes with time, for example we develop 2,3 matured software products and we are expected to develop the more variants of that product.

Software Reuse

A quote inspired from the Ralph E Johnson's software reuse paper

"Developing the software artifacts is hard, developing the reusable software artifacts is even harder."