This 1972 paper by Parnas compares two system decomposition strategies: one based on flowcharts and step-wise refinement, and another based on information hiding. Parnas argues that decomposing a system into modules based on hiding design decisions behind interfaces leads to more stable and flexible systems. He demonstrates this by comparing two proposed modularizations of a KWIC (Key Word in Context) indexing system. The information hiding approach results in modules that are less interconnected and therefore less affected by changes in implementation details or requirements. This approach prioritizes minimizing inter-module communication and dependencies, making the resulting system easier to modify and maintain in the long run.
David Parnas's seminal 1972 paper, "On the Criteria to be Used in Decomposing Systems into Modules," challenges the then-prevailing wisdom of decomposing software systems based on a flowchart representation of the processing steps. Parnas argues that this method, often termed "stepwise refinement," leads to systems that are difficult to modify and maintain. He proposes an alternative approach centered around information hiding and minimizing inter-module dependencies.
The paper begins by illustrating the shortcomings of the flowchart-based decomposition approach through a detailed example of a KWIC (Key Word in Context) indexing system. He demonstrates how seemingly minor changes in the system's requirements necessitate significant code restructuring when modules are organized around processing steps. This fragility stems from the widespread ripple effects caused by alterations to shared data structures and assumptions about processing order.
Parnas champions a decomposition strategy where each module encapsulates a secret, or a design decision that is likely to change. This "secret" could be a data representation, an algorithm, or any other aspect of the system's internal workings. By concealing these details within modules and providing well-defined interfaces, the impact of future modifications is localized. Modules communicate with each other through these interfaces, minimizing dependencies on internal implementations. This approach, heavily based on information hiding principles, allows modules to be developed and modified independently, leading to more robust and maintainable systems.
The paper then elaborates on the criteria for selecting these "secrets." A good decomposition strategy should anticipate potential changes in the system's requirements. By identifying design decisions that are most likely to be altered and encapsulating them within modules, the system becomes more resilient to such changes. The paper stresses that the focus should be on minimizing inter-module communication and shared assumptions, rather than optimizing the flow of control.
Parnas further reinforces his arguments by presenting an alternative decomposition of the KWIC system based on information hiding. He demonstrates how this alternative design isolates the effects of changes, resulting in a more flexible and adaptable system. The different module decompositions highlight the significant impact of choosing the right criteria for modularization.
In conclusion, Parnas's paper argues against flowchart-driven decomposition and advocates for an approach based on information hiding and minimizing inter-module dependencies. By encapsulating "secrets" within modules, developers can create systems that are more readily adaptable to future changes. This seminal work laid the foundation for modern modular software design principles and continues to be highly relevant in contemporary software engineering practices. It highlights the importance of anticipating change and designing systems with flexibility and maintainability in mind, promoting the concept of modularity not just as a structural organization but as a strategy for managing complexity and change.
Summary of Comments ( 4 )
https://news.ycombinator.com/item?id=43244860
HN commenters discuss Parnas's modularity paper, largely agreeing with its core principles. Several highlight the enduring relevance of information hiding and minimizing inter-module dependencies to reduce complexity and facilitate change. Some commenters share anecdotes about encountering poorly designed systems violating these principles, reinforcing the paper's importance. The concept of "secrets" as the basis of modularity resonated, with discussions about how it applies to various levels of software design, from low-level functions to larger architectural components. A few commenters also touch upon the balance between pure theory and practical application, acknowledging the complexities of real-world software development.
The Hacker News post titled "On the criteria to be used in decomposing systems into modules (1972)" has a modest number of comments, sparking a focused discussion around the paper's core concepts and their relevance today.
Several commenters reflect on the enduring wisdom of Parnas's arguments. One user highlights the continuing struggle with modularity despite decades of progress in software engineering, suggesting that "we're still struggling to teach these lessons nearly 50 years later." Another emphasizes the importance of information hiding as crucial for managing complexity, not just in large systems but also in smaller projects.
The discussion touches upon the practical application of Parnas's principles. One commenter shares personal experience applying these ideas to a specific project, noting the resulting improvement in system maintainability. This anecdote provides a real-world illustration of the paper's theoretical concepts. Another commenter emphasizes the importance of "well defined interfaces" not just for modularity, but as a means to enable parallel development, ultimately speeding up project delivery.
A few comments delve into specific aspects of the paper. One user points out the importance of module cohesion and coupling as fundamental principles derived from Parnas's work. They highlight the interplay of these principles in achieving a well-structured system. Another commenter draws attention to the subtle but significant distinction between "hiding secrets" and hiding implementation details.
The discussion also explores alternative viewpoints and historical context. One commenter mentions the rise of microservices and how it relates (or perhaps contrasts) with the module decomposition principles outlined in the paper, questioning whether microservices truly adhere to these ideals or represent a different approach altogether.
While the discussion is not overly extensive, it provides valuable insights into the continuing relevance of Parnas's work and its impact on software engineering practices. The comments demonstrate a shared appreciation for the paper's core message while also acknowledging the ongoing challenges in applying these principles effectively in modern software development.