Towards a Definition of MDE

Defining the nature of Model Driven Engineering (MDE) is not quite as simple as it may appear. On one hand, informal characterisations abound, with most similar in spirit to what Cuesta proposes (emphasis ours):

[Within MDE, software] development processes are conceived as a series of steps in which specification models, as well as those which describe the problem domain, are continually refined, until implementation domain models are reached — along with those which make up the verification and validation of each model, and the correspondence between them. In [MDE], the steps in the development process are considered to be mere transformations between models.¹, ² (Cuesta 2016) (p. 1)

On the other hand, formal definitions are found wanting. To make matters worse, the literature remains unclear as to whether MDE is an approach (Favre 2004), a methodology (Brambilla, Cabot, and Wimmer 2012), a technical space (Bézivin 2005), a paradigm (Völter et al. 2013) (Giese, Hildebrandt, and Neumann 2010), all, some or neither of these. Furthermore, there is a degree of imprecision as to how most of these terms are generally used within computer science. As an example, Harper made known his dissatisfaction with the term paradigm in his essay "What, if anything, is a programming paradigm?", stating:

The trouble with programming paradigms is that it is rather difficult to say what one is, or how we know we have a new one. Without precise definitions, nothing precise can be said, and no conclusions can be drawn, either retrospectively or prospectively, about language design. (Harper 2017)

MDE literature steers into similarly difficult terrain. In (Brambilla, Cabot, and Wimmer 2012), Brambilla et al. call MDE a methodology but then hasten to qualify they (emphasis ours)

[…] realise that methodology is an overloaded term, which may have several interpretations. In this context we are not using the term to refer to a formal development process, but instead as a set of instruments and guidelines […]. (Brambilla, Cabot, and Wimmer 2012) (p. 7)

Those qualifications and the imprecision of the language raise concerns as to the usefulness of the term, so we choose instead to side with Matinnejad (Matinnejad 2011) as well as Asadi and Ramsin (Asadi and Ramsin 2008), who make a strong case for calling MDE an approach or a general framework rather than a methodology.³ With regards to the remaining terms: heeding Harper's warnings above, we feel one should refrain from using the term paradigm altogether; and, whilst agreeing with the notion of MDE as a technical space, we address it in what we believe to be a more fitting context (cf. Technical Spaces).

The matter does not rest here, though, for there are additional viewpoints that must be taken into account when attempting to characterise MDE.

In our opinion, MDE is more than an approach. For our purposes, MDE is to be understood as a large body of knowledge focused on the employment of modeling as the principal driver of software engineering activities. This choice of wording may appear controversial at first sight, given the position of Mussbacher et al. (Mussbacher et al. 2014) — who stated that "[unlike] most other fields of engineering, model-driven engineering does not have a Body of Knowledge (BoK) as such." Nevertheless, both views can be reconciled by accepting a distinction between a formal Body of Knowledge — which MDE lacks — and an informal body of knowledge — which we posit MDE is.

The idea can perhaps be clarified by recourse to the words of Fairley and Chaffer (emphasis ours):

Every profession is based on a body of knowledge, although that knowledge is not always defined in a concise manner. In cases where no formality exists, the body of knowledge is "generally recognized" by practitioners and may be codified in a variety of ways for a variety of different uses. (Bourque, Fairley, and others 2014)

This, we believe, is an apt description of MDE from the perspective of the MDE practitioner. But in order for a practitioner to make sense of this vast and diverse body of knowledge, it is useful to arrange it into some form of structure.

One common method of overlaying structure into MDE is by way of classifying the application of modeling within the software development process. Here, researchers often distinguish between three different "levels" of modeling use, with each level seen as a super-set of the preceding (Ameller, n.d.) (Whittle, Hutchinson, and Rouncefield 2014) (Brambilla, Cabot, and Wimmer 2012). At the lowest level sits Model Based Engineering (MBE), where models are employed as a form of inter and intra-team communication and documentation. Within MBE, models are an input to the development process but, typically, software engineers are responsible for manually translating them into source code.

