Models and Transformations

Unlike the difficulties faced in defining MDE's boundaries (cf. Conditions at the Boundaries), the literature presents a far more consensual picture on the reasons for modeling. Predictably, it emanates mainly from without, given the importance of models in most scientific and engineering contexts. Due to this, we have limited our excursion to two often cited sources in the early MDE literature: Rothenberg and Stachowiak.

In "General Model Theory" (Stachowiak 1973), Stachowiak proposes a model-based concept of cognition and identifies three principal features of models:

• Mapping: Models map individuals, original or artificial, to a category of all such individuals sharing similar properties. The object of the mapping could itself be a model, thus allowing for complex composition.
• Reduction: Models focus only on a subset of the individual's properties, ignoring aspects that are deemed irrelevant.
• Pragmatism: Models have a purpose as defined by its creators, which guides the modeling process. Stachowiak states (emphasis ours): "[models] are not only models of something. They are also models for somebody, a human or an artificial model user. They perform therefore their functions in time, within a time interval. And they are finally models for a definite purpose."¹

Much of the expressive power of models arises from these three fundamental properties.

For his part, Rothenberg's contribution (Rothenberg et al. 1989) also gives a deep insight into the nature of models and the modeling process² and, in particular, his statements on substitutability are of keen interest when uncovering the reasons for modeling (emphasis his):

Modeling, in the broadest sense, is the cost-effective use of something in place of something else for some cognitive purpose. It allows us to use something that is simpler, safer or cheaper than reality instead of reality for some purpose. A model represents reality for the given purpose; the model is an abstraction of reality in the sense that it cannot represent all aspects of reality. This allows us to deal with the world in a simplified manner, avoiding the complexity, danger and irreversibility of reality.

Taken together, the properties identified by Rothenberg and Stachowiak make it clear that software engineering is inevitably deeply connected to models and modeling, as is any other human endeavour that involves cognition. However, this implicit understanding only scratches the surface of possibilities. In order to extract all of the potential of the modeling activity, explicit introspection is necessary. Evans eloquently explains why it must be so (emphasis ours):

To create software that is valuably involved in users' activities, a development team must bring to bear a body of knowledge related to those activities. The breadth of knowledge required can be daunting. The volume and complexity of information can be overwhelming. Models are tools for grappling with this overhead. A model is a selectively simplified and consciously structured form of knowledge. An appropriate model makes sense of information and focuses it on a problem. (Evans 2004) (p. 3)

Therefore, it is important to model consciously; with a purpose. In order to do so, one must first start with a better understanding of what is meant by "model" in the context of the target domain.

The term model is used informally by software engineers as a shorthand for any kind of abstract representation of a system's function, behaviour or structure.³ Ever critical in matters of rigour, Jörges et al. (Jörges 2013) (p. 13) remind us that "[the] existence of MD* approaches and numerous corresponding tools […] indicates that there seems to be at least a common intuition of what a model actually is. However, there is still no generally accepted definition of the term 'model'." In typical pragmatic form, Bézivin (Bézivin 2005a) provides what he calls an "operational engineering definition of a 'model'" (emphasis ours): "[…] a graph-based structure representing some aspects of a given system and conforming to the definition of another graph called a metamodel." Stahl et al. call this a formal model (NO_ITEM_DATA:Stahl:2006:MSD:1196766) (p. 58).

The crux here is to address ambiguity. A formal model is one which is expressed using a formal language, called the modeling language, and designed specifically for the purpose of modeling well-defined aspects of a problem domain. A modeling language needs to be a formal language because it must have well-defined syntax and semantics, required in order to determine if its instances are well-formed or not. The next sections provide an overview of these two topics; since the literature was found to be largely consensual, the focus is solely on their exposition. We then join these two notions as we revisit the concept of metamodel.

Given these concepts, we can now elaborate further on Bezivin's definition above, and connect them from a modeling point of view. Formal models are instances of a modeling language, which provides the modeler with the vocabulary to describe entities from a domain. Together, the abstract syntax and the static semantics of the modeling language make up its metamodel, and instance models — by definition — must conform to it.

