1. Design Rules: The Power of Modularity Bill Griswold Carliss Y. Baldwin & Kim B. Clark Elucidated with examples from the “common” program and asides about Parnas.

2. 2 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 AB Edges mean “knows about”

3. 3 Common’s Design Structure Design params 12345678 1. unique wds.xx 2. count wdsx.x 3. word parse.x 4. input.x 5. top wordsxx. 6. result formatxx.x 7. outputxx. 8. files. Authors observe that these dependences and their grouping into modules are derived through experience with previous instances of the system. SE design methods are meant to bootstrap this process. count words impacts top words

4. 4 Design Rules 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 A’B’ D. R.

5. 5 Common’s Modularized DSM 123456789101112131415161718 1. Icon strings. 2. Icon integers. 3. words IFx. 4. word parse IFx. 5. input words IFx. 6. entry output IFx. 7. top words IF. 8. top IFx. 9. unique wordsxx.xx 10. count wordsxxxx.x 11. word parsexx.x 12. input wordsxxx.x 13. top wordsxxxxxx. 14. result formatxxxxxx.x 15. outputxxxx. 16. files.x 17. mainxxxxxx. 18. topxx.

6. 6 Common’s Design Hierarchy Icon Strings & Integers “Common” Interfaces Top WordsParseInput Top WordsFormatOutputMain/Files Visible Modules Hidden Modules Top IF

7. 7 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!

8. 8 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

9. 9 The Value of Splitting Where j is number of modules: V j = S 0 +  i E(X + i ) under normal distribution: E(X + i ) =.3989  (N/j) 1/2 Collect terms, set S 0 to 0: V j = j 1/2 V 1 A system of 25 modules likely has 5 times the value of a monolithic system

10. 10 The Value of Substitution Where k is number of “experiments”: V k = Q(k) V 1 Assuming a normal distribution: Q(k) = k   z[N(z)] k-1 n(z)dz “Simplifying”, we get: V k = ck 1/2 V 1 Combining with splitting: V j,k = c j 1/2 k 1/2 V 1,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. 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.

11. 11 main Common’s Extension Hierarchy words mgmt IconOutputInput count output-entry parse next-wordtop-words top stringsintegers files Extension hierarchy reveals what augmentations and exclusions will be affordable