Model Driven Engineering (MDE) is all about raising the level of abstraction. It is ironic, then, that many have difficulty defining, communicating about, or working with it, due to it being . . . well . . . too abstract. MDE, as a term, is itself an abstraction. In other words it is a term folks use to encapsulate, package up and hide a whole bunch of details. The difficulty is not so much that it is abstract as it is that MDE is a composite.
The Anatomy of Model Driven Engineering
Model Driven Engineering (MDE) is all about raising the level of abstraction. It is ironic, then, that many have difficulty defining, communicating about, or working with it, due to it being . . . well . . . too abstract.
MDE, as a term, is itself an abstraction. In other words it is a term folks use to encapsulate, package up and hide a whole bunch of details. The difficulty is not so much that it is abstract as it is that MDE is a composite. By composite, we mean something composed of, and that can be broken down into, its definite component parts. MDE has an anatomy. Anything, broken down into its parts, i.e. its anatomy, is easier to understand, talk about and work with. And so it is with Model Driven Engineering.
MDE – Its Anatomy
In its essence and simplicity, MDE is the creation of domain specific languages, editors and generators (this last one is more generally referred to as transformation facilities).
Graphically, this could be depicted as the following:
The arrows are also important as there are dynamic forces each way. Parts of the language have an influence on what the editor looks like. Conversely, and not understood by many folks, is the fact that certain editor and tooling features can push back and bring about change in the language definition. Similar dynamics exists between all parts of this triangle, both ways.
Of course this anatomy is more complex and we will discuss and expand upon that later in this article. So one shouldn’t argue at this point as to whether this anatomy diagram is complete. It breaks the composite of MDE down one level, to an extremely practical level.
The most productive aspect of breaking down MDE into its anatomical parts is that MDE becomes much more practical. One can’t pull up MDE, per se, in their computer screen. One can, however, pull up and examine the language. They can look at the editor. One can look at the generators. Nothing wrong with abstraction for sure, but it helps to be able to literally point your finger at its anatomical parts.
Language – this is the grammar, the vocabulary relationships between terms. In its simplest form, it is the things and the relationships between things. It is the language definition. It is the rules for what makes up the language that others will be speaking/writing/using. It is actually quite constraining, but that is on purpose. It makes it only possible to talk with and about certain things in certain ways.
Editor – This what users use to express their design intent. It captures how the domain experts want to express their ideas. As you might imagine, it has a tight relationship with the Language. In the past, the editor has not received the importance it should and in this diagram it is formally nominated as a first class MDE element.
Generator – The facility provides the “way back” from the abstraction created by the Language and the Editor. In other words, the generator, traverses through the artifacts in the editor and maps these items to lower level, usually more executable, software artifacts.
Below is just a simple example of what each of these might look like.
Expanding on the Triangle
We definitely can expand the anatomy and diagram to make the MDE picture more complete. Sometimes the complication of a diagram reaches a point of diminishing returns which is why we stick primarily with the Language-Editor-Generator triangle and move forward from their with the traction that that provides. Nonetheless, below are some additions and discussion of more aspects of MDE.
Let’s talk a moment about something called constraints. These are also part of the MDE landscape. Constraints are artifacts that assist in making sure the language is used correctly and providing feedback to the user when things are incorrect (or even correct). They make it easier to do the right thing and hard to do the wrong thing. These constraints, however, can exist in many forms and in many areas, including in the three corners of the MDE triangle. By its very definition, the Language constrains the user to only use the elements and relationships that are defined in the language. Additional constraints can be added to the Language in addition to the formal language definition. Constraints can also exist at the Tooling/Editor level quite independent of or in concert with the constraints provided by the Language. It is in the editor that feedback from constraint violations or compliances are presented to the user. It can be presented in graphical, textual or other forms. It can also provide constraint violation solution suggestions. Constraints also exist at the generator level. This is where the notion of “correct by construction” comes in whereby one can be constrained (or assisted depending on how you want to look at it) so as to work with only what the generator provides.
Share this article: