This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Challenge 1: Determining the Web Server Architecture
� Context: A large and complex production web server
� Problems:
– Designing the web server as a large monolithic entity is tediousand error-prone
– Web server developers must work concurrently to improveproductivity
– Portability and resuability are important quality factors
8
Design Principles
Solution: Decomposition
� Decomposition handles complexity by splitting large problems intosmaller problems
� This “divide and conquer” concept is common to all life-cycleprocesses and design techniques
� Basic methodology:
1. Select a piece of the problem (initially, the whole problem)2. Determine the components in this piece using a design paradigm,
e.g., functional, structured, object-oriented, generic, etc.3. Describe the components interactions4. Repeat steps 1 through 3 until some termination criteria is met
– e.g., customer is satisfied, run out of time/money, etc. ;-)
9
Design Principles
Decomposition Example: Web Server Framework
Pipes and filters
Component confi gu rator
Com
po
nent
co
nfig
ura
tor
~
/home/...Protocolhandler
Protocolfilter
Protocol pipelineframework
Concurrencystrategyframework
Tildeexpander
Cached virtualfilesystem
I/O strategyframework
Adapter
Active object Strate gy
Sta
te
Acc
eptor
Asynchronous com pleti on token
Mem
ento
Reactor/Proactor Strate gy Singleton
Sta
te
Event dispatcher
� Features
– High-performance– Flexible concurrency,
demuxing, and cachingmechanisms
– Uses frameworks basedon ACE
www.cs.wustl.edu/�schmidt/PDF/JAWS.pdf
10
Design Principles
Object-Oriented Decomposition Principles
1. Don’t design components to correspond to execution steps
� Since design decisions usually transcend execution time
2. Decompose so as to limit the effect of any one design decision onthe rest of the system
� Anything that permeates the system will be expensive to change
3. Components should be specified by all information needed to usethe component
� and nothing more!
11
Design Principles
Challenge 2: Implementing a Flexible Web Server
� Context: The requirements that a production web server must meetwill change over time, e.g.:
– New platforms– New compilers– New functionality– New performance goals
� Problems:
– If the web server is “hard coded” using low-level system calls it willbe hard to port
– If web server developers write software that’s tightly coupled withinternal implementation details the software will be hard to evolve
12
Design Principles
Solution: Abstraction
IMPLEMENTATIONIMPLEMENTATION
ESSENTIAL
CHARACTERISTICS
UNESSENTIAL
DETAILS
INTERFACEINTERFACE
� Abstraction manages complexityby emphasizing essentialcharacteristics and suppressingimplementation details
� Allows postponement of certaindesign decisions that occur atvarious levels of analysis, e.g.,
– Representational andalgorithmic considerations
– Architectural and structuralconsiderations
– External environment andplatform considerations
13
Des
ign
Prin
cipl
es
Com
mon
Type
sof
Abs
trac
tion
1.P
roce
dura
labs
trac
tion
�
e.g.
,clo
sed
subr
outin
es
2.D
ata
abst
ract
ion
�
e.g.
,AD
Tcl
asse
san
dco
mpo
nent
mod
els
3.C
ontr
olab
stra
ctio
n
�
e.g.
,loo
ps,i
tera
tors
,fra
mew
orks
,and
mul
titas
king
ACEStreams
AC
E R
eact
or
EV
EN
T
LO
OP
EV
EN
T
LO
OP
APPLIC
ATIO
N-
SPE
CIF
IC E
VE
NT H
AN
DLE
R
FU
NC
TIO
NA
LIT
Y
CA
LL
BA
CK
SLO
CA
L
INV
OC
AT
ION
S
IPC
CLA
SS
ES
AD
TC
LA
SS
ES
AC
E T
ask
EV
EN
T
LO
OP
CA
LLB
AC
KS
CA
LLB
AC
KS
14Design Principles
Information Hiding� Information hiding is an important means of achieving abstraction
– i.e., design decisions that are subject to change should be hiddenbehind abstract interfaces
� Application software should communicate only through well-definedinterfaces
� Each interface should be specified by as little information as possible
� If internal details change, clients should be minimally affected
– May not even require recompilation and relinking...
� Enables developers toreduce overall systemcomplexity via decentralizedsoftware architectures
� Increases scalability bysupporting independent andconcurrent development bymultiple personnel
24
Design Principles
Criteria for Evaluating Modular Designs
Component decomposability
� Are larger componentsdecomposed into smallercomponents?
Component composability
� Are larger componentscomposed from existingsmaller components?
Component understandability
� Are components separatelyunderstandable?
Component continuity
� Do small changes to thespecification affect alocalized and limited numberof components?
Component protection
� Are the effects of run-timeabnormalities confined to asmall number of relatedcomponents?
25
Design Principles
Principles for Ensuring Modular Designs
Language support for components
� Components should correspond tosyntactic units in the language
Few interfaces
� Every component shouldcommunicate with as few others aspossible
Small interfaces (weak coupling)
� If any two components communicateat all, they should exchange as littleinformation as possible
Explicit Interfaces
� Whenever twocomponents A and Bcommunicate, this mustbe obvious from the textof A or B or both
Information Hiding
� All information about acomponent should beprivate unless it’sspecifically declaredpublic
26
Design Principles
Challenge 4: “Future Proofing” the Web Server� Context: A production web server whose requirements will change
over time
� Problems:
– Certain design aspects seem constant until they are examined inthe overall structure of an application
– Developers must be able to easily refactor the web server toaccount for new sources of variation
27
Design Principles
Solution: Extensibility
� Extensible software is important to support successions of quickupdates and additions to address new requirements and takeadvantage of emerging opportunities/markets
� Extensible components must be both open and closed, i.e., the“open/closed” principle:
– Open component ! still available for extension
� This is necessary since the requirements and specifications arerarely completely understood from the system’s inception
– Closed component ! available for use by other components
� This is necessary since code sharing becomes unmanageablewhen reopening a component triggers many changes
� The first two are general to all design methods,the latter two are more particular to OO designand programming
ACE_IPC_SAP ACE_Addr
ACE_SOCK_IO ACE_SOCK
ACE_SOCK_Acceptor ACE_INET_Addr
ACE_SOCK_Stream ACE_SOCK_Connector
37
Design
Principles
The
Uses
Relation
(1/3)
Cla
ss
X
Cla
ss
Y
�
XU
sesY
ifthecorrectfunctioning
ofXdepends
onthe
availabilityofa
correctimplem
entationof Y
�
Note,uses
isnotnecessarily
thesam
eas
invokes:
–S
ome
invocationsare
notuses
�
e.g.,errorlogging
–S
ome
usesdon’tinvolve
invocations
�
e.g.,message
passing,interrupts,sharedm
emory
access
�
Auses
relationdoes
notnecessarilyyield
ahierarchy
(avoidcycles...)
38
Design Principles
The Uses Relation (2/3)
� Allow X to use Y when:
– X is simpler because it uses Y
� e.g., Standard C++ library classes– Y is not substantially more complex because
it is not allowed to use X– There is a useful subset containing Y and not
X
� i.e., allows sharing and reuse of Y– There is no conceivably useful subset
containing X but not Y
� i.e., Y is necessary for X to functioncorrectly
� Uses relationships can exist between classes,frameworks, subsystems, etc.
Acceptor-Connector
Reactor Proactor
ServiceConfigurator
Streams Task
39
Design
Principles
The
Uses
Relation
(3/3)
�
Ahierarchy
inthe
usesrelation
isessentialfor
designingreusable
software
systems
�
How
ever,certainsoftw
aresystem
srequire
controlledviolation
ofauses
hierarchy
–e.g.,asynchronous
comm
unicationprotocols,O
Ocallbacks
infram
eworks,signalhandling,etc.
–U
pcallsare
onew
ayto
controlthesenon-hierarchical
dependencies
�
Rule
ofthumb:
–S
tartwith
aninvocation
hierarchyand
eliminate
thoseinvocations
( i.e.,“calls”)thatare
notusesrelationships
40
Design Principles
The Is-Composed-Of Relation
� The is-composed-of relationship shows how thesystem is broken down in components
� X is-composed-of fxig if X is a group ofcomponents xi that share some commonpurpose
� The following diagram illustrates some of theis-composed-of relationships in JAWS
HTTPHandler
SockStream
HTTPHandler
SockStream
HTTPHandler
SockStream
HTTPAcceptor
SockAcceptor
Reactor
41
Design
Principles
The
Is-Com
posed-OfR
elation
�
Many
programm
inglanguages
supporttheis-com
posed-ofrelationvia
some
higher-levelcomponentor
recordstructuring
technique
�
How
ever,thefollow
ingare
notequivalent:
–level(virtualm
achine)–
component(an
entitythathides
oneor
more
“secrets”)–
asubprogram
(acode
unit)
�
Com
ponentsand
levelsneed
notbeidentical,as
acom
ponentmay
appearin
severallevelsofa
useshierarchy
42
Design Principles
The Is-A Relation
� This “ancestor/descendant” relationship isassociated with object-oriented design andprogramming languages that possessinheritance and dynamic binding
� class X possesses Is-A relationship with class Yif instances of class X are specialization of classY.
– e.g., an HTTP_1_0_Handler Is-AACE_Event_Handler that is specialized forprocessing HTTP 1.0 requests
ACE_Event_Handlerhandle_input()get_handle()
HTTP_1_0Handler
HTTP_1_1Handler
43
Des
ign
Prin
cipl
es
The
Has
-AR
elat
ion
�
Thi
s“c
lient
”re
latio
nshi
pis
asso
ciat
edw
ithob
ject
-orie
nted
desi
gnan
dpr
ogra
mm
ing
lang
uage
sth
atpo
sses
scl
asse
san
dob
ject
s
�
clas
sX
poss
esse
sa
Has
-Are
latio
nshi
pw
ithcl
ass
Yif
inst
ance
sof
clas
sX
cont
ain
anin
stan
ce(s
)of
clas
sY.
–e.
g.,t
heJA
WS
web
serv
erH
as-A
React
or
,H
TT
P_A
ccepto
r,
and
CV
_F
ilesy
tem
JAW
SW
ebS
erve
r
HT
TP
Acc
epto
r
Rea
cto
r
CV
_File
syst
em
44
Design Principles
Challenge 7: Enabling Expansion and Contraction ofSoftware
� Context: A production web server whose requirements will changeover time
� Problems:
– It may be necessary to reduce the overall functionality of theserver to run in resource-constrained environments
– To meet externally imposed schedules, it may be necessary torelease the server without all the features enabled
45
Design Principles
Solution: Program Families and Subsets
� This principle should be applied to facilitate extension andcontraction of large-scale software systems, particularly reusablemiddleware infrastructure
– e.g., JAWS, ACE, etc.
� Program families are natural way to detect and implement subsets
– Minimize footprints for embedded systems– Promotes system reusability– Anticipates potential changes
� Heuristics for identifying subsets:
– Analyze requirements to identify minimally useful subsets– Also identify minimal increments to subsets
46 Des
ign
Prin
cipl
es
Exa
mpl
eof
Pro
gram
Fam
ilies
:JA
WS
and
TAO
(1) T
HE
AC
E O
RB
(TA
O)
NE
TW
OR
K
RE
AL
-TIM
E O
RB
CO
RE
AC
E c
om
ponents
IOP
IOP
PL
UG
GA
BL
EO
RB
& X
PO
RT
PR
OT
OC
OL
S
PL
UG
GA
BL
EO
RB
& X
PO
RT
PR
OT
OC
OL
S
RE
AL-T
IME
I/O
SU
BS
YS
TE
M
HIG
H-S
PE
ED
NE
TW
OR
K IN
TE
RFA
CE
OS
KE
RN
EL
RE
AL-T
IME
I/O
SU
BS
YS
TE
M
HIG
H-S
PE
ED
NE
TW
OR
K IN
TE
RFA
CE
OS
KE
RN
EL
OR
B R
UN
-TIM
ES
CH
ED
UL
ER
IDL
SK
EL
ET
ON
IDL
ST
UB
S
opera
tion (
)
ou
t a
rgs
+ r
etu
rn v
alu
e
OB
JEC
T(S
ER
VA
NT
)
in a
rgs
RE
AL-T
IME
OB
JEC
TA
DA
PT
ER
CLIE
NT
OB
JR
EF
(2) T
he J
AW
S W
eb S
erve
r Fr
amew
ork
Service Configurator
Stra
tegy
Stra
tegy
Sing
leto
n
State State
Acceptor
Pipe
s an
d Fi
lters
Activ
e O
bjec
t
Adapter
Serv
ice
Conf
igur
ator
Even
t Dis
patc
her
Conc
urre
ncy
Stra
tegy
Fram
ewor
k
Prot
ocol
Hand
ler
Prot
ocol
Filte
r
Tild
eEx
pand
er/h
ome/
...
~
Reac
tor/P
roac
tor
Memento
I/O S
trate
gyFr
amew
ork
Cach
ed V
irtua
lFi
lesy
stem
Prot
ocol
Pip
elin
eFr
amew
orkAs
ynch
rono
us C
ompl
eton
Toke
n
�
TAO
isa
high
-per
form
ance
,rea
l-tim
eim
plem
enta
tion
ofth
eC
OR
BA
spec
ifica
tion
�
JAW
Sis
ahi
gh-p
erfo
rman
ce,a
dapt
ive
Web
serv
erth
atim
plem
ents
the
HT
TP
spec
ifica
tion
�
JAW
San
dTA
Ow
ere
deve
lope
dus
ing
the
wra
pper
faca
des
and
fram
ewor
kspr
ovid
edby
the
AC
Eto
olki
t
47
Des
ign
Prin
cipl
es
Oth
erE
xam
ples
ofP
rogr
amFa
mili
esan
dS
ubse
ts
�
Diff
eren
tser
vice
sfo
rdi
ffere
ntm
arke
ts
–e.
g.,d
iffer
enta
lpha
bets
,diff
eren
tver
tical
appl
icat
ions
,diff
eren
tI/O
form
ats
�
Diff
eren
thar
dwar
eor
softw
are
plat
form
s
–e.
g.,c
ompi
lers
orO
Ss
�
Diff
eren
tres
ourc
etr
ade-
offs
–e.
g.,s
peed
vssp
ace
�
Diff
eren
tint
erna
lres
ourc
es
–e.
g.,s
hare
dda
tast
ruct
ures
and
libra
ryro
utin
es
�
Diff
eren
text
erna
leve
nts
–e.
g.,U
NIX
I/Ode
vice
inte
rfac
e
�
Bac
kwar
dco
mpa
tibili
ty
–e.
g.,s
omet
imes
itis
impo
rtan
tto
reta
inbu
gs!
48
Design Principles
Conventional Development Processes
� Waterfall Model
– Specify, analyze, implement, test (in sequence)– Assumes that requirements can be specified up front
� Spiral Model
– Supports iterative development– Attempts to assess risks of changes
� Rapid Application Development
– Build a prototype– Ship it :-)
49
Design Principles
Agile Processes
� Stresses customer satisfaction, and therefore, involvement
– Provide what the customer wants, as quickly as possible– Provide only what the customer wants
� Encourages changes in requirements
� Relies on testing
� For example, eXtreme Programming practices
– Planning, designing, coding, testing
50
Design Principles
eXtreme Programming: Planning
TechnologySpike
SystemPrototype
UserStory
PlanningGame
IterationCommitmentSchedule
Change in Requirements, Risk,or Developement Environment
Risk Estimates
Time
Requirements
based on http://www.extremeprogramming.org/rules/planninggame.html
� Start with user stories– Written by customers, to
specify systemrequirements
– Minimal detail, typicallyjust a few sentences on acard
– Expected developmenttime: 1 to 3 weeks each,roughly
� Planning game createscommitment schedule forentire project
� Each iteration should take2-3 weeks
51
Design Principles
eXtreme Programming: Designing
� Defer design decisions as long as possible
� Advantages:
– Simplifies current task (just build what is needed)– You don’t need to maintain what you haven’t built– Time is on your side: you’re likely to learn something useful by the
time you need to decide– Tomorrow may never come: if a feature isn’t needed now, it might
never be needed
� Disadvantages:
– Future design decisions may require rework of existingimplementation
– Ramp-up time will probably be longer later
� Therefore, always try to keep designs as simple as possible
52
Design Principles
eXtreme Programming: Coding
� Pair programming
– Always code with a partner– Always test as you code
� Pair programming pays off by supporting good implementation,reducing mistakes, and exposing more than one programmer to thedesign/implementation
� If any deficiencies in existing implementation are noticed, either fixthem or note that they need to be fixed
53
Design Principles
eXtreme Programming: Testing
� Unit tests are written before code
� Code must pass both its unit test and all regression tests beforecommitting
� In effect, the test suite defines the system requirements
– Significant difference from other development approaches– If a bug is found, a test for it must be added– If a feature isn’t tested, it can be removed
54
Design Principles
Agile Processes: Information Sources� Kent Beck, Extreme Programming Explained: Embrace Change,
Addison-Wesley, ISBN 0201616416, 1999
� Kent Beck, “Extreme Programming”, C++ Report 11:5, May 1999,pp. 26–29+
� John Vlissides, “XP”, interview with Kent Beck in the PatternHatching Column, C++ Report 11:6, June 1999, pp. 44-52+
� Kent Beck, “Embracing Change with Extreme Programming”, IEEEComputer 32:10, October 1999, pp. 70-77