Department of Computer Science
University of Toronto
Structured Analysis
Lecture 15:
Structured Modeling Methods
➜
➜
Definition
Structured Analysis is a data-oriented approach to conceptual modeling
Basics of Structured Analysis
Common feature is the centrality of the dataflow diagram
Notations used
Mainly used for information systems
variants have been adapted for real-time systems
Modeling Process
➜
Department of Computer Science
University of Toronto
Modeling process:
Variants
SADT
Abstract
(essential functions)
SASS
2. Current
logical system
3. New logical
system
1. Current
physical system
4. New
physical system
SSADM
SRD
➜
Concrete
(detailed model)
Advantages and Disadvantages
optative
(new system)
indicative
(existing system)
Model of current physical system only useful as basis for the logical model
Distinction between indicative and optative models is very important:
Must understand which requirements are needed to continue current functionality,
and which are new with the updated system
© 2001, Steve Easterbrook
1
© 2001, Steve Easterbrook
Department of Computer Science
University of Toronto
Modeling tools
Source: Adapted from Svoboda, 1990, p257
➜
Process (data transformation)
➜
An activity outside the target system
related by dataflows to other
processes, data store, and external
entities.
Acts as source or destination for
dataflows that cross the system
boundary
➜
a place where data is held for later
use
Data stores are passive: no
transformations are performed on
the data
whole system as a single process
intermediate level DFDs decompose each process
functional primitives are processes that cannot be decomposed further
➜
Data group
➜
Use of BNF to define structure of data groups
➜
Data element
Primitive Process Specification
Each functional primitive has a “mini-spec”
these define its essential procedural steps
a basic unit of data
Expressed in English narrative, or some form of pseudo-code
➜
© 2001, Steve Easterbrook
Data dictionary
Defines each data element and data group
Consists of lower level data groups,
or individual elements
Data store
Data flow diagram
Context diagram (“Level 0”)
A cluster of data represented as a
single dataflow
represent a data group or data
element
➜
➜
External entities cannot interact
directly with data stores
Data flow
indicate passage of data from output
of one entitie to input of another
Source: Adapted from Svoboda, 1990, p258-263
External entity
activities that transform data
Department of Computer Science
University of Toronto
Central Concepts
➜
2
3
Structured Walkthrough
© 2001, Steve Easterbrook
4
Department of Computer Science
University of Toronto
Hierarchies of DFDs
Level 0: Context Diagram
ticket
system
booking
confirmation
booking
system
tickets
customer
query
Data Dictionary & Process Specs
Source: Adapted from Svoboda, 1990, p262-4
Level 1: Whole System
customer
customer
booking
request
Level 2: subprocesses
Level n: subprocesses
Level n: subprocesses
Example
Example Data
Data Dictionary
Dictionary
customer
query
Mailing
Mailing Label
Label ==
customer_name
customer_name ++
customer_address
customer_address
1.
travel
Timetables
determine request
2.
form of
check
schedule
travel
schedule
proposed
itinerary
proposed
3.
reserve
seats
booking
request
3.1
seating prefs
request 3.1
booking booking
Proposed
reser-request
booking system
request
3.1
preferences
itinerary
vations res.
booking request
booking
request
preferences
Req
id.
request
request
res.
Request id.
Request id. booking
Request
Reqid.
id.
booking
3.3. Request id.system
issue
booking
system
3.2.3.2.
collate
tickets
confirm
system
3.2.
log
3.3.
booked booking
seat confirmbooking
3.3. confirmation
track
booking
ations
itinerary log timestamps
data
track
timestamps
booking
confirmation
confirmation
itinerary
booked
itinerary
check
schedule
4.
issue
tickets
tickets
booking
confirmation
customer
local_address
local_address ==
house_number
house_number ++ street_name
street_name ++
(apt_number)
(apt_number)
community
community address
address ==
city_name
city_name ++ [state_name
[state_name ||
province_name]
province_name]
5
Department of Computer Science
University of Toronto
Developed by Ken Orr in the mid-70’s
Introduces the idea of building separate models for
each perspective and then merging them
© 2001, Steve Easterbrook
6
Department of Computer Science
Source: Adapted from Davis, 1990, p83-86
Control
data
1. Study current environment
Incoming Activity
data
draw DFD to show how data flows through current organization
label bubbles with names of organizational units or individuals
Transformed
data
2. Derive logical equivalents
Performing
mechanism
replace names with action verbs
merge bubbles that show the same logical function
delete bubbles that don’t transform data
Developed by Yourdon and DeMarco in the mid-70’s
‘classic’ structured analysis
Structured Requirements Definition (SRD)
TO
TO OBTAIN
OBTAIN total-this-invoice
total-this-invoice
PRINT
PRINT invoice
invoice
SASS methodology
Structured Analysis and Design Technique (SADT)
Developed by Gane and Sarson
Notational style slightly different from Yourdon &
DeMarco
Adds data access diagrams to describe contents of
data stores
TO
TO OBTAIN
OBTAIN total-this-order
total-this-order
CALCULATE
CALCULATE shipping-and-handling
shipping-and-handling
ADD
ADD shipping-and-handling
shipping-and-handling TO
TO
total-this-order
total-this-order
University of Toronto
Source: Adapted from Svoboda, 1990, p264-5
Structured System Analysis (SSA)
MULTIPLY
MULTIPLY retail-price
retail-price by
by
quantity-shipped
quantity-shipped
© 2001, Steve Easterbrook
DFD variants
Structured Analysis and System Specification
(SASS)
FOR
FOR EACH
EACH part-shipped
part-shipped
GET
GET retail-price
retail-price
customer_address
customer_address ==
local_address
local_address ++
community_address
community_address ++ zip_code
zip_code
fares
Example
Example Mini-Spec
Mini-Spec
FOR
FOR EACH
EACH Shipped-order-detail
Shipped-order-detail
GET
GET customer-name
customer-name ++ customercustomeraddress
address
customer_name
customer_name ==
customer_last_name
customer_last_name ++
customer_first_name
customer_first_name ++
customer_middle_initial
customer_middle_initial
Fare tables
© 2001, Steve Easterbrook
Developed by Doug Ross in the mid-70’s
Uses activity diagrams rather than dataflow
diagrams
Distinguishes control data from processing data
Department of Computer Science
University of Toronto
3. Model new logical system
Name
Modify current logical DFD to show how info will flow once new system is
in place
Don’t distinguish (yet) which components will be automated
ID
Name
4. Define a number of automation alternatives
document each as a physical DFD
Analyze each with cost/benefit trade-off
Select one for implementation
Write the specification
ID
Name
ID Name
7
© 2001, Steve Easterbrook
8
Department of Computer Science
University of Toronto
Department of Computer Science
University of Toronto
Later developments
Alternative Process Model: SRD
Source: Adapted from Davis, 1990, p72-75
1. Define a user-level DFD
➜
Later work recognized that:
interview each relevant individual in the current organization
development of both current physical and current logical models is overkill
Identify the inputs and outputs for that individual
Draw an ‘entity diagram’ showing these inputs and outputs
entity-relationship diagrams are useful for capturing complex data
top down development doesn’t always work well for complex systems
actually a role, rather than an individual
➜
2. Define a combined user-level DFD
Structured Analysis / Real Time (SA/RT)
Developed by Ward and Mellor in the mid-80’s
Merge all alike bubbles to create a single diagram
Resolve inconsistencies between perspective
Extends structured analysis for real-time systems
Adds control flow, state diagrams, and entity-relationship models
3. Define the application-level DFD
➜
Draw the system boundary on the combined user-level DFD
Then collapse everything within the boundary into a single process
Modern Structured Analysis
Captured by Yourdon in his 1989 book
Uses two models: the environmental model and the behavioral model
together these comprise the essential model
4. Define the application-level functions
Includes plenty of advice culled from many years experience with structured
analysis
label the inputs and outputs to show the order of processing for each
function
I.e. for function A, label the flows that take part in A as A1, A2, A3,...
© 2001, Steve Easterbrook
9
© 2001, Steve Easterbrook
Department of Computer Science
University of Toronto
Evaluation of SA techniques
Source: Adapted from Svoboda, 1990, p269
Line
status
Line
tension
Report
line
status
Enable
Disable
Control
line
conditions
Tension off
Tension ok
Enable
Disable
3.2
Source: Adapted from Davis, 1990, p174
Line
tension
Enable
➜
material
inlet
3.3
Enable
Disable
Current
tension
Controlling
tension
3.4
3.5
Tension settings table
© 2001, Steve Easterbrook
Notations are easy to learn, and don’t require software expertise
KEY
name
ID
Clear definition of system boundary
Control
Transformation
Use of abstraction and partitioning
Automated tool support
e.g. CASE tools provide automated consistency checking
Control flow
(discrete)
Inlet
control
Monitor
Tension
Advantages
Facilitate communication.
Disable
3.1
Department of Computer Science
University of Toronto
Real-time extensions
Current
gauge
10
name
➜
Disadvantages
Control flow
(continuous)
Little use of projection
Control
Store
Confusion between modeling the problem and modeling the solution
even SRD’s ‘perspectives’ are not really projection
most of these techniques arose as design techniques
These approaches model the system, but not its application domain
Tension
inlet control
Timing & control issues are completely invisible
Although extensions such as Ward-Mellor attempt to address this
11
© 2001, Steve Easterbrook
12
Department of Computer Science
University of Toronto
References
van Vliet, H. “Software Engineering: Principles and Practice (2nd
Edition)” Wiley, 1999.
In common with many authors, van Vliet does not separate structured analysis
from structured design. This makes sense because the two are intended to be
used together. Section 11.2.2 gives a nice overview of the whole process,
based on Yourdon’s notations (SASS & descendents). He also gives a good
introduction to SADT in section Section 9.3.3.
Svoboda, C. P. “Structured Analysis”. In Thayer, R. H and
Dorfman, M. (eds.) “Software Requirements Engineering, Second
Edition”. IEEE Computer Society Press, 1997, p255-274
Excellent overview of the history of structured analysis, and a comparison of
the variants
Davis, A. M. “Software Requirements: Analysis and Specification”.
Prentice-Hall, 1990.
This is probably the best textbook around on requirements analysis, although
is a little dated now.
© 2001, Steve Easterbrook
13