Super-Design Informatics 122 Alex Baker

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

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

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

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

A few subjects today For each:  A high-level explanation  How this can be even worse on “big” projects

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

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

A linear process? Goal System Design Implementation Design Code

A linear process? Goal System Design Implementation Design Code

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

The agile process? Reworking, refactoring

The agile process? Reworking, refactoring

In reality Debugging Adjusting Expanding Refactoring Redesigning Re-architecting Reconceiving

Why do we change? DesirableFeasible

In theory: DesirableFeasible System design

In theory: DesirableFeasible System design Implementation design

In theory: DesirableFeasible System design Implementation design Implementations

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

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

On the other hand DesirableFeasible System design Implementation design Implementations

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

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

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?

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?

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

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

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

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

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

Changes: Large Scale Design

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

Changes: Long-term Design

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

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

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)

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

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

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

(An Abstract) Example

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

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

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

Consistency: Existing Frameworks

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

3) Representations There is a tradeoff in switching representations

Architecture (Buildings)

Process Design

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

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

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

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

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

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

Unique Requirements Banks Satellites Telephone Networks Car Driving Software

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

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

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

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

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

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

Assignment 6 – Timeline Monday Nov 13 th (Week 8)  10:00: 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

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 with clarification questions to the design team – please cc Andre and Alex on the 14:00 Saturday Nov 18 th (Week 8)  the design team must respond to the

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

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

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

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

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

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

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

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

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