1. Week 8 Implementation Design Alex Baker

2. Implementation Design System Design – Describes what the system should do Implementation Design – Describes what the implementer should do System Design Implementation CGprofile vertexProfile = cgD3D9GetLatestVertexProfile(); const char *vertexOptions[] = {cgD3D9GetOptimalOptions( vertexProfile ), NULL,}; const char* vertexOptions[] = {"-profileopts", "dcls", NULL,};

3. Implementation Design System Design – Describes what the system should do Implementation Design – Describes what the implementer should do Given what our system design tells us: What’s our plan?

4. Motivation: Why Bother with Implementation Design? Suppose we code an object-oriented program – 16 implementers – No Implementation Design What problems might arise?

5. Motivation: Why Bother with Implementation Design? Suppose we code an object-oriented program – 16 implementers – No Implementation Design What problems might arise? – Poorly chosen classes – Multiple people on the same code – Functionality in hidden, or multiple, places – Inefficiencies and interaction problems emerge – Bad match to the system design – No common vision

6. 3 Goals of Implementation Design Provide a shared plan to follow – Consistency Ensure the plan meets its recipients’ needs – Helpfulness Ensure the solution is appropriate – Effectiveness

7. Goal: Consistency As we mentioned in week 6, our audience is: – system designers – implementation designers themselves – programmers – testers – …

8. Goal: Consistency As we mentioned in week 6, our audience is: – system designers – implementation designers themselves – programmers – testers – …

9. Goal: Consistency As we mentioned in week 6, our audience is: – system designers – implementation designers themselves – programmers – testers – … Communication

10. Goal: Consistency Ensuring implementers have the same plan – Every design is a plan, to some extent…

11. Goal: Consistency Ensuring implementers have the same plan – Every design is a plan, to some extent…

12. Goal: Consistency Ensuring implementers have the same plan – Every design is a plan, to some extent…

13. Goal: Consistency Ensuring implementers have the same plan – Every design is a plan, to some extent…

14. Goal: Consistency Ensuring implementers have the same plan – Every design is a plan, to some extent… Division of Labor – Separate parts to work on – Ensuring they work together

15. Goal: Consistency Ensuring implementers have the same plan – Every design is a plan, to some extent… Division of Labor – Separate parts to work on – Ensuring they work together A common vision (Ideas) – Will the developers “guesses” coincide?

16. Goal: Consistency

17. Communication isn’t enough A good representation is important What if we just communicate really well? – Some problems can’t be seen along the way – Implementation design is a bird’s eye view Need a plan that… – Supports the key work – Will lead to an effective product upon completion

18. Role of the Implementation Design As we mentioned in week 6, our audience is: – system designers – implementation designers themselves – programmers – testers – … Reflective Conversation with Materials

19. 3 Goals of Implementation Design Provide a shared plan to follow – Consistency Ensure the plan meets its recipients’ needs – Helpfulness Ensure the solution is appropriate – Effectiveness

20. Goals: Helpfulness In a way, the implementer is our customer! What are the implementer’s needs?

21. The Implementers’ Needs Implementers must – Create code – Modify code – Reuse code

22. The Implementers’ Needs Implementers must – Create code Subtle connections must be adjusted for – Modify code How can you find it? What else will it effect? – Reuse code How can you integrate new code? Reuse this code? The difficulty is in the interconnectivity

23. Spaghetti vs. The Ideal Program … vs.

24. Goals: High-Quality Implementation Reducing interdependency (Low Coupling) – Proper cooperation easier to maintain – Changes don’t propagate – Reuse is facilitated Grouping functionality (High Cohesion) – Easier to find things – Metaphor guides decisions Both aid in dividing work

25. Design Notations Assuming we have a supportive plan… – How do we present it? – What representation will we use? Class Diagrams Interface specifications Textual Descriptions Sequence Diagrams Data Flow Diagrams Petri Nets + any of the notations from system design

26. Design Notations Each has its advantages and disadvantages Diagrams can – Help deal with complexity, abstract, give the big picture – Visualize the invisible: code objects, interactions, timing, etc. Text can explain Depends on the needs of the system too…

27. Goal: Helpfulness When designing, we must recognize the difficult work we are describing A design must help implementers keep complexity under control We must:

28. Goal: Helpfulness When designing, we must recognize the difficult work we are describing A design must help implementers keep complexity under control We must: – provide a plan that meets implementers’ needs – present the plan in a way that the implementers can understand

29. 3 Goals of Implementation Design Provide a shared plan to follow – Consistency Ensure the plan meets its recipients’ needs – Helpfulness Ensure the solution is appropriate – Effectiveness

30. What makes a design effective? Quality of Service Security Reliability Scalability Portability Minimal Hardware Requirements Also still maintainability, testability, reusability Remember your system design!

31. Getting down to Business Existing notations may suit your needs – Created with existing wisdom – Will be more familiar to your implementers

32. The Class Diagram

33. Again: Implementers must code, maintain, reuse System’s needs

34. The Class Diagram Again: Implementers must code, maintain, reuse System’s needs But what classes do I need? – System design provides hints – Requirements’ emphasis can set priorities – What parts are likely to change or be reused? Carefully apply information hiding Create classes with “secrets”

35. Context may also guide classes Frames which classes to use Suggests I/O, interfaces, places for converters

36. Further Existing Wisdom Patterns provide insight into common issues More next week…

37. Data Flow Diagrams A more active depiction of the system 1. Context 2. Internal Processes

38. Sequence Diagrams Can describe usage scenarios – Might be especially useful in some games… Logic of services and transactions Can suggest classes and methods

39. Sequence Diagrams & Communication

40. Petri Nets Maybe communication is very dicey – A distributed system with concurrent processes Petri nets are a notation designed for this Not as common, but can be useful

41. User Interface Specification Could spend a whole year on it… May use existing components – This will guide what is possible – Needs to be determined early in some cases

42. User Interface Specification

43. Can explain: – UI layout itself, but… – Intended functionality – User experience – Simple sequences – Can imply specific implementation, given a particular API

44. Or something else entirely… Overhead of learning

45. Summary Must create an effective plan for implementers And ensure they can readily – Create code – Change code – Reuse code Must consider the system design’s needs A tricky balancing act…

46. Implementation Design in Context Goal Domain of Materials Representation Domain of Use Knowledge ActivityIdeas concern manipulates informs captures enhances

47. Next week Specific Domain wisdom about tackling software design problems Some walkthroughs Implementation design drafts due Thusday