Transcript Document

Computing and SE II
Chapter 5: Requirements Analysis
Er-Yu Ding
Software Institute, NJU
Main Contents
1. Models of Requirement Analysis
2. Structural Analysis: Entity-Relationship
Diagram
3. Structural Analysis: Data Flow Diagram
4. Structural Analysis: State Transition
Diagram
5. Object-Oriented Analysis: Use Case
Diagram
6. Object-Oriented Analysis: Class Diagram
7. Object-Oriented Analysis: Behavioral
Diagram
8. Object-Oriented Analysis: CRC Card
1. Models of Requirement Analysis
——Requirements analysis
Outcome of Analysis
现实世界
用
户
模
型
Analysis
计算世界
分
析
模
型
计
算
模
型
1. Models of Requirement Analysis
—— The Analysis Model
The analysis model consists of a wide variety of diagrammatic
forms used to bridge an important gap.
System
Description
Design
Model
Analysis
Model



System information
System function
System behaviors
Purpose:
• Describe what the customer wants built
• Establish the foundation for the software design
• Provide a set of validation requirements
1. Models of Requirement Analysis
—— Model
• What is a model?
– a model is a simplification of reality
• Why do we model?
– we build models so that we can better understand the
system we are developing
– we build models of complex systems because we cannot
comprehend such a system in its entirety
– four aims to achieve
•
•
•
•
help us to visualize a system
permit us to specify the structure/behavior of a system
give us a template that guides us in constructing systems
document the decisions we have made
1. Models of Requirement Analysis
—— Software Model
• A model is an abstract representation of a
system that enables us to answer questions
about the system.
– When we represent it with real world language,
it’s user model
– When we represent it with computing world
language, it’s design model
– When we represent it with codes, it’s program
model
– When we represent it with a neutral, formal
language, it’s analysis model
–…
1. Models of Requirement Analysis
—— How to represent software
• Describes necessary
and complete
model?
knowledge
– Stakeholders can get what they want
• Decision makers
• Users ,clients…
• Developers
–
–
–
–
Analyst
Designer
Programmer
Integrator
– Developers can develop software according to
software model
• Data, behavior, business rules…
View
...
Viewpoint
content
Perspective
Software
Model
con
ent t
……
Perspective
...
Viewpoint
1. Models of Requirement Analysis
—— Model and View
• Model, views, viewpoints, and
stakeholders
– A model is a simplification of reality,
created in order to better understand the
system being created; a semantically
closed abstraction of a system
– A stakeholder is an individual, team, or
organization (or classes thereof) with
interests in, or viewpoints relative to, a
system
– A content type is an kind of information
•
1. Models of Requirement Analysis
—— Viewpoints, perspectives
Viewpoint is defined asand
a standing
position used by
views
an individual when examining a universe of discourse
(Stakeholders Roles)
• A perspective is defined as a set of facts observed and
modelled according to a particular aspect of reality
(Certain type content observed from some viewpoint)
• A view is defined as an integration of related
perspectives, usually using two kinds of methods
– According to viewpoint (all perspectives observed by some
stakeholders role on different content types)
– According to content type (all perspectives observed by
different stakeholders on some content types)
1. Models of Requirement Analysis
—— Describing Perspectives
• A perspective language is used to
represent the observed information of
the perspectives
– Text, Diagram (semi-formal language),
Formal Language…
• The language defines the set of units
and their associations that can be used
to describe perspectives
• Languages N:M perspectives
• There is no semi-formal or formal
language can describe all kinds of
• UML
1. Models of Requirement Analysis
—— Common Perspectives Languages
– Object diagram
• Classification model
– Behavioral diagram
– OCL
– Use case diagram
• Entity-Relationship Diagram
– Composition( semantic data)
model
• Process Model (DFD)
– Data processing model
• State Machine Model
– Stimulus/response model






