Object-oriented system development uses the requirements that were gathered during analysis to create a blueprint for the future system. A successful object-oriented design builds upon what was learned in earlier phases and leads to a smooth implementation by creating a clear, accurate plan of what needs to be done. This chapter describes the initial transition from analysis to design and presents three ways to approach the design for the new system. | Chapter 8: Moving on to Design Objectives Understand the verification and validation of the analysis models. Understand the transition from analysis to design. Understand the use of factoring, partitions, and layers. Be able to create package diagrams. Be familiar with the custom, packaged, and outsource design alternatives. Be able to create an alternative matrix. Key Ideas The purpose of the analysis phase is to figure out what the business needs. The purpose of the design phase is to figure out how to provide it. The steps in both analysis and design phases are highly interrelated and may require much “going back and forth” Avoiding Classic Design Mistakes Reducing design time Feature creep Silver bullet syndrome Switching tools in mid-project VERIFYING AND VALIDATING (V&V) THE ANALYSIS MODELS Walkthroughs Peer reviews of models and diagrams created during analysis Conducted by teams of analysts, designers, and clients Main purposes: Test the fidelity of the models Uncover errors . | Chapter 8: Moving on to Design Objectives Understand the verification and validation of the analysis models. Understand the transition from analysis to design. Understand the use of factoring, partitions, and layers. Be able to create package diagrams. Be familiar with the custom, packaged, and outsource design alternatives. Be able to create an alternative matrix. Key Ideas The purpose of the analysis phase is to figure out what the business needs. The purpose of the design phase is to figure out how to provide it. The steps in both analysis and design phases are highly interrelated and may require much “going back and forth” Avoiding Classic Design Mistakes Reducing design time Feature creep Silver bullet syndrome Switching tools in mid-project VERIFYING AND VALIDATING (V&V) THE ANALYSIS MODELS Walkthroughs Peer reviews of models and diagrams created during analysis Conducted by teams of analysts, designers, and clients Main purposes: Test the fidelity of the models Uncover errors or faults Potential danger is that analysts be punished for errors uncovered Functional Model V&V Events in Use Case descriptions should map to activities in the Activity Diagram Object node in an activity diagram must be mentioned in Use Case descriptions Sequential ordering within the Use Cases should match ordering in Activity Diagram There must be a one-to-one correspondence of Use Cases in the Use Case Diagram and Use Case descriptions. Functional Model V&V (cont’d) All actors listed in a use case description must be portrayed on the use-case diagram Include stakeholders listed in the use case description as actors in the use-case diagram All relationships listed in a use-case description must be portrayed on a use-case diagram Structural Model V&V Every CRC card should be associated with a class on the class diagram Responsibilities listed on the CRC card must be operations in a class on a class diagram Collaborators on the CRC card imply some type of association on the class .
