Super-Design
Informatics 122
Alex Baker
SystemDesign
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
SystemDesign
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
designProvides conceptual guidanceSpecifies parametersSuggests structureSuggests 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?
Desirable Feasible
In theory:
Desirable Feasible
System design
In theory:
Desirable Feasible
System design
Implementation design
In theory:
Desirable Feasible
System design
Implementation design
Implementations
In theory:
But we aren’t always right the first time
Desirable Feasible
But we aren’t always right the first time
On the other hand
Desirable Feasible
System design
Implementation design
Implementations
On the other hand
Desirable Feasible
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?
Desirable Feasible
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, supposeConceived, designed, codedWe 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 itCan we find the place in the code that causes
this problem?Can it be fixed with minimal rippling?
Our gesture tool is clunkyHave 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 modelNot 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 visualize3d 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
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
Changes: Long-term Design
Needs more likely to change over timeUnderstanding of needs improvesStandards changePlatforms changeMarket pressures for more features
More problematic to make changesDevelopers change, assumptions lost
Changes: Existing Materials
Can be harder to changeMay not have full access to source, etc.May not understand what you do haveMay not be allowed to change
Changes: “Real” projects What can we do? No single answer, but:
Learning before the real thingRigor and wisdom in designWell-reasoned adjustments
Reuse, patterns, styles, frameworks
Awareness of these issuesPractice (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 solutionsBrooks’ Surgical TeamGuidelinesFrameworksProduct Lines
Consistency: Long Term
Designer turnover / legacy systems
Design Drift
Design Decay
Consistency: Existing Frameworks
Consistency: Existing Frameworks
Must conform to existing stuff
Brooks’ ConformityAdhering 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 requireLanguage translationAdditional design decisions
Waterfall model
Single Representation
Using the same for multiple purposesLikely to be subpar for one or the other
Agile’s approach, code for everythingExpressionCommunicationReflective conversing
When design is more than UML
Again…
Large-scale Long-term Existing systems and frameworks
Representations: Large Scale
SingleCode becomes especially tough
Multiple“Distance” increasesComplexity (translation) gets worse
Representations: Long Term
SingleChanges at multiple levels can affect it
MultipleKeeping multiple documents up to dateConsistency and traceability of these changes
Representations: Existing Frameworks
Single (same as framework)Can constrain your only mode of working (!)
MultipleNeed to avoid misrepresenting the
framework’s needs across documents
Unique Requirements
Banks Satellites Telephone Networks Car Driving Software
Unique Reqs - Bank Software
Verifiable
Long termSoftware must run for decade+Laws changeFinance 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 outagesWill 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 13th (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
Assignment 6 – Timeline
14:00 Wednesday Nov 15th (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 17th (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 18th (Week 8) the design team must respond to the e-mail
Assignment 6 – Timeline
14:00 Wednesday Nov 22nd (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
Assignment 6 – Timeline
14:00 Monday Nov 27th (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
Top Related