Transcript Transparency Masters for Software Engineering: A

8.1 Requirements Analysis

Rules of Thumb






Models should focus on requirements that are visible
within the problem or business domain. The level of
abstraction should be relatively high.
Each element of the analysis model should add to an
overall understanding of software requirements and
provide insight into the information domain, function and
behavior of the system.
Delay consideration of infrastructure and other nonfunctional models until design.
Minimize coupling throughout the system.
Be certain that the analysis model provides value to all
stakeholders.
Keep the model as simple as it can be.
1
8.3 Data Modeling





examines data independently of processes
indicates how data objects relate to one another
Object – something that is described by a set of
attributes and will be manipulated within the software
(system)
Each instance of an object (e.g., a book) can be
identified uniquely (e.g., ISBN#)
Object (automobile) has attributes (make, model, body
type, price, etc.)
2
The ERD: An Example
Customer
(1,1)
places
request
(1,m)
(1,1)
standard
task table
generates
(1,1)
selected
from
work
(1,m) tasks
materials
(1,m)
(1,m)
(1,m) work
order
(1,1)
(1,1)
consists
of
lists
3
8.4 Object-Oriented Analysis


Must be understood to apply class-based
elements of the analysis model
Key concepts:




Classes and objects
Attributes and operations
Encapsulation and instantiation
Inheritance
4
What is a Class?
occurrences
roles
organizational units
things
places
structures
external entities
class name
attributes:
operations:
5
Encapsulation/Hiding
The object encapsulates
both data and the logical
procedures required to
method
manipulate the data
method
#2
#1
data
method
#3
method
#6
method
#5
method
#4
Achieves “information hiding”
6
Class Hierarchy
PieceOfFurniture (superclass)
Table
Chair
Desk
”Chable"
subclasses of the
instances of Chair
7
Methods
(a.k.a. Operations, Services)
An executable procedure that is
encapsulated in a class and is designed
to operate on one or more data attributes
that are defined as part of the class.
A method is invoked
via message passing.
8
8.5 Scenario-Based Modeling
“[Use-cases] are simply an aid to defining what exists outside the
system (actors) and what should be performed by the system
(use-cases).” Ivar Jacobson
What are the main tasks or functions that are performed by the
actor?
What system information will the the actor acquire, produce or
change?
Will the actor have to inform the system about changes in the
external environment?
What information does the actor desire from the system?
Does the actor wish to be informed about unexpected changes?
9
Use-Case Diagram
Saf eHome
Access camera
surveillance via t he
Int ernet
cameras
Conf igure Saf eHome
syst em paramet ers
homeowner
Set alarm
10
Activity
Diagram
ent er password
and user ID
valid passwor ds/ ID
Supplements
the use-case
by providing a
diagrammatic
representation
of procedural
flow
invalid passwor ds/ ID
selec t major f unc t ion
prompt f or reent ry
ot her f unct ions
m ay also be
select ed
input t r ies r em ain
selec t surv eillanc e
no input
t r ies r em ain
t hum bnail views
select a specif ic cam er a
selec t spec if ic
c amera - t humbnails
selec t c amera ic on
v iew c amera out put
in labelled window
prompt f or
anot her v iew
exit t his f unct ion
see anot her cam er a
11
Swimlane
Diagrams
•Allows the modeler to
represent the flow of activities
described by the use-case
and at the same time indicate
which actor (if there are
multiple actors involved in a
specific use-case) or analysis
class has responsibility for the
action described by an activity
rectangle.
homeowner
c a m e ra
i n t e rf a c e
ent er pas s word
and us er ID
valid p asswo r d s/ ID
in valid
p asswo r d s/ ID
s elec t m ajor f unc t ion
o t h er f u n ct io n s
m ay also b e
select ed
prom pt f or reent ry
in p u t t r ies
s elec t s urv eillanc e
r em ain
n o in p u t
t r ies r em ain
t h u m b n ail views
select a sp ecif ic cam er a
s elec t s pec if ic
c am era - t hum bnails
s elec t c am era ic on
generat e v ideo
out put
v iew c am era out put
in labelled window
prom pt f or
anot her v iew
exit t h is
f u n ct io n
see
an o t h er
cam er a
12
8.6 Flow-Oriented Modeling
Represents how data
objects are transformed
at they move through the
system
external entity
Data flow diagram (DFD)
Considered by many to
be an ‘old school’
approach, flow-oriented
modeling continues to
provide a view of the
system that is unique—it
should be used to
supplement other
analysis model elements
process
data flow
data store
13
Level 0 DFD Example
user
processing
request
digital
video
processor
video
source
requested
video
signal
monitor
NTSC
video signal
14
The Data Flow Hierarchy
x
a
a
b
P
c
p2
level 1
p4
p3
level 0
f
p1
d
y
e
g
5
b
15
Process Specification (PSPEC)
bubble
PSPEC
narrative
pseudocode (PDL)
equations
tables
diagrams and/or charts
16
Control Flow Diagrams







the control flow diagram is "superimposed" on the DFD and
shows events that control the processes noted in the DFD
control flows—events and control items—are noted by
dashed arrows
a vertical bar implies an input to or output from a control
spec (CSPEC) — a separate specification that describes
how control is handled
a dashed arrow entering a vertical bar is an input to the
CSPEC
a dashed arrow leaving a process implies a data condition
a dashed arrow entering a process implies a control input
read directly by the process
control flows do not physically activate/deactivate the
processes—this is done via the CSPEC
17
Control Flow Diagram
beeper on/off
read
operator
input
copies done
full
manage
copying
problem light
start
empty
reload
process
jammed
perform
problem
diagnosis
create
user
displays
display panel enabled
18
8.7 Class-Based Modeling




Identify analysis classes by examining the
problem statement
Use a “grammatical parse” to isolate potential
classes
Identify the attributes of each class
Identify operations that manipulate the attributes
19
Class Diagram
Class name
System
sy st emI D
v erif icat ionPhoneNumber
sy st emSt at us
delay Time
telephoneNumber
mast erPassword
temporary Password
numberTries
program()
display ()
reset ()
query ()
modif y ()
call()
attributes
operations
20
Class Diagram
FloorPlan
type
name
outsideDimensions
determineType ( )
positionFloorplan
scale( )
change color( )
is placed wit hin
is part of
Cam era
Wall
t y pe
ID
loc at ion
f ieldV iew
panA ngle
Zoom Set t ing
t y pe
wallDim ens ions
determineType ( )
computeDimensions ( )
det erm ineTy pe ()
t rans lat eLoc at ion ()
dis play ID()
dis play V iew()
dis play Zoom ()
is used t o build
is used t o build
is used t o build
WallSegm ent
t y pe
s t art Coordinat es
s t opCoordinat es
nex t WallSem ent
determineType ( )
draw( )
Window
Door
t y pe
s t art Coordinat es
s t opCoordinat es
nex t Window
t y pe
st art Coordinat es
st opCoordinat es
nex t Door
determineType ( )
draw( )
determineType ( )
draw( )
21
8.7 CRC Modeling
Clas s :
Clas s :
Descript
ion:
Clas
s:
Descript
ion:
Clas
s :FloorPlan
Descript ion:
Re s pons
ibility:
Descript
ion:
Re s pons ibility:
Re s pons ibility:
Re s pons ibility:
Collaborator :
Collaborator :
Collaborator :
Collaborator :
def ines f loor plan name/ ty pe
manages f loor plan posit ioning
scales f loor plan f or display
scales f loor plan f or display
incorporat es walls, doors and windows
Wall
shows posit ion of v ideo cameras
Camera
22
Reviewing the CRC Model

All participants in the review (of the CRC model) are given a subset of the CRC model
index cards.



All use-case scenarios (and corresponding use-case diagrams) should be organized
into categories.
The review leader reads the use-case deliberately.


As the review leader comes to a named object, she passes a token to the person holding the
corresponding class index card.
When the token is passed, the holder of the class card is asked to describe the
responsibilities noted on the card.


Cards that collaborate should be separated (i.e., no reviewer should have two cards that
collaborate).
The group determines whether one (or more) of the responsibilities satisfies the use-case
requirement.
If the responsibilities and collaborations noted on the index cards cannot
accommodate the use-case, modifications are made to the cards.

This may include the definition of new classes (and corresponding CRC index cards) or the
specification of new or revised responsibilities or collaborations on existing cards.
23
8.8 Behavioral Modeling

The behavioral model indicates how software will respond to
external events or stimuli. To create the model, the analyst must
perform the following steps:





Evaluate all use-cases to fully understand the sequence of interaction within
the system.
Identify events that drive the interaction sequence and understand how
these events relate to specific objects.
Create a sequence for each use-case.
Build a state diagram for the system.
Review the behavioral model to verify accuracy and consistency.
24
Behavioral Modeling


make a list of the different states of a
system (How does the system behave?)
indicate how the system makes a transition
from one state to another (How does the
system change state?)



indicate event
indicate action
draw a state diagram or a sequence
diagram
25
State Diagram for the ControlPanel Class
t imer < lockedTime
t imer > lockedTime
locked
password = incorrect
& numberOfTries < maxTries
comparing
reading
numberOfTries > maxTries
key hit
password
ent ered
do: validat ePassw ord
password = correct
select ing
act iv at ion successf ul
26
Sequence Diagram
co n t ro l p an el
h o meo w n er
syst em
read y
A
sen
senso
sors
rs
syst em
read in g
p assw o rd en t ered
req u est lo o ku p
co mp arin g
resu lt
password = correct
req u est act ivat io n
num berOf Tries > m axTries
lo cked
A
t imer > lo cked Time
select in g
act ivat io n su ccessfu l
Figure 8 .2 7 Sequence diagram (part ial) f or
act ivat io n su ccessfu l
Saf eHome securit y f unct ion
27