Domain Architecture

At a first glance, MASD's physical analysis and design appears to be a simple expression of Domain Engineering's Domain Analysis and Domain Design (Marco Craveiro, 2021) (Chapter 6), when applied to MASD's physical domain. However, since the shift in perspective caused by the "problem space / solution space inversion" adds significant complexity, it is important to understand the specificity of this application. Figure 2 helps in doing so by portraying both in simplified form: on the left, we have Domain Analysis and Domain Design — often used in an MDE context — and, on the right, MASD's physical analysis and design. The two approaches are separated by a bold black line.

In the figure, yellow circles represent physical artefacts such as files and directories, clustered around dashed blue squares that denote individual TSs. For their part, light-blue circles represent logical elements such as classes and other high-level modeling constructs, likely in TS agnostic form. On the left side of the figure, one begins by observing a nebulous problem domain and designing a set of logical entities to form one or more models that fit requirements. Those logical entities will ultimately give rise to concrete physical entities through refinement, although these are often viewed as mere by-products of the process.⁴

In contrast, the right-hand side of the picture reflects MASD's call for the reversal of this approach: physical entities themselves become the problem domain and one arrives at their logical representation, denoted by orange circles, through empirical analysis, with the core problem domain losing relevance in the process (far right).⁵ Though perhaps not clear from the diagram, MASD's emphasis is on a comparative analysis of physical elements across TSs, not on the metamodels associated with each TS. It is so because MASD's analysis is driven by empirical evidence within the physical domain, rather than by the logical entities and meta-entities that inhabit each TS — even if the latter is more in keeping with MDE's ethos of metamodel to metamodel transforms (Marco Craveiro, 2021) (Chapter 3).⁶

A consequence of this favouring of empirical evidence is that physical analysis and design became distinct from that of their traditional MDE counterparts, where discussions with stakeholders and UML diagrams from a business viewpoint abound.⁷ In contrast, their application within MASD is closer, at least in spirit, to the modeling of scientific objects such as neurons, which were inspirational.⁸ Since the object of our study are Schematic and Repetitive Patterns in the Physical space (SRPPs), we opted for designing a specific approach for their handling which combines physical analysis and design into a single process, described next.⁹

The first challenge in modeling SRPPs is in defining their nature. As already alluded to in The MASD Methodology, SRPPs are conceptually close to Stahl et al.'s schematic and repetitive code; however, physical patterns were preferred over code so as to bring clarity to our ubiquitous language. Whilst source code is MASD's primary target — it is, by definition, the central artefact type in a conventional software product — the methodology aims to model any physical entity manifesting schematic and repetitive patterns, making the new nomenclature a better reflection of these broader aspirations.¹⁰

Terminology aside, an open question remained on what was meant precisely by the term, so placing the concept on firmer ground was a priority. We did so by stating three axioms upon which all our analysis was to rest. First, ascertaining what is "schematic and repetitive" was declared to be a subjective matter, relative to many qualitative factors such as the experience of the observer, and thus demanding extensional definitions.^{11, 12}

Secondly, regardless of their subjective nature, we decided that:

• not all physical entities have patterns, nor are all patterns schematic and repetitive; these we deemed to lay largely beyond the scope of MASD.¹³
• a physical entity may be partially composed of schematic and repetitive patterns, and thus only partially under the remit of MASD (cf. the Relations section).

Thirdly, and most significantly, we equated the discovery of physical entities with schematic and repetitive patterns to the modeling of physical entities at a level of detail sufficient for their reproduction. In other words, one determines if a physical pattern is schematic and repetitive by reproducing it by automated means; if it is possible to do so, then a pattern is deemed to be an SRPP.

What follows from these axioms is that an empirical process of discovery is needed in order to uncover patterns of interest. To arrive at such process, ad-hoc experimentation was carried out on a number of artefacts from an initial set of projects, until reproduction was achieved. Reflecting on the endeavour, we identified a number of well-defined steps:

1. Sampling: one must first determine the size of the physical sample, ensuring adequate coverage — e.g. across different TSs, possibly of different kinds, files of different types, and so forth.
2. Decomposition (or Segmentation): each entity in the sample must be analysed in detail, and divided into well-defined constituent parts called segments.
3. Labelling and Classification: the identified parts must be named and categorised by means of taxonomic and morphological analysis. These will give rise to models of the physical entities and their constituent parts.
4. Reconstruction: the models are then used to recreate the original physical entity — for example via M2T transforms — at which point the pattern is declared to be a SRPP.
5. Cataloguing and Parameterisation: finally, the model for the entity is placed in the broader context of the existing catalogue of patterns. Doing so may entail merging the functionality with existing entities, adding additional parameterisation to existing entities, and so on.

Whilst well-defined in theory, note that the modeling process laid out here is a generalisation of what happens in practice, for these steps are seldom applied in such a clear-cut manner. There often is an overlap between steps, as well as a need for continued iteration in order to obtain the best results. In addition, though our work incorporated all of these steps, several challenges were faced initially due to the ad-hoc nature of the approach, as we tried to gain a better understanding of its mechanics. Sampling proved to be particularly problematic. Firstly, our original sample was composed of two trivial C++ and C# projects — in software engineering parlance, "hello world" projects — but these evolved over time and ultimately become the MRI's C++ and C# reference products.^{14, 15} Secondly, the source code of the MRI code generator was also incorporated into our sample, even as it mutated drastically over time.^{16, 17} Clearly, a more disciplined experimental approach would have been beneficial, with a rigorous process for artefact selection and better care taken in managing artefact evolution.

