CSE3308 - Software Engineering: Analysis and Design, 2005 Lecture 4A.

1
Software Engineering: Analysis and
Design - CSE3308
Structured Analysis - Part 1
CSE3308/DMS/2005/10

Monash University - School of Computer
Science and Software Engineering
CSE3308 - Software Engineering: Analysis and Design, 2005 Lecture 4A.2
Lecture Outline
History of Structured Analysis
Context Diagrams
Event Lists
Data Flow Diagrams
Control Flows and Processes
Levelled Data Flow Diagrams
CSE3308 - Software Engineering: Analysis and Design, 2005 Lecture 4A.3
History of Structured Analysis (SA)
First texts appeared in 1977
Tom de Marco - Structured Analysis and System Specification
Gane and Sarson - Structured Systems Analysis
1984 - SA is extended
McMenamin and Palmer - Essential Structured Analysis
1989 - SA reaches its peak
Yourdon publishes Modern Structured Analysis
Integrates Chens Entity-Relationship Models
1991 Yourdon moves to Object-Oriented Analysis
1995 38% of organisations used SA
Since much if not most expenditure of software organizations is
on maintenance, there is still a lot of work being done on systems
produced using SA, and coded in languages such as Fortran, COBOL
and C
CSE3308 - Software Engineering: Analysis and Design, 2005 Lecture 4A.4
Context Diagrams
Indicate the people, organisations and
systems which communicate with our system
Show the data which our system receives
from the outside world
Show the data produced by the system and
sent to the outside world
Show the data which is shared by the system
with the outside world
Show the boundary between the system and
the rest of the world
CSE3308 - Software Engineering: Analysis and Design, 2005 Lecture 4A.5
( or )
Constructing a Context Diagram
Four components
The System



Terminators
also know as external entities



Data Flows



Data Stores
Students
Student
Enrolment
System
Student
student-id
Students
CSE3308 - Software Engineering: Analysis and Design, 2005 Lecture 4A.6
CD for Student Enrolment System
Student
Staff Member
personal-details,
course-code
student-id
subject-code
password,
subject-code
student-list
student-id,mark
password,subject-code
subject-name,year,
core-flag,prerequisites
student-id
staff-id
Administrator
SubjectsInCourses
SubjectDataForStudent
Students
StudentsInCourses
Prerequisites
Subjects
Finance System
student-id
fees-paid
Student Enrolment
System
CSE3308 - Software Engineering: Analysis and Design, 2005 Lecture 4A.7
Guidelines for Context Diagrams
Use appropriate names
Dont be too specific with names
Student
Fred
Flintstone
Yes No
Student
Student
Enrolment
System
Ready to send input
Okay, send input
Heres the input
Great, I got the input
CSE3308 - Software Engineering: Analysis and Design, 2005 Lecture 4A.8
Guidelines (2)
Can have Dialogue Flows representing two-
way data flow
Student
Enrolment
System
Finance
System
Check fees paid
fees check
response
Duplicate terminators if necessary to simplify
the diagram
CSE3308 - Software Engineering: Analysis and Design, 2005 Lecture 4A.9
Event Lists
List of the external events that occur in the
outside world which affect the system, i.e.
events generated by terminators
Events can be
Flow - some data flows between the external world and
the system
Temporal - an event occurs as a result of some timing
Control - special case of a temporal event, an external
stimulus that occurs at some unpredictable point in time
Events are always viewed from the
terminators point of view
CSE3308 - Software Engineering: Analysis and Design, 2005 Lecture 4A.10
Event examples
Student enrolls in subject (Flow)
Administrator creates subject (Flow)
Administrator receives student transcript
(Flow)
Subject creation is disabled because
semester starts in one month (Temporal)

There is no control event in this list since they are
unusual in business systems. They are, however,
common in real-time systems (see slide 4A.23)
CSE3308 - Software Engineering: Analysis and Design, 2005 Lecture 4A.11
Constructing the Event List
Examine each terminator, and ask what effects the
terminators actions can have on the system
Take care to distinguish between separate events
coincidently packaged together in the requirements
specification
Event Customer places order might in fact be both Customer
places order and Salesperson places customer order
Clue could be different data present in the two cases
Need to allow for failure conditions on the part of the
terminator, but no need to allow for system failures
CSE3308 - Software Engineering: Analysis and Design, 2005 Lecture 4A.12
Events
Look at a system which controls the sales of
goods at a supermarket
Entities to think about
Cash register
Checkout Operator
Customer
Scanner
Receipt printer
What events can you identify?

