State of the Art in Code Generation

The literature on CASE is expansive, and yet, in our opinion, it still fails to deliver an authoritative definition of the term. This is perhaps no more clearly illustrated than via Fisher's compendium (Fisher and Fisher 1988), where he first calls it a "nebulous term" and then dispenses not just one but two definitions, both of which rather broad in scope (emphasis ours):

One definition of computer-aided software engineering is the use of tools that provide leverage at any point in the software development cycle. […] A more restrictive but operationally better definition for computer-aided software engineering is the use of tools that provide leverage in the software requirements analysis and design specification phases, as well as those tools which generate code automatically from the software design specification. (Fisher and Fisher 1988) (p. 6)

Whatever its precise meaning, what most definitions have in common is the sketching of a wide domain boundary for CASE systems — supporting the full range of activities in the software engineering lifecycle — as well as providing automated "methods of designing, documenting and development of the structured computer code in the desired programming language." (Berdonosov and Redkolis 2011) CASE was, by any measure, an extremely ambitious programme, with lofty if laudable goals — as Fisher goes on to explain (emphasis ours):

The ultimate goal of CASE technology is to separate design from implementation. Generally, the more detached the design process is from the actual code generation, the better. (Fisher and Fisher 1988) (p. 5)

Though many of its ideas live on, perhaps unsurprisingly, the CASE programme as a whole did not take hold within the broad software engineering community — or, at least, not in the way most of those involved envisioned.⁷ Understanding why it was so imparts instructive lessons, particularly if you have an interest in automatic programming as does the present work. With similar thoughts in mind, Jörges (Jörges 2013) (p. 19) combed through the literature and uncovered a number of reasons which we shall now revisit, as well as supplementing them with two of our own towards the end.

1. Deficiencies of translation into source code. Though instituting an incredibly diverse ecosystem⁸, most CASE tooling emphasised black-box transformation of graphical modeling languages into source code. There was a belief that automatic code generation for entire systems was looming in the horizon — with Fisher going as far as prophesying the emergence of "a software development environment so powerful and robust that we simply input the application's requirements specification, push a magic button, and out comes the implemented code, ready for release to the end user community." (Fisher and Fisher 1988) (p. 283) Perhaps due to this line of reasoning, generated code was often not designed to be modified, nor were systems built to support user defined code generators — both of which were required in practice. The resulting solutions were convoluted and difficult to maintain.
2. Vendor lock-in. CASE predates the era of widely available Free and Open Source Software (FOSS), and therefore there was a predominance of proprietary software. As with vendor lock-in in general, it was not in the vendor's best interest to facilitate interoperability since, by doing so, it would inadvertently help customers migrate to a competitor's product. As a result, reusability and interoperability were severely hampered. In addition, given the proliferation of small and mid-sized vendors, there was a real difficulty in choosing the appropriate tool for the job — the consequences of which could only be judged long after purchase.
3. Lack of support for collaborative development. Given the state of technology in the era when these tools were designed, it is understandable they did not adequately support the complex collaborative use cases that are required to facilitate the software engineering process. However, some of the difficulties transcended technology and were exacerbated by the vendor lock-in mentioned above; having data silos within each application — with narrow interfaces for data injection and extraction — meant it was difficult to supplement application workflows with external tooling.
4. Limitations in graphical modeling languages. The generic nature of contemporary graphical modeling languages meant they were found wanting on a large number of use cases; oftentimes they were "too generic and too static to be applicable in a wide variety of domains" (Jörges 2013) (p. 20).
5. Unfocused and overambitious vision. As already hinted by the lack of a formal definition, in our opinion CASE is a great example of a movement within software engineering that proposes an overly ambitious agenda, and one in which outcomes are extremely difficult to measure, either quantitatively or qualitatively. Due to this, it is hard to determine success and failure, and harder still to discern how its different components are fairing. In such a scenario, there is the risk of stating that "CASE failed" when, in reality, some of its key components may have been salvaged, modified and repackaged into other approaches such as MDE.
6. Emphasis on full code generation. Subjacent to CASE's goals is the notion that one of the main impediments to full code generation of software systems is a formal language of requirements which is fit for purpose.⁹ However, in hindsight, it is now clear that attaining such a general purpose formal specification language is an incredibly ambitious target.

