1 / 55

Week 2 Design Examples and Designing for Change

Week 2 Design Examples and Designing for Change. Alex Baker. Implementation Design. An implementation design is a road map understandable, unambiguous, consistent, helpful, … An implementation design describes a path from system design to the outcome

tim
Download Presentation

Week 2 Design Examples and Designing for Change

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. Week 2Design Examples andDesigning for Change Alex Baker

  2. Implementation Design • An implementation design is a road map • understandable, unambiguous, consistent, helpful, … • An implementation design describes a path from system design to the outcome • correct, complete, concise, verifiable, effective, … • An implementation design describes what the implementers should do • elegant, partitionable, recomposable, resilient, … • An implementation design is a guide towards future change • evolvable, …

  3. Emphasis: Changability • Subtle • Requires foresight and careful balancing • An implementation design describes what the implementers should do • elegant, partitionable, recomposable, resilient, … • An implementation design is a guide towards future change • evolvable, …

  4. Emphasis: Changability • Reusable • Extensible • Maintainable • Portable • Well-Documented • Adaptable • Simplicity • Readability • Minimalistic • Elegant • Well-Organized • Concise • Efficiency • Powerful

  5. Changability: Basic Principles • Low Coupling: Reducing interdependency • Changes don’t propagate • Reuse is facilitated • High Cohesion: Grouping functionality • Easier to find things • Metaphor guides decisions • Information Hiding

  6. Information Hiding Made Very Simple • A List class with: • getArray() : Array • getElementAt(int i) : Element

  7. Information Hiding Made Very Simple • A List class with: • getArray() : Array • getElementAt(int i) : Element • Its too slow, so we switch to a hash table • Everywhere you call getArray needs changing • Only List is changed • Little things like this add up

  8. The Ideal Program vs. …

  9. Why the Emphasis on Changability? • Change abounds… • During coding • After use • Reuse for later projects

  10. Why is there so Much Change? Designs Outcomes

  11. Why is there so Much Change? Engineering Designs Outcomes Physics Principles Existing Examples

  12. Why is there so Much Change? Software Engineering Designs Outcomes Physics Principles Existing Examples

  13. Why is there so Much Change? Software Engineering Designs Outcomes Physics Principles Existing Examples

  14. Why is there so Much Change? Software Engineering Designs Outcomes Physics Principles Existing Examples

  15. Why the Emphasis on Changability? • Change abounds… • During coding • After use • Reuse for later projects • You usually just don’t know for sure…

  16. Changes During Coding • Refinement of the high level design • Dependencies reveal themselves • Oh, I need to know [X]. • I can’t access that data? • ‘It turns out this class is HUGE’ • Need to redesign as you go • Can changes be made within the design?

  17. Changes during Use • Potential breakdowns at several levels • Customers have needs • Customers make requests • Developers provide software

  18. Reuse • A changing of context • …

  19. Change Happens • Let’s design for it

  20. Our Approach • Lots of examples (3 problems, many solutions, today) • Some overarching lessons • Build up an intuition

  21. UML Review: Class Diagrams Class Name Attribute : Type Attribute : Type Operation (parameter) : Return Type Operation (parameter) : Return Type Operation (parameter) : Return Type

  22. UML Review: Class Diagrams Association Generalization Aggregation Composition

  23. A Class Diagram

  24. Example #1: Theseus and the Minotaur • http://www.logicmazes.com/theseus.html

  25. Original Theseus Design

  26. Original Theseus Design • What if we want to add “Water” ?

  27. Original Theseus Design • What if we want to add “Water” ? ?

  28. Original Theseus Design • What if we want to add “Water” ? • How do we fix this? ?

  29. TntM: Changes • Changing the board size • Adding terrain types • Adding more monsters • Adding a second player • “Intelligent elements”

  30. TntM 2

  31. TntM 2: Object Interfaces & Inheritance

  32. TntM: Changes • Changing the board size • Adding terrain types • Adding more monsters • Adding a second player • “Intelligent elements”

  33. How far is too far? • Changing board size? • Pushable blocks? • Intelligent elements? • Real time gameplay? • Physics challenges?

  34. TntM 2

  35. Bonus! • StompOn( stompee ) Or • StompedOn( stomper )

  36. Aside: Three Degrees of Support • Is it a good solution? • Can they build that solution? • Can that solution be used to make other good solutions?

  37. Example #2 Klax • Blocks fall from above, use a paddle to catch • Deposit blocks in one of 5 columns • Try to make lines of 3 in a row or more • http://www.123games.dk/game/puzzle/klax3d/klax_eng.php

  38. A Good Klax Design?

  39. Chiron 2 Architectural Style

  40. C2 Klax

  41. Spelling Klax?

  42. Spelling Klax?

  43. Example #3: Scrabble

  44. Function Overload Changes to rack

  45. Class Overload

  46. (besides missing details)

  47. Is this a good design?

  48. Overengineered? What change are you designing for?Multiple point values for a given tile type?More types of board objects?

  49. Overengineered? Meanwhile:Board doesn’t actually workPopulating the tiles is likely a hassleTilepool vs. Player.currentTilesInelegance lead to problems

  50. A Nice Approach?

More Related