1. Software Engineering: Analysis and Design - CSE3308
CSE3308/DMS/2001/4
Monash University - School of Computer Science and Software Engineering
Software Engineering: Analysis and Design - CSE3308
Structured Analysis - Part 1

2. Lecture Outline History of Structured Analysis Context Diagrams
Event Lists
Data Flow Diagrams
Control Flows and Processes
Levelled Data Flow Diagrams

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
SA is extended
McMenamin and Palmer - Essential Structured Analysis
SA reaches its peak
Yourdon publishes Modern Structured Analysis
Integrates Chen’s Entity-Relationship Models
1991 Yourdon moves to Object-Oriented Analysis
% of organisations used SA

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

5. Constructing a Context Diagram
4 components
The System
External Entities
also know as terminators
Data Flows
Data Stores
Airline
Booking
System
Customer
reservation
Flights

6. Airline Reservation System
Customer
Airline
Request for
reservation
Flight
confirmation
Flight details
Request
for
reservation
Airline
Reservation
System
Credit Card Data
Credit
details
Reports
Transaction
details
Management
Finance
System

7. Guidelines for Context Diagrams
Yes No
Use appropriate names
Don’t be too specific with names
Customer
Fred
Flintstone
Ready to send input
Order
Entry
System
Customer
Okay, send input
Here’s the input
Great, I got the input

8. Guidelines (2) Can have Dialogue Flows representing two-way data flow
Flight status
response
Credit check
request
Finance
System
Airline
Reservation
System
Customer
Credit check
response
Flight status
request
Duplicate terminators if necessary to simplify the diagram

9. Student Enrolment System
Terminators
Student
University Management
University Staff
Data Stores
Student Results
Data Flows (7)
reports to management, enrolment details from student, confirmation of enrolment to student, payment details from staff, student lists to staff, student results from staff to Student Results database, student results from Student Results database to system

10. Your answer?

11. 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 external entities’ point of view

12. Event examples Customer places reservation (Flow)
Customer cancels reservation (Flow)
Accounting System receives transaction details (Flow)
Management requests weekly report (Temporal)
Airline confirms reservation (Temporal)
Credit card to be verified (Control)

13. Constructing the Event List
Examine each terminator in turn
Decide whether it generates a single event or possibly multiple events
Customer places order
Can be Customer places order and Salesperson places order
Need to allow for failure conditions on the part of the terminator, but no need to allow for system failures

14. 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?

15. Your answer?

16. Data Flow Diagrams
Extends the Context Diagram by defining the processes which make up a system
4 components
Processes
Name - what the process does
Part of system which transforms inputs to outputs
Data Stores
As in context diagrams
Terminators

17. Data Flows
Indicate movement of packets of information from one part of the system to another part
Flows are named
Input flow
Output flow
Diverging flows
Validate
Phone
No.
Phone No.
Flight Schedule
Information
Generate
Flight
Schedule

18. Diverging Data Flows Order Customer Address Produce Valid Order
Validate
postcode
Generate
Shipping
Docs
Invalid
orders
postcode
phone no.
Order details
Validate
phone
no.
street
address
Update
Inventory
Generate
Invoice
Validate
street
address

19. Typical Data Flow Diagram
Customers
Warehouse
Orders
invalid orders
shipping
details
order
details
orders 1.
Receive
Order
books 2.
Ship
Books
name, address
billing
information
Customers
name,
address
Invoices
books
name, address 3.
Collect
Payment
name, invoice
details
Customers
invoices, statements

20. 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

21. Your elements

22. Your DFD

23. 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 processes and related data stores and terminators

24. 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

25. Control Flows and Processes
Real-time systems need a means to model control (signals/interrupts)
Shown with dotted lines and circles
Control flows can be regarded as a binary signal
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

26. Example Process Satellite Data satellite data satellite signal Control
Surveillance
System
enable satellite
processing
Surveillance data
radar signal
enable radar
processing
Process
Radar
Data
radar data

27. Doom Example Game Details Control Game start playing
start administrating
Play Game
Administer
Game
Game Details

28. Leveled DFDs
Most systems are far too complex to depict on one DFD

29. Leveled DFDs (2)
Break each process down into sub-processes

30. 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

31. Balanced DFDs

32. An Unbalanced DFD

33. Data Stores and Leveled DFDs
Show the data store at all relevant levels