Model Driven Engineering tools compared on user activities
In my previous post I gave you a quick overview of the roles involved in Model Driven Engineering. The question for today is how to support these roles with appropriate tooling?
Tools for Model Driven Engineering are often seen as a single category of tools. I’ll argue in this article that they can be separated in two categories: DSL (Domain Specific Language) tools and Model Driven Software Factories. Both types of tools have very different user activities. However, before going into details, let’s first explain the basics: what is a language workbench and what workbenches do we actually need in MDE?
What is a Language workbench?
Martin Fowler introduced the term Language Workbench a couple of years ago to refer to tooling supporting language-oriented programming. I see language-oriented programming as an important aspect of Model Driven Engineering, i.e. the meta level part of MDE. Martin Fowler defines a language workbench by naming the essential characteristics as follows:
- Users can freely define new languages which are fully integrated with each other.
- The primary source of information is a persistent abstract representation.
- Language designers define a Domain-Specific Language (DSL) in three main parts: schema, editor(s), and generator(s).
- Language users manipulate a DSL through a projectional editor.
- A language workbench can persist incomplete or contradictory information in its abstract representation.
If we compare these characteristics with the roles involved in MDE, we see that all roles need to use this language workbench for their own part of the job.
Needed workbenches in Model-Driven Engineering
Let’s take a step back. A language workbench as defined by Martin Fowler in principle consists of a couple of workbenches. So, what workbenches are needed in MDE? Let’s start with the MDE overview picture from my previous post (see Figure 1).
Figure 1 – Overview of Model Driven Engineering
In a model driven development process the dark grey artifacts exhibited in Figure 1 need to be specified somehow. Hence, we need at least three different workbenches. A domain expert and a language engineer together define a DSL in a DSL workbench with use of a meta language. A transformation specialist and an implementation expert together define the transformation rules in a transformation workbench with use of a transformation language. They define how models expressed in the defined DSL are executed. The last workbench is the solution workbench in which the business engineer and solution architect model an application with use of the defined DSL. An overview of the different workbenches and their users is given in Figure 2.
In reality an model driven software development process isn’t that straightforward. DSLs are meant to be domain-specific, i.e. they just model a system aspect. Hence, we need multiple DSLs to describe a software solution. That’s why we also need the role of software factory architect (or method engineer). Someone needs to define what models and DSLs are needed in a development process and how they are connected. In principle this role defines what workbenches are combined in a single MDE tool.
Figure 2 – Overview of workbenches in MDE
Model Driven Engineering Tools
Looking at the current market, we can distinguish between two main approaches in MDE tooling: DSL tools and Model Driven Software Factories.
Let’s compare them on the following points:
- Workbenches: what workbenches are included in the tool.
- Input: what is the input of the tool.
- Output: what is the output of the tool.
- Tool vendor activities: what does a tool vendor need to specify /build in order to create the tool.
- Tool user activities: what does the user of the tool need to specify in order to produce the output. This is of course related to the input, but it also includes the activities not guided by the tool.
- Examples: existing tools in this category (just a few examples, not an exhaustive list).
- Workbenches: DSL workbench and transformation workbench.
- Input: DSL definitions and transformation rules.
- Output: solution workbench and generator.
- Tool vendor activities: meta language definition, transformation language definition, workbench implementations.
- Tool user activities: DSL definitions, transformation rules, architecture definition, (domain) framework implementation.
- Examples: openArchitectureWare, MetaEdit+, Microsoft DSL Tools, JetBrains Meta Programming System.
Model Driven Software Factory:
- Workbenches: solution workbench.
- Input: functional specification.
- Output: working application.
- Tool vendor activities: DSL definitions, transformation rules, architecture definition, domain framework implementation, solution workbench implementation.
- Tool user activities: application modeling.
- Examples: Mendix (domain: Service Oriented Business Applications).
Depending on how well the DSL tool supports the definition of multiple DSLs (referring to each other, change propagation, etc.) and transformations, you can say that a Model Driven Software Factory can be the output of a DSL tool.
DSL tool or Model Driven Software Factory?
What tool you’ll need for your project depends on your specific wishes. A while ago Steven Kelly wrote an article on this subject from a financial perspective (in reaction on this post of me). He concludes with: "Building a DSL for your own use is a lot easier and cheaper, and gives greater benefits". I don’t agree with this conclusion.
Building your own DSLs, i.e. using DSL tools, gives you all the flexibility you’ll ever need. However, it also comes with a cost: DSL design isn’t that easy. Designing a full set of DSLs for modeling all application aspects will cost a lot of effort (the DSLs will evolve along with the applications you build with them). And don’t forget the training, language support, standardization, and maintenance of your languages.
A Model Driven Software Factory, on the other hand, is only useful if it precisely targets the domain you’re searching a solution for. You also need to commit you to the vendor of the factory. However, the domain of a Model Driven Software Factory can be quite broad and with current business process engines, workflow engines, and business rules engines, the used languages can be both applicable to multiple problem domains and easy to understand for business engineers. With a Model Driven Software Factory you can directly start using the DSLs for modeling your application and you don’t need to have the expertise in-house to define the languages, transformations, and generators yourself.
What type of tool you need depends on your situation. My advice: read and understand the characteristics of the different types of tools and make a choice for yourself.
What is your preferred choice?