Workshop on Distributed Software
Management for e-Science
Day 2 - Software Design
Lecture 2
Basic Software Design Issues
Davy Virdee
Applications Consultant, EPCC
Telephone:
Email:
+44 131 650 5023
d.virdee@epcc.ed.ac.uk
Lecture Overview
4Six key issues relevant to all software design phases
– 1. Critical Features
• cassette deck
• text editor example
– 2. Software Design Trade-Offs
– 3. Problem Anticipation
– 4. Cunning Simplification
• Quicksort example
– 5. Software Design Evolution
• keeping it ‘egg-shaped’
– 6. Pride in Software
4Conclusions
2
1
1. Critical Features
4Designing anything non-trivial is a big problem
4Aim to reduce complexity by focusing on the
essentials at the start
4Tackle the ‘critical features’ first
4Those features which:
– are central to the system
• directly related to basic functional goals
– and have the highest degree of expected difficulty or uncertainty
3
Cassette Deck
4Consider a cassette deck
4Part of a hi-fi system
4Suppose you’re trying to design one
4What are the critical features?
4Which aspects are less critical?
4
2
Cassette Deck
4Features
–
–
–
–
–
–
–
–
–
–
–
–
get the cassette into the machine
power supply / transformer
input / output sockets for connection to hi-fi amplifier
headphones socket
tape head for converting between magnetic and sound signals
tape motion
user interface (play, record, stop, rewind etc.)
controller
signal level meters
signal amplification between tape head and inputs / outputs
Dolby noise reduction
solid cover
5
Cassette Deck
4Central features
–
–
–
–
–
–
–
–
–
–
–
–
get the cassette into the machine
power supply / transformer
input / output sockets for connection to hi-fi amplifier
tape head for converting between magnetic and sound signals
tape motion
user interface (play, record, stop, rewind etc.)
controller
signal amplification between tape head and inputs / outputs
solid cover
headphones socket - people can listen via an external amplifier
signal level meters - handy but not essential
Dolby noise reduction - quality enhancement not a core function
6
3
Cassette Deck
4Most difficult/uncertain central features
–
–
–
–
–
–
–
–
–
tape head for converting between magnetic and sound signals
tape motion
controller
get the cassette into the machine - fairly straightforward mechanics
power supply / transformer - exist in lots of other products - re-use
input / output sockets - not inherently difficult
user interface - buttons are relatively easy
signal amplification - amplifiers used in lots of other products - re-use
solid cover - basic mechanics problem
7
Critical Features
4Tape head
– how will it convert sound signals to magnetic?
– will it erode the tape too quickly?
– how can it be aligned accurately with the tape?
4Tape motion
– speed must be constant during playback and record or it will
sound absolutely dreadful
– how do we get it constant?
4Controller
– how will the buttons cause the machine to start playing or
whatever?
8
4
Text Editor Program
4Consider a simple text editor program
–
–
–
–
–
an extremely primitive version of emacs
allows text insertion and deletion at the insertion point (IP)
can move the insertion point with arrow keys
allows sections of text to be given a specified font
save and restore
4What will the critical features of the software
design be?
4Which aspects will be less critical?
9
Critical Features
4Data structure for the text
– what structure would allow easy insertion/deletion at a current
position?
– how would moving up a line, say, work with that data structure?
– how would the data structure accommodate different fonts?
– how would it cope with an attempt to change part of a Roman
section to a Helvetica section?
4Display of the text
– given the current state of the data structure how do you decide
which portion of text to display?
– how much do you re-draw when the data structure changes?
– what happens if the user moves up a line and it goes off the screen?
10
5
Less Critical Features
4Format for the saved file
– as long as reader/writer are consistent, doesn’t matter too much
4Deciding on the complete list of fonts
– once you have the first couple of fonts, adding more shouldn’t be
too difficult
4Deciding on the kind of menu for font selection
– can be changed later without much impact
11
Observations
4Critical features are often depended on by other
features
– e.g. in software many functions depend on the data structure
– e.g. in computers many components depend on the CPU
4Independent features are inherently less complex
and can be given lower priority
– e.g. the signal level meters on the cassette deck
– e.g. the menu type for font selection
12
6
Observations
4Critical features are often converters
– e.g. the tape head converts between magnetic and electric energy
– e.g. the pick-up in an electric guitar converts from mechanical to
electric energy
4Critical features are often at the interfaces
– e.g. interfaces between key modules in software
– e.g. transmitter in a mobile phone
4Critical features may require leaps of invention
– e.g. the tape head
4Sometimes all the features seem critical!
– just have to use ‘gut feel’ on which to tackle first
13
Text Editor Data Structure
4Obvious solution is a big array of characters
h e
l
l
o \n J o n
...
hello
jon
4Excellent for moving the IP left or right
h e
l
l
o \n J o n
...
hello
jon
...
hello
joan
4Bad for insertion and deletion
h e
l
l
o \n J o a n
– have to shunt potentially large chunks down or up the array
14
7
Text Editor Data Structure
4A ‘split-stack’ approach would be better
h e
l
l
o \n J
...
hello
jon
o n
4Still pretty good for moving the IP left or right
h e
l
l
o \n J o
...
n
hello
jon
n
hello
joan
4Excellent for insertion and deletion
h e
l
l
o \n J o a
...
15
Text Editor Data Structure
4What about fonts?
4Store the font on a per-character basis?
h e
C
C
l
l
C
H
o \n J
H
H
H
...
o n
H
hello
jon
H
4Simple solution but uses ~double the memory
16
8
Text Editor Data Structure
4How about special markers for font regions?
>
h e
l
<
>
l
o \n J
... o n
<
hello
jon
4Saves lots of memory on average
4But what if the user changes font for ello?
4How should the data structure rearrange itself?
4Bit tricky
4It’s a trade-off between memory and complexity
17
2. Software Design Trade-Offs
4Recall that for a design to be good we need high
merit
– i.e. desirable properties in the context of the design goals
4For software design the set of desirable properties
is usually the same
–
–
–
–
low time (to run)
low space (memory)
low complexity (of design)
low difficulty (of use)
18
9
Desirable Properties
4Low time
– users always want a faster runtime
4Low space
– requiring too much memory will degrade the runtime (sometimes
terminally) and restrict the set of suitable platforms
4Low complexity
– the simpler the design, the cheaper it will be to build, and the
easier it will be to maintain
4Low difficulty
– if the resulting software isn’t easy to use, then it’s useless
19
Common Trade-offs
4Space vs Complexity
– consider the text editor example where keeping memory low for font
storage increased the complexity
4Time vs Space
– storing and re-using interim results saves time at the expense of
space
4Time vs Complexity
– storing derived data (instead of calculating it) saves time for
subsequent calls but introduces undesirable dependencies
4Complexity vs Difficulty
– automatic grammar checking in a word processor makes it easier to
use, but is tricky to design
20
10
Resolving Trade-offs
4No magic solution
4Have to decide the relative priorities on a caseby-case basis
4In the absence of other factors I use the following
facts for guidance
–
–
–
–
memories keep getting bigger
machines keep getting faster
life is finite
the remainder of mine in particular is getting shorter every day
21
Life-Centric Priorities
41. Low complexity
– otherwise you waste life debugging and redesigning
42. Low difficulty
– otherwise users waste life wrestling with your unforgiving software
43. Low time
– otherwise you and your users waste life waiting for it to run
44. Low space
– there will probably be a bigger machine next year
22
11
3. Problem Anticipation
4This is an important skill in design evaluation
4Being able to look at a proposal and say
“No, it won’t work”
4Have to think carefully through the implications of
current design decisions
4Ask probing questions of the design/designer
– “What happens if …?”
– “Ah, I hadn’t thought of that”
23
Problem Anticipation
4Sounds like a negative skill
4Actually very positive
– wiping out whole branches of the design tree
– improving chances of arriving at a good design
4The earlier a problem is found the better
– it costs much less if found early
24
12
Problem Anticipation
no design
“No, it won’t work”
last designs
(before building)
final items
bad
bad
good
bad
bad
25
4. Cunning Simplification
4Recall that high merit designs are often the
simplest
4A simple design needn’t be a naïve design
4It is often cunning which brings about the simplicity
4Consider the famous Quicksort algorithm
4It uses cunning to reduce the problem of sorting
1 big array to the problem of sorting 2 small arrays
26
13
Quicksort
4Quicksort uses partitioning
– pick a pivot element, p (e.g. the first in the array, 6)
– start from the left and right ends and move inwards
– swap left elements >= 6 with right elements <= 6
6 2 7 9 5 4 3 8
3 2 4 5
9 7 6 8
partitioned about 6
4Cunning observation:
– if you partition an array, the two partitions may then be sorted
independently
– this simplification may be applied recursively
27
Quicksort Example
6 2 7 9 5 4 3 8
partition about 6
3 2 4 5
partition about 3 and 9
3 2
4 5
9 7 6 8
8 7 6
2
3
4
5
6 7
2
3
4
5
6
9
8
7
partition about 3, 4 and 8
9
8
partition about 6
9
degenerate case - sorted
28
14
Quicksort
4The result is a very fast yet simple sorting
algorithm
4Quicksort is an example of ‘Divide and Conquer’
– solve big problems by combining the solutions to smaller
problems
4Need imagination to hunt out the opportunities for
cunning simplification
29
5. Software Design Evolution
4Recall that designs evolve as more detail is added
and problems are found/fixed
4‘Iterative Refinement’
4Very important to keep the ‘whole’ consistent and
clean as more parts are added
30
15
Software Design Evolution
4Next stage is to add a garage
4Bad to just abut it against the house wall
4Much better to alter part of existing wall first
4Formerly excellent pieces of design may need
re-work when more parts are added
31
Egg-Shaped Designs
4Suppose you’re early in the design process and you
have a promising design
4High intersection, high merit, but low detail
4Visualise it as an egg shape
4Strong, simple, elegant, clean, self-consistent
32
16
Egg-Shaped Designs
4When adding more detail or features, you want this:
careful
consistent
re-design
4But the danger is that you get this:
quick
hacky
extension
33
Egg-Shaped Designs
4Keep going down that road and you get this:
scrambled
egg
4Ugly, inconsistent, non-extensible, unusable?
4High detail but low intersection and very low merit
34
17
intersection
Eggs in the Design Cube
ta
de
no design
il
merit
35
Why Does the Egg Get Scrambled?
4Scrambled egg happens because it’s often easier
to add a quick dirty ‘solution’ than do it properly
– false economy of course
4Maintaining a nice egg-shape often requires
intimate understanding of the current design
– so you can re-use existing structure
– avoid worsening existing dependencies
4(Need to be extra careful when the person
extending the design is not the original designer)
36
18
Why Does the Egg Get Scrambled?
4Lack of understanding breeds a reluctance to
modify existing code for fear of breaking it
– so people just add new code
– often results in sprawling hacks
4Better to restructure the original code and re-test it
– to smooth out the egg
37
Scrambled Example
4Suppose there’s a function to print someone’s
name and age, but you just want to print their name
void printNameAndAge (int i) {
// Print out the name and age of the person at the argument index.
printf(“Name is %s \n”, names(i));
printf(“Age is %d \n”, ages(i));
}
4You could simply add this:
void printName (int i) {
// Print out all the name of the person at the argument index.
printf(“Name is %s \n”, names(i));
}
38
19
Egg-Shaped Software
4Change the original function to use your new one:
void printName (int i) {
// Print out all the name of the person at the argument index.
printf(“Name is %s \n”, names(i));
}
void printNameAndAge (int i) {
// Print out the name and age of the person at the argument index.
printName(i);
printf(“Age is %d \n”, ages(i));
}
4Avoids code duplication
4Avoids potential for future inconsistency bugs
39
Facing Scrambled Egg
4Extending existing software is more common than
starting new software from scratch
4What should you do when faced with extending
scrambled egg?
4Don’t panic, and don’t make it worse
4Campaign for extra time to smooth out the bits
you’ll be interfacing with first
– always a good investment even though it adds no new functionality
– ‘refactoring’
40
20
6. Pride in Software
4Great designers, artists and architects take pride in
their work
– so should software designers!
– some people throw code together like it’s beans on toast
– take as much pride in your software as an artist would of a painting!
4Great designers like to show off their work
4They learn a lot from seeing each other’s work
4But solitary software designers can be a bit shy
– don’t be embarrassed about exposing your work
– learn from other people’s mistakes and experience as well as
your own
41
Conclusions
4Six basic software design issues
–
–
–
–
–
–
identify and tackle critical features first
resolve design trade-offs with the project priorities in mind
seek out problems as early as possible
use cunning to simplify the design
keep it egg-shaped as it evolves
take pride in it
42
21