CSE3308/DMS/2004/12
Monash University - School of Computer
Science and Software Engineering
Software Engineering: Analysis and
Design - CSE3308
Structured Analysis - Part 1
CSE3308 - Software Engineering: Analysis and Design, 2004
Lecture 4A.1
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, 2004
Lecture 4A.2
History of Structured Analysis (SA)

First texts appeared in 1977



1984 - SA is extended




McMenamin and Palmer - Essential Structured Analysis
1989 - SA reaches its peak


Tom de Marco - Structured Analysis and System Specification
Gane and Sarson - Structured Systems Analysis
Yourdon publishes Modern Structured Analysis
Integrates Chen’s 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, 2004
Lecture 4A.3
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, 2004
Lecture 4A.4
Constructing a Context Diagram

Four components
 The System
Student
Enrolment
System
 Terminators
»
also know as external entities
 Data Flows
 Data Stores
Student
student-id
Students
CSE3308 - Software Engineering: Analysis and Design, 2004
( or
Students
Lecture 4A.5
)
CD for Student Enrolment System
SubjectDataForStudent
Student
personal-details,
course-code
student-id
subject-code
SubjectsInCourses
Prerequisites
password,
subject-code
student-list
Student Enrolment
System
Subjects
Staff Member
student-id,mark
Students
staff-id
password,subject-code
subject-name,year,
core-flag,prerequisites
student-id
fees-paid
student-id
Finance System
Administrator
StudentsInCourses
CSE3308 - Software Engineering: Analysis and Design, 2004
Lecture 4A.6
Guidelines for Context Diagrams
Yes
 Use
appropriate names
 Don’t
Student
No
Fred
Flintstone
be too specific with names
Ready to send input
Okay, send input
Student
Here’s the input
Student
Enrolment
System
Great, I got the input
CSE3308 - Software Engineering: Analysis and Design, 2004
Lecture 4A.7
Guidelines (2)
 Can
have Dialogue Flows representing twoway data flow
Check fees paid
Finance
System
fees check
response
Student
Enrolment
System
Duplicate terminators if necessary to simplify
the diagram

CSE3308 - Software Engineering: Analysis and Design, 2004
Lecture 4A.8
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
terminator’s point of view
CSE3308 - Software Engineering: Analysis and Design, 2004
Lecture 4A.9
Event examples
 Student
enrols 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, 2004
Lecture 4A.10
Constructing the Event List


Examine each terminator, and ask what effects the
terminator’s 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, 2004
Lecture 4A.11
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, 2004
Lecture 4A.12
Your answer?
CSE3308 - Software Engineering: Analysis and Design, 2004
Lecture 4A.13
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, 2004
Lecture 4A.14
Data Flows
 Indicate
movement of packets of information
from one part of the system to another part
 Flows are named
 Input flow
 Output flow
Phone No.
Generate
Flight
Schedule
Validate
Phone
No.
Flight Schedule
Information
 Diverging flows - see next slide
CSE3308 - Software Engineering: Analysis and Design, 2004
Lecture 4A.15
Diverging Data Flows
Order
personal-details
postcode
Validate
postcode
phone no.
street
address
Validate
street
address
Produce
Valid
Order
Invalid
orders
Generate
Shipping
Docs
Order details
Validate
phone
no.
Generate
Invoice
CSE3308 - Software Engineering: Analysis and Design, 2004
Update
Inventory
Lecture 4A.16
Typical Figure 0 DFD
personal-details,
course-code
Student
Students
1. Enrol
student at
University
student-id
Note:
some analysts do not
show terminators on the
Figure 0 DFD
student-id, subject-code
student-id,subject-code
Prerequisites
SubjectsInCourses
SubjectsInCourses
StudentsInCourses
password,
subject-code
2. Enrol
student in
subject
SubjectDataForSt
udent
4. Create
new
subject
Subjects
Staff Member
student-list
3. Record
mark for
student
student-id, mark
StudentsInCourses
subject-name, course-code, year,
core-flag, prerequisites
Students
password, subject-code
6. Assign
staff
member to
subject
password, student-id
password, subject-code
staff-id
Administrator
5. Print
student
transcript
student-id
fees-paid
Finance System
student-transcript
Note: some flows may be physical, such as the student-transcript
CSE3308 - Software Engineering: Analysis and Design, 2004
Lecture 4A.17
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, 2004
Lecture 4A.18
Your elements
CSE3308 - Software Engineering: Analysis and Design, 2004
Lecture 4A.19
Your DFD
CSE3308 - Software Engineering: Analysis and Design, 2004
Lecture 4A.20
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, 2004
Lecture 4A.21
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, 2004
Lecture 4A.22
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, 2004
Lecture 4A.23
Example
Process
Satellite
Data
satellite signal
Control
Surveillance
System
satellite data
enable satellite
processing
Surveillance data
radar signal
enable radar
processing
Process
Radar
Data
CSE3308 - Software Engineering: Analysis and Design, 2004
radar data
Lecture 4A.24
Action Game Example
Control
Game
enter play
mode
start playing
start
administrating
enter
administration
mode
Play Game
Game Details
CSE3308 - Software Engineering: Analysis and Design, 2004
Administer
Game
Lecture 4A.25
Levelled DFDs
 Most
