CS540 Software Design Lecture 2 1
Lecture 2: Lecture 2: Software Design Software Design
MethodsMethodsAnita S. MalikAnita S. Malik
[email protected]@umt.edu.pk
Adapted fromAdapted from Budgen (2003) Chapter 3 and Budgen (2003) Chapter 3 and Schach (2002) Chapter 1Schach (2002) Chapter 1
CS540 Software Design 2Lecture 2
Recap – Lecture 1Recap – Lecture 1 Design (Verb): Process of DesignDesign (Verb): Process of Design Design (Noun): Result of the Design Design (Noun): Result of the Design
Process, a blue print for the system to be Process, a blue print for the system to be developeddeveloped
Design Process in non-analyticalDesign Process in non-analytical Software Design Phase takes the ‘what’ Software Design Phase takes the ‘what’
part and produces the ‘how’ part; takes part and produces the ‘how’ part; takes system from ‘problem’ domain to system from ‘problem’ domain to ‘solution’ domain‘solution’ domain
Software Design is perhaps the most Software Design is perhaps the most critical factor affecting the quality of the critical factor affecting the quality of the system; it has a major impact on later system; it has a major impact on later phases particularly maintenancephases particularly maintenance
CS540 Software Design 3Lecture 2
Software Design MethodsSoftware Design Methods
Design methods provide guidelines Design methods provide guidelines on the choices to be made during the on the choices to be made during the design processdesign process
Structured Methods, Formal Structured Methods, Formal Methods and Object-Oriented Methods and Object-Oriented MethodsMethods
CS540 Software Design 4Lecture 2
What Support do Design What Support do Design Methods Provide?Methods Provide?
Knowledge transfer mechanismKnowledge transfer mechanism Common standards, guidelines, techniques, Common standards, guidelines, techniques,
criteria and goals to be used by the entire criteria and goals to be used by the entire design teamdesign team
Recording decisions and reasons in a Recording decisions and reasons in a systematic mannersystematic manner
Make sure all factors involved in a problem Make sure all factors involved in a problem are considered (all design elements can be are considered (all design elements can be traced to some requirements)traced to some requirements)
Identify important progress milestonesIdentify important progress milestones
CS540 Software Design 5Lecture 2
Why Methods Don’t Work Why Methods Don’t Work Miracles?Miracles?
Design methods provide guidance and adviceDesign methods provide guidance and advice By focusing on a particular domain of By focusing on a particular domain of
problems e.g., data-processing, real time problems e.g., data-processing, real time systems, it is possible to provide tighter systems, it is possible to provide tighter guidance.guidance.
Cooking recipe analogy – designing a Cooking recipe analogy – designing a software is like writing a cooking recipesoftware is like writing a cooking recipe
Most methods are applied to different Most methods are applied to different domains to optimize their use that results domains to optimize their use that results from familiarity with methodfrom familiarity with method
CS540 Software Design 6Lecture 2
Software Life-cycleSoftware Life-cycle
1.1. Requirements phaseRequirements phase
2.2. Specification phaseSpecification phase
3.3. Design phaseDesign phase
4.4. Implementation phaseImplementation phase
5.5. Integration phase (in parallel Integration phase (in parallel with 4)with 4)
6.6. Maintenance phaseMaintenance phase
7.7. RetirementRetirement
CS540 Software Design 7Lecture 2
Software Development Software Development ProcessProcess
If institutionalized can constrain If institutionalized can constrain creativity rather than support itcreativity rather than support it
Many forms and variations of Many forms and variations of development processdevelopment process
Presence of feedback loops between Presence of feedback loops between the various stages of software the various stages of software processprocess
CS540 Software Design 8Lecture 2
Linear Development Linear Development ProcessProcess
Mainly based on the waterfall modelMainly based on the waterfall model Provides a strong management Provides a strong management
framework for planning, monitoring framework for planning, monitoring and controllingand controlling
Transform model and its limitations Transform model and its limitations (Formal approaches)(Formal approaches)
CS540 Software Design 9Lecture 2
Incremental Development Incremental Development Process (non linear Process (non linear
process)process) Limitations of linear development Limitations of linear development
processprocess Prototypes – constructed to explore Prototypes – constructed to explore
an idea more completely before the an idea more completely before the actual construction startsactual construction starts EvolutionaryEvolutionary ExperimentalExperimental ExploratoryExploratory
Reactive developmentReactive development
CS540 Software Design 10Lecture 2
Context for DesignContext for Design
Ref: (Fig 3.1 Chapter 3 Budgen 2003)Ref: (Fig 3.1 Chapter 3 Budgen 2003)
Regardless of how the software Regardless of how the software development tasks are organized, development tasks are organized, design is strongly linked to the tasks design is strongly linked to the tasks that precede it – Requirements that precede it – Requirements Specification and AnalysisSpecification and Analysis
CS540 Software Design 11Lecture 2
Approximate Relative Cost of Each Approximate Relative Cost of Each PhasePhase 1976–1981 data1976–1981 data
Maintenance constitutes 67% of total costMaintenance constitutes 67% of total cost
CS540 Software Design 12Lecture 2
Good and Bad SoftwareGood and Bad Software
Good software is maintained—bad Good software is maintained—bad software is discardedsoftware is discarded
Different types of maintenanceDifferent types of maintenance Corrective maintenance [about 20%]Corrective maintenance [about 20%] EnhancementEnhancement
Perfective maintenance [about 60%]Perfective maintenance [about 60%] Adaptive maintenance [about 20%]Adaptive maintenance [about 20%]
CS540 Software Design 13Lecture 2
Specification and Maintenance Specification and Maintenance FaultsFaults
60 to 70 percent of faults are 60 to 70 percent of faults are specification and design faultsspecification and design faults
Data of Kelly, Sherif, and Hops [1992]Data of Kelly, Sherif, and Hops [1992] 1.9 faults per page of specification1.9 faults per page of specification 0.9 faults per page of design0.9 faults per page of design 0.3 faults per page of code0.3 faults per page of code
CS540 Software Design 14Lecture 2
Specification and Maintenance Specification and Maintenance Faults (contd)Faults (contd)
Data of Bhandari et al. [1994] - Faults Data of Bhandari et al. [1994] - Faults at end of the design phase of the new at end of the design phase of the new version of the productversion of the product 13% of faults from previous version of 13% of faults from previous version of
productproduct 16% of faults in new specifications16% of faults in new specifications 71% of faults in new design71% of faults in new design
CS540 Software Design 15Lecture 2
Cost to Detect and Correct a Cost to Detect and Correct a FaultFault
CS540 Software Design 16Lecture 2
Structured ParadigmStructured Paradigm The structured paradigm had great The structured paradigm had great
successes initiallysuccesses initially It started to fail with larger products (> It started to fail with larger products (>
50,000 LOC)50,000 LOC) Maintenance problems (today, up to 80% Maintenance problems (today, up to 80%
of effort)of effort) Reason: structured methods are Reason: structured methods are
Action oriented (finite state machines, data Action oriented (finite state machines, data flow diagrams); or flow diagrams); or
Data oriented (entity-relationship diagrams, Data oriented (entity-relationship diagrams, Jackson’s method);Jackson’s method);
But not bothBut not both
CS540 Software Design 17Lecture 2
The Object-Oriented Paradigm The Object-Oriented Paradigm (contd)(contd)
Both data and actions are of equal Both data and actions are of equal importanceimportance
Object: Object: Software component that incorporates both Software component that incorporates both
data and the actions that are performed on data and the actions that are performed on that datathat data
Example:Example: Bank accountBank account
Data:Data: account balanceaccount balance Actions: Actions: deposit, withdraw, determine balancedeposit, withdraw, determine balance
CS540 Software Design 18Lecture 2
Structured versus Object-Structured versus Object-
Oriented ParadigmOriented Paradigm
Information hiding Information hiding Responsibility-driven designResponsibility-driven design Impact on maintenance, developmentImpact on maintenance, development
CS540 Software Design 19Lecture 2
Key Aspects of Object-Oriented Key Aspects of Object-Oriented SolutionSolution
Conceptual independenceConceptual independence EncapsulationEncapsulation
Physical independence Physical independence Information hidingInformation hiding
Impact on developmentImpact on development Physical counterpartPhysical counterpart
Impact on maintenanceImpact on maintenance Independence effectsIndependence effects
CS540 Software Design 20Lecture 2
Responsibility-Driven Responsibility-Driven DesignDesign
Also called “Design by Contract”Also called “Design by Contract” Send flowers to your aunt in Iowa CitySend flowers to your aunt in Iowa City
Call 1-800-FLOWERSCall 1-800-FLOWERS Where is 1-800-FLOWERS?Where is 1-800-FLOWERS? Which Iowa City florist does the delivery?Which Iowa City florist does the delivery? Information hidingInformation hiding
Object-oriented paradigmObject-oriented paradigm ““Send a message to a method [action] of Send a message to a method [action] of
an object“an object“
CS540 Software Design 21Lecture 2
Transition From Analysis to Transition From Analysis to DesignDesign
Structured paradigm:Structured paradigm: Sharp transition between analysis (what) and design Sharp transition between analysis (what) and design
(how)(how) Object-oriented paradigm:Object-oriented paradigm:
Objects enter from very beginningObjects enter from very beginning
CS540 Software Design 22Lecture 2
Analysis/Design “Hump”Analysis/Design “Hump”
Systems analysisSystems analysis Determine what has to be doneDetermine what has to be done
DesignDesign Determine how to do itDetermine how to do it Architectural design—determine Architectural design—determine
modulesmodules Detailed design—design each moduleDetailed design—design each module
CS540 Software Design 23Lecture 2
Removing the “Hump”Removing the “Hump”
Object-oriented analysisObject-oriented analysis Determine what has to be doneDetermine what has to be done Determine the objectsDetermine the objects
Object-oriented designObject-oriented design Determine how to do itDetermine how to do it Design the objectsDesign the objects
CS540 Software Design 24Lecture 2
In More DetailIn More Detail
Objects enter hereObjects enter here
CS540 Software Design 25Lecture 2
WarningWarning Do not use the object-paradigm to enhance a Do not use the object-paradigm to enhance a
product developed using the structured product developed using the structured paradigmparadigm Water and oil do not mixWater and oil do not mix
Exception: if the new part is totally disjointException: if the new part is totally disjoint Example: adding a GUI (graphical user interface)Example: adding a GUI (graphical user interface)