More certainly can be said on the subject of CASE's shortcomings, but, in our opinion, those six findings capture the brunt of the criticism. These lessons are important because, as we shall see (cf. Section Model Driven Engineering), MDE builds upon much of what was learned from CASE — even if it does not overcome all of its stated problems. However, before we can turn in that direction, we must first complete our historical review by summarising an approach with similar ambitions in the field of automatic programming.

In sharp contrast with CASE's lighter approach to theory, Czarnecki's influential doctoral dissertation (Czarnecki 1998) extended his prior academic work — standing thus on firmer theoretical grounds. In it, he puts forward the concept of Generative Programming (GP). GP focuses on (emphasis ours):

[…] designing and implementing software modules which can be combined to generate specialized and highly optimized systems fulfilling specific requirements. The goals are to (a) decrease the conceptual gap between program code and domain concepts (known as achieving high intentionality), (b) achieve high reusability and adaptability, (c) simplify managing many variants of a component, and (d) increase efficiency (both in space and execution time). (Czarnecki 1998) (p. 7)

Of particular significance is the emphasis placed by GP on software families rather than on individual software products, as Czarnecki et al. elsewhere explain (emphasis ours):

Generative Programming […] is about modeling families of software systems by software entities such that, given a particular requirements specification, a highly customized and optimized instance of that family can be automatically manufactured on demand from elementary, reusable implementation components by means of configuration knowledge […]. (Czarnecki et al. 2000)

In sharp contrast with CASE (cf. Section CASE), GP provides a well-defined conceptual model, populated by a small number of core concepts which we shall now enumerate. At the centre lies the generative domain model, responsible for characterising the problem space (i.e., the domain of the problem), the solution space (i.e. the set of implementation components) as well as providing the mapping between entities in these spaces by means of configuration knowledge.¹⁰ Though GP does not dictate specific technological choices at any of the levels of its stack, Feature Models (Czarnecki, Helsen, and Eisenecker 2005) are often used as a means to capture relevant features of the problem domain, as well as relationships amongst them. Concrete software systems are obtained by specifying valid configurations, as dictated by the modeled features, and by feeding the configuration knowledge to a generator, which maps the requested configuration to the corresponding implementation components.

As with CASE, GP did not come to dominate industrial software engineering¹¹, but many of the ideas it championed have lived on and are now central to MDE; the remainder of this chapter will cover some of these topics, with others described elsewhere (Craveiro 2021b) (Chapters 4 and 6 in particular). In our opinion, GP also benefited from cross-pollination with CASE — for example, by attempting to address some of its most obvious shortcomings such as de-emphasising specific technological choices and vendor products, and focusing instead on identifying the general elements of the approach. Alas, one downside of generalisation is the difficulty it introduces in evaluating the approach in isolation; many of the factors that determine the success or failure of its application are tightly woven with the circumstances and choices made by actors within a given instance of the software engineering process — a ghost that will return to haunt MDE (cf. FIXME Chapter). And it is to MDE which we shall turn to next.

Though the academic press has no shortage of literature on MDE¹², it is largely consensual when it comes to its broad characterisation. Cuestas, for example, states the following (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)

However, as we argued previously at length (Craveiro 2021b), this apparent consensus is somewhat misleading, and a characterisation of the fundamental nature of MDE is not as easy as it might appear at first brush.¹⁴ In the afore-cited manuscript, we concluded that the MDE nature is instead better summarised as follows (page 13, emphasis ours):

• 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.
• 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.

The onus is thus on specific MDE variants, rather than on the body of knowledge itself, to lay down the details of how the model-driven approach is to be carried out. In this light, we have chosen to focus on two MDE variants, in order to better grasp the detail. The first is MDA, chosen not only due to its historical significance — in our opinion, it remains the most faithful embodiment of MDE's original spirit and vision — but also because it serves as an exemplary framework to demonstrate the application of MDE concepts. The second variant is AC-MDSD, which was selected because of its importance for MASD (cf. FIXME Chapter). As we shall see, these two variants are also of interest because they put forward contrasting approaches to MDE. Let us begin then by looking at the first of the pair.

MDA is a comprehensive initiative from OMG and arguably the largest industry-wide effort to date, attempting to bring MDE practices to the wider software engineering community.¹⁵ Based on the OMG set of specifications — which include UML (- OMG 2017b) as a modeling language, the MOF (Meta-Object Facility) (- OMG 2016) as a metametamodel and QVT (Query / View/ Transformation) (- OMG 2017a) as a transformation language — MDA is designed to support all stages of software development lifecycle, from requirements gathering through to business modeling, as well as catering for implementation-level technologies such as CORBA (- OMG 2012).

