CS540 Software Design Lecture 2 1 Lecture 2: Software Design Methods Anita S. Malik Adapted from Budgen (2003) Chapter 3 and Schach (2002) Chapter 1

CS540 Software Design 2Lecture 2 Recap – Lecture 1 Design (Verb): Process of Design Design (Verb): Process of Design Design (Noun): Result of the Design Process, a blue print for the system to be developed Design (Noun): Result of the Design Process, a blue print for the system to be developed Design Process in non-analytical Design Process in non-analytical Software Design Phase takes the ‘what’ part and produces the ‘how’ part; takes system from ‘problem’ domain to ‘solution’ domain Software Design Phase takes the ‘what’ part and produces the ‘how’ part; takes system from ‘problem’ domain to ‘solution’ domain Software Design is perhaps the most critical factor affecting the quality of the system; it has a major impact on later phases particularly maintenance Software Design is perhaps the most critical factor affecting the quality of the system; it has a major impact on later phases particularly maintenance

CS540 Software Design 3Lecture 2 Software Design Methods Design methods provide guidelines on the choices to be made during the design process Design methods provide guidelines on the choices to be made during the design process Structured Methods, Formal Methods and Object-Oriented Methods Structured Methods, Formal Methods and Object-Oriented Methods

CS540 Software Design 4Lecture 2 What Support do Design Methods Provide? Knowledge transfer mechanism Knowledge transfer mechanism Common standards, guidelines, techniques, criteria and goals to be used by the entire design team Common standards, guidelines, techniques, criteria and goals to be used by the entire design team Recording decisions and reasons in a systematic manner Recording decisions and reasons in a systematic manner Make sure all factors involved in a problem are considered (all design elements can be traced to some requirements) Make sure all factors involved in a problem are considered (all design elements can be traced to some requirements) Identify important progress milestones Identify important progress milestones

CS540 Software Design 5Lecture 2 Why Methods Don’t Work Miracles? Design methods provide guidance and advice Design methods provide guidance and advice By focusing on a particular domain of problems e.g., data-processing, real time systems, it is possible to provide tighter guidance. By focusing on a particular domain of problems e.g., data-processing, real time systems, it is possible to provide tighter guidance. Cooking recipe analogy – designing a software is like writing a cooking recipe Cooking recipe analogy – designing a software is like writing a cooking recipe Most methods are applied to different domains to optimize their use that results from familiarity with method Most methods are applied to different domains to optimize their use that results from familiarity with method

CS540 Software Design 6Lecture 2 Software Life-cycle 1.Requirements phase 2.Specification phase 3.Design phase 4.Implementation phase 5.Integration phase (in parallel with 4) 6.Maintenance phase 7.Retirement

CS540 Software Design 7Lecture 2 Software Development Process If institutionalized can constrain creativity rather than support it If institutionalized can constrain creativity rather than support it Many forms and variations of development process Many forms and variations of development process Presence of feedback loops between the various stages of software process Presence of feedback loops between the various stages of software process

CS540 Software Design 8Lecture 2 Linear Development Process Mainly based on the waterfall model Mainly based on the waterfall model Provides a strong management framework for planning, monitoring and controlling Provides a strong management framework for planning, monitoring and controlling Transform model and its limitations (Formal approaches) Transform model and its limitations (Formal approaches)

CS540 Software Design 9Lecture 2 Incremental Development Process (non linear process) Limitations of linear development process Limitations of linear development process Prototypes – constructed to explore an idea more completely before the actual construction starts Prototypes – constructed to explore an idea more completely before the actual construction starts Evolutionary Evolutionary Experimental Experimental Exploratory Exploratory Reactive development Reactive development

CS540 Software Design 10Lecture 2 Context for Design Ref: (Fig 3.1 Chapter 3 Budgen 2003) Regardless of how the software development tasks are organized, design is strongly linked to the tasks that precede it – Requirements Specification and Analysis Regardless of how the software development tasks are organized, design is strongly linked to the tasks that precede it – Requirements Specification and Analysis

CS540 Software Design 11Lecture 2 Approximate Relative Cost of Each Phase 1976–1981 data 1976–1981 data Maintenance constitutes 67% of total cost Maintenance constitutes 67% of total cost

CS540 Software Design 12Lecture 2 Good and Bad Software Good software is maintained—bad software is discarded Good software is maintained—bad software is discarded Different types of maintenance Different types of maintenance Corrective maintenance [about 20%] Corrective maintenance [about 20%] Enhancement Enhancement Perfective maintenance [about 60%] Perfective maintenance [about 60%] Adaptive maintenance [about 20%] Adaptive maintenance [about 20%]

