DSL and MDE, necessary assets for Model-Driven approaches
I’ve written a lot about Model-Driven Engineering (MDE). MDE is a broader concept than Model-Driven Architecture (MDA), it adds multiple modeling dimensions and the notion of a software engineering process. While MDA mainly focuses on technical variability by making a difference between platform independent and platform dependent models and by defining transformations between these models, the focus of MDE is also on application-domain variability by adding modeling dimensions for subject areas and architectural aspects.
In the context of model-driven software development the term Domain-Specific Language (DSL) is often mentioned, often as an alternative for MDA. I’ve already written an article focusing on the implementation of DSL’s using metamodels, slightly touching the subject of combining MDE and DSLs. In this article I’d like to explain how MDE and DSL’s are complementary and how they are both necessary for a successful model-driven approach.
Domain expert, programmer
MDE as framework for connecting DSL’s
Model-Driven Engineering (MDE) defines multiple modeling dimensions in addition to the abstract/concrete dimension defined in the Model-Driven Architecture (MDA).
Kent  defines two additional categories of dimensions needed for MDE. The first category contains various dimensions of concern, like different subject areas and different system aspects. The second category of dimensions is less concerned with the technical aspects of a system, but more with organizational issues, like authorship, version (as in version and configuration control), location (in case the system development is distributed across sites) and stakeholder (such as business expert or programmer).
In software development projects it is necessary to determine the important dimensions for a particular project. In most projects authorship and versioning will be important, but other dimensions need the identification of points of interest, like which subject areas play a role and which system aspects are of importance. Another important decision is the levels of abstraction to be used in the process and which stakeholders are involved (for which understandable models have to be made). When building models in a software development process, each model can be placed at an intersection of the dimensions.
For the sake of concreteness, Table 1 shows some example dimensions and their possible values.
|Abstract / concrete||CIM, PIM, PSM|
|Subject areas||Order entry, customer portal, back-end administration, …|
|Aspects||Data, presentation, security, business rules, workflows, …|
|Stakeholders||Domain expert, programmer|
Table 1 – Example dimensions for an MDE project
Examples of models for the dimensions presented in Table 1 are:
- A Computation Independent Model (CIM) of the workflows of the order entry part of the software artifact aimed at a domain expert.
- A Platform Independent Model (PIM) of the data of the back-end administration part of the software artifact aimed at a domain expert.
- A Platform Specific Model (PSM) of the security of the customer portal part of the software artifact aimed at a programmer.
The various dimensions at an intersection play an important role in the choice for a modeling language for that particular model. By example, the modeling language is influenced by the subject area, the stakeholders and the level of abstraction. Such a language is mostly indicated as a Domain-Specific Language (DSL).
And no… a DSL for a modeling language doesn’t mean that it should be a visual / graphical DSL. A model is just an abstract representation of reality and it can also be expressed using a textual DSL.
In short: an MDE methodology defines a framework of dimensions and their intersections, thereby defining the different models needed to describe a certain software application. This information also gives us the opportunity to discuss the needed DSL’s in a (more or less) formal way. Last but not least, an MDE methodology also describes a software engineering process and a maintenance process, thereby defining the order in which models should be produced, how they are transformed into each other (if applicable) and how to change an existing software system using models.
A DSL can be defined as :
DSL is a programming language or executable specification language that offers, through appropriate notations and abstractions, expressive power focused on, and usually restricted to, a particular problem domain.
The domain specificity of a language is a matter of degree. Any language has a certain scope of applicability, but some of them are more focused than others. In general we can separate between two types of domains a DSL can be targeted at:
- Knowledge domains: a field of knowledge or activity characterized by a set of concepts and terminology understood by practitioners in that field.
- System families: a set of software systems that exhibit similar functionality. This domain can be seen as a specialized kind of knowledge domain.
In principle the knowledge domain can be compared to the aspect dimension of MDE, while the system family domain can be compare to the subject area dimension. While designing an MDE methodology it’s an important decision what kind of DSLs have to be defined. If we recall the example dimensions and their values presented in Table 1, we see that defining a DSL for each intersection of dimensions (i.e. for each model) will result in 90 different DSLs (i.e. 3 values at the abstract/concrete dimension, multiplied with 3 values at the subject area dimension, multiplied with 5 values at the aspect dimension, multiplied with 2 values at the stakeholder dimension), which is way too much. The following considerations can be taken into account for reducing the number of needed DSLs:
- Implement DSLs in a way that they are directly executable on a specific platform. For making them executable on another platform the generator or interpreter needs to be rewritten. This eliminates the abstract/concrete dimension.
- Make DSLs extensible by existing GPLs, programmers can formulate the necessary additions in a language they know. This eliminates the stakeholder dimension.
- Focus on the aspect dimension, i.e. define a DSLs for each aspect. Only define a DSL for a subject area if the subject area is very specific (e.g. a specific financial system part).
If we apply these recommendations on our example we can reduce the number of DSLs from 90 to 5. We only need DSLs for the aspects: data, presentation, security, business rules, workflows. Although we still have to define a lot of models, which is quite normal for big software systems, we only have to use five different languages.
Why should we use Domain-Specific Languages?
Languages can be compared using levels based on the number of code statements needed for implementing a function point. This results in a table ranging from low level languages like natural language, machine language and assembly to high level languages which are targeted at a very specific domain (see the SPR programming languages table). Although the difference between a GPL and a DSL is a matter of degree, I think we should only consider the more focused languages as a DSL, such as BNF, HTML or SQL.
A DSL can offer several important advantages over a GPL :
- Domain-specific abstractions: a DSL provides pre-defined abstractions to directly represent concepts from the application domain. Consequently, domain experts themselves can understand, validate, modify, and often even develop DSL programs .
- Domain-specific concrete syntax: a DSL offers a natural notation for a given domain and avoids syntactic clutter that often results when using a GPL.
- Domain-specific error checking: a DSL enables building static analyzers that can find more errors than similar analyzers for a GPL and that can report the errors in language familiar to the domain expert.
- Domain-specific optimizations: a DSL creates opportunities for generating optimized code base on domain-specific knowledge, which is usually not available to a compiler for a GPL.
- Domain-specific tool support: a DSL creates opportunities to improve any tooling aspect of a development environment, including, editors, debuggers, version control, etc.; the domain-specific knowledge that is explicitly captured by a DSL can be used to provide more intelligent tool support for developers.
Deursen et al.  add that DSLs embody domain knowledge, and thus enable the conservation and reuse of this knowledge. Eric Evans  also emphasizes that for tackling the complexity of software development a language is needed understandable by both developers and domain experts.
However, the benefits of DSLs do not come for free. DSL development is hard, requiring both domain and language development expertise. Few people have both. Besides that, depending on the size of the user community, development of training material, language support, standardization, and maintenance may become serious and time-consuming issues.
Although they both focus on raising the level of abstraction in software development, the MDA approach and the DSL approach are often seen as totally different or opposite approaches. I think MDA should be enriched to what I define as MDE. In that case MDE and DSL’s are complementary and necessary for a model-driven approach.
MDE is needed to define the kind of models we need to describe a software application and to define an engineering and maintenance process, i.e. how to build and maintain software using models.
DSL’s are needed to define languages for expressing the models. With use of the MDE modeling dimensions the scope of the DSL’s can be defined in a more precise way. That’s very important because one of the biggest pitfalls of DSL design is that the scope grows and grows due to changing requirements, with the result that you’ll end up with some sort of GPL.
End note: MDA and MDE are often associated with graphical models due to the focus of the OMG on their UML standard. I think the language you use to express a model should be as much tailored as possible. Not only the semantics, but also the syntax. Hence textual DSL’s
can should be a part of MDE.
 S. Kent, "Model driven engineering," in IFM ’02: Proceedings of the Third International Conference on Integrated Formal Methods. London, UK: Springer-Verlag, 2002, pp. 286-298.
 A. v. Deursen, P. Klint, and J. Visser, "Domain-specific languages: An annotated bibliography." ACM SIGPLAN Notices, vol. 35, no. 6, pp. 26-36, Jun. 2000.
 K. Czarnecki, "Overview of generative software development," in UPP, 2004, pp. 326-341.
 E. Evans, Domain Driven Design: Tackling Complexity in the Heart of Software. Addison-Wesley, 2004.