Employing terminology from Kottemann and Konsynsk (Kottemann and Konsynski 1984), the metamodel can be said to capture the deep structure that connects all of its instance models, and the instance models are expressed in the abstract syntax of the modeling language — its surface structure. Within this construct, we now have a very clear separation between the entities being modeled, the model and the model's metamodel as they exist at different layers of abstraction.⁴ However, the layering process does not end at the metamodel.

Since all formal models are instances of a metamodel, the metamodel itself is no exception: it too must conform to a metametamodel. The metametamodel provides a generalised way to talk about metamodels and exists at a layer above that of the metamodel. Though in theory infinite, the layering process is typically curtailed at the metametamodel layer, since it is possible to create a metametamodel that conforms to itself.⁵,⁶

Following on from the above-mentioned work of Kottemann and Konsynski (Kottemann and Konsynski 1984), and that of many others, the OMG standardised these notions of an abstraction hierarchy into a four-layer metamodel architecture that describes higher-order modeling. Bézivin (Bézivin 2005b) referred to it as the 3+1 architecture, and summarised it as follows: "[at] the bottom level, the M0 layer is the real system. A model represents this system at level M1. This model conforms to its metamodel defined at level M2 and the metamodel itself conforms to the metametamodel at level M3." Figure 1 illustrates the idea. Its worthwhile pointing out that the four-layer architecture is a typical example of the constant cross-pollination within MDE, as it was originally created in the context of what eventually became the MDA but nowadays is seen as part of the core MDE cannon itself (Brambilla, Cabot, and Wimmer 2012).⁷

As the literature traditionally explains the four layer model by means of an example (Bézivin 2005b) (Brambilla, Cabot, and Wimmer 2012) (Henderson-Sellers and Bulthuis 2012), we shall use a trivial model of cars to do so. It is illustrated in Figure 2. Here, at M0, we have two cars with licence plates "123-ABC" and "456-DEG". At M1, the two cars are abstracted to the class Car, with a single attribute of type String: LicencePlate. At M2, these concepts are further abstracted to the notions of a Class and Attribute. Car is an instance of a Class, and its property LicencePlate is an instance of Attribute. Finally, at M3, we introduce Class; M2's Class and Attribute are both instances of M3's Class, as is M3's Class itself.

The four-layer metamodel architecture has important properties. For example, whilst terms "model" and "meta" are often used in a relative (and even subjective) manner, within the architecture they now become concise — i.e., metametamodel is an unambiguous term within this framework. In addition, it was designed as a strict metamodeling framework. Atkinson and Kühne explain concisely the intent (emphasis theirs):

Strict metamodeling is based on the tenet that if a model A is an instance of another model B then every element of A is an instance-of some element in B. In other words, it interprets the instance-of relationship at the granularity of individual model elements. The doctrine of strict metamodeling thus holds that the instance-of relationship, and only the instance-of relationship, crosses meta-level boundaries, and that every instance-of relationship must cross exactly one meta-level boundary to an immediately adjacent level. (Atkinson and Kühne 2002)

Strict metamodeling is not the only possible approach — Atkinson and Kühne go on to describe loose metamodeling on the same paper — nor is the four-layer metamodel hierarchy itself free of criticism. On this regard, we'd like to single out the thorough work done by Henderson-Sellers et al. (Henderson-Sellers et al. 2013), who scoured the literature to identify the main problems with the architecture, and surveyed proposed "fixes", which ranged from small evolutionary changes to "paradigm shifting" modifications. Their work notwithstanding, our opinion is that, though the four-layer metamodel has limitations, it forms a reasonably well-understood abstraction which suffices for the purposes of our own research.

An additional point of interest — and one that perhaps may not be immediately obvious from the above diagrams — is that MDE encourages the creation of "multiple metamodels", each designed for a specific purpose, though ideally all conforming to the same metametamodel. As a result of this metamodel diversity — as well as due to other scenarios described on the next section — operations performed on models have become key to the modeling approach.

