Variability
Table of Contents
MASD separates what to generate (the logical and physical models) from how it is configured (the variability model). In MASD the word variability is reserved for non-structural variability — configuration that does not change the object graph of a model, only how it is rendered. The Variability Metamodel (VMM) formalises this dimension; a Variability Model instantiates it with concrete runtime configuration.
The VMM addresses two things:
- Enabling or disabling regions of physical space — technical spaces, facets, and individual archetypes.
- Configuring projections — naming, file extensions, and feature toggles.
Configuration is supplied as tagged values on UML-style stereotypes.
See Domain Architecture and The MASD Methodology for the formal treatment.
The feature architecture
MASD builds on Feature Modelling, simplified:
- A feature is a single configuration point — for example whether the
hashfacet is enabled, or what the output directory should be. Every feature has a qualified name (e.g.masd.cpp.hash.enabled), a type (boolean, string, collection), and a default value. - A feature bundle groups semantically related features.
- A feature template is an abstract feature instantiated over a domain — for
example
masd.archetype, instantiated once per archetype. - A binding point is the set of legal meta-entities at which a feature may be used.
Figure 1: Figure 38 (Dogen): a fragment of the feature bundles defined within the LMM. Source: Domain Architecture.
Profiles
A profile is a bundle of configuration points that can be bound to logical
elements. Profiles are the primary mechanism for configuring generation without
modifying individual model elements, and they are named after the ability they
confer — serializable, hashable, and so on — so they can be reused across
products and product lines. They compose in a hierarchy:
| Level | Name | Applies to |
|---|---|---|
| Broadest | Base profile | The entire product — product-wide defaults. |
| Intermediate | Component profile | A single component — overrides product defaults. |
| Most specific | Element profile | A single model element — overrides everything above. |
A more specific profile inherits from a broader one and overrides only what it needs to change.
Figure 2: Figure 41 (Dogen): sample reference-implementation profiles. Source: Domain Architecture.
Configuration scopes
Feature values can be set at three scopes, from broadest to most specific:
| Scope | Applies to | Example |
|---|---|---|
| Product | Every element in the product | Enable serialisation product-wide |
| Component | Every element in one component | Disable odb for a pure in-memory lib |
| Element | A single logical entity | Enable io on one specific object alone |
A more specific scope always wins. This lets a product set safe defaults and override them surgically at component or element level.
See also
- MASD — methodology overview and the conceptual model.
- Facet — what variability most often controls (facet activation).
- Physical Space — the space whose regions variability enables or disables.
- Logical Space — the default facet-per-entity-type table that variability overrides.
- Applied MASD — how one product instantiates this variability model.