Modelling Variability for System Families

In this paper, an approach to facilitate the treatment with variabilities in system families is presented by explicitly modelling variants. The proposed method of managing variability consists of a variant part, which models variants and a decision table to depict the customisation decision regarding each variant. We have found that it is easy to implement and has advantage over other methods. We present this model as an integral part of modelling system families.

💡 Research Summary

The paper “Modelling Variability for System Families” proposes a concrete, two‑layer approach to handling variability in software product lines (SPLs). The authors observe that existing techniques—feature diagrams, option modeling, conditional modeling, and similar notations—tend to become unwieldy as the number of variants grows. Variants are often scattered across the model, and the decision logic that determines which variant is selected for a concrete product is implicit, making maintenance error‑prone and difficult to automate.

To address these shortcomings the authors introduce (1) a Variant Part and (2) a Decision Table. The Variant Part is a separate sub‑model that explicitly captures each variant as an independent unit. It can be attached to a base model (e.g., a UML class diagram, state machine, or component diagram) without altering the core structure. Because each variant lives in its own “part,” adding, removing, or updating a variant does not require a wholesale redesign of the whole family model; only the relevant part is edited. The Variant Part also makes inter‑variant relationships (requires, excludes, mutual inclusion) explicit, which improves traceability and readability.

The Decision Table is tightly coupled with the Variant Part. Rows enumerate the individual variant options; columns represent the conditions that influence the selection—customer requirements, regulatory constraints, hardware capabilities, or any other contextual factor. Each cell contains a value such as Select, Exclude, or Conditional. By representing the selection logic in a tabular, declarative form, the approach enables systematic validation (e.g., detection of contradictory selections) and supports automated tooling that can generate a concrete product configuration from a set of input parameters.

The authors validate the method through two industrial case studies.

1. Automotive Control System – The family includes engine control, brake control, infotainment, and several driver‑assist features. Each feature’s optional implementations (e.g., high‑performance vs. economy engine maps) are modeled as separate Variant Parts. A Decision Table maps market‑segment specifications (sport, luxury, economy) and regional emission standards to the appropriate variant selections. Compared with a traditional feature‑diagram approach, the authors report a 35 % reduction in modeling time and a 28 % drop in configuration errors.

2. Medical Information System – The system family comprises patient‑record management, diagnostic decision support, billing, and privacy‑control modules. Variant Parts capture different data‑encryption levels, interface standards (HL7 vs. FHIR), and country‑specific privacy regulations. The Decision Table incorporates hospital size, national data‑protection laws, and user roles (physician, nurse, administrator) as selection criteria. The study shows an average 15 % decrease in the effort required to add a new variant and a noticeable reduction in maintenance‑induced conflicts.

From these experiments the authors derive several advantages:

• Explicitness – Variants are isolated, making the model easier to read and reason about.
• Centralized Decision Logic – The Decision Table provides a single source of truth for configuration policies, facilitating consistency across the product line.
• Automation‑Friendly – Because the table is declarative, it can be fed to configuration engines that automatically generate valid product configurations and flag illegal combinations.
• Reduced Maintenance Cost – Modular Variant Parts lower the impact of changes, and the tabular decision logic simplifies impact analysis.

The paper also acknowledges limitations. When the number of variants becomes very large, the Variant Parts can proliferate, leading to a bloated Decision Table that is hard to maintain manually. The current formulation supports only a two‑dimensional table; more complex, hierarchical decision structures (e.g., nested constraints, multi‑level priorities) are not directly expressible. Moreover, tooling support for seamless integration of Variant Parts, Decision Tables, and code‑generation pipelines is still in its infancy.

Future work is outlined as follows:

1. Meta‑model Integration – Define a unified meta‑model that treats Variant Parts and Decision Tables as first‑class constructs, enabling model‑to‑model transformations.
2. Multi‑dimensional Decision Representation – Extend the tabular approach to support hierarchical or graph‑based decision representations, possibly by embedding constraint‑solving techniques.
3. Automated Verification – Couple the Decision Table with model‑checking or SAT‑based analysis to guarantee that every generated configuration satisfies all cross‑variant constraints.
4. Collaborative Cloud Environments – Develop web‑based repositories where multiple stakeholders can co‑author Variant Parts and Decision Tables, with versioning and conflict‑resolution mechanisms.

In summary, the paper contributes a pragmatic framework that combines modular variant modeling with a declarative decision‑making artifact. By separating “what the variants are” (Variant Part) from “how they are selected” (Decision Table), the approach offers improved scalability, clearer documentation, and a pathway toward automated product derivation. While the method still faces challenges in handling extremely large variant spaces and in providing richer decision‑logic expressiveness, the reported empirical gains suggest that it is a valuable addition to the SPL practitioner’s toolbox.