Though more concrete and circumscribed than MDE, MDA is still considered an approach rather than a methodology, in and of itself.¹⁶ The approach's primary goals are "portability, interoperability, and reusability of software". (Group 2014). Beyond these, the MDA Manifesto (Booch et al. 2004) identifies a set of basic tenets that articulate its vision and which serve complementary purposes (Figure 1). These are as follows:

• Direct representation. There is a drive to shift the locus of software engineering away from technologists and the solution space, and place it instead in the hands of domain experts and on the problem space. The objective is to empower experts and to reduce the problem-implementation gap.¹⁷
• Automation. The aim is to mechanise all aspects of the development process that "do not depend on human ingenuity" (Booch et al. 2004). Automation is also crucial in addressing the problem-implementation gap because it is believed to greatly reduce interpretation errors.
• Open standards. By relying on open standards, MDA hoped to diminish or even eliminate Booch et al.'s "gratuitous diversity" (Booch et al. 2004) and to encourage the development of a tooling ecosystem designed around interoperability, with both general purpose tooling as well as specialised tools for niche purposes.¹⁸

Figure 2 presents a selection of MDA's basic terminology as per OMG documentation, which is, unsurprisingly, in line with the MDE terminology defined thus far — as well as that of the supplementary material (Craveiro 2021b). This is to be expected given the central role of MDA in the early development of MDE itself.¹⁹ A noteworthy term on that list is viewpoint, for MDA sees systems modeling as an activity with distinct vantage points or perspectives. Viewpoints give rise to architectural layers at different levels of abstraction, each associated with its own kind of models:

• Computation Independent Model (CIM): The "business or domain models" (Group 2014). Describes business functionality only, including system requirements. CIM are created by domain experts and serve as a bridge between these and software engineers.
• Platform Independent Model (PIM): The "logical system models" (Group 2014). PIMs describe the technical aspects of a system that are not tied to a particular platform.²⁰
• Platform Specific Model (PSM): The "implementation models" (Group 2014). PSMs augment PIMs with details that are specific to a platform, and thus are very close to the implementation detail.

Figure 3 provides a simplified illustration of how the three types of models are related. Instance models are intended to be created using either UML — with appropriate extensions, as required, by means of UML Profiles — or via any other MOF based modeling language, preexisting or specifically created for the needs of the system. M2M transforms can be handled by QVT — including cascading transformations from CIM to PIM and to PSM — or by any other MOF based MT language such as ATL (Atlas Transformation Language) (Jouault et al. 2008). Finally, a large ecosystem of code generation tools, frameworks and standards have evolved for MDA, such as MOFScript (Oldevik et al. 2005), MOFM2T (- OMG 2008) and, arguably most significantly of all, the EMF (Eclipse Modeling Framework) (Steinberg et al. 2008) (Steinberg et al. 2009)²¹ — all of which which facilitate the generation of code from PSMs.

Faced with a potentially large number of heterogeneous models, a requirement often emerges to weave them together to form a consistent overall picture.²² Within MDA, this role is performed by model compilers. Whilst the literature does not readily supply a rigorous definition for the term, Mellor clearly delineates the role they are expected to play, as well as outlining their challenges (emphasis ours):

A model compiler takes a set of executable UML models²³ and weaves them together according to a consistent set of rules. This task involves executing the mapping functions between the various source and target models to produce a single all-encompassing metamodel […] that the includes all the structure, behavior and logic — everything — in the system. […] Weaving the models together at once addresses the problem of architectural mismatch, a term coined by David Garlan to refer to components that do not fit together without the addition of tubes and tubes of glue code, the very problem MDA is intended to avoid! A model compiler imposes a single architectural structure on the system as a whole. (Mellor 2004)

Outside of executable models, model compilers are often associated with MDA code generation, transforming PIM and PSM directly into source code. The line between MDA's code generators and model compilers is blurry, both due to the imprecise terminology as well as the fact that code generators often need to conduct some form of model weaving prior to code generation. Several MDA code generators exist, including AndroMDA²⁴ and Jamda²⁵, and these typically allow for extensibility by means of plug-ins — the much maligned cartridges.²⁶

