November 3, 1997 OOD Template

OO Design Template
Created by Sanjai Rayadurgam for CSi !1"#, $all 1197
%odified for &#"1 by %at' (eimda)l, $all 1999
T)e purpo'e of t)i' doument i' to provide you *it) a template for *riting t)e 'oft*are de'ign
doument for your projet+ ,ou are enouraged to follo* t)e overall 'truture and ontent a'
pre'ribed )ere+ Care ')ould be ta-en to provide all detail'+
.oint' to remember/
Content i' important not t)e volume+
.ay attention to detail'+
Completene'' and on'i'teny *ill be re*arded+
1 of 11
November 3, 1997 OOD Template
Contents
1 Introduction2
1.1 System Overview_______________________________________________2
1.2 Design Objectives_______________________________________________2
1.3 References_____________________________________________________3
1. Revision !istory________________________________________________3
2 Glossary____________________________________________________3
3 Use Cases___________________________________________________3
4 Design Overview______________________________________________3
.1 "ntro#$ction____________________________________________________3
.2 System %rc&itect$re_____________________________________________3
&+0+1 Top1level 'y'tem 'truture of $uel level ontroller2222222222222222222222222223
&+0+0 3evel %onitoring Sub1'y'tem2222222222222222222222222222222222222222222&
&+0+3 $uel Sub'y'tem22222222222222222222222222222222222222222222222222222&
.3 System "nterfaces_______________________________________________
&+3+1 .re''ure Sen'or 4nterfae222222222222222222222222222222222222222222222&
&+3+0 .ump 5alve Controller 4nterfae22222222222222222222222222222222222222222&
. Constraints an# %ss$mptions_____________________________________'
5 Object odel________________________________________________5
'.1 System Object (o#el____________________________________________'
! Object Descri"tions___________________________________________!
).1 Objects in t&e *$el S$bsystem____________________________________+
6+1+1 Objet/ Tan-222222222222222222222222222222222222222222222222222222227
# Dyna$ic odel_______________________________________________%
+.1 Scenarios______________________________________________________,
7+1+1 Senario/ $uel 3evel OverS)oot'2222222222222222222222222222222222222222"
7+1+0 Senario/ 7not)er 'enario22222222222222222222222222222222222222222222"
+.2 State Diagrams_________________________________________________-
6+0+1 State Diagram 1/ Tan-2222222222222222222222222222222222222222222222229
6+0+0 State Diagram 0/ Controller222222222222222222222222222222222222222222229
% &on'(unctional re)uire$ents___________________________________1*
+ ,u""le$entary Docu$entation_________________________________1*
1* -c.nowledge$ents__________________________________________1*
11 I&D/0______________________________________________________1*
0 of 11
November 3, 1997 OOD Template
1 "ntro#$ction
111 ,yste$ Overview
.rovide a brief de'ription of t)e purpo'e of t)e 'y'tem, it' target u'er' and t)e
environment in *)i) t)e 'y'tem *ill be u'ed+ T)i' i' ba'ially from t)e initial part of t)e
re8uirement' doument *it) revi'ion' if any+
1.2 Design Objectives
4n t)i' 'etion di'u'' t)e overall 'y'tem de'ign goal'+ 9roadly mention *)at
funtionality t)e de'ign attempt' to over and *)at it doe'n:t+ 7l'o, refer to non1
funtional re8uirement' li-e performane and u'ability t)at t)e de'ign addre''e'+ T)e
re8uirement' 'peifiation doument ould be u'eful in *riting t)i' 'etion+ Ta-e a loo- at
t)e funtional and non1funtional re8uirement' definition' in your re8uirement'
'peifiation+
T)i' 'etion ')ould provide t)e overall 'ope and onte;t for t)e de'ign+ 7fter reading
t)i' 'etion t)e reader ')ould be able to under'tand what feature' and funtion' are
being addre''ed+ 4n t)e later 'etion', you *ill be e;plaining how t)i' i' a)ieved in your
de'ign+
1.3 References
.rovide referene' to ot)er doument'+
Hint/ ,ou mu't at lea't refer to t)e re8uirement' doument<
1. Revision !istory
Reord )i'tory of )ange' to t)i' doument+ ,ou ')ould 'peify *)at t)e )ange *a',
*)o made t)e )ange and *)en it *a' made =t)e date>+
2 .lossary
Definition of variou' term' u'ed in t)e doument+
Note/ 4f you are T7 a'-', ?*)at do you mean by t)i'@AB, may be you ')ould on'ider
adding a brief definition )ere+
4f 'ome of t)e term' )ave been defined in t)e re8uirement' doument already, you may
ju't refer t)e reader to t)e glo''ary of t)e re8uirement' doument+
3 /se Cases
T)i' 'etion ')all ontain a u'e a'e diagram =in C%3 notation> for t)e 'y'tem and a
de'ription =detailed, but in Dngli')> of ea) u'e a'e =t)e normal operation>+
3 of 11
November 3, 1997 OOD Template
Design Overview
.1 "ntro#$ction
T)i' 'etion ')ould )ig)lig)t t)e over de'ign approa) t)at you adopt =e+g+ objet1
oriented de'ign or 'trutured de'ign>, t)e propo'ed ar)iteture of t)e 'y'tem =e+g+
lient1'erver> and t)e relevant te)ni8ue' and tool' u'ed =e+g+, O%T, Rational Ro'e>+
.2 System %rc&itect$re
.rovide a )ig)1level de'ription of t)e 'y'tem ar)iteture+ C'e a fe* blo- diagram' to
')o* t)e major omponent' and t)eir interation+ 4t may be better to ')o* t)e logial
'truture of t)e program 'eparate from it' p)y'ial 'truture+ Remember to de'ribe t)e
onvention' and notation' u'ed in your diagram'+
&+0+1 Top1level 'y'tem 'truture of $uel level ontroller
The system consists of two major components, a level monitoring subsystem and a fuel
subsystem. The interaction between the systems is bi-directional. Current sensor
measurements are sent to the level monitoring subsystem from the fuel subsystem and
instructions to various actuators are sent back based on the current fuel level.
&+0+0 3evel %onitoring Sub1'y'tem
The Level onitoring !ubsystem consists of the "perator interface and the Controller.
The operator interface in turn consists of #larms and !witches.
&+0+3 $uel Sub'y'tem
#nother diagram and some e$planation%
& of 11
3evel %onitoring
Sub'y'tem
$uel
Sub'y'tem
0evel (onitoring
S$bsystem
Operator
"nterface
Controller
%larms Switc&es
November 3, 1997 OOD Template
.3 System "nterfaces
T)e variou' interfae' provided to u'er' and ot)er e;ternal 'y'tem' ')ould be defined
)ere+ 4f you )ad inluded u'er interfae de'ription' in your re8uirement' doument you
may refer to t)em )ere+ 4f you provide interfae' to ot)er 'y'tem', 'ay e;port and import
data to a different 'oft*are, you ')ould mention t)em )ere+
&+3+1 .re''ure Sen'or 4nterfae
This interface is used to measure the li&uid pressure at the bottom of the tank from which
the fuel level is computed. The sensor measures pressure in pounds per s&uare inch
'psi(. # hardware interface is provided to access the sensor reading from the Controller
software. The data can be accessed by the software at a fi$ed memory location 'using
memory mapped )*"(.
&+3+0 .ump 5alve Controller 4nterfae
+escription goes here%
. Constraints an# %ss$mptions
%ention t)e major de'ign on'traint' )ere+ T)e'e may )ave been impo'ed by t)e
u'tomer, *)i) an be found in t)e re8uirement' doument+ D;plain )o* your de'ign
aommodate' t)e'e on'traint'+
T)ere may al'o be on'traint' impo'ed beau'e of your 'y'tem interating *it) ot)er
e;ternal 'y'tem' or being dependent on 'ome e;ternal 'y'tem' to provide part of t)e
funtionality+ 4n 'u) a'e' learly mention t)e type of 'oft*are your 'y'tem interat'
*it) =e+g+ E,F databa'e 'oft*are, 79C email 'oft*are> and t)e on'traint' t)i' impo'e'
=e+g+ only te;t ba'ed email me''age' are allo*ed>+
4mplementation language' and platform' may impo'e ertain on'traint'+ %ention t)em
)ere+
$or on'traint' impo'ed by your de'ign )oie', briefly mention t)e option' t)at you )ad,
t)e tradeoff' involved and t)e rea'on *)y you made t)e )oie+
1+ ,esponse from the controller to changes in the fuel level should reach the controller
within -.. milliseconds+
This is addressed by a combination of the priority scheme and the underlying
e$ecutive software that operates the controller. /vents are scheduled to be handled
by the e$ecutive by priority. The e$ecutive runs every 01 milliseconds and schedules
the event-handler for the highest priority event pending in the event-&ueue. #ll
event-handlers e$ecute within the 01-millisecond time limit.
0. #nother constraint%
7n e;ample of a de'ign )oie impo'ing a on'traint/
Choice of email software restricts messages to plain te$t.
2e had the option of choosing an easy to use software that provides the basic
functionality or a full-featured messaging system. The former option meant that we could
use only te$t based messages whereas the latter option meant a lot of overhead in
! of 11
November 3, 1997 OOD Template
installing and supporting the software. !ince our application re&uired predominantly te$t-
based messages, we chose the first option. )n future binary data could be sent over the
te$t-based system using some coding scheme.
' Object (o#el
'.1 System Object (o#el
.rovide t)e objet model for t)e *)ole 'y'tem+ 4f t)e model i' too big partition t)e
diagram u'ing 'ome rea'onable riteria+ $or e;ample, you may provide t)e lient1'ide
and t)e 'erver1'ide objet model' a' 'eparate diagram'+
G)at ')ould go into an objet diagramA
7ll t)e 'y'tem objet' ')ould find a plae )ere+ T)e'e objet' are t)e one' identified by
reading t)e re8uirement'+ Refer to t)e la'' leture note' =07 Ot 97> for determining
*)at ')ould and *)at ')ouldn:t go into t)i' diagram+
7ll a''oiation' bet*een objet' ')ould be identified and a''oiation' ')ould be
deorated *it) t)e rig)t ardinality+ 7ggregation and in)eritane relation')ip' ')ould be
identified+ 7 brief e;planation ')ould aompany ea) diagram+
Remember/ ,ou may )ave to iterate 'everal time' before you agree on t)e rig)t objet1
model for your 'y'tem+
6 of 11
November 3, 1997 OOD Template
Objet model for t)e $uel 3evel %onitoring Sy'tem
) Object Descriptions
4n t)i' 'etion you *ould de'ribe in detail ea) objet, it' attribute' and it' met)od'+
,ou ')ould logially group objet' toget)er+ $or e;ample, you may u'e your ar)iteture
diagram' to group objet' *it)in a 'ub1'y'tem toget)er+
.rovide a 'ub'etion for ea) objet+ $or ea) objet, briefly de'ribe it' purpo'e, any
on'traint', =e+g+, only 'ingle in'tane> and li't t)e attribute' and t)e met)od' of ea)
objet in t)e 'y'tem objet model+ 4f t)e objet i' 'tored in 'ome permanent data 'tore
t)en mention t)at it i' per'i'tentH el'e mention t)at it i' a tran'ient objet+
$or ea) objet de'ribe ea) of it' attribute' *it) t)e follo*ing detail'/ name, type, a
one line de'ription of t)e attribute if it' meaning i' not intuitive and on'traint' on t)e
attribute =e+g+ attribute mu't )ave uni8ue value for ea) objet or value range i' re'trited
to po'itive integer'>+
Da) met)od ')ould be de'ribed *it) t)e follo*ing detail'/ met)od name, return type
and value, parameter', purpo'e and a brief de'ription of t)e algorit)m u'ed =if it i' non1
trivial>+ .re1ondition' and po't1ondition' ')ould be mentioned )ere if t)ere are any
a''umption' about t)e argument' or t)e return value'+ 3i't t)e attribute' read and
modified by t)i' met)od and ot)er met)od' invo-ed by t)i' met)od+ $inally, provide te't
a'e' t)at an be u'ed to verify t)e implementation met)od+
7 of 11
$3% Sy'tem
target1level
Controller
Operator
Ifuel1level
lo*1level
)ig)1level
Tan- .ump
$uel Sy'tem
7larm
S*it)
5i'ible 7larm
$uel
pre''ure
.re''ure
Sen'or
.u')e'
7udible 7larm
%onitor'
Control'
Notifie'
%ea'ure'
1++J
Sound' 1++J
1++J
1++J
1++J 1++J
1++J
Notifie'
9ar Sen'or mm(g Sen'or
November 3, 1997 OOD Template
!11 Objects in t2e 3uel ,ubsyste$
6+1+1 Objet/ Tan-
Purpose: To model the relevant aspects of the physical tank that stores fuel
Constraints: None
Persistent: No (created at system initialization from other available data(
6.1.1.1 Attribute Descriptions
1. Attribute: fuel-level
Type: real (double precision)
Description: Stores the current fuel level in the tank
Constraints: should be a value between and ma!-level
". Attribute: ma!-level
Type: real (double precision)
Description: ma!imum level of fuel that the tank can hold
Constraints: non-ne#ative
$. Another attribute
6.1.1.2 Method Descriptions
1. Method: %d&ust'evel(double pressure)
Return Type: boolean
Parameters: pressure ( the current pressure readin# for the tank
Return vaue: success or failure
Pre!condition: fuel-level between and ma!-level
Post!condition: fuel-level between and ma!-level
Attributes read"used: fuel) pump) alarm) fuel-level
Methods caed: fuel.#et*density()) alarm.sound*alarm()
Processin# o#ic:
The fuel density is obtained from the fuel attribute of the tank. New fuel-level is
computed from density and pressure. +f level falls outside the ran#e ,low-level) hi#h-level)
the alarm associated with the tank is sounded and the pump is stopped.
Test case 1: -all %d&ust'.vel with pressure / and fuel-level 0. .!pected output is12.
+ Dynamic (o#el
T)e purpo'e of t)i' 'etion i' to model )o* t)e 'y'tem re'pond' to variou' event', i+e+,
model t)e 'y'tem:' be)avior+ Ge do t)i' u'ing 'e8une diagram' and 'tate diagram' a'
di'u''ed in la''+
T)e fir't 'tep i' to identify different 'enario' =e+g+ $uel 3evel Over')oot'>+ Ge don:t
e;pet you to identify all po''ible 'enario', but your li't ')ould over at lea't t)e typial
'y'tem u'e a'e'+ Do not invent 'enario' li-e set3target3level and get3target3level
=t)e'e are ju't 'imple met)od' at a lo* level>+ 7 general guideline i' to inlude 'enario'
t)at *ould ma-e 'en'e to t)e u'tomer+ $or e;ample, ,esetting The #!2, may be a
'enario for t)e 7SG+
" of 11
November 3, 1997 OOD Template
#11 Scenarios
$or ea) 'enario you *ill )ave a 'ub'etion )aving t)e follo*ing/
Senario Name/ .rovide 'ome meaningful name for t)e 'enario
Senario De'ription/ 7 brief de'ription of *)at t)e 'enario i' about and t)e
'e8uene of ation' t)at ta-e plae
Se8uene Diagram/ 7 'e8uene diagram ')o*ing variou' event' and t)eir relative
time ordering =a' di'u''ed in la''>+
7+1+1 Senario/ $uel 3evel OverS)oot'
De'ription/ This scenario shows the typical se&uence of actions that takes place when
fuel level e$ceeds the prescribed high-level.
4uel level goes higher than high-level
The pump is stopped
The alarm goes off
The operator presses reset
9 of 11
Tan1 2$mp Controller
'top
%larm Operator
level1re8ue't
alarm1on
re'et
alarm1off
level1re'pon'e
Dvery !'
3evel )ig)
November 3, 1997 OOD Template
7+1+0 Senario/ 7not)er 'enario
De'ription/
#12 State Diagrams
4n t)i' 'etion you ')ould inlude 'tate diagram' for important part' of t)e dynami
model of your 'y'tem+ ,ou may inlude a 'tate diagram for ea) objet, but t)at may at
time' be too mu) of un*anted detail+ ,ou may identify a fe* important objet' in your
'y'tem and provide 'tate1diagram' for t)em+ Remember t)at 'tate1diagram' need no
orre'pond one1to1one to objet'+ T)ey an be at )ig)er1level' of ab'tration+ ,ou may
al'o identify 'ome event' and ation' t)at orre'pond to important operation'+
7+0+1 State Diagram 1/ Tan-
See t)e 'tate diagram on t)e ne;t page for t)e Tank objet+ T)e variou' 'tate' of t)e
objet are ')o*n along *it) t)e tran'ition' and ation' t)at ta-e plae *)en t)e 'en'or'
are read+ T)e -ey operation' from t)i' diagram are level-re&uest, level-response and
level-report.
7+0+0 State Diagram 0/ Controller
% state #iagram for anot&er object3
0ow
1# of 11
4ormal
!ig&
level5report678
97 : low5level;
level5report678
97 < low5level;
level5report678
97 < &ig&5level;
level5report678
97 : &ig&5level;
level5re=$est >
level5response6low8
level5report678
97 < f$ll5level;
#o? rea#5sensors
*$ll
@elow5*$ll
level5re=$est >
level5response6normal8
level5re=$est >
level5response6f$ll8
level5re=$est >
level5response6&ig&8
November 3, 1997 OOD Template
, 4on5f$nctional re=$irements
4n t)i' 'etion you )ave to e;plain )o* you e;pet to meet t)e non1funtional
re8uirement' 'peified in t)e re8uirement' doument+ 7' far a' po''ible, a''e'' your
de'ign objetively for ea) non1funtional re8uirement 'peified in t)e re8uirement
doument and e;plain )o* you meet t)e re8uirement+ 4f 'ome non1funtional
re8uirement' are not totally under t)e ontrol of t)e 'y'tem you are de'igning, t)at
')ould be mentioned )ere+ ,ou ')ould al'o mention )o* you e;pet t)e 'y'tem to
evolve in future and )o* your de'ign *ould aommodate t)o'e antiipated )ange'+
- S$pplementary Doc$mentation
.rovide any ot)er relevant doumentation t)at may )elp under'tanding t)e de'ign+
1A %c1nowle#gements
T)i' de'ign template *a' prepared *it) t)e )elp of Dr+ %at' (eimda)l, C)ad Ryan and
S)ituo (an+ T)eir omment' and 'ugge'tion' =and my typing '-ill'<> *ere t)e ritial
input' t)at *ent into t)e ma-ing of t)i' doument+ T)e e;ample' and diagram' )ave
been adapted from Dr+(eimda)l:' leture note'+
11 "4DBC
aggregation, 6
ar)iteture
'y'tem ar)iteture, 3
a''oiation', 6
attribute', 7
blo- diagram', 3
ardinality, 6
omponent' and t)eir interation, 3
on'traint'
de'ign, !
language' and platform', !
de'ign
approa), 3
on'traint', !
doumentation
'upplementary, additional, 1#
environment, 0
event trae diagram', "
)i'tory, 3
in)eritane, 6
interfae
'y'tem+ !ee
u'er, &
met)od, 7
objet
de'ription', 6
objet model, !
referene', 3
re8uirement'
funtional, 0
non1funtional, 0, 1#
'enario', "
'tate diagram, 9
'tate diagram', "
'y'tem be)avior, "
term', 3
11 of 11