Software Conceptual Integrity: Deconstruction, Then Reconstruction

Conceptual Integrity is the most important consideration for software system design, as stated by Frederick Brooks. Brooks also suggested that Conceptual Integrity can be attained by means of design principles, such as Propriety, and Orthogonality. However, Brooks’ principles have not been formalized, posing obstacles to their application in practice, and to a deeper comprehension of Conceptual Integrity. This paper has three goals: first, to achieve deeper comprehension of Conceptual Integrity by deconstructing it into two phases, viz. Conceptualization and Modularization, iteratively applied during software system design; second, to show that the algebraic Linear Software Models already provide the hitherto lacking formalization of Brooks’ design principles, which surprisingly belong mainly to the Modularization phase; third, to reconstruct Conceptualization and Modularization, preserving the desirable tension between: a- phases separation, each with its own specific formal manipulation techniques; b- precise transition between these phases, consisting of explicit mutual relationships. The tension stems from the Modularity Matrix linking two very different kinds of entities - system concepts and abstract mathematical constructs - as seldom linked before. The paper motivates the two software design phases, illustrating Conceptualization with examples, and characterizing Modularization by its more mature mathematical theory.

💡 Research Summary

The paper revisits Frederick Brooks’s seminal claim that “Conceptual Integrity” is the most important consideration in software system design. It argues that Brooks’s three verbal design principles—Propriety, Orthogonality, and Generality—have never been formally defined, limiting their practical use and deeper theoretical understanding. To address this gap, the authors deconstruct the notion of Conceptual Integrity into two distinct yet iterative phases: (1) Conceptualization, the process of identifying and defining the domain concepts that the system must embody, and (2) Modularization, the systematic organization of those concepts into independent, cohesive modules.

Conceptualization is positioned as a human‑centric activity, drawing on Dijkstra’s “Separation of Concerns” and a “Separability Principle” that distinguishes software‑proper properties from human‑concern properties (team dynamics, economics, etc.). The authors argue that this separation allows the use of scientific (natural‑science‑like) methods for software proper while reserving social‑science techniques for human aspects. However, the paper provides only a high‑level philosophical justification for this split and does not detail concrete techniques for extracting concepts from requirements or domain models.

The core technical contribution lies in the Modularization phase, where the authors employ the Linear Software Models framework they have previously developed. Central to this framework is the Modularity Matrix, a binary matrix whose columns represent “structors” (a generalization of classes) and rows represent “functionals” (a generalization of methods). An entry of 1 indicates that a given structor provides a given functional. By assuming that all structors and functionals are linearly independent, the matrix must be square, a result derived from the Perron‑Frobenius theorem. The authors further invoke block‑diagonalization theorems: when subsets of structors and functionals are disjoint, the matrix can be permuted into a block‑diagonal form, each block corresponding to a module.

To handle imperfect modularizations (outlier couplings), the paper references eigen‑vector based techniques. Weighted and symmetrized versions of the Modularity Matrix yield eigenvectors with positive components (again via Perron‑Frobenius), which can be used to rank or cluster elements. An alternative approach uses the Laplacian matrix derived from the Modularity Matrix; its Fiedler eigenvector (the eigenvector associated with the smallest non‑zero eigenvalue) identifies natural partitions, as guaranteed by the Fiedler theorem. The authors also note an equivalence between the Modularity Matrix and a Modularity Lattice, linking their work to Formal Concept Analysis.

Crucially, the authors map Brooks’s design principles onto properties of the Modularity Matrix: Propriety corresponds to sparsity (eliminating unnecessary 1‑entries), Orthogonality to the independence of rows and columns (no overlapping responsibilities), and Generality to the reusability of structors across multiple functionals. They further draw parallels with the “four rules of simple design” from agile methodology (Test Everything, Explicit Intent, Eliminate Duplication, Minimize Entities), suggesting that these practical rules embody the same theoretical constraints.

The paper concludes by emphasizing the “precise transition” between the two phases: concepts identified during Conceptualization become the labels for structors and functionals, which are then fed into the Modularity Matrix construction. This creates a feedback loop where the mathematical analysis can suggest refinements to the conceptual model, and vice versa.

While the formalism is mathematically elegant, several limitations are evident. The assumption of linear independence for all structors and functionals is rarely satisfied in real‑world systems that employ inheritance, polymorphism, and dynamic binding, which introduce non‑linear relationships. Moreover, the paper offers limited guidance on how to operationalize Conceptualization in practice—no concrete method for requirement elicitation, domain modeling, or traceability is presented. The “precise transition” remains abstract, and the authors do not provide case studies or tool support that demonstrate the end‑to‑end workflow on a non‑trivial software project.

Nevertheless, the work makes a valuable contribution by providing a rigorous algebraic foundation for Brooks’s otherwise informal design principles. By linking conceptual integrity to linear algebraic structures, it opens avenues for automated analysis, quantitative evaluation of design quality, and potentially for tool‑assisted design optimization. Future research will need to address the practical integration of concept extraction techniques, relax the independence assumptions, and validate the approach on large‑scale industrial systems.