A second type of challenge was in distinguishing between physical elements, models and their instances, since we initially referred to all using the same terms (i.e. files and directories). In order to avoid confusion between real files and directories, as found in a filesystem, and their representation within MASD, we decided to qualify MASD physical entities with artefact (e.g. file artefact, folder artefact). This terminology was incorporated into MASD's ubiquitous language and is used consistently throughout the present manuscript. In the same vein, though not often mentioned to avoid confusion, MASD's physical elements are still logical representations of concrete physical elements.

As Figure 3 should make clear, we are not referring to the logical dimension within MASD (the Logical Domain section), but instead to the modeling and subsequent refining of MASD's logical representation of physical entities into its final form, encompassed by the area of the dashed blue square in the picture. There, we take an instance of a physical model element (circles in orange) and create the corresponding file or folder in the filesystem (circles in yellow). Once the terminology was modified to reflect this, the ubiquitous language became unambiguous.

Regardless of challenges, the process has allowed us to identify and incorporate a number of physical patterns, many of which proved useful in the implementation of the MRI's code generator itself. What follows is a non-exhaustive list of SRPPs:

• type definitions, including constructors and properties (getters and setters);
• GoF design patterns (Vlissides, John and Helm, Richard and Johnson, Ralph and Gamma, Erich, 1995);
• serialisation support for different formats such as JSON and XML, possibly using different serialisation libraries;
• several mechanisms for test data generation;
• pretty-printing — i.e. dumping object state into a human-readable string representation;
• ORM mapping, providing RDBMS support;
• hashing — the generation of a hash function for the given state of an object;
• lexical casting, converting a C++ type into a string representation;
• unit test generation, validating the functionality of the generated features;
• generation of mocks for unit testing;
• and many more.

As more physical patterns were identified and implemented, further empirical evidence was accumulated on their general characteristics. Since the continued growth of the pattern catalogue is a key concern of the methodology, and given that reconstruction is not always feasible, distinguishing what is reconstructible from what is not became a central question to MASD. In order to better understand the commonalities between the patterns within the catalogue, we decided to classify them with regards to input variability¹⁸.

A property common to the captured SRPPs is that they all are trivial functions of input variability. Somewhat tautologically, a trivial function of input variability is defined to be any physical entity that can be fully or partially reproduced, given arbitrary (but valid) input describing structural or non-structural variability.¹⁹ Reflecting on the modeling process (the Physical Modeling section), we realised that the steps of decomposition, labelling and classification are in effect an exercise in teasing apart functional dependencies on input variability from each physical entity, as explained by the flowchart in Figure 4.

From this perspective, one can then create a taxonomy of the identified SRPPs with regards to input variability, leading us to Figure 5. Physical elements are first classified as dependent or independent of input variability. Any element which is independent of input variability is inherently not reproducible — for example, free text, arbitrary directory structures and the like — and thus ignored (marked in red). Next, physical elements which are functions of input variability can either be complex functions — that is, functions which cannot be described in a mechanical manner, and thus must be ignored — or they are trivial functions of input variability. As there are two kinds of input variability, there are also two kinds of trivial functions: trivial functions of structural variability and trivial functions of non-structural variability.²⁰ Two sample trivial functions of non-structural variability are supplied: boilerplate and a long-form licence text such as the GNU Public Licence.^{21, 22} Finally, trivial functions of structural variability — which we often abbreviate to just trivial structural functions — are classified into two kinds, and several examples are provided for both.

Trivial structural functions have two main use cases. The first and most obvious is the definition of data types — e.g., classes and their attributes.²³ The second use case is the implementation of simple behaviours for those data structures which depend on structural variability, such as serialisation and ORM support. These we refer to as trivial behaviours, in contrast to complex behaviours which transcend "simple mathematization" — to borrow Hutchinson et al.'s wise words, out of context though they may be (Hutchinson, John and Rouncefield, Mark and Whittle, Jon, 2011) — and thus demand manual handling. From this lens, special purpose code generators (Marco Craveiro, 2021a) are seen to either generate type definitions and a single trivial behaviour — e.g. protobuf and the XSD tool generate the type definition and a serialisation format — or solely a trivial behaviour — e.g. ODB generates the ORM infrastructure, but relies on an existing type definition. With SRPP, what MASD proposes is the inventorisation of all such trivial behaviours and their unification under a single, integrated, framework.²⁴

Once a taxonomy for input variability functions had been arrived at, we then set on devising a scheme for their composition. The literature provided ample material in this regard, which was found to be inspirational but ultimately unsuitable for our needs.²⁵ Using MASD's philosophy as a guide, we settled on a simple — and consequently inflexible — approach: a generated artefact may only be composed of zero or one trivial structural functions and zero or more trivial non-structural functions.²⁶ Admittedly, the limitation is severe, but the trade-off removes most of the complexity inherent to composition, and is therefore in keeping with the methodology's goals.

