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.

Type

Journal article

Intellectual base

Primary research

Year

1972

DOI

10.1145/361598.361623

Link

https://doi.org/10.1145/361598.361623

Cited from

art_aesthetics, chemistry_materials, computer_science, earth_sciences, economics_finance, engineering_design, mathematics, military_security, organizational_management, philosophy, psychology, systems_cybernetics

Cited by

21 citations across 21 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

• 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.

• 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.

• 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.

• 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.

• 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.
• 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 — supports markers 211, 219, 220.

• 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.

• 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.
• 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
• Minimalism
  • Modularity and minimalism can coexist (a minimalist interface built with modular code), but they serve different purposes: modularity manages complexity through organization; minimalism reduces complexity through elimination.
• Modularity
  • The decomposition of a system into modules with distinct functional responsibilities
• Preparatory Field Conditioning
  • Neither needs a working model of the other's internals.
• 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.

• 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.
• Task Interdependence
  • The tightness of coupling (tight coupling where delays propagate immediately versus loose coupling where buffers absorb variation)

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.

Mechanisms

• 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.

• Software Module Decomposition
  • This is the original argument for decomposing by information hiding rather than by flowchart step.

    This sourceIt remains the canonical justification for boundary-by-secret over boundary-by-function.

Verification

This reference passed the adversarial substantiation pipeline: it was checked to exist and to support the claim it is attached to. See how references were verified.

Registry ID ref:bd3a3b7ad83e · see in the full table