On the Criteria to Be Used in Decomposing Systems into Modules

1. On the Criteria to Be Used in Decomposing Systems into Modules Team 3 Nupur Choudhary Aparna Nanjappa Mark Zeits

2. An Overview • Introduction • What is a Module ? • Some Buzzwords • Address book system • Information Hiding • Java Bean Example • Modular Hierarchy • Conclusion CS-575 Software Design - Team 3

3. A Risk of Bad Design • 103-year-old man told to bring parents for eye test (comp.risks Aug 22, 2002) – British pensioner Joseph Dickinson, 103, had a shock when his local hospital called him in for an eye test and told him to bring his parents. "I must be getting younger, in fact much younger," he told his local paper, the Hartlepool Mail. He was born in 1899, but because the hospital computer only read the last two digits it mistook his age as just three years old.... CS-575 Software Design - Team 3

4. Historic Context • 1960s • Structured Programming • Formally specifying the semantics of programming languages and proving programs satisfy a predicate. • Adopted because it’s a better way to think about programming • 1970s • Structured Design • Methodology/guidelines for dividing programs into subroutines. CS-575 Software Design - Team 3

5. Historic Context (contd...) • 1980s • Modular (object-based) programming • Grouping of sub-routines into modules with data. • 1990s • Object-Oriented Languages started being commonly used • Object-Oriented Analysis and Design for guidance. CS-575 Software Design - Team 3

6. Introduction • Decomposition in Engineering Crystal Palace – Built for the 1851 Great Exhibition – Covered ~19 acres in London’s Hyde Park – Completed in 17 weeks, possible in part because of its modular design CS-575 Software Design - Team 3

7. Introduction • Because maintenance costs dominate development costs, it is desirable to design a system that can easily adapt to change • Change is costly when a whole system must be examined/altered to deal with a “small” change • Importance of Modularization CS-575 Software Design - Team 3

8. What is a Module? • A Work Assignment. • Represented by a design decision specific to itself and unknown to other modules • Support flexibility in implementation • Do Not represent steps in processing • Low coupling, high cohesion. CS-575 Software Design - Team 3

9. Some Buzzwords • Module - parts that can be put together to make a complete system - work assignment, subroutine, memory load , functional component • Encapsulation - language facility • Information Hiding - design principle CS-575 Software Design - Team 3

10. An Address Book System • Contacts are stored in a plain text file • They are stored in the following syntax Powers,Austin 69 Mojo Drive 800-OBEHAVE • All contacts are separated by a semi-colon CS-575 Software Design - Team 3

11. Modularization 1 Add Adds a contact Sort Sorts contacts rw w Data Storage Controls format of data storage rw r Delete Deletes a contact Find Finds a contact CS-575 Software Design - Team 3

12. Got Change? But what if we would like to change the format of data storage to - [Powers,Austin|69,Mojo Drive|1-800-OBEHAVE] What modules will we need to modify? ALL OF THEM!!!! CS-575 Software Design - Team 3

13. Modularization 2 Data Storage Controls format of data storage Add Adds a contact Sort Sorts contacts rw w Read/Write Interface Reads from, writes to address book rw r Delete Deletes a contact Find Finds a contact CS-575 Software Design - Team 3

14. Modularization 2 • In this design, the new change would only require modifying the Data Storage and the Read/Write Interface modules. • The Add, Delete, Sort and Find modules do not need any changes. Their algorithms remain untouched. • Why? CS-575 Software Design - Team 3

15. Comparing Rationales CS-575 Software Design - Team 3

16. Information Hiding • Before decomposing a system into modules, a list of all possible design changes is made - Hiding Assumption List • Each module hides the implementation of an important design decision so that only the constituents of that module know the details • All design decisions are independent of each other CS-575 Software Design - Team 3

17. Information Hiding in Modularization 2 • Modularization 2 used this principle of Information Hiding. • All of its modules are independent and have well-defined interfaces. • There is very low coupling between them. CS-575 Software Design - Team 3

18. Information Hiding in Modularization 2 • Each module is very task-specific. All modules are highly cohesive. • For example, the sorting algorithm is known only to the Sortmodule. Similarly, the format of data storage is known only to the Read/Write Interfacemodule. CS-575 Software Design - Team 3

19. Benefits of Good Modular Design • Independent Development Since each module is independent, they can be developed independently at the same time  Shortened Development Time! CS-575 Software Design - Team 3

20. Benefits of Good Modular Design • Product Flexibility & Reusability Modules can be easily modified without affecting the rest of them. More over, modules can be easily replaced to add, enhance or change product capabilities. CS-575 Software Design - Team 3

21. Benefits of Good Modular Design • Comprehensibility It is easier for programmers to fully understand the design of the entire product by individually studying the modules. CS-575 Software Design - Team 3

22. Another example – JavaBeans • JavaBeans are modular by nature. • Perform single tasks • Are reusable and platform independent • Changeable throughout life • Use Introspection to retrieve information about capabilities • Supports bound & constrained properties CS-575 Software Design - Team 3

23. Another example – JavaBeans • The “GetApplic” JavaBean • Supply Database, Cable number and/or equipment number • Retrieves “Applicability” from database • Very good example of Information Hiding CS-575 Software Design - Team 3

24. Modular Hierarchy For Modularization 2 of the Address Book System, using Dijkstra’s method, we have: • Level 1 – Data Storage • Level 2 – Read/Write Interface • Level 3 – Add, Delete, Find, Sort CS-575 Software Design - Team 3

25. Modular Hierarchy Level 1 Depends on Level 2 Depends on Level 3 CS-575 Software Design - Team 3

26. The Module Guide • Assists a maintenance programmer during debugging to find modules that are affected by a change or are causing problems. • Includes brief description module role • Shows how responsibilities are allocated among major modules • States the criteria behind responsibility assignment CS-575 Software Design - Team 3

27. Conclusion • High utility of Parnas’ partitioning approach to design of flexible computer systems • This approach does not obsolete other modularity criteria • It is desirable to have small, manageable modules and various design principle should be used in conjunction with Parnas’ partitioning for best results CS-575 Software Design - Team 3

28. References • “Parnas Partitioning” by A.J. Maher • Java World • “Some Software Engineering Principles” by D.L. Parnas • “The Modular Structure of Complex Systems” by D.L. Parnas • Citations : IEEE Transactions on Software Engineering CS-575 Software Design - Team 3

29. Any questions? CS-575 Software Design - Team 3