The limitation is perhaps best understood by means of an example. In traditional OO programs, objects accumulate different kinds of behaviours, in an attempt to model entities found in the problem domain. Thus, it is common for a class to contain both domain-specific behaviours — e.g. a Shape may be able to Draw, Rotate and so forth — as well as infrastructural behaviours — e.g. the Shape may also be able to SerialiseToJson, ToString and the like. It is often the case that all of these behaviours are implemented as methods in one file. The restrictions on composition described above mean that MASD explicitly forbids such behavioural composition with regards to infrastructure; each of these behaviours — e.g. "JSON Serialisation", "Pretty-printing", etc. — is mapped to a separate trivial structural function and is associated with a single file artefact.²⁷

Having embraced the unsophisticated approach, it was then straightforward to align generational variability with the specific use cases identified within the physical space:

• Positive variability was deemed to be best suited to modeling the inter-artefact composition of trivial structural functions. By making these responsible for separate artefacts, we greatly simplified the process of stitching together the final implementation — which now becomes a mere expression of artefact relations (the Artefacts section). In addition, non-structural variability can be used to configure the presence or absence of each top-level function, in turn determining artefact relations. Thus, whilst still a difficult problem, it opens the door to the application of solving (the Variability Domain section).
• Negative variability was deemed to be better suited to modeling intra-artefact instances of non-structural variability. For example, one can enable or disable class constructors as part of a type definition in a straightforward manner, adding little complexity to the overall process.

All of these moving parts can now be summarised into a cohesive narrative:

• MASD locates physical entities with SRPP by empirical means. Content is deemed to be a SRPP if a trivial function can be created that reconstructs the target.
• MTs (M2Ts in particular) are be used to implement trivial functions of input variability. These make use of negative variability techniques to handle non-structural variability.
• each generated artefact must have a single responsibility, and that responsibility imbues the artefact with a type within MASD's physical representation.²⁸ The type is the trivial structural function.
• a broader framework is required to handle the inter-artefact composition of trivial functions of input variability, making use of positive variability techniques. As we shall see, MASD's solution is to embed the framework into the geometry of physical space itself (the Folders section).

File artefacts in MASD are a generalisation of regular files as defined by the POSIX specification (IEEE, 2018).²⁹ They can be organised hierarchically using folder artefacts, a generalisation of POSIX's directories which will be the subject of further scrutiny in the Folder Artefacts section. The next three sections demonstrate how physical modeling helped reveal the deep structure³⁰ within file artefacts by dissecting their taxonomy, morphology and relationships.

Like file artefacts, folder artefacts also have an underlying structure, albeit simpler, and therefore it too can be unearthed via the physical modeling process. The analysis is presented in three parts. First, we discuss the folder taxonomy revealed by dissecting our sample, which includes terse descriptions of the identified elements. Next, the interaction with different forms of input variability is investigated. Finally, examples are provided to clarify all concepts discussed.

The entities described thus far in this chapter are part of MASD's PMM. The PMM defines the geometry of physical space in MASD. Physical space has an hierarchical nature, which is to be expected given its entities emanate from a hierarchical filesystem. Figure 23 exemplifies the relationship between the metametamodel (M3), the PMM (M2) and the PM (M1) by populating a metamodel hierarchy with a small number of sample entities. Files in the filesystem (M0) have been omitted for brevity.

In the figure, MASD's metametamodel is comprised of archetypes, divided into file archetypes and folder archetypes. Within the metamodel, the archetypes are instantiated by artefacts such as file artefacts and folder artefacts. The figure then goes on to supply examples for both artefact types and, of these, the file artefact example is of special interest due to its name:

cpp.include.types.class_header

The notation denotes a fully-qualified physical meta-name and it is a physical address within MASD's physical space; it conveys a point in that space. To bring the notion home, let us look at a few more example archetypes:

• cpp.include.types.enum_header is the archetype responsible for generating the definition for a C++ enumeration. It exists within the cpp TS, the include part and the types facet.
• cpp.src.types.class_implementation is the archetype that generates the implementation of a C++ class. It exists within the cpp TS, the src part and the types facet.
• csharp.main.types.class is the archetype responsible for generating the definition of a C# class. It exists within the csharp TS, the main part and the types facet.

More generally, physical addresses take the following form:

[technical space].[part].[facet].[archetype]

Besides just points, physical addresses can also be used to denote regions of physical space, which are sets, in the mathematical sense, of physical entities. For example, cpp contains all parts, facets and artefacts in the C++ TS; cpp.include is a subset of cpp and contains all facets and artefacts within that part. The geometry of physical space brings structure to the modeled physical patterns but, more significantly, the space is arranged in this fashion to facilitate the management of variability of physical entities — a topic of later analysis (cf. the Variability Domain section).

Figure 24 provides a birds-eye view of the PMM and related entities, bringing together all of the elements discussed thus far as well as introducing two new ones — platforms and cartridges — which, due to their complexity, will be dealt with by the next section (cf. the Platforms and Cartridges section). The image is largely a collage of previous diagrams, with a few noteworthy points. First, TSs are shown twice to illustrate their dual nature in MASD: for endogenous purposes, they represent folder artefacts, but for exogenous purposes they are seen as sets of platforms. In addition, we see archetypes associated with the PMM though we previously alluded to a metametamodel; in practice, MASD opted for folding the metametamodel into the metamodel — that is, for employing loose metamodeling rather than strict metamodeling (Marco Craveiro, 2021) (Section 3.4). It was done so because the PMM was designed to cater for specific two use cases:

