Chapter 10 Introduction to Design

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