On the criteria to be used in decomposing systems into modules¶
Parnas, D. L. (1972). On the criteria to be used in decomposing systems into modules. Communications of the ACM, 15(12), 1053-1058.
Cited by¶
24 citations across 24 artifacts.
Each citation links to the sentence it supports in the citing article.
Primes¶
- Abstraction
- T6: Naming vs Reality.
This sourceIntroduces information hiding: each module hides a design decision likely to change behind a stable interface, so the named abstraction conceals (and reifies) an underlying contestable choice.
Supported in partVerified against the publisher's abstract
The abstract establishes only that how a system is split into modules depends on contestable, purpose-dependent criteria; it says nothing about naming or the reification of abstractions.
“The effectiveness of a “modularization” is dependent upon the criteria used in dividing the system into modules.”
- T6: Naming vs Reality.
- Boundary
- Liskov's concept of data abstraction barriers and Parnas's information hiding principle
This sourceinformation-hiding principle — modules should be decomposed around the design decisions each hides, making system design fundamentally boundary-design.
Supported in partVerified against the publisher's abstract
Parnas's own 1972 paper on decomposing systems into modules; its abstract says modularization depends on the criteria used to divide a system into modules, but does not itself state the information-hiding principle.
“The effectiveness of a “modularization” is dependent upon the criteria used in dividing the system into modules.”
- Liskov's concept of data abstraction barriers and Parnas's information hiding principle
- Catalysis
- Software engineering: build tools, scaffolding generators, formatters, and code-mod tools catalyse a codebase's transformation (refactor, upgrade, style) without becoming part of the output and while being reusable across many codebases.
This sourceEstablishes information hiding: a stable module interface shields clients while the hidden implementation can change — the structural basis for reusable build/codemod/formatter tools that transform a codebase without becoming part of its output.
- Software engineering: build tools, scaffolding generators, formatters, and code-mod tools catalyse a codebase's transformation (refactor, upgrade, style) without becoming part of the output and while being reusable across many codebases.
- Category Retrieval Lock In
- The property-rich substrate is a function whose true property list includes its memory behavior, exception profile, concurrency guarantees, and performance characteristics.
This sourceEstablishes information hiding: a module's interface is a stable label that compresses away (hides) its implementation properties, so callers bind to the interface, not the hidden operational behavior.
- The property-rich substrate is a function whose true property list includes its memory behavior, exception profile, concurrency guarantees, and performance characteristics.
- Compatibility
- Designers can reason about composition without exhaustive testing—the principle Parnas (1972) established as the foundation of modular system design through information hiding.
This sourceSeminal information-hiding paper: establishes modular decomposition so that modules can be designed and changed independently behind stable interfaces, the foundation for reasoning about composition without exhaustive testing.
Supported in partVerified against the publisher's abstract
Parnas (1972)'s abstract credits modularization with flexibility and comprehensibility of a system, but it never states that designers can reason about composition without exhaustive testing.
“This paper discusses modularization as a mechanism for improving the flexibility and comprehensibility of a system while allowing the shortening of its development time.”
- Designers can reason about composition without exhaustive testing—the principle Parnas (1972) established as the foundation of modular system design through information hiding.
- Decomposition
- Computer science & software engineering: Modular design, separation of concerns, microservices architecture, API-driven decomposition, object-oriented hierarchy, divide-and-conquer algorithms (merge sort, quicksort), component-based frameworks—an approach Parnas (1972) anchored with his information-hiding criterion for module boundaries.
Supported in partVerified against the publisher's abstract
The abstract of Parnas (1972) confirms that how a system is divided into modules is decided by explicit criteria, but it never names the information-hiding criterion or any of the other engineering practices the claim lists.
“The effectiveness of a “modularization” is dependent upon the criteria used in dividing the system into modules.”
- Computer science & software engineering: Modular design, separation of concerns, microservices architecture, API-driven decomposition, object-oriented hierarchy, divide-and-conquer algorithms (merge sort, quicksort), component-based frameworks—an approach Parnas (1972) anchored with his information-hiding criterion for module boundaries.
- Dependency
- Dependency is the directed relation in which one element relies on another being present, prior, compatible, or supplied — a structural asymmetry where A cannot proceed, function, be interpreted, or retain its value unless some condition on B is met, a relation Parnas (1972) made foundational to modular decomposition by treating "module A depends on module B" as the operational criterion governing which design changes propagate.
This sourceFounds modular decomposition on information hiding; treats which modules depend on which as the operational criterion governing how design changes propagate.
Supported in partVerified against the publisher's abstract
Parnas (1972) founds modular decomposition on criteria for dividing a system into modules; its abstract says nothing of dependency graphs, package managers or versioning.
“The effectiveness of a “modularization” is dependent upon the criteria used in dividing the system into modules.”
- Dependency is the directed relation in which one element relies on another being present, prior, compatible, or supplied — a structural asymmetry where A cannot proceed, function, be interpreted, or retain its value unless some condition on B is met, a relation Parnas (1972) made foundational to modular decomposition by treating "module A depends on module B" as the operational criterion governing which design changes propagate.
- Division of Labor
- Listed in the references but not attached to a specific claim.
- Information Hiding
- In software engineering it is Parnas's module decomposition, encapsulation in object-oriented programming, API design where only the documented interface is the contract, opaque handle types, and the principle of least privilege.
This sourceOriginates information hiding — modules should hide the design decisions most likely to change behind a stable interface, capping each consumer's dependency at the public surface so internals can change freely.
Supported in partVerified against the publisher's abstract
Parnas's abstract backs only the module-decomposition clause: modularization as criterion-based division of a system into modules; it says nothing of encapsulation, API contracts, opaque handles, or least privilege.
“The effectiveness of a “modularization” is dependent upon the criteria used in dividing the system into modules.”
- In software engineering it is Parnas's module decomposition, encapsulation in object-oriented programming, API design where only the documented interface is the contract, opaque handle types, and the principle of least privilege.
- Interface
- A bounded surface—physical, digital, or abstract—across which two distinct systems exchange information, energy, matter, or control, the foundational concept Parnas (1972) crystallized in his analysis of modular decomposition.
Supported in partVerified against the publisher's abstract
Parnas (1972) is a landmark paper on modular decomposition criteria; its abstract never defines an interface as a bounded surface for exchanging information, energy, matter, or control, so it does not source that definition.
“This paper discusses modularization as a mechanism for improving the flexibility and comprehensibility of a system while allowing the shortening of its development time.”
- A bounded surface—physical, digital, or abstract—across which two distinct systems exchange information, energy, matter, or control, the foundational concept Parnas (1972) crystallized in his analysis of modular decomposition.
- Layered Accumulation
- Listed in the references but not attached to a specific claim.
- Layering
- The hierarchical decomposition into well-defined layers, each exposing an interface and hiding implementation detail
Supported in partVerified against the publisher's abstract
Parnas's abstract supplies criteria-based decomposition of a system into modules and modularization's benefits, but says nothing of hierarchical layers, per-layer interfaces, or hiding implementation detail.
“The effectiveness of a “modularization” is dependent upon the criteria used in dividing the system into modules.”
- The hierarchical decomposition into well-defined layers, each exposing an interface and hiding implementation detail
- Minimalism
- Modularity
- The decomposition of a system into modules with distinct functional responsibilities
Supported in partVerified against the publisher's abstract
Parnas's abstract backs decomposing a system into modules as a criteria-governed design act, but says nothing about modules having 'distinct functional responsibilities'.
“The effectiveness of a “modularization” is dependent upon the criteria used in dividing the system into modules.”
- The decomposition of a system into modules with distinct functional responsibilities
- Preparatory Field Conditioning
- Refactoring
- The architectural insight that the held-constant envelope can be the only externally visible commitment — a heritage facade behind which everything is renovated — transfers to long-lived software APIs, where the published interface is the facade and everything behind it is free to change.
This sourceIntroduces information hiding: a stable interface is presented to the rest of the system while the design decisions likely to change are hidden behind it — the foundation for treating a published API as a held-constant facade behind which internals freely change.
- The architectural insight that the held-constant envelope can be the only externally visible commitment — a heritage facade behind which everything is renovated — transfers to long-lived software APIs, where the published interface is the facade and everything behind it is free to change.
- Substitutability
- It separates "which component fills a role?" from "what functions must that role provide?" and names the property that different answers to the first question need not change the answer to the second—a separation Parnas (1972) operationalized as "information hiding," in which each module exposes only the design decisions that other modules must depend on, leaving its internal implementation freely substitutable.
Supported in partVerified against the publisher's abstract
Parnas's abstract grounds the paper in decomposition criteria but never states information hiding or substitutable implementations.
“The effectiveness of a “modularization” is dependent upon the criteria used in dividing the system into modules.”
- It separates "which component fills a role?" from "what functions must that role provide?" and names the property that different answers to the first question need not change the answer to the second—a separation Parnas (1972) operationalized as "information hiding," in which each module exposes only the design decisions that other modules must depend on, leaving its internal implementation freely substitutable.
- Task Interdependence
Domain-specific¶
- Interface segregation principle
- The principle is a specific application of information hiding (Parnas) and minimised coupling to the OO method-contract level
This sourceParnas's information-hiding criterion - each module hides a design decision, its interface revealing as little as possible - which is the underlying idea the article traces ISP to, though Parnas draws no connection to object-oriented method contracts.
Supported in partVerified against the source
- The principle is a specific application of information hiding (Parnas) and minimised coupling to the OO method-contract level
Mechanisms¶
- Abstract Data Type Interface
- An interface that promises too little forces callers to reach around it and re-couple to the representation; one that promises too much — leaking internal order, exposing internals — quietly freezes the representation it was meant to free, exactly the leak that information hiding warns against.
This sourceShows that exposing internal design decisions and representation assumptions across an interface freezes dependencies that information hiding is intended to conceal.
- An interface that promises too little forces callers to reach around it and re-couple to the representation; one that promises too much — leaking internal order, exposing internals — quietly freezes the representation it was meant to free, exactly the leak that information hiding warns against.
- Layered Model
- Its strength is independent evolution: a layer can be rewritten, optimized, or replaced behind a stable interface without touching the rest, and each layer can be understood and tested on its own terms.
This sourceShows that information-hiding modules can be changed or replaced independently and studied and tested one at a time.
- Its strength is independent evolution: a layer can be rewritten, optimized, or replaced behind a stable interface without touching the rest, and each layer can be understood and tested on its own terms.
- Modular Design Rule
- The guarding discipline is Parnas-style information hiding:
This sourceDefines information hiding as preserving a stable module interface while concealing design decisions likely to change.
- The guarding discipline is Parnas-style information hiding:
- Modular Interfaces
- This is the classic value of information hiding — decoupling users from decisions they should not have to make.
This sourceDefines information hiding as placing a changeable design decision inside one module so other modules need not know or depend on it.
- This is the classic value of information hiding — decoupling users from decisions they should not have to make.
- Software Module Decomposition
- This is the original argument for decomposing by information hiding rather than by flowchart step.
This sourceIntroduces information hiding as a criterion for decomposing systems into modules and contrasts it with decomposition around processing or flowchart steps.
- This is the original argument for decomposing by information hiding rather than by flowchart step.
Verification¶
Does it exist? Confirmed. This work's DOI resolves to a registered record, which fixes its identity. That is all it fixes.
Does it back the claim? Read against the text for 11 of 24 citations: 11 supported in part. Each verdict is shown under its citation below, with what in the work backs the sentence.
Was it audited? Yes. A second, independent pass read the citation against the article text and recorded a verdict.
Support is checked per citation rather than per work — the same source can be cited soundly in one article and wrongly in another. Per-citation recording began recently, so a citation with no recorded check is a gap in the record rather than evidence it went unchecked.
See how references were verified.
Registry ID ref:bd3a3b7ad83e · see in the full table