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

CS-575 Software Design - Team 3 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 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 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 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 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 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 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 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 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 Modularization 1 Data Storage Controls format of data storage Add Adds a contact Delete Deletes a contact Sort Sorts contacts Find Finds a contact w rw r

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

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

CS-575 Software Design - Team 3 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 Comparing Rationales Modularization 1Modularization 2 Design Criterion Each major processing step is made into a module Modules are designed using the principle of information hiding Is task- specific? Yes. For e.g., the Add module is responsible for directly adding a contact into the address book. Yes. For e.g., the Add module is responsible for directly adding a contact into the address book Inter- dependence HIGH. All modules are heavily dependent on the Data Storage module NONE. All modules are independent!

CS-575 Software Design - Team 3 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 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 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 Sort module. Similarly, the format of data storage is known only to the Read/Write Interface module.

CS-575 Software Design - Team 3 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 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 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 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 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 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 Modular Hierarchy Level 3 Level 2 Level 1 Depends on

CS-575 Software Design - Team 3 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 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 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 Any questions?