Next, at an intermediate level, sits Model Driven Development (MDD), where the software development process is driven entirely by models, and whose translation to code is performed by automated means. Finally, MDE is located at the highest level of the hierarchy; it orchestrates all engineering activities of a software system via modeling, including its development, operation and maintenance.⁴ Figure 1 provides a graphical illustration of these relationships.

Whilst this hierarchy is conceptually convenient and appeals to the intuition of most software engineers — possibly because it echoes earlier notions around Object-Based and Object Oriented (OO) programming⁵ — in practice, the layers are notoriously difficult to tease apart and are thus of limited use outside introductory material. Indeed, empirical observations such as those of Hutchinson et al. (Hutchinson et al. 2011) reveal that they are closer to a spectrum of possibilities rather than a set of well-defined categories. As a result, the terms MDD and MDE are used interchangeably in much of the literature, and their presence often merely signifies "a model-driven approach" instead of the more technical meaning intended by the hierarchy. And, sadly, this is just the end of the beginning of the confusing terminology.

Matters are further complicated by the existence of a number of additional model-driven approaches and methodologies outside the hierarchy, similar in characteristics but differing in naming, such as Model-Driven Software Engineering (MDSE) (Brambilla, Cabot, and Wimmer 2012), Model-Driven Software Development (MDSD) (Völter et al. 2013), Model Driven Architecture (MDA) (Poole 2001), Model-Integrated Computing (MIC) (Sprinkle 2004), Model Oriented Programming (MOP) (Badreddin and Lethbridge 2013), Model-Based Software Engineering (MBSE) (Estefan and others 2007) and many others. The literature customarily refers to these as MDE variants (Brambilla, Cabot, and Wimmer 2012) (p. 10) or MDE flavours (Völter et al. 2013) (p. 11), but these are not precise terms. Interestingly, our review did not uncover a much needed taxonomy or a detailed comparative study characterising variants and their relationships, in what appears to be a glaring gap in the literature.

The need for grouping is certainly present, for it is cumbersome have to name variants individually when making arguments that apply to model-driven in general. Völter sought to redress this shortcoming by grouping variants under the umbrella term MD* (Völter 2009) and it quickly became established practice in the literature. However, it is not yet clear if the existence of this grouping has helped or hindered those seeking to understand what MDE is, specially as there is no rigorous definition of the members of the group nor of its properties, much beyond Völter's original — and uncharacteristically carefree — comment: "I use MD* as a common moniker for MDD, MDSD, MDE, MDA, MIC, and all the other abbreviations for basically the same approach." (Völter 2009)

With a hint of well-placed irony, Brambilia et al. spoke of the MD* Jungle (Brambilla, Cabot, and Wimmer 2012) (p. 9), adding that (emphasis ours) "MDE can be seen as the superset of all these variants, as any [MD*] approaches could fall under the MDE umbrella." (Brambilla, Cabot, and Wimmer 2012) (p. 10) It is in this sense that the term MDE is to be understood within this context — a sense, we believe, that is entirely consistent with its role as a body of knowledge. However, questions are then raised as to how best determine what is inside the informal body of knowledge, as opposed to what remains outside.

Much like the boundaries from within, the boundaries from without are no less troublesome to isolate. Over time, MDE has been integrated with a number of existing approaches and methodologies such as Software Product Line Engineering (SPLE) (Pohl, Böckle, and van Der Linden 2005), Agile (Matinnejad 2011), Generic Programming (GP) and Domain Engineering (Czarnecki 1998) — to name but a few — to an extent that its now difficult to determine whether certain concepts should be included as part of MDE's body of knowledge or are extraneous to it. A similar problem occurs with terms defined in its variants such as Model Driven Architecture (MDA), particularly for those which have wider applicability to modeling problems outside the MDE variant itself.

