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  focus towards addressing Goal and Domain of Use “How do we fundamentally approach the problem?”  typically represents an intermediate “design in progress”  architecture design can be part of system design Implementation design  describes what the implementer should do  focus towards addressing Domain of Materials “How do we make the approach reality?”  typically represents a final “completed design”  module design can be part of implementation design

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. A few subjects today For each:  A high-level explanation  How this can be even worse on “big” projects

7. 1) Planning for Change? What does that mean? Where does it happen?  Waterfall lifecycle model  Iterative approaches  Agile approaches

8. A linear process – No Change? Waterfall-like models System design sets up implementation design  Provides conceptual guidance  Specifies parameters  Suggests structure  Suggests modules and work divisions

9. A linear process? Goal System Design Implementation Design Code

10. A linear process? Goal System Design Implementation Design Code

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

12. The agile process? Reworking, refactoring

13. The agile process? Reworking, refactoring

14. In reality Debugging Adjusting Expanding Refactoring Redesigning Re-architecting Reconceiving

15. Why do we change? DesirableFeasible

16. In theory: DesirableFeasible System design

17. In theory: DesirableFeasible System design Implementation design

18. In theory: DesirableFeasible System design Implementation design Implementations

19. In theory: But we aren’t always right the first time DesirableFeasible

20. But we aren’t always right the first time On the other hand DesirableFeasible System design Implementation design Implementations

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

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

23. 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 changes  Many ways to design for change

24. Consider Cake For example, suppose  Conceived, designed, coded  We find the layered system is cumbersome Where are changes needed? Does the higher level accommodate them?

25. Cake: Debugging Clicking an object sometimes doesn’t select it  Can we find the place in the code that causes this problem?  Can it be fixed with minimal rippling? Our gesture tool is clunky  Have we reused this? Can it be fixed?

26. Cake: Expanding Along existing axis…  Adding more object types  Implementing new layer actions Fairly easy? We know how to design for these changes

27. Cake: Recoding or Redesigning? Changing the layer model  Not making each layer type-specific The program’s response time is too slow Making UML instead of Architecture

28. Cake: Reconceiving? Making UML instead of Architecture Layers too difficult to visualize  3d view of the layers Should we even be using layers?  Goals of exploring, comparing

29. Designing for Change How can we design for these changes? Should we? What are the tradeoffs?

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

31. Changes: Large Scale Design

32. More people working  More people changing  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

33. Changes: Long-term Design

34. Needs more likely to change over time  Understanding of needs improves  Standards change  Platforms change  Market pressures for more features More problematic to make changes  Developers change, assumptions lost

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

36. 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)

37. 2) Unified Design Vision We saw this in the Layered Design exercise Also a problem in Cake Design drift, design decay

38. Choices have subtle effects One-click interaction in Cake Not having an Object class in T+M Not allowing 3 consecutive pieces in Jetris

39. When decisions are distributed Elegance difficult to maintain across many people Especially if we consider code-as-design changes too

40. (An Abstract) Example

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

42. Consistency: Large Scale Lots of design work, lots of people needed? Possible solutions  Brooks’ Surgical Team  Guidelines  Frameworks  Product Lines

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

44. Consistency: Existing Frameworks

45. Must conform to existing stuff Brooks’ Conformity  Adhering to the real world one of software’s issues

46. 3) Representations There is a tradeoff in switching representations

47. Architecture (Buildings)

48. Process Design

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

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

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

52. Representations: Large Scale Single  Code becomes especially tough Multiple  “Distance” increases  Complexity (translation) gets worse

53. Representations: Long Term Single  Changes at multiple levels can affect it Multiple  Keeping multiple documents up to date  Consistency and traceability of these changes

54. 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

55. Unique Requirements Banks Satellites Telephone Networks Car Driving Software

56. Unique Reqs - Bank Software Verifiable Long term  Software must run for decade+  Laws change  Finance packages change

57. 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

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

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

60. Wrapup Designing for change Multiple designer issues Representation issues Large scale Long term Within existing frameworks UML often not enough – need “meta-design”

