Design Rules:
The Power of Modularity
Carliss Y. Baldwin & Kim B. Clark
Elucidated with examples from
the “common” program and asides
about Parnas.
Bill Griswold
The Modularity Conundrum
• Powerful systems are built of many elements
• Power comes from elements’ interplay
• This interplay results in essential
interdependences and reduces ability to
– reuse element w/o others
– change element w/o changing others
A
B
Edges mean
“knows about”
2
Common’s Design Structure
Design params
1
2
3
1. unique wds
.
x
x
2. count wds
x
.
x
3. word parse
.
4. input
4
x
.
5. top words
x
x
6. result format
x
x
.
7. output
8. files
5
x
count words
impacts
top words
6
7
8
Authors observe that these
dependences and their
grouping into modules are
derived through experience
with previous instances of
the system. SE design
x to
methods are meant
bootstrap this process.
.
x
x
.
.
3
Design Rules
D. R.
A’
B’
• Idea: have components depend on design
parameters guaranteed not to change,
called Design Rules
• Design rule may be a convention, interface,
representation, programming language, etc.
• Design rules are the global, unhidden
assumptions; they are the architecture
• Chosen properly, elements depend on design
rules rather than on each other, becoming
true modules
4
Common’s Modularized DSM
1
1. Icon strings
2
3
4
5
6
7
8
9
10
11
x
.
x
x
x
x
.
x
14
15
16
17
18
.
3. words IF
x
4. word parse IF
x
5. input words IF
x
.
.
.
6. entry output IF
x
.
7. top words IF
.
8. top IF
x
.
9. unique words
x
10. count words
x
11. word parse
x
x
12. input words
x
x
13. top words
14. result format
x
15. output
x
x
x
x
x
x
.
x
x
x
x
x
x
x
x
x
x
.
x
x
x
x
x
x
.
x
16. files
18. top
13
.
2. Icon integers
17. main
12
x
x
.
x
x
.
.
x
x
.
5.
Common’s Design Hierarchy
Icon
Strings & Integers
Top IF
Visible Modules
“Common” Interfaces
Words
Top
Hidden Modules
Top Words
Format
Parse
Input
Output
Main/Files
6
The Modular Operators
• Modular operators restructure a design,
presumably into a more modular form
– inversion: lift local decision to visible module
• independence via duplication --> design rule
– substitution: replace one module impl w/ improved
• classic Parnas motivation for modularity
– split: break a module into two sub-modules
– augmentation: add a new module to system
• also exclusion: remove module from system
– port: move module to another system
• generalize and build system-specific adapters
“Top” created by all except exlcusion!
7
The Value of Modularity
• Modularity not only accommodates change
• It encourages innovation by decentralizing
decision making on hidden modules
• Technically, it creates the option for third
parties to innovate on a module
– Parties compete to create a better module
– A few “experiments” likely to create superior
module whose value to users exceeds cost of
experiments; downside minimal because can keep
old
• Cluster of innovators emerge around
architecture, resulting in new industry
8
The Value of Splitting
• Where j is number of modules:
Vj = S0 + i E(X+i)
• under normal distribution:
E(X+i) = .3989(N/j)1/2
• Collect terms, set S0 to 0:
Vj = j1/2 V1
• A system of 25 modules likely has 5 times
the value of a monolithic system
9
The Value of Substitution
• Where k is number of “experiments”:
Vk = Q(k) V1
• Assuming a normal distribution:
Q(k) = k z[N(z)]k-1n(z)dz
• “Simplifying”, we get:
Vk = ck1/2 V1
• Combining with splitting:
Vj,k = cj1/2 k1/2 V1,1
Computing the Net Option
Value of a module requires
incorporating the costs of
experimentation and picking
the best module.
Cost effectiveness depends
on holding right number of
experiments and on local
module tests (e.g., size,
speed, cost of module) as
opposed to system tests.
10
Common’s Extension Hierarchy
Extension hierarchy
reveals what
augmentations and
exclusions will be
affordable
next-word
parse
main
files
top-words
words mgmt
output-entry
top
count
Input
strings
Icon
integers
Output
11