Our review of the literature did not uncover any adequate solutions to this thorny problem. Though by no means authoritative, our approach was to include in the present analysis all of the concepts that are relevant to our purposes and to use the notion of integrations where the concepts are more obviously external to MDE — e.g., "Agile integration" (cf. Software Development Methodologies). But all the difficulties discussed thus far point out there may be a deeper malaise with the discipline itself.

Jörges et al. encapsulated all of these themes in a manner that could be construed as an indictment to the entire endeavour (emphasis ours):

This "fuzziness" or lack of precision can be observed for most of the vocabulary used in the context of MD*. There is still no established fundamental theory of modeling and related concepts that would be comparable to the maturity achieved in other disciplines of computer science, such as compiler construction. (Jörges 2013) (p. 14)

However, behind the lack of precision lies method, as Bézivin's incisively explains: "[we] are not interested here by a theoretical definition […] but by an engineering one, i.e. a definition that will help users to implement and maintain systems." (Bézivin 2005) Citing Fowler (Fowler 2004), Brambilla et al. go as far as warning practitioners to "[b]eware of statements of pure principles: when it comes down to it, the real point of software engineering practice is to increase productivity, reduce errors, and cut code." (Brambilla, Cabot, and Wimmer 2012) (p. 23) Translated to the software development vernacular, MDE sees fuzziness as a feature, not a bug. This is a very significant statement of intent. For the remainder of this work we shall refer to it as the Pragmatism Principle, albeit restated in a slightly different form:⁶

When defining terms within MDE['s] body of knowledge, engineering definitions are preferred over theoretical definitions. That is, pragmatic definitions that help practitioners implement and maintain the systems of today, even when imprecise, are preferred over rigorous theoretical definitions that are either not yet completely formulated or that fail to meet the helpfulness criteria.

In our opinion, the Pragmatism Principle helps explain the apparent fuzziness of a significant subset of MDE's vocabulary for, in an environment where operational definitions abound, there is a permanent danger of duplication, inconsistencies and misunderstandings. After all, what suffices for one use case may not do at all for others. Nonetheless, we view the Pragmatism Principle as an important factor in MDE's progress and find it to be consistent with our view of MDE as a body of knowledge rather than a methodology or a paradigm, as we are no longer constrained by a need for rigour at all costs or even for overall consistency.

Note that the Pragmatism Principle is not a carte blanche to legitimise and empower sloppy reasoning. Rigour is still important to MDE, as are theoretical foundations, and the lack of fundamentals often appears in MDE research roadmaps (France and Rumpe 2007) (Mussbacher et al. 2014). The Pragmatism Principle merely justifies using an empiric approach to enable progress whilst the theoretic foundations are being laid, and presupposes the ability to make a trade-off between rigour and applicability where needed. And these trade-offs are not restricted to rigour and pragmatism either.

Seen from the present vantage point, Model Driven Engineering's (MDE) role — de facto if not de jure — has been to provide the building blocks from whence model-driven methodologies can be constructed, to the precise specifications of its practitioners. And, in this regard, it has been very successful. In our opinion, the main downside of the Pragmatism Principle — and thus, of the approach as a whole — is that it places a great deal of responsibility on the practitioner to make the correct trade-offs, therefore requiring a high-level of mastery of a large and complex cannon.⁷

At this juncture we can now sketch out our understanding of the discipline, which is as follows:

• MDE is an informal body of knowledge centred on the employment of modeling as the principal driver of software engineering activities.
• MDE promotes the pragmatic application of a family of related approaches to the development of software systems, with the intent of generating automatically a part or the totality of a software product, from one or more formal models and associated transformations (cf. Models and Transformations).
• MDE is best understood as a vision rather than a concrete destination. A vision guides the general direction of the approach, but does not dictate the solution, nor does it outline the series of steps required to reach it.⁸

• It is the responsibility of the MDE practitioner to select the appropriate tools and techniques from the MDE body of knowledge, in order to apply it adequately to a specific instance of the software development process. By doing so, the practitioner will create — implicitly or explicitly — an MDE variant.

Now that we have a basic understanding of MDE's reach⁹, we can turn our attention towards its core concepts: Models and Transformations.