1 / 70

Super-Design

Super-Design. Informatics 122 Alex Baker. In this class we’ve gone…. System Design Arch. Imp. Design Code. Recapping 121. System design describes what the software system should do “How do we fundamentally approach the problem?” “What is desirable?” Architecture, and…

marianela
Download Presentation

Super-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. Super-Design Informatics 122 Alex Baker

  2. In this class we’ve gone… System Design Arch. Imp. Design Code

  3. Recapping 121 • System design • describes what the software system should do • “How do we fundamentally approach the problem?” • “What is desirable?” • Architecture, and… • Implementation design • describes what the implementer should do • “How do we make the approach reality?” • “What is a feasible answer?” • Class diagrams, and…

  4. Recapping 121 • A system design captures the essence of the solution • An implementation design captures the full solution

  5. Putting it back in perspective System Design Arch. Imp. Design Code

  6. The “Big Picture” • In the sense of: 1) New perspective on some major topics 2) The impact of these issues on “big” projects

  7. “Big” Projects • What’s the biggest project you’ve worked on?

  8. “Big” Projects • What’s the biggest project you’ve worked on? • A glimpse of the real world • 3 particularly interesting issues

  9. 1) Planning for Change? • So we know we want to do it, but what does it mean?

  10. 1) Planning for Change? • So we know we want to do it, but what does it mean? • What is the role of change, in theory, in: • Waterfall lifecycle model • Iterative approaches • Agile approaches

  11. The Waterfall Model • System design sets up implementation design • Provides conceptual guidance • Specifies parameters • Suggests structure • Suggests modules and work divisions

  12. The Waterfall Model • System design sets up implementation design • Provides conceptual guidance • Specifies parameters • Suggests structure • Suggests modules and work divisions • Never to return! (In theory)

  13. A linear process? (Really?) Goal System Design Implementation Design Code

  14. An iterative process - Completely? • New designs, based on results from previous iterations – no actual reuse?

  15. The agile process? • Reworking, refactoring

  16. The agile process? • Reworking, refactoring

  17. In reality, not so simple • Debugging • Adjusting • Expanding • Refactoring • Redesigning • Re-architecting • Reconceiving

  18. Why do we change? Desirable Feasible

  19. In theory: Desirable Feasible System design

  20. In theory: Desirable Feasible System design Implementation design

  21. In theory: Desirable Implementations Feasible System design Implementation design

  22. On the other hand Desirable Implementations Feasible System design Implementation design

  23. On the other hand • Some degree of learning and changing • How can we apply what we are learning most easily? Desirable Feasible

  24. Software processes • No process is truly linear or iterative • We don’t get it right the first time • Code, designs, architectures, concepts are often reused when we start over • Many kinds of changes • Many ways to design for change

  25. Consider VBoard • What changes would we like to make?

  26. VBoard: Expanding • Along existing axis… • Adding more UI widgets • Implementing new gestures • Fairly easy? • We know how to design for these changes

  27. VBoard: Bugs • Sometimes relationship lines “fall under”: • Can we understand the program flow to know why? • Can we find the place in the code that causes this problem? • Can it be fixed with minimal rippling?

  28. Problems: Recoding or Redesigning? • Suppose our (future) gesture system is clunky: • Have we reused this? Can it be fixed? • The program grinds to a halt eventually! • Is this a bug or a fundamental design flaw?

  29. VBoard: Reconceiving? • For example: • Making it UML-specific • Is the grid the right approach to organization? • Should we have scraps?

  30. VBoard: Reconceiving? • For example: • Making it UML-specific • Is the grid the right approach to organization? • Should we have scraps? • How much redesign to we have to do? • Do we start over? • What knowledge can we apply?

  31. When design is more than UML • Large-scale • Long-term • Existing systems and frameworks • These challenges are greater

  32. Changes • Large-scale • Long-term • Existing systems and frameworks

  33. Changes: Large Scale Design • More people working • More people changing • People working with more changes they didn’t make • Code level changes become design changes.. • Does a design accommodate this? • More places to change • Harder to fix, harder to contain • Design might need to be divided among several

  34. Changes: Long-term Design • Large-scale • Long-term • Existing systems and frameworks 1978 2000 (!) 2007

  35. Changes: Long-term Design • Needs more likely to change over time • Understanding changes • Standards change • Platforms change • Market pressures for more features • Customer changes • More problematic to make changes • Developers change, assumptions lost

  36. Changes • Large-scale • Long-term • Existing systems and frameworks

  37. Changes: Existing Materials • Can be harder to change • May be harder to understand • May not have full access to source, etc. • May not understand what you do have • May not be allowed to change

  38. Changes: “Real” projects • What can we do? No single answer, but: • Learning before the real thing • Rigor and wisdom in design • Well-reasoned adjustments • Reuse, patterns, styles, frameworks • Awareness of these issues • Practice (hint, hint)

  39. Tired of talking about designing for change?

  40. 2) Unified Design Vision

  41. 2) Unified Design Vision: Tough! • Adding patterns assignment • Also a problem in “Cake” • Design drift, design decay

  42. Choices have subtle effects • Modeless interaction in VBoard • What if you didn’t know? • Having a word class in Scrabble • The piece models in Jetris

  43. Choices have subtle effects • Modeless interaction in VBoard • What if you didn’t know? • Having a word class in Scrabble • The piece models in Jetris • Is everyone on board?

  44. When design is more than UML • Again… • Large-scale • Long-term • Existing systems and frameworks

  45. Consistency: Large Scale • Lots of design work, lots of people needed • Maintaining shared goals and knowledge • Possible solutions • Product Lines • Frameworks/Patterns/Architectural Styles • Guidelines/Principles • Brooks’ Surgical Team

  46. Consistency: Long Term • Designer turnover / legacy systems • Design Drift • Design Decay

  47. Consistency: Existing Frameworks • In reality, a lot is reuse • Frameworks (Piccolo) • Libraries • Components • Must conform • Consider Piccolo • Or Jetris • Brooks’ Conformity • Adhering to the real world one of software’s issues

  48. Consistency of Vision • Want a single, unified vision • But this is tough with: • Tons of people • Changing people and changing needs • Pressures to conform to existing models • Tough enough on a personal project

  49. Consistency of Vision • Has helped inspire: • Software Architecture • Architectural Style • Product Line Architectures • Design Patterns • Traceability • Rationale

  50. 3) Representations • One or Many?

More Related