From Problem Space to Solution Space

Kurtev et al. proposed Technical Spaces (TS) in their seminal paper (Kurtev, Ivan and Bézivin, Jean and Aksit, Mehmet, 2002), defining them as follows: "A technological space is a working context with a set of associated concepts, body of knowledge, tools, required skills, and possibilities." Mens and Van Gorp subsequently updated the language and tightened the notion by connecting it to metametamodels: "A technical space is determined by the metametamodel that is used (M3-level)." (Mens, Tom and Van Gorp, Pieter, 2006) Examples of TS include MDE itself, XML, Java and other such programming languages.

In (Bézivin, Jean and Dupé, Grégoire and Jouault, Frédéric and Pitette, Gilles and Rougui, Jamal Eddine, 2003), Bézivin et al. outlines their motivation: "The notion of TS allows us to deal more efficiently with the ever-increasing complexity of evolving technologies. There is no uniformly superior technology and each one has its strong and weak points." The idea is then to engineer bridges between technical spaces, allowing the importing and exporting of artefacts across them. These bridges take the form of adaptors called "projectors", as Bézivin explains (emphasis ours):

The responsibility to build projectors lies in one space. The rationale to define them is quite simple: when one facility is available in another space and that building it in a given space is economically too costly, then the decision may be taken to build a projector in that given space. There are two kinds of projectors according to the direction: injectors and extractors. Very often we need a couple of injector/extractor to solve a given problem. (Bézivin, Jean, 2005)

TS are a useful — if somewhat imprecise⁸ — conceptual device and bridging across them has been demonstrated to work in practice (Bézivin, Jean and Dupé, Grégoire and Jouault, Frédéric and Pitette, Gilles and Rougui, Jamal Eddine, 2003). However, our position is that to fully fulfil their promise, an extraordinary engineering effort is required to model all significant features from existing TS, to expose them to modeling languages and to keep those models updated. As we shall see in the next section, much of the same challenges apply to platforms.

The term platform is employed within the software engineering profession in a broad a variety of contexts, from hardware to operative systems, compilers, IDE like the Eclipse Platform⁹, virtual machines providing programming environments such as the JVM and the CLR, and in numerous other cases. It is also a core term within MDE, and a foundation upon which many other concepts build, so it is important to arrive at a clear understanding of its meaning.

The literature often uses the MDA definition as a starting point, stated as follows:

A platform is the set of resources on which a system is realized. This set of resources is used to implement or support the system. In the context of a technology implementation, the platform supports the execution of the application. Together the application and the platform constitute the system. (Object Management Group, 2014) (p. 9)

From a software engineering standpoint, a platform is often seen as mechanism for reuse and abstraction, but MDE goes further and considers as particularly useful those that are "semantically rich" and "domain-specific", \marginpar{Versus MDE} made up of "prefabricated, reusable components and frameworks [because they] offer a much more powerful basis than a 'naked' programming language or a technical platform like J2EE." (Völter, Markus and Stahl, Thomas and Bettin, Jorn and Haase, Arno and Helsen, Simon, 2013) (p. 15)

Figures 2 and 3 explore these ideas by depicting the relationship between platforms and TS. From this perspective, TS provide the raw building materials and platform developers leverage their technical expertise to, in the words of Brambilla et al., "combine them into a coherent platform" (Brambilla, Marco and Cabot, Jordi and Wimmer, Manuel, 2012) (p. 13). By sitting atop a platform, software engineers can abstract themselves from lower-level implementation details and focus on the problem at hand.

In the presence of code generation, a tempting alternative may appear to be to bind the building blocks directly against a modeling language. Experience has however demonstrated the pitfalls of this approach, and here we are once more faced with the familiar theme of a need to raise the abstraction level. In practice, the building blocks found in TS are at too low a level to make them suitable for direct integration with a modeling approach because, as already discussed (cf. Section The Structure of the Solution Space), bridging the abstraction gap becomes increasingly difficult as the gap widens. Stahl et al. agree, but focus instead on the converse, stating that "[the] platform has the task of supporting the realization of the domain, that is, the transformation of formal models should be as simple as possible. […] Clearly, the easier the transformations are to build, the more powerful is the platform." (Völter, Markus and Stahl, Thomas and Bettin, Jorn and Haase, Arno and Helsen, Simon, 2013) (p. 61) France and Rumpe follow the same line of reasoning, positing that abstractions such as platforms are key, because "[the] introduction of technologies that effectively raise the implementation abstraction level can significantly improve productivity and quality with respect to the types of software targeted by the technologies." (France, Robert and Rumpe, Bernhard, 2007)