• To generate the code generator; that is, elements such as TSs, parts, facets and artefacts were modeled as SRPPs themselves. This was done by applying the physical modeling process to the development of the code generator, and extracting physical patterns, which were modeled and catalogued just as any other physical pattern.
• To serve as the target of refinement; that is, logical entities are transformed into physical entities via transform chains, and these physical entities are subsequently transformed into files and directories in the filesystem.

Loose metamodeling was sufficient to satisfy both of these use cases, so it was preferred to strict metamodeling. This "use case focused" approach is also in keeping with the vision for the methodology — targetting narrow application and thus affording simpler solutions when compared to more ambitious applications of MDE. Loose metamodeling is not without its costs, however, and terms such as archetypes and artefacts are where its limitations start to show. These two terms are used through MASD, and at times it may appear that they are interchangeable; however, as the metamodel hierarchy already alluded to, they serve different roles in MASD's domain architecture. The choice of term is meant to denote the level of abstraction at which one is operating:

• the term archetype is used in the following contexts: 1) when we are referring to the generating function that creates instances of individual artefacts; 2) when we want to describe sets of artefacts, such as regions of physical space.
• the term artefact is employed when we want to classify a set of files, or when we have an artefact instance in memory for example.

And with this clarification, we are close to completing our survey of the physical domain. Before we do so, there are two additional physical entities we need to cover, and these are of a different nature of those identified thus far.

The artefact-centric view of the world posited by the physical domain is instrumental in addressing some of MDE's ambiguities in its vocabulary, previously described in the state of the art chapter and (Marco Craveiro, 2021) (Chapter 4). This section explains how it is used to characterise two important concepts, pertaining to two key entities within MASD's physical domain: platforms and cartridges. We start with the former.

A platform is understood to be an aggregation of building blocks within a TS (cf. Figure 24) — that is, a named and possibly versioned set of artefacts which, for all intents and purposes, is indistinguishable from a software product. The only difference between the two is that MASD deems products to be artefact collections it generates — i.e., endogenous — whereas platforms are external to it and can only be accessed by means of an associated PDM (cf. the Logical Domain section) — i.e, exogenous. In other words, platforms lack the regularity afforded to MASD software products — thus requiring mapping — and are responsible for raising the abstraction level — thus simplifying the generating functions. Figure 25 illustrates MASD's artefact-centric and hierarchical view of platforms.

Whilst broad, this is nonetheless a definition that contains no ambiguity; a TS defines the syntax via its metamodel, and platforms are sets of artefacts that are valid instantiations of the syntax, and which have not been created by MASD. With this we avoid questions such as "is the CLR a platform?" or "is the JVM a platform?" (Marco Craveiro, 2021) (Chapter 5), as these are not meaningful in a MASD context. If there is a library exposing the internals of the CLR or the JVM, then these libraries are considered platforms. More broadly, MASD is only interested in statements involving sets of physical artefacts.

Cartridges are of a similar nature to platforms with regards to their endogeneity.⁵³ They are defined as any code generator external to MASD whose input can be modeled as a text artefact generated by MASD, and whose output is a set of text artefacts on which MASD may perform further processing. The cartridge entity in the PMM (cf. Figure 24) models aspects of the external code generator such as its version and any other properties that have a functional dependency on the input artefacts generated by MASD.⁵⁴ In this way, the role of the cartridge entity is similar to that of the PDM: it regularizes external entities for consumption by MASD. From this perspective, MASD works as an orchestration framework for cartridges, requiring only minimal knowledge about the cartridges themselves; significantly, this is merely a by-product of the fact that cartridge inputs are sources of SRPPs.

MASD's interplay with cartridges is perhaps best understood by example. Let us consider MASD's integration of the tools ODB⁵⁵ and clang-format⁵⁶, two tools popular with C++ developers. MASD consumes these tools via a workflow with the following steps:

• Step 1: MASD generates the input files for ODB whenever users request RDBMS support for a given C++ project.
• Step 2: MASD supplies the input files to ODB, which generates a set of C++ files implementing the database layer.
• Step 3: MASD supplies the output of ODB to clang-format, which indents the source code according to a user-defined convention.

This workflow is implemented in the MRI as a cartridge pipeline, as depicted graphically in Figure 26. Regular M2T transforms are used to implement Step 1, whereas Steps 2 and 3 are exposed to the MASD framework as Text-to-Text (T2T) transforms — i.e., receiving artefacts as inputs and producing artefacts. Note that the T2T transforms are composed into a transformation pipeline to produce the desired output, as they are parametrised by non-structural variability — i.e., users can decide if they would like RDBMS support and/or source code formatting. In addition, the T2T transform encapsulating clang-format has an input artefact with configuration specific to the tool; it is generated by a M2T transform within MASD.⁵⁷

Platforms and cartridges enable MASD to access the outside world. However, their modeling is seen as an instance of a more general process: ultimately, MASD extracts a general set of modeling entities from within the physical domain. These entities live in MASD's logical domain, and it is to it we shall turn to next.