And it is with cartridges that we round-off MDA's concepts relevant to MASD. Clearly, an overview as brief as the present cannot do justice to the breadth and depth of MDA. However, for all of its impressive achievements, MDA is not without its detractors. Part of the problem stems from the early overambitious claims, which, as we shall see in FIXME Chapter, were not entirely borne out by evidence.²⁷ In addition, UML itself has been a source of several criticisms, including sprawling complexity, a lack of formality in describing its semantics, too low a level of abstraction, and the difficulties in synchronising the various UML models needed to create a system.²⁸

Certain challenges are wider than UML and pertain instead to OMG's stance towards standardisation. On one hand, open and detailed specifications undoubtedly facilitated MDA's adoption and helped create a large and diverse tooling ecosystem. On the other hand, they also abetted an heterogeneous environment with serious interoperability challenges, populated by large and complex standards that forced practitioners to have a deep technical knowledge in order to make use of them. As a result, numerous aspects of these standards are not fully utilised by practitioners, with many either ignoring them altogether or resorting to more trivial use cases. There is also a real danger of ossification, with some standards not seeing updates in years — partially because the processes for their development are drawn-out and convoluted.

This state of affairs led Thomas to conclude that the best course of action is perhaps a lowering of expectations: "Used in moderation and where appropriate, UML and MDA code generators are useful tools, although not the panaceas that some would have us believe." (Thomas 2004) Reading between the lines, one is led to conclude that at least part of MDA's problems stem from its vast scope. It is therefore interesting to compare and contrast it with the next variant under study, given it takes what could be construed as a diametrically opposed approach.

Product of several years of field experience, Stahl et al. introduced AC-MDSD as a small part of their seminal work on MDSD (Völter et al. 2013) (p. 21).²⁹ In their own words, "[…] AC-MDSD aims at increasing development efficiency, software quality, and reusability. This especially means relieving the software developer from tedious and error-prone routine work." Though it may be argued that the concepts around M2P (Model-to-Platform) transforms for infrastructural code were already well-established within MDE, having their roots in ideas such as MDA model compilers and MDA code generators (cf. Section MDA), it is important to note that AC-MDSD has very few commonalities with MDA. It is a minimalist approach, specified only at a high-level of abstraction and inspired mainly by practical experimentation.

AC-MDSD's very narrow focus makes it a suitable starting point for the exploration of model-driven approaches, as Stahl et al. go on to explain (emphasis ours):

We recommend you first approach MDSD via architecture-centric MDSD, since this requires the smallest investment, while the effort of its introduction can pay off in the course of even a six-month project. Architecture-centric MDSD does not presuppose a functional/professional domain-specific platform, and is basically limited to the generation of repetitive code that is typically needed for use in commercial and Open Source frameworks or infrastructures (sic.). (Völter et al. 2013) (p. 369)

The core idea behind AC-MDSD emanates from Stahl et al.'s classification of source code into three categories:

• Individual Code: Code crafted specifically for a given application, and which cannot be generalised.
• Generic Code: Reusable code designed to be consumed by more than one system.
• Schematic and Repetitive Code: Also known as boilerplate or infrastructure code, its main purpose is to perform a coupling between infrastructure and the application, and to facilitate the development of the domain-specific code.

As represented diagrammatically in Figure 4, schematic and repetitive code can amount to a significant percentage of the total number of LOC in a given system, with estimates ranging between 60% to 70% for web-based applications (Völter et al. 2013) (p. 369) and 90% or higher for embedded systems development (Czarnecki 1998).^30,31 Besides the effort required in its creation, infrastructure code is also a likely source of defects because its repetitive nature forces developers to resort to error prone practices such as code cloning (Staron et al. 2015). Code generators do exist to alleviate some of the burden — such as wizards in IDE and the like — but they are typically disconnected and localised to a tool, with no possibility of having an overarching view of the system. Thus, the goal of AC-MDSD is to provide an holistic, integrated and automated solution to the generation of infrastructural code.

Following this line of reasoning, Stahl et al. theorise that systems whose software architecture has been clearly specified have an implementation with a strong component of schematic and repetitive programming; that is, the system's architecture manifests itself as patterns of infrastructural code, thus ultimately leading to the idea of generative software architectures. In a generative software architecture, the schemata of the architecture is abstracted as elements of a modeling language; domain models are created for an application, and, from these, code generators create the entire set of infrastructural code. In the simplest case, the modeling language can be created as a UML Profile with the required architectural concepts, and the instance models then become PIM (cf. Section MDA). For simplicity, Stahl et al. recommend bypassing explicit transformations into PSMs prior to code generation, and generate code directly from the PIM instead. Once a generative software architecture is put in place, only a small step is required to move towards the creation of product lines.