Unfortunately, not all is positive. On the same paper, France and Rumpe leave a decidedly stark warning about the challenges created by the very same process: "[the] growing complexity of newer generations of software systems can eventually overwhelm the available implementation abstractions, resulting in a widening of the problem-implementation gap." In other words, modeling languages close to a platform can only remain relevant if they are continually kept up to date with the constant changes to the platforms they depend on, or else risk becoming obsolete. This is a very difficult problem to tackle.

An obvious way to mitigate issues that arise from the constant platform churn is to decouple platform-dependent concepts from those that are independent of a target platform. This partitioning — originally popularised within MDA but now rightfully considered a part of mainstream MDE — does not directly address the underlying causes but does have the advantage of reducing the overall impact surface. As a result, by classifying models with regards to their dependence on a platform, we arrive at the notion of Platform Independent Model (PIM) and Platform Specific Model (PSM). In (Völter, Markus and Stahl, Thomas and Bettin, Jorn and Haase, Arno and Helsen, Simon, 2013) (p. 20), Stahl et al. explain that "[…] concepts are more stable than technologies […]. The PIM abstracts from technological details, whereas the PSM uses the concepts of a platform to describe a system." A secondary advantage of this approach is that a single PIM can be mapped to multiple PSM, as demonstrated by Figure 4.

However, when one looks at these elegant solutions in more detail, the literature enters once more difficult terrain. First and most significantly, there are still looming challenges in establishing just what exactly a platform is. Bézivin explains the matter rather eloquently (emphasis ours):

There is a considerable work to be done to characterize a platform. How is this related to a virtual machine (e.g. JVM) or to a specific language (e.g. Java)? How is this related to a general implementation framework (e.g. DotNet or EJB) or even to a class library? How to capture the notion of abstraction between two platforms, one built on top of the other one? The notion of a platform is relative because, for example, to the platform builder, the platform will look like a business model. One may also consider that there are different degrees of platform independence, but here again no precise characterization of this may be seriously established before we have an initial definition of the concept of platform. (B{\'e}zivin, Jean, 2005)

Secondly, there is the question of how the mappings are to be achieved. In the same paper, Bézivin suggested employing Platform Definition Models (PDMs) as a way to bridge this gap — that is, the use of models to describe the capabilities of platforms. This and several other ideas informed research, which became very active and produced a number of localised solutions, for example in the context of MDA (Wagelaar, Dennis and Jonckers, Viviane, 2005) and XML (Neubauer, Patrick, 2016). Nonetheless, a general approach to the problem remains illusive, as Anjorin et al. explain (emphasis theirs):

Although there exist numerous strategies and mature tools for certain isolated subtasks or specific applications, a general framework for designing and structuring model-to-platform transformations, which consolidates different technologies in a flexible manner, is still missing, especially when bidirectionality is a requirement. (Anjorin, Anthony and Saller, Karsten and Rose, Sebastian and Sch{\"u}rr, Andy, 2012)

Their work provides an informed summary of the state of the art on this regard, as well as proposing a promising direction for such a generalised framework; nevertheless, substantial research and engineering work remains, in order to address all of the issues highlighted above.

Thirdly, there are those who question the need to make PSM explicitly visible, asking whether they are not best seen as a conceptual device and a (hidden) implementation detail. Stahl et al. report that "[p]ractical project experience has hitherto proved that this simplification [of foregoing explicitly visible PSMs] is usually more useful than the additional degrees of freedom gained with PSMs." (Völter, Markus and Stahl, Thomas and Bettin, Jorn and Haase, Arno and Helsen, Simon, 2013) (p. 24) According to them, such a simplification permits more efficient development and reduces the thorny issues around model synchronisation, particularly from lower to higher levels of abstraction — i.e., the propagation of changes from PSM to PIM (cf. Section The Structure of the Solution Space).¹⁰

In light of all of these difficulties, and even taking into account the Pragmatism Principle, one is nevertheless forced to conclude that Bézivin's words of warning still to loom large over the field: "Answering the question of what is a platform may be difficult, but until a precise answer is given to this question, the notion of platform dependence and independence (PSMs and PIMs) may stand more in the marketing than in the technical and scientific vocabulary." (B{\'e}zivin, Jean, 2005)

These stimulating words complete our sketch of the solution space and its challenges. Our attention shall now turn "upwards" once more, towards the bigger picture, as we investigate the interaction between MDE and the various methodologies and processes used for the development of software systems.