The MASD Methodology
Use computer-based tools to mechanize those facets of software development that do not depend on human ingenuity. — Booch et al. (Booch et al. 2004)
The present chapter outlines the fundamental characteristics of the MASD methodology, and it is organised as follows. Section Motivation for a new SDM starts by arguing that the multifaceted list of requirements set out by Requirements for a New Methodology can only be addressed by a new SDM, and explains how our methodology differs from typical SDM use cases. Attention is then turned towards the three canonical SDM components: the core philosophy (Section Motivation for a new SDM), the modeling conventions (Section Modeling Conventions) and the methodology's processes and actors (Section Processes and Actors). The chapter ends with Section Comparison with Other Approaches, where a comparison of MASD against like-minded approaches is performed. Let us begin then by establishing our motivation.
Motivation for a new SDM
After combining literature review with personal experience1, it is our position that Stahl et al.'s two-track iterative software development model (cf. AC-MDSD) did not advance far enough for our needs. In our opinion, problem domain decoupling becomes a significant factor in the context of the requirements gathered in Requirements for a New Methodology. This happens because the infrastructure problem domain we've set out to explore is simultaneously sufficiently complex and sufficiently distinct from the core problem domain to warrant a clearer demarcation of responsibilities between the two.2
Accordingly, we argue instead for the logical consequence of Stahl et al.'s ideas, which is to have a dual-SDM approach, because one can only mediate such complex interactions by means of an SDM, crafted specifically to handle the infrastructure problem domain, and to ensure it is kept it at arms length from the core problem domain.3 However, it does not suffice to merely isolate the two problem domains with two distinct SDM. Using tool vendor offerings as a proxy, our analysis demonstrated they tend to fall in what we named the over-generalisation trap.4 Therefore, in order to avoid this fate, it is also crucial for the SDM to explicitly target the "barely general enough" generalisation sweet-spot described towards the end of Section AC-MDSD.
It is in this sense that the application we put forward differs from the typical integration of MDE with SDM; its purpose is not to manage the entirety of the software development lifecycle but merely a small but well-defined subset of its activities: those related to the management of SRPP, which take central stage in the methodology. SRPP are a furthering of Stahl et al.'s ideas around schematic and repetitive code (cf. Section AC-MDSD), but generalised to other kinds of patterns within the physical space5; they result from a deep interrogation on the nature of physical and logical dimensions within a software project, and are discussed in great detail in FIXME domain architecture. This approach is believed to hold the key in shielding end-users from many of the complex themes discussed in State of the Art in Code Generation, allowing the methodology's modeling conventions — and consequently its domain architecture — to be reduced to only those concepts needed in order to realise its objectives.6
Philosophy
In order to plot a clear and concise narrative for MASD, we have divided its philosophy into three distinct but interdependent concerns: a vision, a mission statement and a set of fundamental core values.7,8 The vision provides MASD with a overarching purpose, setting the overall direction for the methodology. The mission statement is comprised of a set of actions that will be taken to fulfil the vision. Finally, the core values are the basic principles that act as guides or sign-posts for all decision making on the long road towards making the vision a reality. The next three sections describe these elements in detail.
Vision
MASD's vision is as follows:
To accelerate MDE adoption by traditional software engineers for the generation of infrastructural code.
Mission Statement
MASD's mission is to provide a systematic and integrated approach to the lifecycle management of SRPP, a class of patterns found in software systems. The lifecycle management of these patterns calls for:
- their identification, capture and classification in a open, centralised and continuously evolving library;
- the analysis and characterisation of their inter-dependencies and variability requirements;
- their generation by automated means;
- the associated conformance testing, required to empirically verify and validate their generation;
- their evolution, as related use cases are considered; and, ultimately,
- their decommission, once no longer required.
Core Values
MASD's core values are anchored on six complementary principles, all centred around increasing automation, as depicted in Figure 1. The next six sections discuss each principle in turn, anti-clockwise, supplying context and a rationale for their inclusion. Each principle is composed of a numbered principle definition for cross-referencing purposes, a list of the associated requirements it addresses (cf. Requirements for a New Methodology) and an overview detailing the objective of the principle. Note that the principles are stated in imperative form by design, as they are intended as exhortations to MASD actors (cf. Actors).
Figure 1: MASD principles.
First Principle: Focus Narrowly
MASD has a narrow focus on its problem domain, with well-defined identity, boundaries, audience and responsibilities.
MASD has a single focus on solution space concepts — given that's where software infrastructure resides — and commits itself to only serving one set of users: software engineers. With a narrower focus comes a smaller conceptual framework and hence a smaller cognitive load, making it suitable for new practitioners. In addition, a well-defined scope also provides a more straightforward filtering function with which to circumscribe the methodology's boundaries.9
MASD is able to externalise a large subset of modeling concerns because its only focus is the code generation of infrastructural code. Therefore, all other functionality related to modeling is deemed to be external to MASD's domain, such as support for graphical notations, DSL, MT, model evolution, model synchronisation, reverse engineering and many other aspects of MDE. Where required, these must be addressed elsewhere; and their integration with MASD is the role of the next tenet.
Second Principle: Integrate Pervasively
MASD adapts to users' tools and workflows, not the converse. Adaptation is achieved via a strategy of pervasive integration.
MASD promotes tooling integration: developers preferred tools and workflows must be leveraged and integrated with rather than replaced or subverted. First and foremost, MASD's integration efforts are directly aligned with its mission statement (cf. Mission Statement) because integration infrastructure is understood to be a key source of SRPP.10 Secondly, integration efforts must be subservient to MASD's narrow focus (P-1); that is, MASD is designed with the specific purpose of being continually extended, but only across a fixed set of dimensions. For the purposes of integration, these dimensions are the projections in and out of MASD's acrshort:ts, as Figure 2 illustrates.11
Figure 2: MASD Pervasive integration strategy.
Within these boundaries, MASD's integration strategy is one of pervasive integration. MASD encourages mappings from any tools and to any programming languages used by developers — provided there is sufficient information publicly available to create and maintain those mappings, and sufficient interest from the developer community to make use of the functionality. Significantly, the onus of integration is placed on MASD rather than on the external tools, with the objective of imposing minimal changes to the tools themselves. To demonstrate how the approach is to be put in practice, MASD's research includes both the integration of org-mode (cf. FIXME Chapter chap:literate-modeling), as well as a survey on the integration strategies of special purpose code generators (Craveiro 2021c); subsequent analysis generalised these findings so that MASD tooling can benefit from these integration strategies. Undertakings of a similar nature are expected as the tooling coverage progresses.
Clearly, if left to its own devices, pervasive integration could be construed as an unachievable target due to its overly ambitious scope — particularly given the very large size of the pool of potential integration candidates. Moreover, this is a problem that affects the capture of SRPP in general. It is the role of the next principle to provide direction for the exploration of such an immense problem space.
Third Principle: Evolve Gradually
MASD is designed to grow gradually and deliberately over time, covering an increased surface area of its problem domain.
MASD sets out to create a conceptual framework for the exploration of the problem space of infrastructural code; in the limit, it views all infrastructural code as part of one single but extremely large problem domain — allowing for a globalised view — and its objective is to identify and model its entities along with their associated variability. Thus, MASD sees the processes related to the continual discovery of the shape of the problem domain as a indissoluble part of the methodology, as is the resulting library of patterns of infrastructural code, and strives for comprehensive coverage over long timescales.
Figure 3: Interrelationship between discovery and application.
The exploration of infrastructural code is made through empirical and iterative means, and guided by pragmatism. In this manner, MASD expects to fulfil its vision through a very large number of gradual steps over a long period of time, slowly and incrementally building up its SRPP library in a cohesive manner — which also includes integrations (P-1). The driver for changes is practice; that is, in general, features in MASD must be driven by concrete use cases from users in the field rather than through the inclusion of speculative features.12,13
However, even taking long timescales into account, such a large undertaking can only be performed by leveraging an equally large and motivated group of individuals. This in turn raises issues of community and organisation, addressed by next principle.
Fourth Principle: Govern Openly
MASD promotes an open governance model because a thriving community is a necessary condition to fulfil its vision.
Whilst all work on MASD thus far was performed by the dissertation's author, careful consideration has been given to creating a governance model that will allow external parties to contribute.14 These contributions are viewed as an essential ingredient for the fulfilment of the methodology's vision (cf. Section Vision), because, from a end-user perspective, MASD's usefulness is closely related to the breadth and depth of its SRPP pattern library, and the library can only grow if the methodology is pitted against the full breadth and depth of its target problem domain.
These lofty aspirations are not without precedent. MDE has a long-standing experience with FOSS development in leading projects such as acrshort:emf (Steinberg et al. 2008), acrfull:gme (Davis 2003) and many others; in the most successful cases, the approach has yielded several positive results such as a growing and diverse community as well as source code reuse — characteristics which we seek to emulate.
Benefiting from their experience, we thought important to structure MASD in a fashion similar to a FOSS project, in anticipation of its expected future.15 Once chosen, the governance model had implications on actors and processes, so that we could mirror more closely the structures typically found in FOSS — i.e. roles such as maintainer, contributor, end-user and so forth can be directly mapped to MASD's actors and processes defined in Section Processes and Actors.
A plurality of voices has benefits but is not without its hazards, requiring careful orchestration to ensure all involved pull in the same direction. Therefore, in addition to P-1, we also set a clear stance on the use of standards, as the next principle will demonstrate.
Fifth Principle: Standardise Judiciously
MASD employs de facto standardisation at its core to promote agility, and de jure standardisation at the edges to ensure stability.
After reflecting on the MDA experience with international standards (cf. Model Driven Architecture), we decided to limit the use of de jure standards in MASD to projections in and out of MASD's TS (P-2), as that is where we see them adding most value. Projections from and to the outside world are expected to remain stable, and are aligned to the target of the projection, so it makes sense to use well-known standards where those are available. Conversely, MASD's core shall be restricted to de facto standards because, there, empiricism and agility are deemed more important than stability.
Within the core, de facto standards are based on two pillars: this dissertation, as the basis for the definition of the methodology in a future document called the acrfull:mss; and the acrfull:mri (cf. FIXME Chapter chap-mri) as the single source of truth of everything else — tooling interfaces, the SRPP library of patterns and associated variability, and the like. The duality is justified as follows. In order to remain relevant to its users, the acrshort:mri is expected to undergo constant change (P-3), making it a good candidate for an Agile process (Beck et al. 2001).
On the other hand, the SDM itself is expected to experience only minor revisions, reconcilable with the vision and principles here put forward. This does not mean the acrshort:mss is frozen; change is strongly encouraged in MASD and the philosophy is itself liable to change just as much as any other of its components — provided there is sufficient justification. However, it is important to understand that, by design, the identity of MASD is deeply embedded within its philosophy. Therefore, we anticipate it to change in a small and incremental manner, maintaining a similar direction to what has been proposed by this document — or else for a completely new (and distinct) SDM to be put forward in its place.
This multi-layered approach with regards to standards is designed to provide an adequate support for the speed of change of each of these aspects, in order to better serve the target audience. That said, the target audience is multi-layered as well, and thus demands support for distinct levels of usage. And that is the role of the next and final principle.
Sixth Principle: Assist and Guide
MASD's role is to continually assist its end users in choosing the appropriate level of automation for their projects.
MASD is designed from the ground up to support both top-down and bottom-up approaches, and is focused on identifying a set of levels of usage that mirror the behaviour uncovered from adoption literature and personal experience. As a result, instead of enforcing a model-driven view of software engineering, MASD views the use of automation in the development of a software system as a spectrum of possibilities (Figure 4), ranging from no automation to the automated generation of all infrastructural code, as the full MASD vision is eventually realised.16 All points in the spectrum are equally valid and a system may be composed of an heterogeneous mix of automation approaches, both from within and outside of MASD — though hopefully orchestrated via its strategy of pervasive integration (P-2).
Figure 4: The automation spectrum and the automation gradient.
MASD aims to empower its practitioners in determining the adequate level of automation for a given context, as a function of their prior experience. Over time, as they master methodology and tooling, practitioners are expected — but not forced — to progressively climb the automation gradient, though always remaining within the narrow confines of an AC-MDSD approach. Crucially, MASD does not promote the use of automation as a uniquely positive development regardless of context, but rather views it as a set of engineering trade-offs that must be made during the software development process. Though assisted by the methodology, it is ultimately the practitioner's responsibility to make those trade-offs.17 MASD views software engineering not as driven by modeling but by the manual writing of code; modeling is considered a subsidiary activity that can be of assistance to the development process in distinct but well-defined capacities, within the scope of infrastructural code.18
And it is with this message of end-user focus that we conclude our incursion through MASD's philosophy. It's also worthwhile noting that the methodology's philosophy has had far reaching implications to all the work carried out; for one, it was instrumental in shaping MASD's modeling language and other related aspects of its domain architecture. And it is to these we shall turn our attentions to next.
Modeling Conventions
The second aspect of an SDM are its conventions with regards to modeling. In our view, the notion carries additional weight within MDE application, because modeling conventions manifest themselves as a modeling language, and the modeling language is but one component of the domain architecture. All components of the domain architecture must be designed to work in concert and cannot be understood in isolation, leading us to defer their wholesale exposition to FIXME Chapter chap:domain-architecture. Therefore, the present section is tasked exclusively with painting the backdrop with which to understand the domain architecture — i.e., elucidating the conventions and motivation in the MASD's modeling landscape. And it is here that DDD, as championed by Evans (Evans 2004), takes central stage.
Though making selective use of the approach, MASD was nonetheless greatly influenced by DDD, particularly with regards to modeling conventions. A clear example is MASD's ubiquitous language19: it is explicitly composed of both an informal model and a formal model, as depicted in Figure 5, and we view it as a significant statement of intent with regards to the limits of a formal modeling approach. As does Evans, we do not believe it is possible — or even desirable — to express all entities in MASD's problem domain formally. Furthermore, when an entity is captured formally, effort must be made to ensure only those aspects needed to recreate the associated SRPP are modeled. That is, MASD seeks to keep the footprint of the formal model as small as possible because, from experience, we have found its maintenance to be costly (Craveiro 2021b). Since the formal model does not tell the whole story, the informal model is then responsible for weaving an all-encompassing narrative that imbues entities with meaning.
Figure 5: MASD modeling language.
That said, the MASD modeling landscape is somewhat convoluted at present; due to this, its distinct moving parts and their relationships are perhaps best explained from a high vantage viewpoint.20 Figure 6 provides a birds-eye view of the top-level components and their associations, which we shall now describe. As mentioned previously (cf. P-5), the acrshort:mss is a subset of the present document, containing only the aspects relevant to the MASD SDM. The acrshort:mri (cf. FIXME Chapter #chap-mri) is a software product family composed of several software products: a code generator and a set of reference products — at present, one per supported TS. There is only one implementation of the code generator, called Dogen and described in FIXME Section mri-dogen. The formal model is specified and implemented within the code generator and it is used to document and generate the code generator itself, as well as for testing its functionality. The reference products (cf. FIXME Section mri-rm) also serve a dual purpose, being used for both conformance testing as well as canonical instances of the domain architecture for demonstrative purposes. Finally, the informal model is scattered across the acrshort:mss and the acrshort:mri — in particular, the developer documentation included in the code generator's source code repository.
Figure 6: acrshortpl:masd top-level components.
Given this context, it should by now be clear that MASD views the determination of its modeling conventions as a dynamic process. Consequently, the manner in which the domain is explored is of key importance to the methodology, as are those responsible for performing the exploration; and it is to them we shall turn to in the next section.
Processes and Actors
The third and final component of MASD as an SDM are its processes and associated actors. Accordingly, both the application of MASD as well as its internal development are governed by well-defined processes and their corresponding actors playing well-defined roles. This section provides an overview of both actors (Section Actors) and processes (Section Processes), linking them back to the concepts defined thus far.
Actors
Within MASD, there are three distinct personas with different responsibilities: the maintainer, the developer and the user.21 These represent the canonical roles available in MASD software development. The next three sections shed light on these actors.
MASD Maintainer
The MASD Maintainer is the gatekeeper of the acrshort:mss and the acrshort:mri. Its role is to review change requests, often made as pull requests to the desired component, ensuring they are consistent with the methodology's philosophy (cf. Section Philosophy) and fit the acrshort:mri codebase. All changes that impact the acrshort:mri must have a set of tests that specify and validate empirically the new behaviours, in order to be considered for inclusion; they must therefore update all relevant reference products. Once the changes have been reviewed and approved, the MASD Maintainer is responsible for merging them and releasing new versions of the affected components.
Figure 7: Use case diagram for MASD Maintainer.
Since MASD is continuously evolving, the management of backwards and forwards compatibility is a significant challenge for the MASD Maintainer. In general, maintaining compatibility should be the main priority, unless there are explicit technical reasons not to do so. In cases where compatibility must be broken, the MASD Maintainer will communicate the change to its users by means of semantic versioning (Preston-Werner 2018), supplying detailed examples on how to update legacy models to the newest version.22 The reference products are used for this purpose, demonstrating the before and after states.
MASD Developer
The MASD Developer is responsible for creating change requests for the acrshort:mss and the acrshort:mri, in response to demands for new features or fixes to existing features. The MASD Developer is expected to be familiar with state of the art approaches in MDE as well as MASD itself, and to use those selectively, in accordance with the MASD vision.
Figure 8: Use case diagram for MASD Developer.
As an example, the MASD Developer can create mappings for new platforms, add new injectors or extend existing ones with new functionality, add new modeling elements to the MASD metamodels, target new TS or augment the features on the already supported TS and so forth. All changes must be submitted and reviewed by the MASD Maintainer.
MASD User
As a consumer of the MASD methodology, the MASD User is a traditional software developer who applies MASD to the development of a software system. The typical use cases for the MASD User is to create new models and to transform them into code. However, as MASD is continuously evolving, users are also encouraged to identify limitations and opportunities to extend it.
Figure 9: Use case diagram for MASD User.
MASD Users communicate their requests for new features to MASD Developers, who are then responsible for its development. Change requests must include a acrfull:mwe demonstrating the proposed change. The acrshort:mwe is used as a target for the reference products and will form the basis of the conformance tests used to ensure the new change was implemented correctly. The acrshort:mwe will make its way into the code base via the appropriate processes, as described in the next section.
Processes
There are three processes within MASD catering for both the internal development of the methodology as well as its application: the acrshort:mri Development Process (Section MRI Development Process), the acrshort:mss Development Process (Section MSS Development Process) and the MASD Application Process (Section MASD Application Process). All these processes are then combined under the MASD Composite Process (Section MASD Composite Process). The next four sections describe these processes in more detail.
MRI Development Process
The acrshort:mri is a dynamic software product family whose evolution takes place via the acrshort:mri Development Process. A simplified version of the process is shown on Figure 10. MASD Users and MASD Developers are responsible for identifying patterns in source code deemed to be SRPP. The identification process must include a distilling of the schematic and repetitive structure into a acrshort:mwe so that the fundamental characteristics of the pattern can be isolated from irrelevant content. If the isolated patterns are not yet covered by the acrshort:mri, MASD Developers act according to Test-Driven practices and start by updating the impacted reference products to match the desired result.
Figure 10: acrshort:mri Development Process.
MASD Developers then attempt the automated generation of the reference products, which now incorporate the acrshort:mwe, by making changes to the acrshort:mri until all tests pass. Often, the code generation of the requested changes forces a cascading set of modifications across the acrshort:mri metamodels, in order to reflect the introduction of the new feature throughout the stack. However, simpler cases may be able to make use of the existing infrastructure.
Once the acrshort:mwe has been successfully reproduced and both MASD User and MASD Developer are in agreement with how the feature has been implemented — e.g. configuration settings, impact on existing features, and so on — the changes are then proposed to the MASD Maintainer as a change request to the affected acrshort:mri repositories. The MASD Maintainer reviews and validates the changes and, once approved, publishes the new versions of the impacted software products. Via this process, the acrshort:mri is expected to evolve and grow over time, eventually providing a rich SRPP library of out of the box.
MSS Development Process
As described in Section RQ-05, changes to the acrshort:mss are expected to be few and far between. Nonetheless, for completeness, a process catering for these changes is provided — as illustrated by figure 11. Once a shortcoming to the MASD methodology is located and discussed with the MASD Maintainer, the instigator of the change is expected to create a patch to the acrshort:mss as a change request. The MASD Maintainer will then apply the change and release a new version of the acrshort:mss.
MASD Application Process
MASD Users apply the methodology in the development of software systems by using the acrshort:mri to generate code for their system. Before they can do so, they must first settle on the appropriate injector to use — e.g. acrshort:ide or preferred modeling tool support if those injectors are available in MASD, or otherwise a simpler format such as JSON — and on a MASD application level. The application level will determine how much MASD will influence the development process, via P-1. There are four levels of application, with an increasing level of dependency in MASD:
- Level 0: Stub and Skeleton Generation. The acrshort:mri is used as a one-off generator to create stubs for methods, skeletons for classes and the like. Once the code is generated, it must be manually maintained.
- Level 1: Artefact Generation. The acrshort:mri acts like a special purpose code generator (Craveiro 2021c), albeit with a potentially wider remit given the feature set of MASD (cf. FIXME Chapter chap:domain-architecture). The project structure, integration of generated artefacts and other development decisions are unaffected by MASD.
- Level 2: Component Generation. MASD is used to model and generate one or more components in a larger system, such as a library or an executable. The component follows the MASD component directory structure layout and may use MASD generated build files. However, the remaining system remains unaffected.
- Level 3: Product Generation. MASD is used to model and generate an entire product — i.e. a complete software system, composed of executables and libraries. In this case, all (or most) components that make up a product are modeled and generated using MASD, with the user writing code to implement problem space specific behaviour. The product follows all of MASD's conventions, including its product directory structure layout.
- Level 4: Product Line Generation. MASD is used to model and generate a family of related products.
Typically, new MASD Users start at Level 0 and explore the methodology incrementally — use more features, model different types of elements, etc. Over time, as they gain experience, they are expected (but not required) to progress towards Level 4. Experienced MASD Users may then decide that MASD is too limiting for them and move to a more traditional MDE modelware stack, or work on integrating existing MDE tooling with MASD.
Once the level of application has been decided upon, the process of application itself is straightforward, as Figure 11 depicts. It works as follows: MASD Users identify the elements to model and the features that are of interest. If those features are already available in MASD — as implemented by the acrshort:mri, and explored in more detail in FIXME Chapter chap:domain-architecture — users can freely create their models, generate code and consume the generated code from handcrafted artefacts. As with most development today, the process is an iterative one, with identification and modeling progressing side-by-side with traditional programming. If the required features are not available, the MASD User is encouraged to report it via the acrshort:mri Development Process (cf. Section MRI Development Process).
Figure 11: MASD Application process.
The simplicity of the workflow described above may not adequately convey its significance within the methodology, so it is worthwhile stating explicitly that all moving parts of MASD exist solely to service the MASD application process. Furthermore, application and empiricism are the main drivers for MASD — an ideal we tried to enshrine within its core values (cf. Core Values). This notion of interconnectivity between processes in MASD can be modeled at a higher level of abstraction, giving rise to a composite process.
MASD Composite Process
MASD's development has been characterised by severe resource constraints — more so than any of our previous experiences with MDE (Craveiro 2021b). Due to this, there has been an emphasis on doing more with less, forcing us to apply a strategy of bootstrapping — that is, using the acrshort:mri to develop the acrshort:mri itself — and dogfooding — a generalisation of bootstrapping, applying it not just tooling but to MASD itself; in other words, using the methodology to develop the methodology.23 The next obvious step in this generalisation ladder is the notion of a MASD Composite Process, using MASD's processes for its own development.24 Figure 12 illustrates the idea.
Figure 12: MASD Composite Process.
The centrepiece of the flowchart is the use of MASD Application Process (cf. Section MASD Application Process) to drive the development of MASD (i.e., the acrshort:mri and the acrshort:mss). Since the acrshort:mri is a non-trivial software product, it allows us to realistically emulate the traditional two-track environment one would find in the industry, without having to absorb the cost of simultaneously developing two distinct software products.25 In addition, by forcing the acrshort:mri to travel through the same four levels of the MASD Application Process we expect end users to travel, we obtain first-hand knowledge of the benefits and pitfalls of the process. More generally, this recursive application forces us to gain direct experience on the roles enacted by all actors (cf. Section Actors), as well as all processes (cf. Section Processes), meaning we can ensure they are fit for purpose.26
Comparison with Other Approaches
The previous sections have outlined a system of beliefs which underlies all thinking within MASD. Before proceeding, it is worthwhile comparing MASD's beliefs against others already analysed in State of the Art in Code Generation, with MDE being the obvious starting point.27 In contrast with the latter, MASD's vision is carefully designed to be compact in scope. One might go as far as saying it is only small subset of the overall MDE vision, and with a different direction of travel: where MDE shows a tendency towards increased rigour, abstraction and completeness28, MASD tilts the balance towards empiricism and engineering. This focus on the small is a fundamental characteristic of MASD and is also in line with our findings about MDE's state of practice (cf. The State of MDE Adoption). In this sense, MASD's use of MDE is seen mostly as an implementation detail. This is a subtle but crucial point so perhaps worthy of further elaboration.
Just as MDE's vision is to insulate domain experts from the intricacies of the implementation details, allowing them to focus on the problem space and narrowing the problem-implementation gap, so does MASD use MDE itself to insulate its domain experts — i.e., software engineers — from the implementation details — that is, the MDE techniques used by MASD, as well as the solution space implementation details — in order to allow them to focus on their problem space — the engineering of software systems — therefore reducing their problem-implementation gap: the distance between models of infrastructural code and infrastructure code itself.
On the face of it, this distinctive focus on software engineers and the solution space may appear to confront MDA's calls for direct representation (cf. Model Driven Architecture). MASD's intent is not to make any statements with regards to the validity of either of these approaches, but merely to clarify the distinctiveness of their scopes. There is thus a need to integrate MASD with other MDE based approaches, such as MDA, in order to cater for direct representation and the problem space.
The relationship between MASD and AC-MDSD is also of great relevance. Whilst MASD can be thought of as one possible realisation of the AC-MDSD principles, it is also designed to address our deep-seated concerns with naive applications of the approach (cf. Section AC-MDSD). What is novel about MASD, when compared against AC-MDSD, is its view of infrastructural code as a problem domain on its own right, worthy of study by employing MDE techniques. That is, unlike typical AC-MDSD solutions, which are customised for the specifics of a given problem, the objective of MASD is to find solutions that are applicable to the problem of infrastructural code in general.
This is a very important conceptual leap because we no longer view infrastructure code as a system-specific attribute, with perhaps some aspects that are generalisable; instead, we view it as a completely generalisable problem domain, which requires a degree of customisation for specific systems. Where AC-MDSD sees a localised solution that may only share few commonalities with other localised solutions, MASD sees it merely as the expression of variability between two different MASD models. As all quests for generality are fraught with difficulties, MASD has taken special care to temper these efforts via its core values (cf. Core Values).
And so ends our exploration of MASD as a methodology for the development of software systems. The next chapter's focus is on exploring the conceptual model imposed by MASD and all of its associated machinery.
Bibliography
Footnotes:
The traditional notion of an SDM was examined in (Craveiro 2021b) (Chapter 5), as well as its integration with model-driven approaches. (Craveiro 2021a) covers our personal experiences.
n.b., we are not attempting to make a general argument about AC-MDSD; instead, the discussion is restricted to an application of AC-MDSD that targets our specific requirements (cf. Requirements for a New Methodology). Simpler uses need not share this level of complexity, and for those, this analysis would not be relevant.
For details of the complex interactions alluded to here, please see (Craveiro 2021b) (p. 46-47).
MDE vendor tooling is deemed to be a good proxy for the level of complexity of our requirements because they target a generalised problem domain, in the same fashion as we intend to tackle the infrastructure problem domain.
MASD employs the terms physical and logical in the same manner as put forward by Lakos in his systematic study of development artefacts in a software system. He states (emphasis ours):
Developing successful software on a large scale demands a thorough understanding of two distinct but highly interrelated aspects of design: logical design and physical design. Logical design, as we will use the term, address all functional aspects of the software we develop. […] Physical design […] addresses issues surrounding the placement of logical entities, such as classes and functions, into physical ones, such as files and libraries. All design has a physical aspect. That is because all of the source code that makes up a typical C++ program resides in files, which are physical. (NO_ITEM_DATA:lakos2019large) (p. 44)
Lakos appears to be quite unique within the literature for his incessant questioning of compile time physical design, and its implications to logical design. Regrettably, a literature review of Lakos' copious material is unfeasible, given the space and time constraints of the present work. The interested audience is directed to Lakos multi-volume opus as our preferred recommendation (NO_ITEM_DATA:lakos2019large). However, as far as this dissertation is concerned, the essence of the argument had already been made in the prior incarnation of the work (Lakos 1996), of a more modest size.
It may be argued that the UML has long had provisions for a physical view, distinct from the logical view — e.g., (Stevens and Pooley 1999) (p. 155), (Booch, Rumbaugh, and Jacobson 1999) (p. 343). Nonetheless, in stark contrast to our intentions, the physical view has often been relegated to deployment as well as runtime concerns, whereas our focus is on compile-time artefacts. This disconnect forced MASD to turn its gaze towards Lakos.
The endeavour can now be summarised in a more concrete fashion. MASD is a new SDM designed to aid in the engineering of software systems by fulfilling the requirements previously gathered in Requirements for a New Methodology. An SDM is needed in order to orchestrate the many complex moving parts into an organised form of collaboration towards a common, well-established goal. MASD makes use of a well-defined subset of MDE techniques, and applies them to the problem domain of infrastructure, striving to attain an adequate level of generalisation. Significantly, MASD has not been designed as a replacement for the application of MDE to the core problem domain, but as a complementary approach with which it can be integrated.
We shall now build upon this motivational framework, and tackle the philosophical considerations that underpin the methodology.
A literature review on vision and mission statements is deemed to be beyond the scope of the present work. The interested reader is directed to Stallworth Williams (Stallworth Williams 2008) for an accessible treatment.
In our opinion, setting out a clear vision and mission statement for MASD is crucial due to the deficit in clarity that surrounds MDE's variants (Craveiro 2021b) (p. 10).
Besides the lessons learned from MDE, MASD's narrow focus is also a product of our research into special purpose code generators (Craveiro 2021c) (Section 3.1), as well as the incredibly insightful comments by Clark and Muller regarding the industry's search for a "shrink-wrapped black-box process" that hides its MDE internals (Clark and Muller 2012) (cf. Technical Factors)
In other words, much of the machinery required for integration is believed to be schematic and repetitive in nature. This belief is justified empirically via the author's two decades of industrial software development, as well as the experiences in MDE application (Craveiro 2021b).
See Chapter 4 of (Craveiro 2021b) (p. 31) for details on acrfullpl:ts and associated projections.
Nonetheless, there is a significant caveat: MASD's reference implementation is a key end-user of the methodology, meaning that features will be specifically added for this purpose, even if they have no external use cases.
The State of MDE Adoption alluded to the challenges posed by making "too many" features available to end users. For a more specific example of the dangers in adding speculative features to MDE tooling, see our own experience report (Craveiro 2021a) (Section 6.3).
Availing themselves of Renz's ideas on the matter (Renz 2007), Capra et al. define governance in this context as follows: "The governance of software projects is defined as the complex process that is responsible for the control of project scope, progress, and continuous commitment of developers. Governance is recognized to have a key role in enabling software project success […]." (NO_ITEM_DATA:&capra2008empirical)
A review of the available literature was carried out before embarking in this direction, but it is deemed to lay outside the scope of the dissertation. For those interested, we relied mainly on Crowston et al.'s comprehensive survey of the literature on FOSS development, spanning over 135 published empirical studies and including both quantitative and qualitative methods (Crowston et al. 2012). The review highlighted several points of interest, but the findings most relevant to the present work relate to the different roles in FOSS projects. Once these were identified, Lee and Cole's analysis was used to attain an increased understanding of their properties (Lee and Cole 2003).
The MASD automation spectrum is inspired on Groher and Völter's's analysis of variability and their modeling of it as a continuum (Groher and Voelter 2007). Figure 4 in particular is our take on their idea of the "Expressive power of DSLs" as a spectrum of possibilities. The automation gradient was inspired on Bosch et al.'s work on variability (Bosch et al. 2001).
Hence why the adjective assisted was chosen, as opposed to the more traditional choices such as oriented, driven, based and the like, as touched upon in (Craveiro 2021b) (p. 10, note 5).
At this juncture, one can begin to see the key differences between MASD and model-driven methodologies emerging, and it is certainly a topic worthy of further elaboration; it is addressed at the end of the chapter (cf. Comparison with Other Approaches).
Evans states (capitalisation his):
The vocabulary of that UBIQUITOUS LANGUAGE includes the names of classes and prominent operations. The LANGUAGE includes terms to discuss rules that have been made explicit in the model. It is supplemented with terms from high-level organising principles imposed on the model […]. Finally, this language is enriched with the names of patterns the team commonly applies to the domain model. (Evans 2004) (p. 23)
Brining order to this complex picture will be part of our future work.
Stahl et al. suggest avoiding this problem altogether by always maintaining backwards compatibility: "The DSL typically continues to be developed in the course of one (or more) projects. The knowledge and understanding of the domain grows and deepens, so the DSL will thus be extended. To make life simpler, one must make sure that the DSL remains backwards-compatible during its evolution." However, this approach limits the evolution of the DSL so MASD forfeits it. Nevertheless, breaking compatibility should be seen as the alternative of last resort.
Harrison states: "[T]he idea that someone would use the products they were making became known as 'eating your own dog food.' […] Regardless of its genesis, the software industry has adopted the phrase to mean that a company uses its own products. Somewhere along the line, the noun 'dog food' appears to have morphed into a verb." (Harrison 2006)
Further theoretical work is required with regards to the classification of this composite process. An argument could be made in favour of naming it a meta-process, which Rolland et al. define as "[…] a process for the construction of a process model." (Rolland, Prakash, and Benjamen 1999) The composite process could be said to drive the underlying processes, but as it is not acting as a constructor for its components, we decided against this approach.
Using the acrshort:mri as a model for a typical software product is in the Rothenberg spirit (Craveiro 2021b) (p. 16), for he had stated: "Modeling, in the broadest sense, is the cost-effective use of something in place of something else for some cognitive purpose. It allows us to use something that is simpler, safer or cheaper than reality instead of reality for some purpose." (Rothenberg et al. 1989) This is precisely our intent.
The MASD Composite Process is a translation of compiler bootstrapping to MASD. On the former, Sjölund et al. explain:
One of the advantages [of compiler bootstrapping] is assumed to be higher quality since the designers and developers of a language and its compiler will be major users, and therefore will be highly motivated to correct possible design flaws and errors. Another advantage is portability — the bootstrapped compiler is primarily dependent on itself, not on other languages, once it has been bootstrapped. […] Bootstrapping means that the language and its compiler is defined and implemented using itself.
The nature of the MASD Composite Process means that all of our application case studies will have two distinct levels of application:
- Application level: that is, the use of MASD as a regular user. Conclusions at this level will be applicable to any user of the methodology and/or the acrshort:mri.
- Meta-Application level: that is, the impact of this particular application on the methodology itself.
Finally, the Composite Process also supplies a very useful fitness function with which to measure progress for both the methodology and acrshort:mri: the objective of the acrshort:mri is to be able to generate itself, via the MASD Application Process, at Level 4 (product line generation), without requiring further changes to MASD. Achieving this milestone marked the end of the development of MASD's basic framework.
With this words we complete our analysis of MASD's processes and actors. The picture painted thus far is quite distinct from typical applications of MDE. The next section will bring the chapter to a close by elaborating on these differences.
In so far as only one philosophy exists for MDE. For the purpose of this exercise, we can consider the statements by France and Rumpe in How Widely Adopted is MDE? as representative of the MDE vision. However, the subject is by no means uncontroversial. This, we posit, is yet another side-effect of MDE's role as a diverse and constantly evolving body of knowledge (Craveiro 2021b) (Chapter 2).
As inferred by looking at research roadmaps such as France and Rumpe's (France and Rumpe 2007), as well as Mussbacher et al.'s (Mussbacher et al. 2014).