CS540 Software Design 13Lecture 2 Specification and Maintenance Faults 60 to 70 percent of faults are specification and design faults 60 to 70 percent of faults are specification and design faults Data of Kelly, Sherif, and Hops [1992] Data of Kelly, Sherif, and Hops [1992] 1.9 faults per page of specification 1.9 faults per page of specification 0.9 faults per page of design 0.9 faults per page of design 0.3 faults per page of code 0.3 faults per page of code

CS540 Software Design 14Lecture 2 Specification and Maintenance Faults (contd) Data of Bhandari et al. [1994] - Faults at end of the design phase of the new version of the product Data of Bhandari et al. [1994] - Faults at end of the design phase of the new version of the product 13% of faults from previous version of product 13% of faults from previous version of product 16% of faults in new specifications 16% of faults in new specifications 71% of faults in new design 71% of faults in new design

CS540 Software Design 15Lecture 2 Cost to Detect and Correct a Fault

CS540 Software Design 16Lecture 2 Structured Paradigm The structured paradigm had great successes initially The structured paradigm had great successes initially It started to fail with larger products (> 50,000 LOC) It started to fail with larger products (> 50,000 LOC) Maintenance problems (today, up to 80% of effort) Maintenance problems (today, up to 80% of effort) Reason: structured methods are Reason: structured methods are Action oriented (finite state machines, data flow diagrams); or Action oriented (finite state machines, data flow diagrams); or Data oriented (entity-relationship diagrams, Jackson’s method); Data oriented (entity-relationship diagrams, Jackson’s method); But not both But not both

CS540 Software Design 17Lecture 2 The Object-Oriented Paradigm (contd) Both data and actions are of equal importance Both data and actions are of equal importance Object: Object: Software component that incorporates both data and the actions that are performed on that data Software component that incorporates both data and the actions that are performed on that data Example: Example: Bank account Bank account Data: account balance Data: account balance Actions: deposit, withdraw, determine balance Actions: deposit, withdraw, determine balance

CS540 Software Design 18Lecture 2 Structured versus Object-Oriented Paradigm Information hiding Information hiding Responsibility-driven design Responsibility-driven design Impact on maintenance, development Impact on maintenance, development

CS540 Software Design 19Lecture 2 Key Aspects of Object-Oriented Solution Conceptual independence Conceptual independence Encapsulation Encapsulation Physical independence Physical independence Information hiding Information hiding Impact on development Impact on development Physical counterpart Physical counterpart Impact on maintenance Impact on maintenance Independence effects Independence effects

CS540 Software Design 20Lecture 2 Responsibility-Driven Design Also called “Design by Contract” Also called “Design by Contract” Send flowers to your aunt in Iowa City Send flowers to your aunt in Iowa City Call FLOWERS Call FLOWERS Where is FLOWERS? Where is FLOWERS? Which Iowa City florist does the delivery? Which Iowa City florist does the delivery? Information hiding Information hiding Object-oriented paradigm Object-oriented paradigm “Send a message to a method [action] of an object“ “Send a message to a method [action] of an object“

CS540 Software Design 21Lecture 2 Transition From Analysis to Design Structured paradigm: Structured paradigm: Sharp transition between analysis (what) and design (how) Sharp transition between analysis (what) and design (how) Object-oriented paradigm: Object-oriented paradigm: Objects enter from very beginning Objects enter from very beginning

CS540 Software Design 22Lecture 2 Analysis/Design “Hump” Systems analysis Systems analysis Determine what has to be done Determine what has to be done Design Design Determine how to do it Determine how to do it Architectural design—determine modules Architectural design—determine modules Detailed design—design each module Detailed design—design each module

CS540 Software Design 23Lecture 2 Removing the “Hump” Object-oriented analysis Object-oriented analysis Determine what has to be done Determine what has to be done Determine the objects Determine the objects Object-oriented design Object-oriented design Determine how to do it Determine how to do it Design the objects Design the objects

CS540 Software Design 24Lecture 2 In More Detail Objects enter here Objects enter here

CS540 Software Design 25Lecture 2 Warning Do not use the object-paradigm to enhance a product developed using the structured paradigm Do not use the object-paradigm to enhance a product developed using the structured paradigm Water and oil do not mix Water and oil do not mix Exception: if the new part is totally disjoint Exception: if the new part is totally disjoint Example: adding a GUI (graphical user interface) Example: adding a GUI (graphical user interface)