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