Software Engineering:

Analysis and Design -

CSE3308
Structured Analysis - Part 1
 Lecture Outline

History of Structured Analysis

Context Diagrams

Event Lists

Data Flow Diagrams

Control Flows and Processes

Levelled Data Flow Diagrams
 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 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
 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
 Constructing a Context

Four components
Diagram

The System S tu d e n t
E n r o lm e n t
S y s te m


Terminators
» also know as external entities S tu d e n t


Data Flows s t u d e n t - id

Data Stores S tu d e n ts
( or Students )
 CD for Student Enrolment
System S u b je c t D a t a F o r S t u d e n t
S tu d e n t
p e r so n al-d e tails,
c o u r se -c o d e
stu d e n t-id S u b je c t s In C o u r s e s
s u b je c t - c o d e

P r e r e q u isite s
passw ord,
s u b je c t - c o d e
stu d e n t-list
S tu d e n t E n r o lm e n t S t a ff M e m b e r
S u b je c t s
S y ste m s t u d e n t - i d ,m a r k

s t a ff- i d S tu d e n ts

p a s s w o r d ,s u b je c t - c o d e
s u b j e c t - n a m e ,y e a r , stu d e n t-id
c o r e - fl a g ,p r e r e q u i s i t e s fe e s - p a i d
stu d e n t-id
F in an ce S yste m
A d m in istr ato r
S tu d e n ts In C o u r s e s
 Guidelines for Context
Diagrams
Yes No

Fred
Student

Use appropriate names Flintstone


Don’t be too specific with names
Ready to send input

Okay, send input

Student
Student Enrolment
Here’s the input
System
Great, I got the input
 Guidelines (2)

Can have Dialogue Flows
representing two-way data flow
Check fees paid

Finance Student
Enrolment
System fees check System
response

 Duplicate terminators if necessary to simplify

the diagram
 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
 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)
 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
 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?
Your answer?
 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
as in
place in DFD Context
level Diagram
hierarchy
Name - what the process does

 Data Flows
 Data Flows

Indicate movement of packets of
information from one part of the
system to another partValidate
Phone No. Phone

Flows are named No.

Flight Schedule
Generate

Input flow Flight
Information
Schedule


Output flow
 Diverging Data Flows
Order

personal-details
Produce
Validate Invalid Generate
postcode Valid
postcode orders Shipping
Order
Docs

phone no. Order details

street Validate
address phone
no. Update
Inventory
Validate Generate
street Invoice
address
 Typical Figure 0 DFD
Note:
p e r so n al-d e tails, some analysts do not
c o u r se -c o d e
S tu d e n ts show terminators on the
S tu d e n t 1.Enrol
stu d e n t-id Figure 0 DFD
stu d e n t at
U n ive r sity

s t u d e n t - i d , s u b je c t - c o d e
s t u d e n t - i d ,s u b je c t - c o d e S u b je c t s In C o u r s e s S tu d e n ts In C o u r s e s

P r er e q u isite s passw o rd,

2.Enrol
s u b je c t - c o d e
stu d e n t in S t a ff M e m b e r
s u b je c t stu d e n t-list
3.R ecord
S u b je c t D a t a F o r S t stu d e n t-id , m ar k
m a r k fo r
S u b je c t s In C o u r s e s udent stu d e n t
4 . C r e ate
new
s u b je c t
S u b je c t s S tu d e n ts In C o u r se s

s u b je c t - n a m e , c o u r s e - c o d e , y e a r ,
c o r e - fl a g , p r e r e q u i s i t e s S tu d e n ts

p a s s w o r d , s u b je c t - c o d e

6 . A ssig n 5. P rint
s t a ff stu d en t
m e m b e r to tr an scr ip t stu d e n t-id
p assw o r d , stu d e n t-id
s u b je c t p a s s w o r d , s u b je c t - c o d e fe e s - p a i d
s t a ff- i d F in an c e S yste m
A d m in istr ato r stu d e n t-tr an sc r ip t

Note: some flows may be physical, such as the student-transcript

 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
Your elements
Your DFD
 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
 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
 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-
 Example
Process satellite data
satellite signal Satellite
Data

enable satellite
Control processing
Surveillance
System Surveillance data

radar signal

enable radar
processing Process radar data
Radar
Data
Action Game Example
Control
Game
enter play
start playing
mode
start
administrating
enter
administration
mode
Play Game Administer
Game Details Game
 Levelled DFDs

Most systems are far too complex to
depict on one DFD
 Levelled DFDs (2)

Break each process down T e rm in ato r 1 T e rm in a to r 2

into sub-processes

Numbering of processes T he
S y s te m
indicates their parents T e rm in ato r 3
D a ta s to re 1

process, and thus their

position in the hierarchy C o n t e x t D ia g r a m

of levelled DFDs
1 . W ig g le T e rm in ato r 2
W id g e t
T e rm in a to r 1
3 .1 C r e a t e 3 .2 M a n g l e
D o o ve r 2 . G rin d
D o o ve r G adget

3 . D an g le
3 .3 D a ta s to re 1 T e rm in a to r 3 D o o ve r D ata s to re 1
W an g le
D o o ve r

F ig u r e 3 D F D F ig u r e 0 D F D
 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
T e rm in a to r 1 T e rm in a to r 2
Balanced DFDs
A,G
B

T he
S y s te m C
D T e rm in a to r 2
D ata s to re 1 1 . W ig g le
T e rm in a to r 3 W id g e t B
A E
T e rm in ato r 1
2 . G rin d
C o n t e x t D ia g r a m F G adge t
G
H C

F 3 . D an g le
T e rm in ato r 3 D D o o ve r C D atas to re 1
G
3 .1 C r e a t e H
D o o ve r I 3 .2 M a n g l e
D o o ve r
F ig u r e 0 D F D
J
K

3 .3 D ata s to re 1
W a n g le C
D D o o ve r

Balanced DFDs
F ig u r e 3 D F D
 Unbalanced DFDs
T e rm in a to r 1 T e rm in a to r 2

A,G
B

1 . W ig g le T e rm in a to r 2
T he W id g e t B
S y s te m C
D A E
D atas to re 1 Z
T e rm in a to r 3 T e rm in ato r 1
2 . G rin d
F G adge t
G
H
C o n t e x t D ia g r a m C

3 . D an g le
T e rm in ato r 3 Q D o o ve r
F D a tas to re 1
W
G
3 .1 C r e a t e H
D o o ve r I 3 .2 M a n g l e F ig u r e 0 D F D
D o o ve r

J
K C
X

3 .3 D atas to re 1
C
W a n g le
D o o ve r Can you see the
problems?
F ig u r e 3 D F D
 Data Stores and Levelled DFDs
T e rm in ato r 1 T e rm in ato r 2

A,G
B

1 . W ig g le T e rm in a to r 2
T h e S y s te m C W id g e t
D B
D atasto r e 1 E
T e rm in ato r 3 A
T e rm in ato r 1
2 . G rin d
F G adget
G
C o n t e x t D ia g r a m H C

3 . D an g le
F T e rm in ato r 3 D D o o ve r C D atasto r e 1

G
3 .1 C r e a t e H
D o o ve r I 3 .2 M a n g l e
D o o ve r F ig u r e 0 D F D
J
K

D
3 .3 W a n g l e
D o o ve r
C D atasto r e 1 Show datastores at
every level at which
F ig u r e 3 D F D they are used
 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.