1. On the Criteria to Be Used in Decomposing Systems into Modules
D. L. Parnas

2. Modularization
Modularization is a mechanism for improving the flexibility and comprehensibility of a system while shortening its development time
The system must be decomposed into modules (a.k.a subsystems) using certain criteria
A lot of what this paper talks about is common day knowledge, but remember that it was written in the early 1970’s

3. Historical Perspective
The concept of a module was not new when this paper was written
BUT, although others spoke about what a module was, nothing was done to describe how a system is decomposed into modules
Major contribution is that Parnas provides criteria for decomposing systems into modules (and not for the notion of a module itself)

4. Benefits of using a Modular Approach to Software Design
Managerial – individual modules can be developed concurrently since they will be specified by their external behavior and interfaces
Flexibility – individual modules should be able to be changed without radical impact to the rest of the system
Program Understanding – possible to study the systems more abstractly – by understanding the modules prior to understanding the code

5. What is a Module A module is not a subprogram it’s a work assignment
Design at the module level first – then define the modules themselves
A module is categorized by the design decision(s) that it hides from all of the other modules in the system (information hiding)
Sounds a lot like the approaches we use today for design of object- and component-oriented programs (30+ years later)

6. Dividing a System into Modules
A module is physically categorized by a well defined interface that is small and simple enough to be thoroughly understood and well programmed
There is no question about what a modules is - the real question is about how a system is decomposed into modules, and how to compare one modularization to another modularization

7. Parnas Example: KWIC Index – Classical Modularization
Input
Storage
(File/Memory)
Circular Shift
Controller
Alphabetizing
Output
Criteria for Decomposition: Processing Steps

8. Parnas Example: KWIC Index – Information Hiding Modularization
Input
Storage
(File/Memory)
Line Storage
Controller
Circular Shifter
Alphabetizer
Output
Criteria for Decomposition: Information Hiding

9. Revisiting the Motivation for using a Modular approach to Design Software
Changeability – The information hiding approach supports change much easier. The classical technique would require modifications to many modules to support most changes – the IH approach hides representation behind module interfaces
Independent Development – IH interfaces are more abstract, supporting concurrent development easier (consider needing to change the data structure)
Comprehensibility – As per the changeability benefits described above – more detailed understanding of the overall system is required with the classical technique
The IH approach better supports exception management and error processing

10. Example: J2EE Simple approach towards web-based system development
Generation 1: Servlets
Simple approach towards web-based system development
Servlet does not hide very much information
Manages the entire UI, all of the control logic, all of the business logic, and any database interaction
http
Servlet
http

11. Example: J2EE Generation 2: Servlets & JSP’s
Better separation of input and output processing
Support for different output formats
Servlet still “knows” too much about overall system
Its hard to reuse certain aspects of a system using a servlet/jsp solution
http
Servlet
JSP
http

12. Example: J2EE Generation 3: Full MVC Approach http Controller
(Servlet)
Good example of information hiding
Well defined interfaces
Reuse presentation and business logic
Reuse components outside of the web domain
Configuration
View Beans
Action Classes
Result Beans
Exceptions
Business Logic
http
JSP

13. Summary
Parnas mentions some constraints about information hiding such as needing to go through interfaces and the cost associated with doing so
Parnas suggests some techniques to deal with these problems
Fortunately, today we don’t have to worry about the overhead of function and/or method calls
Doesn’t the information hiding approach sound a lot like OO?

14. Summary
Parnas also gives another plug for upfront design by stating that the criteria used to decompose a system into modules cannot be easily determined at runtime
Parnas suggests that to check the degree of information hiding compliance you should investigate change scenarios
Parnas demonstrated this on the IH decomposition of the KWIC system by showing some IH gaps and a design flaw
Parnas further comments on hierarchies by stating that the decomposition of a system into modules does not necessarily need to be hierarchical