Domain-Specific Modeling

(based on [FR05a])

Looking at other engineering disciplines, it is evident that modeling is a vital and important part of the development of complex artifacts. Good modeling techniques provide support for the separation of concerns principle, rigorous analysis of designs, and for structuring construction activities. Models can play a similar role in the development of software-based systems. Furthermore, the software development activity has a characteristic not present in physical engineering: deliverable products (software systems) can be generated from models (an observation made by Bran Selic, IBM/Rational at an MDA summer school). This characteristic can and should be exploited in our quest to make software development an engineering activity.

The current landscape of modeling languages is highly diverse. Graphical languages, such as Petri Nets and Statecharts have successfully been used for years. Standardized languages such as the SDL have had a good base of tool support but have seen their use in industry diminish over time. Languages can be specific to an application domain (e.g., SDL was developed to support modeling of telecommunication systems), to a development phase (e.g., SCR method uses a language designed specifically for modeling requirements of reactive systems), or they can be general-purpose (e.g., the UML). Recently, much attention is on the development of domain-specific languages (DSLs). Proponents of DSLs claim that their use can help bridge the gap between a domain expert’s view of a software system and its implementation. The domains covered by DSLs can range from highly individual application areas, such as “railroad planning applications” to broader domains, such as the “embedded system domain”.

The UML was at first an attempt to unify various object-oriented modeling languages, and it seemed that its target applications were primarily business systems. The UML is now being used to model applications and concepts in a variety of domains, including embedded systems and business workflows. While this broadened the scope of the UML it has made it difficult to develop semantics that can be used to support its application in a number of domains. This has led to the realization that a single, consistent semantics that supports the use of the UML may not be possible, and to the view of the UML as a family of languages. There are currently a number of semantic variation points in the UML to support this notion. Developing a semantic framework for the UML that takes into consideration its numerous variation points is proving to be an extremely difficult task – and the important issues are not all technical!

It should not be surprising then that in specific domains, the use of existing “domain-specific languages” persists. A DSL, let it be a programming or a modeling language, has several advantages. Among them:

  • Domain-specific constructs are better suited for communication with users in the domain. The users can better understand the models if they are presented in domain-specific terms. This leads to the claim that domain-specific models are better suited for requirements engineering than the UML.
  • DSLs have restricted semantic scope (i.e., the number of semantic variations they have to deal with is small compared with general-purpose languages), thus developing a semantic framework is less challenging.
  • Restricting semantic scope can lead to better support for generating implementations from models. Given an appropriate component-framework that implements individual constructs of the DSL, the composition of these components can lead to powerful implementations.
  • DSL’s increase domain-specific reuse of components, which can lead to improved the quality of systems and order-of-magnitude improvements in time-to-market and developer productivity. Examples from the telecommunication indicate that a speedup factor of ten is possible.

So far DSL’s have been developed in an ad-hoc manner, that is tooling was implemented without much reuse of existing technology. Reuse was limited in some cases to use of graphical framework for developing editors and the use of parser generators for textual languages. More recent work has focused on making the development of DSLs more systematic. Among the DSL development environments that are being created are Meta-Editors and graphical editor environments that allow developers to quickly create new DSLs and associated editors. In the MDA/MOF context, general data structures for the abstract syntax of models and techniques for their transformation are under development. Software companies such as Microsoft have identified this as an important area of development, and Microsoft and have released early versions of DSL development environments.

The advent of frameworks for developing DSLs will raise new challenges, some of which are identified below:

  • (C1) If building or improving a DSL is a vital part of a project, the development process needs to incorporate these new activities. = It is not yet clear if a new breed of software development specialists (domain engineers?) will be needed to effectively carry out these new activities.
  • (C2) Two questions that will have to be addressed can be stated as follows: Is there a need for company or industry-wide standard DSLs? If yes, who will develop the standards?
  • (C3) If the burden of defining a new DSL becomes considerably lower, we will probably see a large number of DSLs created and used. The situation will be similar to the one faced with the use of XML-Dialects: Many Dialects will appear and their interoperability or translation between them will be a major problem. This could give rise to a modeling Tower of Babel.
  • (C4) To prevent the Tower of Babel, it might be necessary to build DSLs on a common syntactical and semantic base that reaches far beyond a common infrastructure for defining abstract syntax. The UML might provide such a base, but how can one derive a structural or behavioral DSL from a sub-language of the UML?
  • (C5) A language should have a semantics (in its original meaning of “meaning”). Will a DSL development framework support practical definition of DSL semantics of DSLs? How can this be done?

This essay is essentially taken from a SoSyM editorial, which is published under the Creative Commons licence and contains some updates:

  1. [FR05a]
    R. France, B. Rumpe:
    Domain specific modeling.
    In: Journal Software and Systems Modeling (SoSyM), Volume 4(1), pp. 1-3, Springer Berlin / Heidelberg, 2005.