The Software System Tuple

The Independent Variation Principle is stated over a model of a software system. This model names every object the theory needs to reason about change. It is called the software system tuple.

The tuple is written $S = (F, \kappa_F, E, \text{Coupling}, C, \Gamma)$ . Each entry is one ingredient of the model.

$F$ — functional purpose. The overall goal the system is designed to realize.
$\kappa_F$ — relevant causal domain knowledge. The causal knowledge the system must carry to realize $F$ . It spans every concern domain that contributes a source of change: technical domains (business logic, algorithms, data formats, persistence, protocols), operational and quality domains (performance, availability, security, deployment, concurrency, regulation), and organizational domains (who holds decision authority over elements).
$E$ — elements. The finite set of artifacts inside the system boundary that can change in response to a change driver. A function, a class, a data structure, a configuration file — whatever grain of artifact the analysis operates on.
Coupling — the coupling relation. A record of how elements depend on one another, tagged by dimension and strength.
$C$ — change drivers. The finite set of independent sources of change. Each change driver $\gamma \in C$ governs a slice of knowledge $\kappa_\gamma$ , and the slices partition $\kappa_F$ .
$\Gamma$ — change-driver assignment. The function that maps each element to the set of change drivers that can force it to change: $\Gamma : E \to \mathcal{P}(C)$ .

The first five ingredients are inputs. They describe the system and its environment as the analysis finds them. The sixth, $\Gamma$ , is the pivot: it is the map the whole principle operates on.

1 What the tuple is for

The tuple gives the theory a fixed vocabulary. When the site says “a change driver,” “an element,” or “the coupling relation,” it means exactly the object named in the tuple. The tuple does not describe a new kind of system. It describes any software system in terms that make its structure under change visible.

The tuple is defined and discussed in the formal papers. Here we explain what each entry means and why the tuple is built this way. The software system tuple $S = (F, \kappa_F, E, \text{Coupling}, C, \Gamma)$ is the model the Independent Variation Principle is stated over, as defined in the published paper on the principle [1]. The role of the causal domain knowledge $\kappa_F$ in the model is developed in the paper on the nature of cohesion [2].

2 Elements respond to change drivers

The central modelling move is $\Gamma$ : every element is assigned the set of change drivers whose activation would force it to be modified. A computeTax() function is assigned the tax-legislation driver, because when the tax rate changes, the function must change. A sanitizeInput() function is assigned the sanitization-policy driver.

The assignment is not arbitrary. It is read from the domain: which external conditions, if they activate, force this element to change. Whether an element responds to one driver or several is a property of the domain’s causal structure, not a choice the designer makes.

3 Two sets must be distinguished

$\Gamma(e)$ is the set of change drivers that force element $e$ to change. The module driver set $\Gamma(M)$ of a module $M \subseteq E$ is the union of the driver sets of its elements.

These are different objects. $\Gamma(e)$ is a set of drivers for a single element. $\Gamma(M)$ is a set of drivers for a group of elements. Keeping them separate matters when the theory reasons about how elements group into modules.

The formal development. The definitions, theorems, and proofs behind this page are published in:

The Independent Variation Principle — Zenodo, 2026 — doi:10.5281/zenodo.20794332
On the Nature of Cohesion: Cohesion as Correctness Relative to a Partitioning Rule — Zenodo, 2026 — doi:10.5281/zenodo.21703193

All published papers

References

[1]

Y. Loth, “The independent variation principle.” Zenodo, Jun. 2026. doi: 10.5281/zenodo.20794332.

[2]

Y. Loth, “On the nature of cohesion: Cohesion as correctness relative to a partitioning rule.” Zenodo, Jul. 2026. doi: 10.5281/zenodo.21703193.