Models transformation is generally recognized as the basic mechanism of model based systems engineering (MBSE). Yet, the actual scope of transformations is somewhat limited to design-to-code, and its sequential bias puts MBSE at odds with agile development approaches. Could a revisited understanding help to figure out this apparent discrepancy ?
Transformation Issues
Traditional transformation paradigm involves ordered sequences of models obtained by applying rules to their immediate predecessor(s). That organizational scheme has three critical consequences, for applicability, economics of reuse, and development processes.
- Applicability: the effectiveness of transformations is conditioned by (a) an executable language for the description of targets, and (b) a closed and compact set of unambiguous patterns. Those conditions can only be satisfied for the downstream part of the development process.
- Reuse: given the sequencing constraints, models are to be managed and reused along tree-like structures with duplicates introduced at branching points.
- Development processes: sequenced models brings forth phased options and leaves out agile solutions.
Assuming those issues are not conclusive, they may be overcame by revisiting the nature of transformations.
Transformation vs Inheritance & Composition
Most of the proposed taxonomies (see references below) put the focus on languages and mechanisms (e.g rules) of sequential transformation without paying enough attention to the nature and the semantics of models contents. Even when abstraction levels are taken into account, the respective contents of each level remain undefined. As it happens, that issue may be the key to a better understanding of models transformation.
To begin with, rule-based transformation has to be compared to inheritance and composition:
- Structural inheritance can be used to refine models as to take into account business scenarii previously ignored; e.g special conditions for good customers.
- Functional inheritance can be used to introduce new capabilities; e.g new authentication procedures.
- Functional composition can be used to apply capabilities across different scenarii; e.g customized authentication procedures.
- Rules-based solutions can be used by any kind of transformation.
That taxonomy implies a clear distinction between operations executed within the same level of abstraction and those targeting artifacts defined at different levels: contrary to rules-based transformations, inheritance and composition can only be applied to artifacts sharing common semantics.
heterogeneous Models
While that would clearly prevent their use for models organized along abstraction levels, semantic pitfalls could be mastered for models built from artifacts from different abstraction levels.
Releasing models from (still to be defined) abstraction levels would bring two critical benefits:
- Whatever the terminology (abstract, conceptual, functional, etc.), abstraction semantics are much easier to define for artifacts than for models.
- That would remove a chunk of restrictions on the design of transformation processes.
In that case transformation rules could be turned into combination ones and sequential transformation turned into cross-breeding.
Mendel, Models, Mongrels
Taking a cue from Gregor Mendel’s use of cross-fertilization, the aim of a revisited transformation paradigm would be three-fold:
- To refine the granularity of reuse, from models to artifacts
- To substitute combination for sequential transformation whenever possible.
- To substitute graphs for trees, with models organized along two basic layers, final (aka mongrels) or reusable (aka blueprints).
As far as MBSE is concerned, the genetics metaphor helps to clarify the nature of abstraction. Conceptually, it introduces a distinction between artifacts and models:
- With regard to artifacts, abstraction layers are defined by scope: enterprise, systems, platforms.
- With regard to models, abstraction layers are defined by capabilities: reusable (stable traits), or final (recessive traits).
That taxonomy is corroborated by its functional counterpart: artifacts transformation is carried out with inheritance and composition, models transformation relies on combination.
More important, that understanding goes a long way solving the issues regarding scope, reuse, and development processes.
Scope: Weaving Analysis & Design Traits
Definitions and taxonomies should always be assessed with regard of their applicability. On that account there isn’t much to say for abstraction layers applied to models: they don’t fit because too many traits can be defined across different layers, e.g: business rules, authentication, encryption, etc.
That difficulty can be neatly and consistently removed by models built from artifacts defined at different levels.
Models Reuse: Blueprints vs Mongrels
Reuse is all too often seen as a contentious objective with inconclusive ROI. One one hand it requires significant overheads to manage the resources, on the other hand the outcomes can introduce regressive traits. The distinction between sound reusable models and final ones significantly reduces both the costs of the former and the risks of the latter.
Processes Organization: MBSE & Agile
Model based systems engineering and the agile development model are arguably two of the most conclusive approaches to software engineering. Unfortunately they are often seen as difficult bedfellows, principally (but not uniquely) because the former insists on the importance of models with some bias toward phased processes, while the latter is all for iterative processes with models mentioned as an afterthought, if at all. Yet, both approaches could be made complementary on condition that models could be processed iteratively. And that could be achieved if sequenced transformations of homogeneous models would be replaced by the combination of heterogeneous ones.
Within such a framework an agile team could, e.g, iteratively develop new business requirements, taking into account existing functionalities (a) and business rules (b), and generate code (c).
Further readings
- Thread: Model Based Systems Engineering
- Knowledge Based Model Transformation
- Legacy Refactoring
- Modernization & The Archaeology of Software
- EA & MDA
- The Cases for Reuse
- The Economics of Reuse
- Agile & Models
External Links
- Report of the Dagstuhl Seminar
- Classification of Model Transformation Approaches
- Atlas Transformation Language (ATL)