With regards to the construction of software systems, Stahl et al. propose a two-track iterative development model, where infrastructural engineering is expressly kept apart from application development, though allowing for periodic synchronisation points between the two — a useful take that is not without its dangers, as will be shown shortly. In addition, given only infrastructural code is targeted, AC-MDSD presupposes a need for integrating handcrafted code and generated code, with full code generation explicitly defined as a non-goal. The onus is on the MDE practitioner to determine the most suitable integration approach for the system in question, aided and abetted by the literature — for instance, by deploying the techniques such as those surveyed by Greifenberg et al. (Greifenberg et al. 2015a) (Greifenberg et al. 2015b).

Experience reports of AC-MDSD usage in various contexts do exist, though they are by no means numerous and appear to lack a critical analysis of theory and application (Al Saad et al. 2008) (Escott, Strooper, King, et al. 2011) (Escott, Strooper, Suß, et al. 2011) (Manset et al. 2006). The paucity may be attributable, at least in part, to researchers employing terminology other than AC-MDSD, rather than to the principles espoused — the afore-cited evidence, anecdotal though it may be, does suggest a favouring of the overall approach by software engineers when they embark on MDE.³² In the absence of authoritative points of view, we have chosen to undertake a critique from personal experience, rooted on our adoption of AC-MDSD on a large industrial project (Craveiro 2021a). Whilst limited, and though it pre-empts the discussion on MDE adoption (cf. FIXME Chapter), there are nevertheless advantages to this take, since the principal difficulty with AC-MDSD lies on the specifics of its application rather than with the sparseness of the theoretical framework.

We shall start by identifying the importance of AC-MDSD, which in our opinion is understated in the literature. As Stahl et al.'s quote above already hinted, infrastructural code is seen as low-hanging fruit for MDE because it is arguably the most obvious point to automate in the development of a software system. Carrying on from their analysis, our position is that the following interdependent factors contribute to this outcome:³³

• Ubiquitous Nature: Infrastructural code is prevalent in modern software systems, as these are composed of a large number of building blocks³⁴ which must be configured and orchestrated towards common architectural goals. It is therefore a significant problem, and its only increasing with the unrelentingly growth of software (cf. Section The Importance of Code Generation).
• Deceptively Easy to State: Unlike other applications of MDE, the issues addressed by AC-MDSD are easy to state in a manner comprehensible to all stakeholders. Existing systems have numerous exemplars that can serve as a basis for generalisation — employable simultaneously as a source of requirements, as well as a baseline for testing generated code. For new systems, engineers can manually craft a small reference implementation and use it as the target of the automation efforts, as did we, twice — (Craveiro 2021a) Section 4.5, and FIXME Section of the present document.
• Deceptively Easy to Measure: The costs associated with the manual creation and ongoing maintenance of infrastructural code are apparent both to software engineers as well as to the management structure, because they are trivially measurable — i.e. the total resource-hours spent creating or maintaining specific areas of the code base against the resource-hour cost is a suitable approximation. Engineers also know precisely which code they intend to replace, because they must identify the schematic and repetitive code. As a corollary, simplistic measures of cost savings are also straightforward to impute.³⁵
• Deceptively Easy to Implement: The creation of technical solutions to realise AC-MDSD are deceptively simple to implement, as there is an abundance of template-based code generation tools that integrate seamlessly with existing programming environments — e.g. Microsoft's T4 (Vogel 2010) (p. 249), EMF's XText (Eysholdt and Behrens 2010), etc.³⁶ These tools are supplied with a variety of examples and target software engineers with little to no knowledge of MDE.
• Produces Results Quickly: As already noted by Stahl et al., limited efforts can produce noticeable results, particularly in short to medium timescales but, importantly, the full consequence of its limitations play out at much longer timescales.

Perhaps because of these factors, many localised AC-MDSD solutions have been created which solve non-trivial problems, meaning the approach undoubtedly works. However, in our experience, AC-MDSD has inherent challenges which we ascribe to the following interrelated reasons.

