CSE403, Software Engineering
Autumn 1999
Layering and Design Patterns
1)
Today,
two things
a)
Understand
the benefits of considering families of systems during software design,
including the layering technique for achieving it
b)
Understand
the very basic notions of design patterns
2)
Families
of systems
a)
It
is quite common for there to be many related versions of a software system
b)
True
even omitting new versions intended “just” for adding features and fixing bugs
c)
Parnas
makes the analogy to families of hardware systems
d)
The
IBM 360 family is a great example
e)
One
instruction set, many many implementations
f)
One
goal was to meet distinct price-performance needs; another was to handle
upgrading
3)
Software
examples
a)
Windows
NT, Windows 98, Windows 2000
b)
Local
language versions of desktop packages
c)
Federal
vs. state versions of TurboTax
d)
Different
Unix versions
e)
A
bazillion others
4)
A
common approach to developing members in a family of systems
a)
Design
and build the first member
b)
Modify
the first member to make the next member
c)
And
so on
5)
Basic
problem
a)
The
basic problem is that this is reactive design
b)
The
design one gets for a later member of the family is based not on the best
design, but on the history that led to it
c)
Ontogeny
recapitulates Phylogeny
6)
Parnas
argues that there are significant benefits to anticipating the family in
advance
a)
Premise
b)
There
are collections of software systems in which one benefits enormously from
understanding their commonalities before focusing on their differences
c)
These are program families
d)
One
should explicitly design with this idea in mind
e)
Then
the design will explicitly account for the family, leading to better designs
7)
Note
a)
In
neither approach will the design for a later member of the family be the same
as if it were designed on its own
b)
In
the evolutionary approach, this is because it’s derived from earlier designs
c)
In
the family approach, this is because it’s designed as part of a family
d)
This
is a tradeoff that is likely to have benefits in the long-term
8)
Stepwise
refinement
a)
This
is the top-down style of program design that Parnas discussed at length
b)
Take
your high-level task, decompose it into parts, assuming you can implement each
part
c)
Then
successive apply this technique to each of those parts, until you have a
complete program
d)
Each
of the parts that is not fully implemented represents a kind of family
9)
Example:
sorting
while $
x,y Î[1..N]½ A[x] < A[y] do
swap(A[x],A[y])
end
a)
You
can think of this as capturing the entire family of exchange sorts
b)
Bubble
sort, insertion sort, shell sort, quicksort, etc.
c)
The
decisions about the order of indices to compare distinguishes the family
members
10)
Stepwise
refinement can reasonably be viewed as a design technique for representing
families of systems
a)
But
the approach is so top-down, which yields practical limitations
b)
In
particular, one has to replay decisions from whatever node in the design tree
is chosen, all the way down
c)
In
small examples, small deal; in big systems, big deal; in really big systems,
really big deal
11)
Layering
a)
Parnas’
later work focuses on layers of abstract machines as a way to design families
of systems
b)
Another
view is to design in a way that easily enables the building of supersets
(extensions) and subsets (contractions)
c)
These
are equally important directions to be able to move in software
d)
In
a strict layered design, a level can only use the immediately lower level
e)
Levels
often promote operations through to the next level
f)
In
the strictest view, recursion would be prohibited
12)
The
classic example is the THE operating system (Dijkstra)
a)
Level 5: User Programs
b)
Level
4: Buffering for I/O devices
c)
Level
3: Operator Console Device Driver
d)
Level
2: Memory Management
e)
Level
1: CPU Scheduling
f)
Level
0: Hardware
13)
Layering
network protocols is another example
14)
The
uses relation
a)
Parnas
says to layer using the uses relation
b)
A
program A uses a program B if the correctness of A depends on the presence of
a correct version of B
c)
Requires
A’s
specification and implementation and B’s specification
d)
What’s
the specification? Signature? Implied
or informal semantics?
15)
uses vs. invokes
a)
These
relations often but do not always coincide
i)
Invocation
without use example: name service with cached hints
ipAddr := cache(hostName);
if not(ping(ipAddr))
ipAddr := lookup(hostName)
endif
b)
Use
without invocation: examples?
16)
Parnas’
observation
a)
A
non-hierarchical uses relation makes it difficult to produce useful subsets of a system
b)
That
is, loops in the uses relation (A uses B and B uses A, directly or indirectly)
cause problems
c)
It
also makes testing difficult
d)
So,
it is important to design the uses relation
17)
Criteria
for uses(A,B)
a)
A is essentially simpler because it uses B
b)
B is not substantially more complex because it does not use A
c)
There
is a useful subset containing B but not A
d)
There
is no useful subset containing A but not B
18) Note again Parnas’ focus on criteria to help you design
19) Design patterns
a)
Advanced
chess players are in part superior because they don’t see each piece
individually
i)
Instead,
they chunk groups of them together
ii)
This
reduces the search space they need to assess in deciding on a move
Idiomatic
usages are related to chunking
iii)
“What
do I do to add today’s lecture notes to the 403 web page?”
(1)
Save
as postscript (get the options right)
(2)
Run
the Adobe distiller
(3)
Move
the pdf to the course web directory
(4)
Edit
the notes.html file
(5)
Check
that it works
iv)
These
kinds of usages show promise for automation or at least chunking
High
level programming languages can be viewed as providing idioms that have proven
generally useful
v)
These
high level constructs are sometimes more, constraining the ability to see the
pieces
vi)
Structures
(1)
Grouping
together heterogeneous elements
vii)
Structured
loops
(1)
Grouping
together disciplined uses of comparisons and branches
viii)
Procedure
call
(1)
Saving
& restoring registers, jumps, …
So,
what are design patterns?
b)
"a
‘well-proven generic scheme’ for solving a recurring design problem”
c)
Idioms
intended to be “simple and elegant solutions to specific problems in
object-oriented software design”
d)
A
key to design patterns is that they are drawn from examples in existing systems
Not
proposed solutions to possible problems, but real solutions to real problems
e)
They
are language-independent
i)
Although
some language support is starting to exist in some cases
f)
Again,
there is an analogy to high-level control structures
Knuth’s
1974 article (“Structured Programming with go to Statements”) shows that this
is not a language issue alone
20)
Patterns
are a collection of low-level, “mini-architectures” that combine structure and
behavior
a)
They
are closely linked to the programming level
b)
Information
hiding is a (higher-level) design notion, which is often supported in
programming languages
21)
A
very brief and incomplete example: the flyweight pattern (from the Gang of
Four)
a)
What
happens when you try to represent lots of small elements as full-fledged
objects?
b)
It’s
often too expensive
c) And it’s pretty common
22)
An
alternative approach
a)
Use
sharing to support many fine-grained objects efficiently
b)
Fixed
domain of objects
c) Maybe other constraints
23)
Flyweight
structure is shown with the object model above
a)
Flyweight
(glyph in text example)
i)
Interface
through which flyweights can receive and act on extrinsic state
b)
ConcreteFlyweight
(character)
i)
Implements
flyweight interface, shareable, only intrinsic state (independent of context)
c)
UnsharedConcreteFlyweight
(row, column)
d)
FlyweightFactory
i)
Creates
and manages flyweight objects
e) This pattern can be instantiated in many situations
i) The GoF book gives an example of text in rows and columns
ii) You can go look if you want
24) Classifications of patterns (original Gang of Four, GoF, patterns)
a)
Creational
i)
Abstract
factory, builder, factory method, prototype, singleton
b)
Structural
i)
Adapter,
bridge, composite, decorator, façade, flyweight, proxy
ii)
Behavioral
(1)
Chain
of responsibility, command, interpreter, iterator, mediator, memento, observer,
state, strategy, template method, visitor
25)
An
historical aside
a)
•The
Gang of Four loosely based their initial work on that of architect Christopher
Alexander
i)
Not
a systems or software architect, but an architecture architect (with planning,
too)
ii)
The
Timeless Way trilogy
(1)
The
Timeless Way of Building (1979), A Pattern Language: Towns, Buildings,
Construction (1977), The Oregon Experiment (1975)
(2)
Not
surprisingly, a focus on idiomatic solutions to common design problems
An
enlightening experience
b)
I
had an experience with two of the Gang of Four
c) They sat down with Griswold and me to show how to use patterns to (re)design a software design we had published
i)
The
rate of communication between these two was unbelievable
ii)
Much
of it was understandable to us without training (a good sign for a learning
curve)
26)
Evaluation
a)
Design
patterns are not a silver bullet
i)
But
they are impressive, important and worthy of attention
ii)
I
think that (slowly?) some of the patterns will become part and parcel of
designers’ vocabularies
This
will improve communication and over time improve the designs we produce
The relatively disciplined structure of the pattern descriptions may be a plus