MASD's Logical Metamodel (LMM) is an instance of the Logical Metamodel (LMM), responsible for housing meta-elements modeling entities of interest within the logical domain. The LMM also caters for the various types of logical models such as PIMs, PSMs and PDMs — which, as already mentioned, are the gateway for exposing platforms to MASD. The LMM was created with Piefel and Neumann's ideas in mind (Piefel, Michael and Neumann, Toby, 2006), in that it is an intermediate model designed specifically for code generation and serves no other purpose.⁵⁹ The majority of the entities housed in the LMM originate from generalisations of elements uncovered via physical analysis and design (the Physical Domain section), via the process depicted by Figure 27.

Nonetheless, it is important to note that the TS metamodel is also of great relevance to the shape of the logical entities; there is a natural relationship between constructs in the TS's metamodel and the patterns we are trying to capture in the LMM, as demonstrated by Figure 28. The bottom part of the diagram, in yellow, points out useful sources for logical entities given common elements in TSs; it is a logical view of the argument already put forward from a physical perspective via trivial structural functions (the Physical Domain section).⁶⁰

The free-style depiction used in the figure also tries to elicit the dangers of reading too much into the relationship between the TS's metamodel and MASD's logical representation. A construct is only relevant to MASD's logical model if it captures all the information required to create a projection of said construct into the physical domain (the Projections section). The TS metamodel offers a good source of inspiration for the identification of these logical elements; however, the objective of the LMM is not to replicate a TS's metamodel but instead to abstract commonalities between them, from the perspective of the projections. In this vein, as depicted in Figure 28, it is often necessary to break down TS metamodel entities, such as classes, into constituent parts — assignment, cloning, construction and so on — or finding higher level constructs which are not directly relevant to the TS metamodel — such as design patterns. Therefore, by observing patterns of use within text artefacts, we model at varying levels of abstraction when compared to the TS metamodel, as well as modeling languages such as UML — both of which designed for different use cases. This is perhaps best understood by looking at modeled entities and their groupings. Figure 29 provides a high-level overview.

At present, the LMM is made up of ten distinct packages, each targetting a distinct area of a software product.⁶¹ Their intent can be summarised as follows:

• Structural: Models structural variability within programming languages. It is the portion of the LMM that is the closest to programming language constructs.
• Build: contains entities responsible for build files such as Makefiles and CMake files, often used on UNIX-like operative systems.
• ORM: provides support for RDBMS, including tools such as ODB.
• Visual Studio: models the infrastructure needed to support the Visual Studio IDE, used on Windows platforms.
• Variability: contains all entities required to generate non-structural variability support in the MRI (the Variability Domain section).⁶²
• Templating: models entities related to logic-less templates, used in MASD to create M2T transforms.
• Mapping: support for PIMs is attained via these entities, which provide the infrastructure to map TS-agnostic types to their TS-specific counterparts.
• Decoration: contains all entities modeling file artefact decoration, as uncovered by morphological analysis (the Artefacts section).
• Serialization: provides support for entities required in a serialisation context.
• Physical: Models MASD's physical entities such as parts, archetypes, relations and the like; contains the LMM's representation of the PMM, and it is used to generate it.

As there are over one hundred individual classes in the LMM, it is not feasible — nor necessary — to cover each of them in detail. It is however worthwhile sampling one of the packages in order to get a flavour for how these elements are modeled. Figure 30 does just so, providing a glimpse of the main components in the LMM's structural package. Most of the depicted elements are TS-agnostic representations of metatypes commonly found in programming languages, but there are a few noteworthy exceptions which warrant a fuller description — as do the varying levels of abstraction, denoted in the figure by the colour scheme.⁶³

Module, enumeration and built-in model, respectively, namespaces (or packages), enumerations and built-in types. Object is intended to stand for DTOs, though at present is synonymous with the TS concept of class, containing both properties (attributes) and operations.⁶⁴ Grouped together, these four elements and their dependent types (in light blue) can be thought of generalisations of the "traditional metatypes" found in a programming language TS, as well as modeling languages such as UML.

Moving upwards in the abstraction ladder, we then have a second group of metatypes, in purple, which exist at a higher level of abstraction from that of the TS metamodel, and which we named idiomatic metatypes. These are as follows:

• Exception represents types that denote error conditions. During the projection into physical space, MASD takes care of all of the machinery needed to make them idiomatic in the target TS, such as inheriting from std::exception in C++ or System.Exception in C#. They can also be mapped to error codes where the TS has support for these — e.g. the C language.
• Primitive is a wrapper around a built-in type that allows the creation of strong primitive types. For example, instead of using std::string to denote a unique identifier for a person, MASD allows the creation of a specialised primitive type for this purpose — e.g., a PersonId, with an underlying type of string.⁶⁵
• Entry point represents the function where program execution begins — e.g., main in the C/C++ TS and, typically, its C# counterpart of Main.

All of these entities should be familiar to software developers, with more of their ilk to be added in the near future such as named key-value pairs, units (e.g. support for units of measure like the metric system), named bitsets and the like. Types in this grouping are mainly related to idioms, uses and conventions that often span multiple TSs, but are restricted to a single type.