61. Assignment 6 – Basics Design an independent tool in an office productivity suite  the design of your tool should have useful and real functionality  the design of your tool should be implementable, in a week, by another team  the design of your tool should be complete It is your task to balance the functionality with the need for a real implementation Do not forget about extensibility Do not forget about the lessons learned in this class

62. Assignment 6 – Timeline Monday Nov 13 th (Week 8)  10:00: e-mail preliminary system design and preliminary implementation design to Alex and Andre  14:00: feedback from Alex and Andre in class, 15 minutes per group; additional time can be scheduled after class

63. Assignment 6 – Timeline 14:00 Wednesday Nov 15 th (Week 8)  bring final system design and final implementation design to class  hand off final system design and final implementation design to the group that will implement your design (30 min)  receive final system design and final implementation design from the group whose design you will implement (30 min) 14:00 Friday Nov 17 th (Week 8)  you can send one e-mail with clarification questions to the design team – please cc Andre and Alex on the email 14:00 Saturday Nov 18 th (Week 8)  the design team must respond to the e-mail

64. Assignment 6 – Timeline 14:00 Wednesday Nov 22 nd (Week 9)  bring demoable implementation of the design that you were tasked to implement  you may choose to deviate your implementation from the design that you received in the first place but you must document and motivate your deviations  Also, 10:00 you will receive details of surprise assignment via e-mail

65. Assignment 6 – Timeline 14:00 Monday Nov 27 th (Week 10)  bring surprise assignment

66. Grading considerations Fill out an evaluation sheet (available at class webpage) due once a week:  Wednesday of week 8  Wednesday of week 9  Wednesday of week 10 We will look at the designs and take them into account when grading the implementations  If the design you receive appears subpar, we will consider this  We expect an earnest, hardworking effort no matter what, though

67. Assignment 6 – Groups Group 1:  MIKE WADHERA, MITCH WILLIAMS, JULIE RICO, SAM ARCHER, SAM CHANG  A mini spreadsheet Group 2:  KYLE STRASSER, CHRIS BAKER, SEAN CASHIN, JAMES GARY, NICK INGERSOLL  A mini database Group 3:  GABRIELA MARCU, ANGELO PIOLI, BRYANT HORNICK, NG WENG LEONG, PETER LEE  A mini web authoring tool Group 4:  JUNG HO KIM, CYNTHIA K. LAM, MICHELLE ALVAREZ, JASON DRAMBY  A mini slide authoring and presentation tool Focus on a simple implementation  All projects need to be able to save and open files  We will guide you during Monday’s meetings, adaptability

68. Group 1: Mini Spreadsheet Excell-like, input and output via cells Should be able to set up a cell whose result is a formula, based on one or more other cells Should be able to, for example, have a cell be the sum of several other cells’ results Nested operations

69. Group 2: Mini Database Access-like Choose your own interaction method Need to be able to set up tables and to perform complex queries on them (selection according to Boolean operations) May require a bit of research

70. Group 3: Mini web authoring tool Two panes, one for editing, one preview pane Should be able to handle at least basic html: formatting, simple tables, bullet lists Should be expandable to accommodate new tags Should be able to save viable.html files

71. Group 4: A mini slide authoring and presentation tool Similar to Powerpoint Should allow for formatting, bulleting Need to be able to insert simple drawn shapes Need to be able to “give a presentation”, allow a slideshow with forward and backward progress through the slides

72. Assignment 6 – Groups Group 1:  MIKE WADHERA, MITCH WILLIAMS, JULIE RICO, SAM ARCHER, SAM CHANG  A mini spreadsheet Group 2:  KYLE STRASSER, CHRIS BAKER, SEAN CASHIN, JAMES GARY, NICK INGERSOLL  A mini database Group 3:  GABRIELA MARCU, ANGELO PIOLI, BRYANT HORNICK, NG WENG LEONG, PETER LEE  A mini web authoring tool Group 4:  JUNG HO KIM, CYNTHIA K. LAM, MICHELLE ALVAREZ, JASON DRAMBY  A mini slide authoring and presentation tool Focus on a simple implementation  All projects need to be able to save and open files  We will guide you during Monday’s meetings, adaptability