Requirements for a New Methodology

As explained at length in (Craveiro 2021b) (Chapter 2), MDE is a vast body of knowledge with unclear boundaries. The new approach must avoid these difficulties by explicitly defining its purpose and clarifying its relationship with MDE and MD*. In addition, the boundaries of the new approach are circumscribed exclusively to AC-MDSD — namely, to the automatic generation of schematic and repetitive code (cf. Architecture-Centric MDSD (AC-MDSD)).

Identity is a thorny problem within MDE (Craveiro 2021b) (p. 10), and thus a frequent source of confusion to newcomers. In addition to having a well-defined purpose (RQ-01), any proposed solution must also have a well-defined identity, explicitly distinct from all existing approaches within MDE. An important consequence of a well-defined identity is that it will facilitate macro-analysis of its application (cf. Analysis of Evidence at a Macro-Scale).

MDE accumulates knowledge on the subject of modeling, serving many distinct audiences in the software development process. As a consequence, it is difficult to find an entry point into the body of knowledge (Craveiro 2021a), (Craveiro 2021b) (Chapter 2). The new approach must set out its target audience explicitly; its focus is only on software engineers with little to no knowledge of MDE. The intent is not to discourage experienced MDE practitioners, but to bring clarity as to whom the approach is aiming to serve. All decisions must take into account the target audience.

A key part in establishing a well-defined purpose (RQ-01) and identity (RQ-02) is to create a domain architecture that acts as the single source of truth for the approach. MDE concepts that are difficult to define rigorously — such as TS, platforms and the like — must be made clear and unambiguous within the domain architecture. In addition, these more rigorous definitions must not disagree with their common usage within MDE.

The domain architecture (RQ-04) must be designed for continuous extension in order to remain relevant. The approach must define the processes by which it can be updated, as well as the criteria for inclusion or exclusion of changes. This requirement attempts to address France and Rumpe's warning regarding the "widening of the problem-implementation gap" through evolution (cf. MDA), and reflects the importance placed on keeping up to date with changes on platforms and TS.

Given the limited scope of the new approach, software engineers will require an overall process to manage the software development lifecycle via a traditional SDM, which we call the host methodology. As with MDE, the new approach must be agnostic to the host methodology being applied. Unlike MDE, the new approach must integrate with its host without requiring any changes to the latter or to itself.²

In order to allay concerns over cost, vendor lock-in and vendor survivability (cf. External Organisational Factors), the approach and all of its components must have a governance model that accepts contributions from a variety of sources. The approach must include a process by which any interested party can contribute changes. The governance model should be focused towards increasing the number of use cases for the approach (RQ-11), in accordance to its purpose (RQ-01) and target audience (RQ-03).

The modeling language for the new approach must support both PSM and PIM (cf. MDA). Platform independence must be built upon a set of well-defined mappings in accordance with the domain architecture (RQ-03), and extensible by users. Use of PIM must remain optional.

The new approach must cater for PDMs.³ These provide mappings for external building blocks, making them accessible by the methodology's modeling language. PDM must be extensible by users and subsequently incorporable into the domain architecture (RQ-04) and tooling via a well-defined process.

The modeling language put forward by the approach must include limited support for product lines, constraining variability to a well-defined variability space.⁴

A framework for the management of schematic repetitive code (cf. MDA) must be defined as part of the domain architecture (RQ-04). It must include a catalogue of the patterns already identified, including their taxonomy, variability and dependencies, as well as outlining a process to identify and propose new patterns.

In order to avoid the complexity created by heterogeneous tooling (cf. External Organisational Factors), the new approach must provide a single, end-to-end solution for the modeling and generation of schematic and repetitive code (RQ-11).

This entails specifying the behaviour of all necessary tooling (RQ-04) both in terms of their inputs — i.e. modeling languages — and outputs — i.e. programming languages. It also entails providing a comprehensive reference implementation. Significantly, this requirement does not preclude integrating with external tools, but instead attempts to minimise accidental complexity within its core competences (RQ-01).

All tooling should use a black-box approach where possible. For example, end-users are not expected to have access to a MT language to operate on the input models; instead, from an end-user perspective, PIM and PSM must act as if transformed directly into source code (cf. Technical Factors). More generally, the approach should aim to promote tooling closer in spirit to special purpose code generators (Craveiro 2021c) rather than to traditional MDE tools.

Closely related to RQ-13 is the need for a clear demarcation of responsibilities between those applying the new approach and those maintaining and extending it. End-users — the consumers of the approach — should only be required to learn a minimal set of modeling concepts in order to use it. Those working on the approach itself are expected to be competent MDE practitioners.

Note that this requirement does not preclude allowing end-users to get involved with tool development, but merely defines the distinct roles available.

One of the most significant themes to come out of the adoption literature analysis were deficiencies in tooling integration (cf. Technical Factors). Consequently, the new approach must take special care in this regard, as follows:

• Reuse input formats: instead of proposing new native representations for its modeling language, the new approach should focus on specifying mappings (via RQ-04) to existing modeling languages. These mappings are intended to cover tooling used by developers such as IDE and build systems, as well as existing modeling tools.
• Standard error reporting: the reporting of errors and warnings must be designed in accordance with existing tooling — in particular those which are already well supported in contemporary development environments (Craveiro 2021c).
• Minimal dependencies: in order to facilitate integration, the reference implementation must be available as both as a command-line utility and as a library, with little to no external dependencies (Craveiro 2021c).

The overall objective of these dimensions is to allow end-users to continue using preferred toolsets and to cause minimal disruption to existing workflows.

Following on from RQ-06, end-users must be able to make use of the approach according to their specific needs. These range from code-generation of trivial PSM (RQ-08) to the management of products and even entire product lines (RQ-10), and thus span both top-down and bottom-up application (cf. Social Factors). As a result, the domain architecture (RQ-04) must specify these different levels of use, and define how they are to be supported by the approach and its tooling — with the objective of guiding users towards more advanced uses as their mastery develops.

Last but not least, experienced MDE practitioners should also be able to make use of the approach if, and only if, such use cases do not raise the complexity bar for the target audience (RQ-03) and are within the remit of the approach's purpose (RQ-01).

The reference implementation must be validated by a set of automated conformance tests which determine the level of compliance. These can then be reused by third-party implementations. Conformance tests must cover scalability — i.e. expected behaviour for different model sizes — as well as any available integration with third party tooling.