• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Bear Bibeault
  • Ron McLeod
  • Jeanne Boyarsky
  • Paul Clapham
Sheriffs:
  • Tim Cooke
  • Liutauras Vilda
  • Junilu Lacar
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Tim Holloway
  • fred rosenberger
  • salvin francis
Bartenders:
  • Piet Souris
  • Frits Walraven
  • Carey Brown

Righting Software: D. Parnas' paper on modularization

 
Sheriff
Posts: 15815
264
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
In the book sample I've been citing, there's a reference to a 1972 paper titled On the Criteria To Be Used in Decomposing Systems into Modules by David Parnas. In the conclusion of the paper,

David Parnas wrote:... it is almost always incorrect to begin the decomposition of a system into modules on the basis of a flowchart. We propose instead that one begins with a list of difficult design decisions or design decisions which are likely to change. Each module is then designed to hide such a decision from the others.


What I've read in the book sample and Juval's answers so far does seem to align to the above proposal, to base design decisions on what's likely to change (what Juval refers to as Volatility-based Decomposition).

I'd like to get some feedback on my current understanding, which admittedly is still very fuzzy, about all this. Drawing from what I know and what I've experienced in the past, it seems to me these ideas are related to DRY (Don't Repeat Yourself) and the Single Responsibility Principle (that a software module should have one and only one reason to change). One of the criticisms of functional decomposition is that you often end up duplicating the same kind of functionality or "knowledge" across multiple modules. This is a violation of DRY which states that "In a system, there should be one and only representation of each piece of knowledge."

Juval, am I (even somewhat) on the right track here? There are still a lot of other questions I'd like to ask but it seems to me the above is fundamental to correctly understanding yours and Parnas' ideas about modularization and decomposition.
 
Author
Posts: 12
10
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
While DRI and SRP are good ideas, they are secondary if not tertiary to the main idea of encapsulating change.
As you will see in Chapter 3, where the book offers structure and guidelines, a single component could even encapsulate multiple volatilities.
So the dominant idea, the main added value is the encapsulation, not the singularity of it.
What you are missing in the picture is the role of components, a governing taxonomy.
I hope that once you read Chapter 3 (and Chapter 4) it will become clear.
    Bookmark Topic Watch Topic
  • New Topic