Understanding David Parnas’ Information Hiding and System Modularization
An interpretation of David L Parnas’ “On the Criteria To Be Used in Decomposing Systems into Modules”
I wrote this article to help explain David Parnas’ famous academic 1971 paper in a more digestible format. I hope someone finds this useful.
Ice Cream and System Design
Today, we are going to be imagining designing an ice cream sandwich assembly line as a parable for designing software systems.
Parnas’ paper explains that when attempting to design a complex system, such as our ice cream plant, we should break up the factory into smaller (bite-sized, if you will) sections that he calls “modules”. Since we have a large group of engineers, architects, and construction workers, they can’t all work on the same portion of the factory at once. Too many chefs spoil the soup (or this case, ice cream)! Therefore, we need to split our team members up into groups and assign them their own specific tasks. Having clearly defined modules will help us do that.
This ideas of separating work into smaller chunks isn’t a new concept. The real question is, what’s the best way to break systems up?
The primary argument of Parnas’ paper, besides for modularization of systems, is that we must implement a concept called “Information Hiding” and the explanation of what that means. Information hiding is the idea that we must create our software systems so that two systems are independent of each other’s process; that is, Process B doesn’t care how Process A does its work. Let’s get back to our ice cream factory to illustrate.
Let’s outline some of the possible ice cream sandwich factory processes, please keep in mind that I don’t have industry experience, other than a layperson’s interest in the topic at hand.
I imagine the process flow would look something like this, with each system having multiple processes:
1. Flour, sugar, yeast, milk, eggs, chemicals, flavorings, etc… are delivered to the factory.
a. Ingredients are separated into ice cream and cookie staging areas.2. The sandwich cookie ingredients are mixed together and baked.
a. Ingredient mixing
b. Cookie baking
c. Quality control
d. Moved to ice cream line for filling3. The ice cream ingredients are mixed together and cooled to the temp for magical ice cream consistency.
a. Ingredient mixing
b. Cooling process
c. Quality control4) Cookies are filled with ice cream
a. Ice cream injection process
b. Excess ice cream wiped off5) Quality control
a. Yuuuum!6) Sandwiches are individually wrapped7) Sandwiches are boxed8) Boxes are stacked on pallet9) Pallet is stored in freezer10) Pallet is retrieved and put on truck to distribution center.11) DONE
Now, I may have gone overboard with this description, but the nitty gritty details will help us in our analogy.
Problems Occurring with Information Leaking
Now, let’s say that the entire production line is automated, or, at the very least, the production workers are very literal and aren’t very flexible. Neither the robots nor the human workers are very good at thinking critically and essentially do their tasks exactly as ordered. The only opportunity we must make this a flexible system is to be very careful about how we design our initial set of instructions.
For example, an easy practice would be to configure each machine so that it is expecting that the cookies will be 25mm x 75mm”. You know this is the correct size since you had a series of high-level meeting with the executives who told you emphatically that this is the best size and that the size will never change.
However, what if they do change? Market research is performed, and square sandwiches are shown to be all the rage. If you try to simply and quickly modify the cookie baking machine you will get catastrophic results! The ice cream filling machine, the excess wiper, the packaging machine, the packaging itself, all those are the wrong size! The only way to change the sandwich size is by changing every single machine in the system.
What if you wanted to change the type of individual paper wrapping on each sandwich? Seems innocuous enough, but you may not realize that the new paper is much thicker, and the sandwiches no longer fit in the box! Now you must configure several machines, the wrapping machine, the boxing machine, the palletizer (since the boxes are not the same size anymore), etc.… to resolve one small process change. This one small process change might even cause major disruption if the same number of boxes no longer fit on a pallet, since a truck only has limited space for pallets, there could be a shortage of trucking space to fulfill a steady order! Additional trucks will need to be brought in; rush charges assessed. This could get expensive quickly!
Resolving Information Leakage
How would we build this system so that these kinds of issues are never encountered? Well, we want to perform Information Hiding. We want each process to be totally independent upon the other. In our examples, we would build each machine so that it automatically adjusts to the size of the cookie. These machines would scan the cookie, determine its size and avoid the issues of being confused at an incorrectly sized one. Furthermore, the boxing machine wouldn’t build the box until it determined how large the sandwiches are during this current run. Only then would it choose a specific box size which matches the incoming sandwiches. So too, would the other downstream machines perform their tasks.
Imagine if your human workers refused to spread ice cream on the sandwiches since you used to carry the cookies to them by hand but now put the box on a cart. They don’t need to know about formula changes, temp changes, or anything else. All they need to do is spread ice cream. Changes to one process (module) should not affect another.
Now, obviously, designing machines that are self-governing is more complicated than simply hardcoding values into it, but we’re not here to go on a picnic. Rather, we’re here to build robust, easy to use, and easily maintainable systems.
A good analogue to the wrapping paper example in a software system might be hardcoding for a specific file type or data format. On a very simple level, if you if you declare your variable using specific types, such as `int x = input;` that input variable can change in the future and cause bugs. Instead, using generic variable types, such as `var x = input;` would allow the upstream data type to change from an `int` to a `decimal` from the data provider and you might not even know it. Obviously this is a simplistic example, but it illustrates the point that we should attempt to build our processes independent of each other as much as possible.
Designing Correctly
Professor Parnas then goes on to discuss how the classical method of designing a system, sitting down and drawing a flowchart, is flawed.
Flowcharts are useful when attempting to separate a large system into modules (decomposition or modularization) but not for designing a system that implements information hiding. Such code is more flexible and more reusable since the implementation of each class is hidden from others, preventing tightly coupled classes. If my ice cream packer implements information hiding, I can also send granola bars to be packaged by it, with no issues.