Moving up the abstraction ladder once more takes us to the GoF's design patterns (Vlissides, John and Helm, Richard and Johnson, Ralph and Gamma, Erich, 1995); these are shown in green on the diagram. Design patterns distinguish themselves from idiomatic use cases by being larger aggregates, usually involving the collaboration of multiple classes. The MRI only supports the visitor pattern (p. 331) at present — applicable whenever inheritance is employed — but other patterns such as singleton (p. 127) as well as builder (p. 87) are currently under development. Though they are being accrued incrementally, it is expected that the majority of the GoF patterns will eventually be represented within the LMM.⁶⁶

From design patterns, the level of abstraction is raised one final time; Figure 31 captures the entire ascent over the abstraction ladder. Object templates are to be found at this highest level (Figure 30, in orange). They allow the creation of modeling entities that exist only at modeling-time, and demonstrate the power of employing loose metamodeling in this context. Object templates were inspired on C++ concepts⁶⁷, because they abstract classes with the same shape, though entirely unrelated from the TS's type system perspective. In addition, now that C++ 20 has introduced language-level concept specifications, MASD is looking into projecting object templates into the physical domain via the new language feature. Regardless of this new use case, object templates have already proven extremely useful to the MRI, and are used extensively throughout MASD's code generator. Their use may not be entirely obvious, however, so a small example is required to clarify how it and other LMM metatypes are employed in practice.

Figure 32 does so by portraying a UML class diagram that instantiates object templates, objects, primitives and visitor. MASD metatypes are supplied as UML stereotypes, contained within the MASD UML profile. First, we turn out attention to object templates. The metatype Identifiable dynamically generates a new stereotype, in this case applied to types ClassA and ClassB; both classes will be generated with a property called Id, but there will be no reference to the object template Identifiable within the generated C++ code.⁶⁸

With regards to the primitive ElementId, its underlying type is defined via UML's tagged values, located just below the class name:

masd.primitive.underlying_element=std::string

The tag in the tagged value — masd.primitive.underlying_element — represents an entity within MASD's variability domain (the Variability Domain section). The value of the tag represents the type std::string, sourced from the C++ Standard Library. It is made accessible to MASD via the PDM cpp.std, containing all exposed types within the C++ Standard Library.

Next, we turn to visitor support, which, at present, is not without its flaws. The element Base is annotated with the stereotype of masd:visitable, triggering the generation of a visitor for this base type, dispatching to all of its derived types (Derived, in this case). Alas, the approach is now understood to be a misuse of the LMM's type system because the visitor class itself is not present in the class diagram, being instead generated internally.⁶⁹ And on the theme of implicit associations, the object metatype is also used implicitly in Figure 32: UML classes without a MASD stereotype denoting a LMM metatype default to masd::object; thus Base, Derived, ClassA and ClassB are all implicitly tagged as masd::object.

The analysis of the model put forward in Figure 32 concludes with a demonstration of how object templates can be linked back to TS-specific features such as concepts. In the listing below, a sample print function was handcrafted, with a template parameter whose name matches the object template; the generic function can be instantiated by any type meeting the requirements of the Identifiable concept — e.g. ClassA or ClassB. In other words, the C++ concept maps to our logical representation of the Identifiable object template. Note that the listing presupposes the presence of all necessary includes for pretty-printing of the ElementId primitive. The listing also demonstrates the initialisation of primitive types — e.g. idA and idB.

template<typename Identifiable>
void print(const Identifiable& ident) {
    std::cout << "Id:" << ident.Id() << std::endl;
}

void caller() {
    ElementId idA("A");
    ClassA a(idA);
    print(a);

    ElementId idB("B");
    ClassB b(idB);
    print(b);
}

This example of a logical entity projected into the physical domain brings us into the general topic of projections, which the next section will develop.

As shown previously, MASD's physical domain can be thought of as a physical space, with an associated notation for points. The logical space is a similar construct, with its own point notation derived from element containment. As a result, much like physical space, logical space is also hierarchical in nature. Since modules are the only LMM element that can contain other elements⁷⁰, the following notation describes any point in logical space (with the word modules omitted due to space constraints):

[product].[component].[internal].[element name]

Product stands for product modules and represents the set of one or more modules associated with the product name — e.g. Some.Product, using dot notation, is made up of product modules Some and Product. Component stands for component modules and represents one or more modules associated with the component (e.g. Some.Component); and internal — i.e., internal modules — represents zero or more modules used internally within the component (e.g ModuleA.ModuleB).⁷¹ Finally and predictably, element name represents the name of the logical element, e.g. ElementA. There are clear similarities between this approach and what was put forward in the physical domain; Figure 33 joins them together into a single viewpoint.^{72, 73}

The first interesting point in this comparison is that all points in logical space use the same notation, whether when representing elements in the metamodel (e.g. the LMM) or any instance model (e.g. any LM). Since there is nothing distinctive about the LMM — it is just a regular model after all — and since we prefer loose metamodeling, there is no requirement to make a distinction between its types and any user types. On the right hand side of the diagram, at the top, we have the previously described notation for points in physical space at the metamodel level (the Physical Domain section). Finally, at the bottom right, physical paths are shown — i.e. physical points at the model level. These represent the projection of logical elements across to physical space and are a function of:

• The geometry of physical space, as dictated by the PMM, which enforces regularity — e.g. specifies the placement of product folders, component folders, part folders, facet folders, etc.;
• Structural variability in the logical model, which instantiates each of these elements: the product and component names are supplied by the user, as are all internal folders and the element name;
• Non-structural variability, dictating the exact configuration to select; for example, what extension to use for C++ headers, whether to express product and component folders, whether to override the name of the technical space folder, and so forth.

Paths are just one of many projections within MASD. Almost all logical entities are projected into the physical dimension — the most obvious exception being object templates, which at present are consumed by the transform chains during processing and do not have a physical representation.⁷⁴ Typically, projections are functions of structural variability, parametrised by non-structural variability, and often implemented as M2T transforms. To simplify matters, we shall ignore non-structural variability for the purposes of the present discussion, as it is covered in the Variability Domain section; but it is important to bear in mind that any such projection will offer a number of configurable parameters which will have a significant effect on the result of the projection.

Projections are best understood with examples. Figure 34 shows an example projection of the logical element masd::object (the Composition section).

In the diagram, an initial representation is used as input to the process; this is known as the codec representation and it is designed to be as simple as possible.⁷⁵ The idea is to make the creation of extractors a straightforward matter, allowing the implementation of a codec for each required tool, in keeping with the methodology's tenets (P-2, Integrate Pervasively, in particular). In addition, we want to keep the number of bespoke transforms in each codec to a bare minimum, leaving all the heavy lifting to common transforms. Figure 35 contains a fragment of the codec model, with the key entities.

The codec representation defines the projection of its elements into the logical model proper, taking these ideas into account; it is always a one-to-one projection, but because LMM elements are highly specialised, many such projections have been defined. By and large, UML stereotypes determine the routing to a logical element — e.g., an element with stereotype of masd::obejct will be converted into the LMM's structural metatype of object, an element with a stereotype of masd::enumeration will be mapped to a structural metatype of enumeration and so on. Elements without stereotypes are assigned a default mapping; for example, UML classes without stereotypes default to masd::obejct.

Next we have the projections from the LMM into the PMM. These projections are functions that take points in logical space and map them into sets of points in physical space, often spanning multiple regions. Returning to our example, the UML class at the codec level is first projected into a masd::object, and then projected into the physical locations depicted by Figure 36. The figure uses the same colouring scheme as before, with TS, parts and facets containing archetypes. Its not necessary to go into the details on each archetype shown — hopefully most have self-explanatory names — but it is significant that there are a large number of them (18, in yellow) and their number is expected to grow considerably over time, as more patterns are added to MASD.

Clearly, not all functionality is required for all use cases; for example, one may require type definitions only, or type definitions with serialisation support, meaning that all other projections would not be necessary. And it is here that we enter the last domain within MASD, dealing with the configurability of logical and physical model elements, as well as the configurability of the projections between spaces.

Variability is a vast and complex topic within MDE, so, to avoid confusion, all mentions in this document have been carefully qualified — up to the present section.^{76, 77} Unfortunately, given its prominence within MASD, it is impractical to enunciate so clearly each use of variability within the domain architecture, as doing so would make naming entities unwieldy. Furthermore, a natural alignment was observed between certain variability kinds and MASD's domains, meaning that, in practice, confusion seldom arises.⁷⁸ For all of these reasons, the variability domain specialises only on non-structural variability; and the term "variability", when used in a MASD-only context, is understood to be synonymous with this kind of variability, with other uses explicitly qualified.

Once boundaries had been established, the question of how to integrate domain modeling with variability modeling emerged. Clauß (Clau{\ss}, Matthias, 2001) and Thibaut et al.'s (Possomp{\`e}s, Thibaut and Dony, Christophe and Huchard, Marianne and Rey, Herv{\'e} and Tibermacine, Chouki and Vasques, Xavier, 2010)(Possomp{\`e}s, Thibaut and Dony, Christophe and Huchard, Marianne and Tibermacine, Chouki, 2011) take on the matter was preferred over others, mainly due to their emphasis on a single integrated modeling approach that encompasses variability requirements. The simplicity of the implementation was of particular interest, since having a single model meant augmenting MASD's UML profile with a limited number of variability concepts. Whilst not as expressive as Feature Modeling or Orthogonal Variability Modeling (OVM), the approach is sufficient for the well-defined needs of MASD — especially because it lowers the cognitive load of end-users by reducing the number of concepts needed to model effectively. Having settled on the boundaries and the approach to variability modeling, our efforts then shifted towards identifying the entities of interest within this domain, covered in the next section.

The Variability Metamodel (VMM) is designed to provide variability services to MASD's logical and physical domains. Due to this, it's deeply intertwined with both domains, and it is used in many complex workflows. However, at its core it was created to address two simple needs:

• enabling and disabling regions of physical space, such as TS, facets and artefacts;
• configuring various aspects of the projections to physical space: naming the directories for facets, configuring file names and extensions, enabling or disabling certain features in code generation, etc.

Since in MASD variability is built atop of UML class diagrams, we made use of tagged values to convey configuration.⁷⁹ As an example, a masd:object can be configured to enable two regions of physical space — types and hash — by supplying the following tagged values:

