Super-Design

1
Super-Design

• Informatics 122
• Alex Baker

2
In this class weve gone
System Design Arch. Imp. Design Code
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
Putting it back in perspective
System Design Arch. Imp. Design Code
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

• Whats the biggest project youve worked on?

8
Big Projects

• Whats the biggest project youve 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?
Desirable
Feasible
19
In theory
Desirable
Feasible
System design
20
In theory
Desirable
Feasible
System design
Implementation design
21
In theory
Desirable
Feasible
Implementations
System design
Implementation design
22
On the other hand
Desirable
Feasible
Implementations
System design
Implementation design
23
On the other hand

• Some degree of learning and changing
• How can we apply what we are learning most easily?

Desirable
Feasible
24
Software processes

• No process is truly linear or iterative
• We dont 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 didnt 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

1978
2000 (!)
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 didnt know?
• Having a word class in Scrabble
• The piece models in Jetris

43
Choices have subtle effects

• Modeless interaction in VBoard
• What if you didnt 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 softwares
  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
• Agiles 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 frameworks
  needs across documents

59
Representations

• No one solution
• Theres a lot of complexity, it all has to go
  somewhere
• No silver bullet as they say..
• Softwares 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

64
(No Transcript)
65
(No Transcript)
66
Unique Reqs Car Driving SW

• Complexity
• Reliability
• Can we count on input from sensors?
• What happens when theres an error?

67
Unique Reqs Car Driving SW

• Reliability
• Can we count on input from sensors?
• What happens when theres an error?
• UML far from enough

68
Wrapup

• Designing for change
• Multiple designer issues
• Representation issues

69

• Theres more to software design than we can show
  you first hand
• UML often not enough, need meta-design
• Senior projects a start

70
Remember

• Talks Tuesday
• Questions about assignment?
• About Informatics?