Firstly, it exposes end-users to the complexities of the implementation and that of MDE theory, discouraging the unfamiliar. Paradoxically, it may also result in approaches that ignore MDE entirely — that which we termed unorthodox practitioners³⁷ in (Craveiro 2021a) — and thus present inadequate solutions to problems that have already been addressed competently within the body of knowledge. This happens because its easy to get up-and-running with the user friendly tooling — that is, without any foundational knowledge — but soon the prototype becomes production code, and mistakes become set in stone; before long, a Rubicon is crossed beyond which there is just too much code depending on the generated code for radical changes to be feasible.

Secondly, the more automation is used, the higher the cost of each individual solution because customisation efforts require a non-negligible amount of specialised engineering work, and will need continual maintenance as the product matures. The latter is of particular worry because these costs are mostly hidden to stakeholders, who may have been led to believe that the investment in infrastructural code "had already been made", rather than seeing it as an ongoing concern throughout the life of a software system.

The third problem arises as the interest on the technical debt (Cunningham 1992) accrued by the first three factors comes due. Naive interpretations of AC-MDSD inadvertently trade velocity and simplicity in the short term for complexity and maintenance difficulties in the long term — at which point all deceptions are unmasked.³⁸ This temporal displacement means that when the consequences are ultimately felt, they are notoriously difficult to quantify and address; by that time, the system may be on a very different phase of its lifecycle (i.e. maintenance phase).

Fourthly, end-users are less inclined to share solutions because the commonalities between individual approaches at the infrastructural level may not be immediately obvious due to a lack of generalisation. Knowledge transfer is impaired, we argue, because practitioners and tool designers view their infrastructural code as inextricably linked to the particular problem domain they are addressing or to a specific tool, and thus each developer becomes siloed on an island of their own making. This notion is reinforced by MDE's vision of every developer as a competent MDE practitioner, able to deploy the body of knowledge to fit precisely its own circumstances, and further compounded by MDE's focus on the problem space rather than the solution space.³⁹ Conversely, aiming for generalisation is only possible once practitioners have mastered the MDE cannon, which takes time and experience. Thus, systems with similar needs may end up with their own costly solutions, having little to no reuse between them.

Alas, generalisation is no silver bullet either, as attested by the fifth and final challenge: that of problem domain decoupling.⁴⁰ This issue emerges as the emphasis shifts from special purpose AC-MDSD solutions towards a general purpose approach, within a two-track development framework. With this shift, the relative scopes of the application domain versus the infrastructural domain also shift accordingly, and what begins as a quantitative change materialises itself as a qualitative change. Figure 5 models a simplified version of the dynamic in pictorial form, though perhaps implying a discreteness to the phenomena which is not necessarily present in practice.

Though subtle at first, these changes are eventually felt for (emphasis theirs):

[…] as the scope of the infrastructural domain grows, it becomes a software product in its own right. Thus, there is an attempt to simultaneously engineer two tightly interlocked software products, each already a non-trivial entity to start off with. At this juncture one may consider the ideal solution to be the use of vendor products as a way to insulate the problem domains. Unfortunately, experimental evidence emphatically says otherwise, revealing that isolation may be necessary but only up to a point, beyond which it starts to become detrimental. We name this problem over-generalisation.⁴¹ (Craveiro 2021b) (p. 47)

In other words, there is a fine balancing act to be performed between under and over generalisation, with regards to the infrastructural domain and the problem domain; finding the right balance is a non-trivial but yet essential exercise (emphasis theirs):

What is called for is a highly cooperative relationship between infrastructure developers and end-users, in order to foster feature suitability — a relationship which is not directly aligned with traditional customer-supplier roles; but one which must also maintain a clear separation of roles and responsibilities — not the strong point of relationships between internal teams within a single organisation, striving towards a fixed goal. Any proposed approach must therefore aim to establish an adequate level of generalisation by mediating between these actors and their diverse and often conflicting agendas. We named this generalisation sweet-spot barely general enough, following on from Ambler’s footsteps (Ambler 2007)⁴², and created Figure 5.5 to place the dilemma in diagrammatic form. (Craveiro 2021b) (p. 47)

As we shall see (cf. FIXME Chapter), this quest for an approach targeting the barely general enough sweet-spot has greatly influenced the present work.

In summary, our opinion is that those very same attributes that make AC-MDSD amenable as a starting point for MDE exploration are also closely associated with its most significant downsides. Interestingly, this double-edged sword characteristic is not unique to AC-MDSD, but instead generalises well to MDE — as the next chapter will describe in detail.