masd.cpp.include.types.enabled=true
masd.cpp.src.types.enabled=true
masd.cpp.include.hash.enabled=true
masd.cpp.src.hash.enabled=true

Boolean values are one of many possible types for tagged values. Over time, MASD accrued many additional types and a type system was created in order to validate user input, as well as to facilitate the processing of these entities within the MRI. Figure 37 shows the available value types at present, with more on the pipeline.

As with values, a similar problem was faced with regards to tag validation. Initially, ad-hoc code was written for each new tag as they were introduced but, once enough use cases were collected, the notion was generalised via the introduction of features and configurations. Features implement a simplified version of the concept as found in Feature Modeling, allowing the creation new configuration points within the domain architecture. Features are grouped into semantically related sets called feature bundles. Figure 38 shows a small subset of the feature bundles defined in the LMM. There we can see that the LMM metatype feature_bundle is instantiated, with each instantiation containing a number of features of varying types.

Note that feature bundles themselves also make use of the variability machinery. For example, features have binding points — that is, each feature must enunciate the set of meta-entities that can legally make use of it — and these are declared via variability, as are other configurable elements:⁸⁰

masd.variability.default_binding_point=element
masd.variability.key_prefix=masd.type_parameters

Features are useful in isolation, but MASD's approach of having a dynamically expanding PMM posed a challenge: as new TSs, parts, facets and archetypes were added, there was a need to model individually their respective features, such as for example enabled as per previous listing. The process was error prone and repetitive, so the notion of feature templates was introduced. These are abstract features which must be instantiated over a domain in order to become concrete features — i.e., made available to end-user diagrams. Figure 39 shows how features such as enabled are defined as templates.

Each of these modeling elements declares a domain over which template instantiation is to be performed. For example, archetype_features has the following tagged value:

masd.variability.instantiation_domain=masd.archetype

The domain masd.archetype covers all available archetypes across the entirety of the PMM. Other domains exist such as masd — spanning the whole physical space — masd.facet, including only facets — and so forth. This scheme allows the fine-grained definition of features across the different regions of the PMM. At present, the main source of domains has been the geometry of physical space, but there is no direct connection between the domain as a variability concept and the PMM; these are merely seen as sets of strings, meaning other applications are possible. At present, no additional use cases have emerged.

Significantly, the VMM resulted from the application of the physical modeling process (see the Physical Modeling section) to the MRI itself. All of the generalisations presented here emerged from a long iterative process, with several years of experimentation — from detecting SRPP's within the variability domain, through to modeling them in the LMM and ultimately to generating code to encapsulate them as trivial structural functions — and this process is still ongoing. For example, one area where support is limited at present is in declaring relationships between features; once implemented, it will allow solving for valid configurations.⁸¹ And configurations brings us to the final topic within variability: the Variability Model (VM).

All entities described in the VMM thus far are mainly used for the code generation of variability support in the MRI. However, a second aspect of variability is the creation of run-time configurations, which instantiate the available features with specific values. The simplest case of a configuration was already covered, which is to add all configuration points to the affected elements via tagged values. However, a problem soon emerged with regards to reusing configurations: once features were made available and used throughout, it became obvious that component models for a given product shared a great degree of commonality configuration-wise, as did products from the same product line.

This use case was addressed by introducing profiles to the LMM⁸². These are bundles of configuration points that can be bound to logical elements such as component models and objects. With the introduction of profiles, the VM took a renewed relevance, meaning each product can now define a configuration model describing a configuration language for the product or product line, and it can then be reused across a set of component models. Figure 40 shows a fragment of the MRI's configuration, with a number of profiles (stereotype masd::variability::profile). The use of inheritance enables the construction of elaborate trees of profiles, supporting simultaneously minimal duplication and fine grained configuration.

A second point of interest in the figure is the use of profile templates. These follow the same logic as do feature templates, allowing for the instantiation of a configuration point over a domain. Its main use, as per the image, is in enabling or disabling all regions of physical space of a given type (facets, in the example). Much like feature templates, they are very useful given the ever expanding geometry of PMM, saving users from duplicating configuration points.

As already alluded to, another extremely important aspect of profiles is how, via their names, they can be used to create a very useful DSL that describes the intended characteristics of various model elements. Figure 41 shows a number of profiles used in the MRI, all named after the abilities they convey, such as for example serializable or hashable. To further increase the relevance of this DSL, one can associate a colouring scheme with profiles, making the diagrams visually distinctive.

Once defined, profiles can then be bound to models and model elements in one of two ways: either via variability or via stereotypes. The latter takes the same approach as object templates — i.e. one can populate element stereotypes with one or more profiles names, thus binding the profile with the element.⁸³ The former is achieved by applying the profile tag to the element in question:

masd.variability.profile=default_profile

To facilitate the detection of binding errors — such as binding a profile that was meant for a model against an element such as object — MASD allows setting the scope of the binding on a profile; e.g., the following configuration point ensures that a profile can only be bound to a model:

masd.variability.binding_point=global

Whilst workable, this high-level specification of scopes does not address all of the present use cases. As with feature binding, more work is needed in order to satisfy the fine-grained binding specifications we need for the current uses across logical and physical domains. And with this, we have now introduced all of the core domains that make up MASD's domain architecture. What remains is to join the dots between these three domains, forming a combined space.