Fact Model
Entity-event model
Object Role Model
Organization model
Petri Nets
……
1. Models of Requirement Analysis
—— Analysis Model – Structural
Function
Data Object
description
ERD
Data
DFD
Process
specification
(PSPEC)
Data dictionary
STD
Behavior
Control Specification (CSPEC)
1. Models of Requirement Analysis
—— OO Analysis Model - UML
Function
Class diagram
Object diagram
Use case diagram
Activity diagram
Data
Object
Behavior
State-chart diagram
Interaction diagram




2. Structural Analysis: EntityRelationship Diagram
——independently
Data Modeling
Examines data objects
of processing
Focuses attention on the data domain
Creates a model at the customer’s level of abstraction
Indicates how data objects relate to one another
Automobile
Person
Make
Model
Body type
Price
Color
Birthday
Height
Weight
Expertise
2. Structural Analysis: Entity-Relationship
Diagram
—— What is a Data Object?
Object —something that is described by a set
of attributes (data items) and that will be
manipulated within the software (system)
each instance of an object (e.g., a book)
can be identified uniquely (e.g., ISBN #)
each plays a necessary role in the system
i.e., the system could not function without
access to instances of the object
each is described by attributes that are
themselves data items
2. Structural Analysis: Entity-Relationship
Diagram
—— Typical
Objects
external entities (printer, user, sensor)
things (e.g, reports, displays, signals)
occurrences or events (e.g., interrupt, alarm)
roles (e.g., manager, engineer, salesperson)
(e.g., division, team)
organizational units
places (e.g., manufacturing floor)
structures (e.g., employee record)
Automobile
Person
2. Structural Analysis: Entity-Relationship
Diagram
—— Data Objects and Attributes
A data object contains a set of attributes that act as
an aspect, quality, characteristic, or descriptor of
the object
Automobile
Person
Make
Model
Body type
Price
Color
Birthday
Height
Weight
Expertise
2. Structural Analysis: EntityRelationship Diagram
——Relationship
 Connectedness

A fact that must be remembered by the system and cannot or is not
computed or derived
 Several instance of a relationship can exist
 Entity can be related in many ways
own
2. Structural Analysis: EntityRelationship Diagram
——Cardinality and Multiplicity
own
Automobile
Person
own
Make
Model
Body type
Price
Color
Birthday
Height
Weight
Expertise
2. Structural Analysis: Entity-Relationship
Diagram
—— ERD Notation
One common form:
object1
(0, m)
relationship
(1, 1)
object 2
attribute
Another common form:
relationship
object1
(0, m)
object 2
(1, 1)
attribute
2. Structural Analysis: Entity-Relationship
Diagram
—— The ERD: An Example
Customer
(1,1)
places
(1,m)
request
for service
(1,1)
standard
task table
generates
(1,1)
selected
from
(1,n)
work
order
(1,1)
work
(1,w) tasks
materials
(1,w)
(1,i)
consists
of
lists
(1,1)
2. Structural Analysis: Entity-Relationship
Diagram
—— Building an ERD
• Level 1—model all data objects
(entities) and their “connections” to
one another
• Level 2—model all entities and
relationships
• Level 3—model all entities,
relationships, and the attributes that
provide further depth
2. Structural Analysis: EntityRelationship Diagram
——ERD- Let’s try it
• 为选课系统建立ERD描述
3. Structural Analysis: Data Flow
Diagram
——Flow
Oriented
Model
• Represents
how
data objects
are
transformed at they move through the
system
• A data flow diagram (DFD) is the
diagrammatic form that is used
• 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
3. Structural Analysis: Data Flow
Diagram
—— The Flow Model
Every computer-based system is an
information transform ....
input
computer
based
system
output
3. Structural Analysis: Data Flow
Diagram
—— Flow Modeling Notation
external entity
process
data flow
data store
3. Structural Analysis: Data Flow
Diagram
—— External Entity
A producer or consumer of data
Examples: a person, a device, a sensor
Another example: computer-based
system
Data must always originate somewhere
and must always be sent to something
3. Structural Analysis: Data Flow
Diagram
—— Process
A data transformer (changes input
to output)
Examples: compute taxes, determine area,
format report, display graph
Data must always be processed in some
way to achieve system function
3. Structural Analysis: Data Flow
Diagram
—— Data Flow
Data flows through a system, beginning
as input and be transformed into output.
base
height
compute
triangle
area
area
3. Structural Analysis: Data Flow Diagram
——
Data Stores
Data is often stored for later use.
sensor #
report required
look-up
sensor
data
sensor number
sensor #, type,
location, age
type,
location, age
sensor data
3. Structural Analysis: Data Flow
Diagram
• all icons must
labeled
with
meaningful
—— be
Data
Flow
Diagramming
•
•
•
•
•
names
the DFD evolves through a number of levels of
detail
always begin with a context level diagram (also
called level 0)
always show external entities at level 0
always label data flow arrows
do not represent procedural logic
3. Structural Analysis: Data Flow
Diagram
——Level 0 (Context Diagram)
user
processing
request
digital
video
processor
video
source
NTSC
video signal
requested
video
signal
monitor
3. Structural Analysis: Data Flow
Diagram
—— Constructing
a DFD—I
• review the descriptions and use a
grammatical parse to determine
“operations”
• determine external entities
(producers and consumers of data)
• create a level 0 DFD
3. Structural Analysis: Data Flow Diagram
—— Constructing
a DFD—Refine
Process
• write a narrative describing the
transform
• parse to determine next level
transforms
• “balance” the flow to maintain
data flow continuity
• develop a level 1 DFD
3. Structural Analysis: Data Flow
Diagram
x
a
a——
c
Level
1
b
P
y
p2
f
p1
d
level 1
p4
p3
level 0
e
g
5
b
3. Structural Analysis: Data Flow
Diagram
• ——
Each Flow
bubbleModeling
is refined untilNotes
it
does just one thing
• The expansion ratio decreases as
the number of levels increase
• Most systems require between 3
and 7 levels for an adequate flow
model
3. Structural Analysis: Data Flow
Diagram
——
Using
PSPEC
• Process Specification (PSPEC) can be used to specify the
processing details implied by a process within a DFD
bubble
PSPEC
narrative
pseudocode (PDL)
equations
tables
diagrams and/or charts
3. Structural Analysis: Data Flow
Diagram
Check &
—— Using
convert
PSPEC
pressure
PSPEC
If absolute tank pressure > max pressure
then
set above pressure to “true”;
else
set above pressure to “false”;
begin conversion algorithm x-01a;
compute converted pressure;
end
end if
3. Structural Analysis: Data Flow
Diagram
—— Mapping
analysis model
to design model
Maps into
design model
3. Structural Analysis: Data Flow
Diagram
—— DFD- Let’s try it
• 用DFD描述ATM机的功能
4. Structural Analysis: State
•
Transition Diagram
——Behavioral
modeling
The behavioral
model indicates
how
software will respond to external events or
stimuli. events
behavior
Outside
world
Application
How do I model the software's reaction to some
external event?
4. Structural Analysis: State Transition
Diagram
——
• State:
Basic concept
– a set of observable circum-stances that
characterizes the behavior of a system at a
given time
• State transition:
– the movement from one state to another
• Event:
– an occurrence that causes the system to
exhibit some predictable form of behavior
• Action:
– process that occurs as a consequence of
making a transition
4. Structural Analysis: State
Transition Diagram
——
1. Make a list of
the State
differentModeling
states of a system
(How does the system behave?)
2. Indicate how the system makes a transition
from one state to another (How does the
system change state?)
1. indicate event
2. indicate action
3. Draw a state transition diagram
4. Structural Analysis: State
Transition Diagram
——Notation
and
Example
button2Pressed
Event
Initial state
button1&2Pressed
Increment
Hours
Blink
Hours
button1Pressed
Transition
button1&2Pressed
State
Blink
Minutes
button2Pressed
Increment
Minutes
button1Pressed
Blink
Seconds
Stop
Blinking
button1&2Pressed
Final state
button2Pressed
Increment
Seconds
4. Structural Analysis: State Transition
Diagram
——
You are designing
a traffic light
system for this
intersection.
State DiagramNorth
- Lets Try It!
West
Draw a state
diagram showing
the different
states and how
they transition.
East
South
5. Object-Oriented Analysis: Use
Case Diagram
“[Use-cases] are simply an aid to defining what
——theUse-Cases
exists outside
system (actors) and what
should be performed by the system (use-cases).”
Key Points:
–Ivar Jacobson
• A scenario that describes a thread of usage for
achieving a functional requirement
• Actors represent roles people, devices, or external
systems play
• System internals are ignored
Example:
See Pressman Chapter 8, Section 8.5.1
•
5. Object-Oriented Analysis: Use
Case Diagram
A descriptive name for the scenario
——
The
Key
Elements
of a Use– e.g.,
“Customer
Checkout”,
“Browse
Products”
• The primary actor in the scenario
Case
– Who is interacting with the system?
• The primary actor’s goal
– What is the actor trying to accomplish?
• Scenario pre-conditions
– What assumptions are being made?
• Scenario trigger
Remember why
we’re interested in
use-cases!
– How was the scenario initiated?
• The “sunny day” scenario
– In the best case, how does the user interact with the system?
• Exceptions
– What might go wrong?
5. Object-Oriented Analysis: Use
Case Diagram
(1) What should
we write
about?
——
Developing
a Use-Case
(2) How much should we write about it?
(3) How detailed should we make our description?
(4) How should we organize the description?
• What are the main tasks or functions that are performed by the
actor?
• What system information will the actor acquire, produce or
change?
• Will the actor have to inform the system about changes in the
external environment?
• Does the actor wish to be informed about unexpected changes?
• …
5. Object-Oriented Analysis: Use
Case Diagram
——Use
Case Diagram - Let’s Try It
The Online
Bookstore
The Online Bookstore System (OBS) will be a web-based
application that allows customers to browse and purchase
online product offerings. The application will support the notion
of an online shopping cart, similar to other online retailers such
as Amazon.com. The checkout features of the system will be
integrated with our credit card transaction processor, as well
as our internal billing system. The system will also provide an
administrator-view that will allow authorized employees to view
and administer products, customers, and orders.
1. Based on this description, what are the key use-cases?
2. Select one key use-case, describes it.
5. Object-Oriented Analysis: Use
Case Diagram
You’ll probably have a lot of use-cases!
Online Bookstore
—— Use-Case
Diagrams
System
Use case diagrams (UCD) provide a
diagrammatic table of contents, and a
high-level overview of the system.
Browse products
Add products to
shopping cart
Diagrams Show:
View shopping cart
Customer
• Actors
• Use-cases
• Relationships among
them
Credit card
transaction processor
Checkout
Billing system
Example UCD
6. Object-Oriented Analysis: Class
Diagram
——Object
• Object models
describe Models
the system in terms
of object classes
• An object class is an abstraction over a set
of objects with common attributes and the
services (operations) provided by each
object
• Key concepts:
– Classes and objects
• Attributes and operations
• Encapsulation
– Association and Link
• Inheritance
• Aggregation (Composition)
• Polymorphism
6. Object-Oriented Analysis: Class
Diagram
—— Objects
• Natural ways of reflecting the realworld entities manipulated by the
system
• Object class identification is
recognised as a difficult process
requiring a deep understanding of the
application domain
• Object classes reflecting domain
6. Object-Oriented Analysis: Class Diagram
——Attributes and operations
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
6. Object-Oriented Analysis: Class Diagram
—— Encapsulation/Hiding
The object encapsulates
both data and the logical
procedures required to
manipulate the data
method
#2
method
#1
data
method
#3
method
#6
method
#5
Achieves “information hiding”
method
#4
6. Object-Oriented Analysis: Class
Diagram
• Two analysis
classes are often
—— Associations
and related
to one another
in some fashion
Dependencies
– In UML these relationships are called
associations
– Associations can be refined by indicating
multiplicity (the term cardinality is used
in data modeling
• If there are associations between
classes, then there are links between
instances of the classes
6. Object-Oriented Analysis: Class
Diagram
—— Association
Wall
1
is used t o build
1
is used t o build
0..* is used t o build
1..*
WallSegm ent
1
Window
Door
0..*
Diagram
——Inheritance
• Organise the domain object classes
into a hierarchy
• Classes at the top of the hierarchy
reflect the common features of all
classes
• Object classes inherit their attributes
and services from one or more superclasses. these may then be specialised
as necessary
Libr ary user
User class
hierarchy
Name
Address
Phone
Registration #
Register ()
De-r egister ()
Reader
Borrower
Items on loan
Max. loans
Affiliation
Staff
Department
Department phone
Student
Major subject
Home address
6. Object-Oriented Analysis: Class Diagram
—— Object Aggregation
• Aggregation model shows how classes
which are collections are composed of
other classes
• Similar to the part-of relationship in
semantic data models
Object
Aggregation
6. Object-Oriented Analysis:
Class Diagram
——
Class-Based
• Identify
analysis
classes byModeling
examining
the problem statement
• Use a “grammatical parse” to isolate
potential classes
• Identify the attributes of each class
• Identify operations that manipulate the
attributes
6. Object-Oriented Analysis: Class Diagram
—— Identifying Analysis Classes
occurrences
roles
organizational units
things
places
external entities
structures
class name
attributes:
operations:
6. Object-Oriented Analysis: Class
Diagram
——
Class Selection
1. Retained
informationCriteria
2.
3.
4.
5.
6.
Needed services
Multiple attributes
Common attributes
Common operations
Essential
requirements
•
6. Object-Oriented Analysis: Class
Diagram
The SafeHome security function enables the homeowner to configure the
security system
when it Class
is installed, Selection
monitors all sensors connected to the
——
security system, and interacts with the homeowner through the Internet, a PC,
or a control panel.
•
During installation, the SafeHome PC is used to program and configure the
system. Each sensor is assigned a number and type, a master password is
programmed for arming and disarming the system, and telephone number(s)
are input for dialing when a sensor event occurs.
•
When a sensor event is recognized, the software invokes an audible alarm
attached to the system. After a delay time that is specified by the homeowner
during system configuration activities, the software dials a telephone number
of a monitoring service, provides information about the location, reporting
the nature of the event that has been detected. The telephone number will be
redialed every 20 seconds until a telephone connection is obtained.
•
The homeowner receives security information via a control panel, the PC, or
a browser, collectively called an interface. The interface displays prompting
messages and system status information on the control panel, the PC, or the
browser window. Homeowner interaction takes the following form…
Potential class
6. Object-Oriented Analysis: Class
Diagram
—— Identifying Classes
Classification
Accept / Reject
homeowner
role; external entity
reject: 1, 2 fail
sensor
external entity
accept
control panel
external entity
accept
installation
occurrence
reject
(security) system
thing
accept
number, type
not objects, attributes
reject: 3 fails
master password
thing
reject: 3 fails
telephone number
thing
reject: 3 fails
sensor event
occurrence
accept
audible alarm
external entity
accept: 1 fails
monitoring service
organizational unit; ee
reject: 1, 2 fail
Retained information
Needed services
Multiple attributes
Common attributes
Common operations
Essential requirements
•
6. Object-Oriented Analysis: Class
Diagram
University——
Bank will
be opening
in Oxford,
Mississippi,
in
Let’s
Try
It.
Class
Diagram
January, 2000. We plan to use a full service automated
teller machine (ATM) system.The ATM system will interact
with the customer through a display screen, numeric and
special input keys, a bankcard reader, a deposit slot, and a
receipt printer.Customers may make deposits, withdrawals,
and balance inquires using the ATM machine, but the
update to accounts will be handled through an interface to
the Accounts system.Customers will be assigned a Personal
Identification Number (PIN) and clearance level by the
Security system. The PIN can be verified prior to any
transaction.In the future, we would also like to support
routine operations such as a change of address or phone
number using the ATM
7. Object-Oriented Analysis: Behavioral
Diagram
——Behavioral Diagram
• State Chart
– State Transition Diagram
• Interaction Diagram
– Sequence Diagram
– Communication Diagram
• Activity Diagram
7. Object-Oriented Analysis: Behavioral
Diagram
——System behaviour modelling with
• The behavioral model indicates how
States
Chart
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.
– Build a state diagram for the system.
– Review the behavioral model to verify accuracy
and consistency.
7. Object-Oriented Analysis: Behavioral
Diagram
——
Identifying Events
• A use-case is examined for points of information
exchange.
• The homeowner uses the keypad to key in a fourdigit password. The password is compared with the
valid password stored in the system. If the password
in incorrect, the control panel will beep once and
reset itself for additional input. If the password is
correct, the control panel awaits further action.
7. Object-Oriented Analysis: Behavioral
Diagram
——
State Diagram
State diagram for the ControlPanel class
7. Object-Oriented Analysis: Behavioral Diagram
—— System behaviour modelling with Sequence
Diagram
• A behavioural
model shows the
interactions between objects to
produce some particular system
behaviour that is specified as a usecase
• Sequence diagrams (or collaboration
diagrams) in the UML are used to
model interaction between objects
7. Object-Oriented Analysis: Behavioral
Diagram
: Cashier
——
: POS System
: Inventory System
Sequence Diagram
makeNewSale( )
ready
enterItem(itemID, quantity)
description, total
*[more items]
endSale( )
total
makePayment( )
change due
payment information
receipt
7. Object-Oriented Analysis: Behavioral
Diagram
——Let’s Try It!
• Give a correct version for figure 8-21.
7. Object-Oriented Analysis: Behavioral
Diagram
—— System behaviour modelling with Activity
Supplements the use-case
by providing a diagrammatic
representation of procedural
flow
ent er password
and user ID
Diagram
valid passwor ds/ ID
invalid passwor ds/ ID
select major f unct ion
prompt f or reent ry
ot her f unct ions
m ay also be
select ed
input t r ies r em ain
How might we make this
better?
select surveillance
no input
t r ies r em ain
t hum bnail views
select a specif ic cam er a
select specif ic
camera - t humbnails
select camera icon
view camera out put
in labelled window
prompt f or
anot her view
exit t his f unct ion
see anot her cam er a
7. Object-Oriented Analysis: Behavioral Diagram
—— System behaviour modelling with Activity Diagram
homeowner
c a m e ra
i n t e rf a c e
Swimlane Diagrams
ent er password
and user ID
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
valid p asswo r d s/ ID
in valid
p asswo r d s/ ID
select m ajor f unct 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
select surveillance
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
select specif ic
cam era - t hum bnails
select cam era icon
generat e video
out put
view cam era out put
in labelled window
prom pt f or
anot her view
exit t h is
f u n ct io n
see
an o t h er
cam er a
8. Object-Oriented Analysis: CRC Card
——CRC Modeling
• CRC : Class-ResponsibilityCollaborator
• Analysis classes have “responsibilities”
– Responsibilities are the attributes and
operations encapsulated by the class
• Analysis classes collaborate with one
another
– Collaborators are those classes that are
required to provide a class with the
information needed to complete a
responsibility.
8. Object-Oriented Analysis: CRC
Card
——CRC Card
对象的描述
候选对象
对象维护的状态
候选对象
（背面）
协作者
对象执行的行为
（正面）
9. Writing the Software
Specification
Everyone knew exactly
what had to be done
until someone wrote it
down!
The End
• Next Lecture
– Software Design
Reviews
• 为选课系统建立ERD描述
• 用DFD描述ATM机的功能
• 用STD描述十字路口红绿灯
A First Level DFD
ATM card no
System
clock
Customer
Requested
PIN
prompts
1.0
Verify
Customer
ID
service
transaction
2.0
Initial
Transaction
3.0
Process
Transaction
4.0
Perform
accounting
Database
Lost-stolen_list
Printer
Back
State Diagrams
(Traffic light example)
Traffic Light
State
Transition
Red
Yellow
Green
Event
Start
Back
Back