systems are far too complex to depict
on one DFD
CSE3308 - Software Engineering: Analysis and Design, 2004
Lecture 4A.26
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
Terminator 1
Terminator 2
The
System
Datastore 1
Terminator 3
Context Diagram
Terminator 2
1. Wiggle
Widget
Terminator 1
3.1 Create
Doover
2. Grind
Gadget
3.2 Mangle
Doover
Terminator 3
3.3
Wangle
Doover
3. Dangle
Doover
Datastore 1
Figure 0 DFD
Figure 3 DFD
CSE3308 - Software Engineering: Analysis and Design, 2004
Lecture 4A.27
Datastore 1
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, 2004
Lecture 4A.28
Balanced DFDs
Terminator 1
Terminator 2
A, G
B
The
System
D
Terminator 2
1. Wiggle
Widget
C
Datastore 1
Terminator 3
B
E
A
Terminator 1
2. Grind
Gadget
F
G
Context Diagram
H
Terminator 3
D
3. Dangle
Doover
C
C
F
G
3.1 Create
Doover
H
I
Figure 0 DFD
3.2 Mangle
Doover
J
K
D
3.3
Wangle
Doover
C
Datastore 1
Balanced DFDs
Figure 3 DFD
CSE3308 - Software Engineering: Analysis and Design, 2004
Lecture 4A.29
Datastore 1
Unbalanced DFDs
Terminator 1
Terminator 2
A, G
B
The
System
D
Terminator 2
1. Wiggle
Widget
B
E
A
C
Datastore 1
Terminator 3
Z
Terminator 1
2. Grind
Gadget
F
G
H
Context Diagram
Terminator 3
Q
C
3. Dangle
Doover
F
W
Figure 0 DFD
G
3.1 Create
Doover
H
I
3.2 Mangle
Doover
J
C
K
X
3.3
Wangle
Doover
C
Datastore 1
Can you see the
problems?
Figure 3 DFD
CSE3308 - Software Engineering: Analysis and Design, 2004
Lecture 4A.30
Datastore 1
Data Stores and Levelled DFDs
Terminator 1
Terminator 2
A, G
B
The System
C
D
Terminator 2
1. Wiggle
Widget
Datastore 1
Terminator 3
B
E
A
Terminator 1
2. Grind
Gadget
F
G
Context Diagram
H
Terminator 3
D
3. Dangle
Doover
C
C
F
Datastore 1
G
3.1 Create
Doover
H
I
Figure 0 DFD
3.2 Mangle
Doover
J
K
D
3.3 Wangle
Doover
C
Datastore 1
Figure 3 DFD
CSE3308 - Software Engineering: Analysis and Design, 2004
Show datastores at
every level at which
they are used
Lecture 4A.31
References
 Yourdon,
E., Modern Structured Analysis,
Prentice Hall, 1989.
 There is now a condensed edition, called Just Enough
Structured Analysis, available online via the Resources
page on the unit web site.
CSE3308 - Software Engineering: Analysis and Design, 2004
Lecture 4A.32
Descargar

Software Engineering: Analysis and Design