The second most significant component of MDE , after models, are Model Transformations (MTs) or just transforms. MTs are functions defined over metamodels and applied to their instance models. MTs receive one or more arguments, called the source models, and typically produce one or more models, called the target models. Source and target models must be formal models, and they may all conform to the same or to different metamodels.

The literature has long considered MT themselves as models (Bézivin 2005b), thus formalisable by a metamodel and giving rise to the notion of MT languages; that is, modeling languages whose domain is model transformations. MT languages are an important pillar of the MDE vision because they enable the automated translation of models at different levels of abstraction. Figure 3 provides an example of how MT languages work, when transforming one type of model to another. However, these are not the only type of MT found in the literature.

The literature commonly distinguishes between two classes of modeling languages, according to their purpose (Brambilla, Cabot, and Wimmer 2012) (p. 13):

• General Purpose Modeling Languages (GPML): These are languages that are designed to target the modeling activity in the general case, and as such can be used to model any problem domain; the domain of these languages is the domain of modeling itself. The UML (- OMG 2017) is one such language.¹⁰
• Domain Specific Language (DSL): These are languages which are designed for a specific purpose, and thus target a well-defined problem domain. They may have broad use or be confined to a small user base such as a company or a single application. As an example, the authors report in (Craveiro 2021) on the experiences and challenges of a financial company creating their own modeling DSL.

Figure 5 captures how modeling languages relate to the terminology introduced thus far.

As with most MDE terminology, this classification is not universally accepted. For instance, Stahl et al. (Völter et al. 2013) (p.58) take the view that (emphasis theirs) "[often] the term modeling language is used synonymously with DSL. We prefer the term DSL because it emphasizes that we always operate within the context of a specific domain." Somewhat unexpectedly, Jörges et al. (Jörges 2013) (p. 15) agree with this stance. We are instead of the opinion that conflating DSL with modeling languages hinders precision unnecessarily and thus is not a useful development. For the remainder of this work, we shall use the three terms (modeling language, GPML and DSL) with specifically the above meanings.¹¹ The crux of the problem is, then, in deciding how a given modeling problem is to be tackled.

There are obvious advantages in clarifying the relationship between programming languages and modeling languages, because the latter can benefit from the long experience of the former. Predictably, the literature has ample material on this regard. Whilst discoursing on the unification power of models, Bézivin spoke of "programs as models" (Bézivin 2005b); France and Rumpe tell us that "[source] code can be considered to be a model of how a system will behave when executed." (France and Rumpe 2007) Indeed, from all that has been stated thus far, it follows that all general purpose programming languages such as C++ and Java can rightfully be considered modeling languages too and their programs can be thought of as models implemented atop a grammarware stack.

Here we are rescued by Stahl et al., who help preserve the distinction between programming languages and modeling languages by reminding us that they have different responsibilities (emphasis ours): "The means of expression used by models is geared toward the respective domain’s problem space, thus enabling abstraction from the programming language level and allowing the corresponding compactness." (Völter et al. 2013) (p. 15) That is, programming languages are abstractions of the machine whereas modeling languages are abstractions of higher-level problem domains — a very useful and concise separation (cf. Spaces and Levels of Abstraction).¹⁵

With this, we arrive at the taxonomy proposed by Figure 6.

A related viewpoint from which to look at the relationship between modeling languages and programming languages is on how information can be propagated between the two via MT (cf. Section Models and Their Transformations). The simplest form is via forward engineering, whereby a model in a modeling language is transformed into a programming language representation, but changes made at the programming language level are not propagated back to the modeling language.

The converse happens when using reverse engineering: a model in a modeling language is generated by analysing and transforming source code in a programming language. Clearly, there are difficulties in any such an endeavour due to the mismatch in abstraction levels, as explained above. Finally, the most difficult of all scenarios is RTE (Round Trip Engineering), in which both modeling and programming language representations are continually kept synchronised, and changes are possible in either direction. Figure 7 illustrates these three concepts.

As briefly alluded to in Section Models and Their Transformations, these and other related topics fall under the umbrella of model synchronisation within MDE literature. They are addressed in From Problem Space to Solution Space, which starts to delve in more detail into MDE's aspirations of matching modeling languages to different abstraction levels.