1. Super-Design Informatics 122 Alex Baker

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

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. System Design Arch. Imp. Design Code Putting it back in perspective

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? DesirableFeasible

19. In theory: DesirableFeasible System design

20. In theory: DesirableFeasible System design Implementation design

21. In theory: DesirableFeasible System design Implementation design Implementations

22. On the other hand DesirableFeasible System design Implementation design Implementations

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

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 19782000 (!)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?

51. Architecture (Buildings)

52. Process Design

53. Multiple Representations Translating between them Easier in some fields than others May require  Language translation  Additional design decisions Waterfall model

54. Single Representation Using the same for multiple purposes  Likely to be subpar for one or the other Agile’s approach, code for everything  Recording decisions  Communication  Reflective conversing

55. When design is more than UML One more time  Large-scale  Long-term  Existing systems and frameworks

56. Representations: Large Scale Multiple  Complexity (translation) gets worse  Takes longer to get to coding, will more change? Single - Code becomes especially tough  Can the implementers keep their bearings?  Is a unified vision feasible?  Can you find the rationale you need?

57. Representations: Long Term Multiple - Consistency and traceability of changes Single - New hire issues

58. Representations: Existing Frameworks Single (same as framework)  Can constrain your only mode of working (!) Multiple  Need to avoid misrepresenting the framework’s needs across documents

59. Representations No one solution There’s a lot of complexity, it all has to go somewhere “No silver bullet” as they say.. Software’s a hassle!

60. Unique Requirements Banks Satellites Telephone Networks Car Driving Software

61. Unique Reqs - Bank Software Verifiable Long term  Run for decade+  Laws change  Finance packages change

62. Unique Reqs - Satellites Software must be reliable  Can it be proven  Can we fix it remotely? Long term  High cost of building and installing Highly interconnected System Design  UML not the answer

63. Unique Reqs – Telephone Network Reliability Distribution Fault tolerance  How do we accommodate outages  Will losing one node cripple the system? Different representations needed

66. Unique Reqs – Car Driving SW Complexity Reliability Can we count on input from sensors? What happens when there’s an error?

67. Unique Reqs – Car Driving SW Reliability Can we count on input from sensors? What happens when there’s an error? UML far from enough

68. Wrapup Designing for change Multiple designer issues Representation issues

69. There’s more to software design than we can show you first hand UML often not enough, need “meta-design” Senior project’s a start

70. Remember: Talks Tuesday Questions about assignment? About Informatics?