CSE3308 - Software Engineering: Analysis and Design, 2005 Lecture 4A.13
Your answer?
CSE3308 - Software Engineering: Analysis and Design, 2005 Lecture 4A.14
Data Flow Diagrams
Extends the Context Diagram by defining the
processes which make up a system
4 components
Processes
A process is a part of the system that transforms
inputs to outputs. It has:
Number - identifies process and indicates place in DFD level
hierarchy
Name - what the process does

Data Flows
Data Stores
Terminators
as in Context Diagram
}
CSE3308 - Software Engineering: Analysis and Design, 2005 Lecture 4A.15
Indicate movement of packets of information
from one part of the system to another part
Flows are named
Input flow

Output flow

Diverging flows - see next slide
Data Flows
Validate
Phone
No.
Phone No.
Generate
Flight
Schedule
Flight Schedule
Information
CSE3308 - Software Engineering: Analysis and Design, 2005 Lecture 4A.16
Diverging Data Flows
Validate
postcode
Validate
phone
no.
Validate
street
address
personal-details
postcode
phone no.
street
address
Produce
Valid
Order
Generate
Invoice
Update
Inventory
Generate
Shipping
Docs
Order
Invalid
orders
Order details
CSE3308 - Software Engineering: Analysis and Design, 2005 Lecture 4A.17
Typical Figure 0 DFD
Note:
some analysts do not
show terminators on the
Figure 0 DFD
Student
Staff Member
6. Assign
staff
member to
subject
2. Enrol
student in
subject
1. Enrol
student at
University
4. Create
new
subject
3. Record
mark for
student
5. Print
student
transcript
personal-details,
course-code
student-id
student-id, subject-code
student-id,subject-code
password,
subject-code
student-list
student-id, mark
password, subject-code
subject-name, course-code, year,
core-flag, prerequisites
password, student-id
password, subject-code
staff-id
Administrator
Students
SubjectsInCourses
SubjectDataForSt
udent
Students
StudentsInCourses
Prerequisites
Subjects
Finance System
student-id
fees-paid
StudentsInCourses
student-transcript
SubjectsInCourses
Note: some flows may be physical, such as the student-transcript
CSE3308 - Software Engineering: Analysis and Design, 2005 Lecture 4A.18
An example
For the checkout operator example
What are the terminators?
What are the main processes?
What are the main data flows?
Draw a data flow diagram to put the above
elements together
CSE3308 - Software Engineering: Analysis and Design, 2005 Lecture 4A.19
Your elements
CSE3308 - Software Engineering: Analysis and Design, 2005 Lecture 4A.20
Your DFD
CSE3308 - Software Engineering: Analysis and Design, 2005 Lecture 4A.21
Guidelines for constructing DFDs
Choose meaningful names
Number the processes
Redraw the DFD as many times as necessary
for aesthetics
Avoid overly complex DFDs
Fit on one A4 page
approximately 6-7 processes and related data stores and
terminators
CSE3308 - Software Engineering: Analysis and Design, 2005 Lecture 4A.22
Guidelines (2)
Make sure the DFD is internally consistent
and consistent with any associated DFDs
Avoid infinite sinks - processes with inputs but no
outputs
Avoid spontaneous generation processes - processes
with outputs but no inputs (possible exception is a
random number generator)
Beware of unlabelled flows and processes
Beware read-only/write-only stores
Make sure that incoming and outgoing flows from the
DFD match those on the DFD at the level above
CSE3308 - Software Engineering: Analysis and Design, 2005 Lecture 4A.23
Control Flows and Processes
Real-time systems need a means to model
control (signals/interrupts)
Shown with dashed lines and circles
A control flow can be regarded as a binary
signal - does not carry value-bearing data
Used to trigger/wake-up a dormant process
Internal behaviour of a control process
described by a state-transition diagram
Generally one control process in a DFD
inputs and outputs of control process consist
only of control flows
CSE3308 - Software Engineering: Analysis and Design, 2005 Lecture 4A.24
Example
Control
Surveillance
System
Process
Radar
Data
Process
Satellite
Data
Surveillance data
radar data
satellite data
enable satellite
processing
enable radar
processing
satellite signal
radar signal
CSE3308 - Software Engineering: Analysis and Design, 2005 Lecture 4A.25
Action Game Example
Administer
Game
Play Game
Game Details
Control
Game
start
administrating
start playing
enter
administration
mode
enter play
mode
CSE3308 - Software Engineering: Analysis and Design, 2005 Lecture 4A.26
Levelled DFDs
Most systems are far too complex to depict
on one DFD
CSE3308 - Software Engineering: Analysis and Design, 2005 Lecture 4A.27
Levelled DFDs (2)
Break each process
down into sub-processes
Numbering of processes
indicates their parents
process, and thus their
position in the hierarchy
of levelled DFDs
The
System
Terminator 1
Terminator 3
Terminator 2
Datastore 1
Context Diagram
Terminator 1
Terminator 3
Terminator 2
Datastore 1
Figure 0 DFD
1. Wiggle
Widget
3. Dangle
Doover
2. Grind
Gadget
Datastore 1
Figure 3 DFD
3.1 Create
Doover
3.3
Wangle
Doover
3.2 Mangle
Doover
CSE3308 - Software Engineering: Analysis and Design, 2005 Lecture 4A.28
Guidelines for Levelled DFDs
How many levels?
Each level should have approximately 6 processes
Simple systems: 2-3 levels
Medium size: 3-6 levels
Large size: 5-8 levels
All parts of the system may not need the
same numbers of levels
Levels must be consistent with each other
Data flows coming into and going out of a process at one
level must correspond to the data flows coming into and
out of the entire figure at the next lower level - this is
known as balancing
CSE3308 - Software Engineering: Analysis and Design, 2005 Lecture 4A.29
Balanced DFDs
Terminator 1
Terminator 3
Terminator 2
Datastore 1
B
D
Figure 0 DFD
1. Wiggle
Widget
3. Dangle
Doover
2. Grind
Gadget
E
F
H
A
G
C
C
Datastore 1
D
Figure 3 DFD
F
H
G
C
3.1 Create
Doover
3.3
Wangle
Doover
3.2 Mangle
Doover
J
K
I
Balanced DFDs
The
System
Terminator 1
Terminator 3
Terminator 2
Datastore 1
A, G
B
C
D
Context Diagram
CSE3308 - Software Engineering: Analysis and Design, 2005 Lecture 4A.30
Unbalanced DFDs
Can you see the
problems?
The
System
Terminator 1
Terminator 3
Terminator 2
Datastore 1
A, G
B
C
D
Context Diagram
Terminator 1
Terminator 3
Terminator 2
Datastore 1
B
Q
Figure 0 DFD
1. Wiggle
Widget
3. Dangle
Doover
2. Grind
Gadget
E
F
H
A
G
C
Z
Datastore 1
Figure 3 DFD
F
H
G
C
3.1 Create
Doover
3.3
Wangle
Doover
3.2 Mangle
Doover
J
K
I
X
C
W
CSE3308 - Software Engineering: Analysis and Design, 2005 Lecture 4A.31
Data Stores and Levelled DFDs
Terminator 1
Terminator 3
Terminator 2
Datastore 1
B
D
Figure 0 DFD
1. Wiggle
Widget
3. Dangle
Doover
2. Grind
Gadget
E
F
H
A
G
C
C
Datastore 1
D
Figure 3 DFD
F
H
G
C
3.1 Create
Doover
3.3 Wangle
Doover
3.2 Mangle
Doover
J
K
I
Show datastores at
every level at which
they are used
The System
Terminator 1
Terminator 3
Terminator 2
Datastore 1
A, G
B
C
D
Context Diagram
CSE3308 - Software Engineering: Analysis and Design, 2005 Lecture 4A.32
References
Yourdon, E., Modern Structured Analysis,
Prentice Hall, 1989.
There is now a condensed edition, called J ust Enough
Structured Analysis, available online via the Resources
page on the unit web site.