CSC/ECE 517 Fall 2010/ch2 S23 NR

Domain Specific Object Oriented Languages

Overview

Domain specific languages (DSLs) are the programming languages focused to certain domain used to find the solutions using domain specific representation techniques. Domain can be any field such as Mathematics, Relational Databases, etc or it can even be any specific business/business unit such as Insurance, Billing department of any company, salary calculation, etc. Popular examples of Domain specific languages are R, S and Q languages for statistics, Mathematica and Maxima for symbolic mathematics, spreadsheet formulas and macros, SQL for relational database queries

Domain specific languages vs. General programming languages

General Programming languages are the ones which can be used for developing solution for any field or any business units. Most popular examples being C, C++ and Java. Domain specific languages provide a high edge over general languages in their application domain.

Domain Specific Object Oriented Languages

Domain-specific Object Oriented Languages are usually little languages that are particularly expressive in a certain problem domain and are also task-specific, application-oriented. In addition to that it also encompasses object oriented principles such as Inheritance, Encapsulation and Abstraction. They offer substantial gains in expressiveness and ease of use as compared with General object oriented programming languages in their domain of application. Some of the well known object oriented DSLs are,

• Smalltalk which was developed by Xerox Coorp. for educational use

• Simula which was developed for simulation of programs. ^[3]

• Scalable Vector Graphics (SVG) is a family of specifications of an XML-based file format for describing two-dimensional vector graphics, both static and dynamic.

Typical characteristics of Domain specific languages

DSLs are usually small, offer only restricted suite of notations and abstractions and are also called as micro/ little languages. Sometimes, however, they are made on top of general purpose language, thus offering domain-specific expressive power in addition to the expressive power of the GPL^[7].

DSLs are declarative. Hence, 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 ^[7].

Requirements for a DSL

Many of the requirements for DSLs are same as ones for the general-purpose programming languages. However, they differ on the level of importance when compared with the general purpose languages.^[6]

The core requirements for a DSL are as follows:

• Conformity: The language must address to all the important concepts of the target domain. This is the basic requirement for any DSL.

• Supportability: it is feasible to provide DSL support via domain specific popular tools, for typical model and program management. It will be of great ease if the DSL support is provided via tools, which are already used by the people of specified domain. The host tool can easily take care of the basic functionalities of the domain.

• Integrability: The DSL language should be capable of working with other tools and languages of the domain. This is essential for easy adaptation of existing applications to new language.

• Longevity: The DSL should be used for sufficient amount of time by the users to justify the cost of creating DSL and its supporting tools.

• Simplicity: It should be easy to be adapted by the new and existing users in the domain. This also makes sure that the user focus more on the application development rather than learning the DSL.

• Quality: The language should produce high quality applications which are better in terms of all the related language constructs like reliability, security, safety, etc.

The above mentioned requirements are the general requirements for DSLs. There can be additional requirement depending upon the domain for which they are created.

Risks and Opportunities

There are associated risk and opportunities related to any DSL which decides its success. Before deciding on the creation of the new DSL, one should always make sure that the amount of opportunities related to its creation are more than the risk involved. The following are the typical risks and opportunities related to any DSL^[7].

The Opportunities

• DSLs allows a solution to be expressed more particularly in the domain of the problem, thus development of DSL programs is easy for the domain experts.

• Since DSLs are specific to a domain, programs are concise and self documented to a large extent.

• DSLs enabling the experts to focus more on a problem domain thus enhancing the quality and productivity, making it more reliable, easy to maintain..

• They embody specific domain knowledge, and thus enabling the conservation and reuse of this knowledge in a way.

• It enables programs to be validated and optimized at the domain level.

• Since it is specific to a language improves its ability to be tested.

• It gives better end user experience.

• They are easy and exciting for the problem domain experts.

The Risks

• The cost of designing, implementing and maintaining DSL is high.

• The additional cost of educating the users to learn DSL.

• The domain experts need to have knowledge about language design principles in order to develop it a DSL.

• The scope of DSL is not defined.

• It is difficult to balance between domain-specificity and general-purpose programming constructs.

• It does not have a strong development tool support as compared to other general purpose programming languages. Eg. NetBeans and Eclipse for Java, C++, etc.

DSL v/s Object Oriented Frameworks

Domain Specific object oriented languages can be easily used to develop readable and maintainable applications in a particular domain. Whereas construction of closely related programs in any domain can be achieved easily using object oriented framework.

They can be compared on the basis following criterion:-

• Expressiveness: DSL expresses knowledge that is domain-specific whereas using a general purpose programming language as in a framework provides more flexibility in adapting to specific needs.

• The Calling Framework: A framework often is an active entity and does not get called but it calls functions provided by the application developer. This can also be easily achieved using a DSL. ^[2]

• Overriding Default Behavior: White-box frameworks allow the application developer to override default behavior using inheritance. This can also be achieved by using DSL but it does not seem obvious and intuitive. ^[2]

• Language technology: DSL requires tools for supporting rapid prototyping of scanners, parsers, type checkers, interpreters, compilers. On the contrary, there is no such need in object oriented frameworks as they are made on the top of high level languages. ^[2]

Open Issues or challenges related to DSLs

The following are the open issues related to DSL that require further investigation. ^[7]

• How do requirements are refined when a specific domain is considered? Each domain has its own requirements and specification on to the use of the DSL, resulting in higher stress for analyzing the domain.

• How can we measure the cost-versus-benefit of using DSLs as opposed to general-purpose languages?

• What about the side-effects of using DSLs, in particular, the implicit use of a number of (loosely coupled) languages throughout development, the use of a federation of tools versus an integrated development environment, etc.

Conclusion

Domain specific languages(DSL) are focused towards a specific domain solution enabling easy development for domain experts. DSL are more domain specific than general languages. They are productive, reliable, and maintainable but on the other hand needs expertise, developmental tools and overhead cost involved which should be carefully considered before development. Thus, DSL are providing good solution for domain- specific problems but it has few issues to be considered. Recent development in various high level programming languages has addressed most these issues by development of various domain specific packages.

References

[1] Matteo Bordin, Tullio Vardanega "A Domain-specific Metamodel for Reusable Object-Oriented High-Integrity Components"

[2] Van Deursen "Domain-Specific Languages versus Object-Oriented Frameworks: A Financial Engineering Case Study"

[3] Jan Heering, Marjan Mernik "Domain-Specific Languages for Software Engineering"

[4] Martin Karlsch "A model-driven framework for domain specific languages demonstrated on a test automation language"

[5] Uwe Zdun "Concepts for Model­Driven Design and Evolution of Domain­Specific Languages"

[6] Dimitrios S. Kolovos, Richard F. Paige, Tim Kelly, and Fiona A.C. Polack "Requirements for Domain-Specific Languages"

[7] Paul Klint, Joost Visser "Domain-Specific Languages: An Annotated Bibliography1 Arie van Deursen"