1 / 34

Chapter 10 Introduction to Design

Chapter 10 Introduction to Design. 鄧姚文 joseph@im.knu.edu.tw http://w3.im.knu.edu.tw/~joseph. Agenda. What is design? Are you ready? The need for design Design patterns Planning for design Designing packages or subsystems Design efforts for the Timecard application. Introduction.

Download Presentation

Chapter 10 Introduction to Design

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Chapter 10 Introduction to Design 鄧姚文 joseph@im.knu.edu.tw http://w3.im.knu.edu.tw/~joseph OOAD

  2. Agenda • What is design? • Are you ready? • The need for design • Design patterns • Planning for design • Designing packages or subsystems • Design efforts for the Timecard application OOAD

  3. Introduction • Design builds on the understanding of the problem as developed during requirements gathering and analysis • Goal • To make implementation as simple and efficient as possible OOAD

  4. What is Design? • Object-oriented design • Detailed description of the objects that work together to fulfill the system’s requirements • Sequence diagrams • Interaction between objects • Class diagrams • The structure, behavior, and relationships OOAD

  5. Are you ready? • Solid foundation • Clear system vision • Solid use case model • Fairly complete analysis model • Careful and appropriate technology selection • Resilient architecture • Premature design risks project failure • Each step in the development process feeds the next OOAD

  6. The Need for Design • Omitting or neglecting design is prohibitively expensive and insanely risky • Developer productivity and morale suffer • Inconsistent code and incompatible modules • Discovery of deficiencies in the architecture delayed • Accurate scheduling is impossible • Expensive to fix flawed ideas and incompatible implementations OOAD

  7. Productivity and Morale • Challenge • New technologies • Complex requirements • Extreme schedule pressure • Coding, testing, integration • Daunting, exhilarating, frustrating, addictive • Momentum is an important key • Good design->incremental success->total success • Bad design->failure and wasted efforts->total failure OOAD

  8. A Malleable Medium • UML can be shaped and reshaped very easily • Code is not so easy to work with • Mistakes that are not caught before implementation are very expensive to fix OOAD

  9. Scheduling and Delegation • Estimation of the effort required for each class • The sum of the estimation is more accurate than a rough guess based on the requirements • Delegation 授權、委任 • Split into packages and classes • Develop in parallel • Integration OOAD

  10. Design Patterns • Design pattern • A well-defined, well-documented, and time-tested solution to a common problem in software design • Best applied to a well-defined problem OOAD

  11. Design Patterns (cont’d) • Each design pattern has • A name • A problem description • The pattern is intended to solve • A solution • Objects and their interactions • A discussion of the consequence • Positive and negative impact • A sample implementation • A list of related patterns OOAD

  12. Design Patterns Benefits • Common language • Help developers communicate their designs quickly and efficiently • Reinforce OO theory • Excellent case studies for object-oriented design OOAD

  13. Planning for Design • Establish goals for the entire design • Helps maintain consistency of the system and makes each decision easier • Establish design guidelines • To have project-wide guidelines during design • Find independent design efforts • Divide up the design effort OOAD

  14. Planning for DesignEstablish Goals for the Entire Design • Balance of clarity, performance, reliability, extensibility, and reuse potential OOAD

  15. Planning for DesignEstablish Goals for the Entire Design • Clarity • Easy to understand • Keep strong cohesion for methods in classes and for classes in package • Loose coupling makes the interfaces between packages tight and easy to understand • Encapsulation improves readability by limiting what you need to know to use a class OOAD

  16. Planning for DesignEstablish Goals for the Entire Design • Performance and reliability • Pick the right technology then design to the technology’s strengths • Must understand how the technology exchanges data between different tiers and how the technology ensures data integrity • Loose coupling makes the interfaces between packages tight and easy to understand • Encapsulation improves readability by limiting what you need to know to use a class OOAD

  17. Planning for DesignEstablish Goals for the Entire Design • Extensibility • Loose coupling and strong cohesion • Change will reside in the same package • The package will be loosely coupled with the rest of the system • Identify areas that are very likely to change • Encapsulate the variability inside of a swappable subsystem • Design the system to use configuration data • A very clear vision of the future of the system OOAD

  18. Planning for DesignEstablish Goals for the Entire Design • Reuse potential • Reuse classes within a project • Reuse classes between projects • Useful abstraction and well-encapsulated data • Keep classes small and well-focused • Keep the dependencies to a minimum • Make the abstraction easy to use and understand OOAD

  19. Planning for DesignEstablish Design Guidelines • Use the same diagrams • Describe the solution at the same level of detail • Follow the same naming conventions OOAD

  20. Planning for DesignEstablish Design Guidelines • Diagrams for each use case • Use several sequence diagrams to describe each use case • One for each significant flow of events • A single class diagram to capture the relationships between all the classes in a sequence diagram • Use state diagram to show state-dependent behavior OOAD

  21. Planning for DesignEstablish Design Guidelines • Level of detail • Each method must be fully specified • Complete with arguments and return type • Any object used in a sequence diagram must be created • In the same sequence diagram • In a supporting sequence diagram OOAD

  22. Planning for DesignEstablish Design Guidelines • Naming conventions • Name each method with a well-selected verb or a combination of a verb and a noun • The name of the method should match the return type • Name each class with a noun, a combination of nouns, or a combination of adjectives and nouns • The purpose of each class and method must be clear and unambiguous to other developers • Use clearly defined terms from design patterns OOAD

  23. Planning for DesignEstablish Design Guidelines • Cohesion • Each set of methods within a class must form a cohesive whole • Have a common goal • Have a common responsibility • Classes inside each package must have a unify purpose or nature OOAD

  24. Planning for DesignFind Independent Design Efforts • Divide up the design effort • Identify packages or groups of packages that are loosely coupled with the rest of the system • Agree on the interfaces before starting independent design activities • Packages that are tightly coupled must be designed together • Packages that are loosely coupled and well encapsulated are candidates for independent development • Each independent design effort must fit the technology abilities of a single team OOAD

  25. Design Packages or Subsystems • Each package is designed and implemented as a separate deliverable • Developers cooperate to finalize the interfaces between the packages • The architecture determines the permissible relationships between the system’s packages • Evaluate package dependency for compliance with the architecture OOAD

  26. Design Packages or Subsystems • Steps for each design effort • Identify goals and priorities • Review prior steps • Design to goals • Apply design to use cases OOAD

  27. Design Efforts for the Timecard Application • The Timecard application seems to naturally break into 4 design efforts • TimecardDomain and TimecardWorkflow packages • HtmlProduction framework • TimecardUI packages • BillingSystemInterface subsystems OOAD

  28. More Design Patterns OOAD

  29. Iterator Pattern • 以相同的方式一一存取物件 • 與物件的實作無關 OOAD

  30. OOAD

  31. OOAD

  32. Adapter Pattern • 包裝成為另外一個長相 OOAD

  33. OOAD

  34. OOAD

More Related