cse3308 - software engineering: analysis and design, 2001lecture 2b.1 software engineering: analysis...
Post on 20-Dec-2015
216 views
TRANSCRIPT
CSE3308 - Software Engineering: Analysis and Design, 2001 Lecture 2B.1
Software Engineering: Analysis and Design - CSE3308
Structured Analysis - Part 1
CSE3308/DMS/2001/4
Monash University - School of Computer Science and Software Engineering
CSE3308 - Software Engineering: Analysis and Design, 2001 Lecture 2B.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, 2001 Lecture 2B.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
1988 - 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
CSE3308 - Software Engineering: Analysis and Design, 2001 Lecture 2B.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, 2001 Lecture 2B.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
CSE3308 - Software Engineering: Analysis and Design, 2001 Lecture 2B.6
Airline Reservation System
Airline Reservation
System
Management FinanceSystem
CustomerAirline
Credit Card Data
Reports
Requestfor
reservation
Flight confirmation
Creditdetails
Flight details
Request forreservation
Transactiondetails
CSE3308 - Software Engineering: Analysis and Design, 2001 Lecture 2B.7
Guidelines for Context Diagrams
Use appropriate names
Don’t be too specific with names
CustomerFred
Flintstone
Yes No
Customer
OrderEntry
System
Ready to send input
Okay, send input
Here’s the input
Great, I got the input
CSE3308 - Software Engineering: Analysis and Design, 2001 Lecture 2B.8
Guidelines (2)
Can have Dialogue Flows representing two-way data flow
CustomerAirline
ReservationSystem
FinanceSystem Flight status
request
Flight statusresponse
Credit check request
Credit checkresponse
Duplicate terminators if necessary to simplify the diagram
CSE3308 - Software Engineering: Analysis and Design, 2001 Lecture 2B.9
Student Enrolment System System
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
CSE3308 - Software Engineering: Analysis and Design, 2001 Lecture 2B.10
Your answer?
CSE3308 - Software Engineering: Analysis and Design, 2001 Lecture 2B.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
CSE3308 - Software Engineering: Analysis and Design, 2001 Lecture 2B.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)
CSE3308 - Software Engineering: Analysis and Design, 2001 Lecture 2B.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
CSE3308 - Software Engineering: Analysis and Design, 2001 Lecture 2B.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?
CSE3308 - Software Engineering: Analysis and Design, 2001 Lecture 2B.15
Your answer?
CSE3308 - Software Engineering: Analysis and Design, 2001 Lecture 2B.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 As in context diagrams
CSE3308 - Software Engineering: Analysis and Design, 2001 Lecture 2B.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
ValidatePhone
No.
Phone No.
GenerateFlight
Schedule
Flight Schedule Information
CSE3308 - Software Engineering: Analysis and Design, 2001 Lecture 2B.18
Diverging Data Flows
Validatepostcode
Validatephone
no.
Validatestreet
address
CustomerAddress
postcode
phone no.
streetaddress
Produce ValidOrder
GenerateInvoice
UpdateInventory
Generate Shipping
Docs
Order
Invalidorders
Order details
CSE3308 - Software Engineering: Analysis and Design, 2001 Lecture 2B.19
Typical Data Flow Diagram
Customers Warehouse
Customers
1.ReceiveOrder
3.Collect
Payment
2.Ship
Books
Orders
Customers
Invoices
invalid orders
orders
orderdetails
shippingdetails
books
books
name, address
name, address
name, address
invoices, statements
name, invoice details
billing information
CSE3308 - Software Engineering: Analysis and Design, 2001 Lecture 2B.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
CSE3308 - Software Engineering: Analysis and Design, 2001 Lecture 2B.21
Your elements
CSE3308 - Software Engineering: Analysis and Design, 2001 Lecture 2B.22
Your DFD
CSE3308 - Software Engineering: Analysis and Design, 2001 Lecture 2B.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
CSE3308 - Software Engineering: Analysis and Design, 2001 Lecture 2B.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
CSE3308 - Software Engineering: Analysis and Design, 2001 Lecture 2B.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
CSE3308 - Software Engineering: Analysis and Design, 2001 Lecture 2B.26
Example
ControlSurveillance
System
ProcessRadarData
ProcessSatellite
Data
Surveillance data
radar data
satellite data
enable satelliteprocessing
enable radarprocessing
satellite signal
radar signal
CSE3308 - Software Engineering: Analysis and Design, 2001 Lecture 2B.27
Doom Example
Administer Game
Play GameGame Details
ControlGame
start administratingstart playing
CSE3308 - Software Engineering: Analysis and Design, 2001 Lecture 2B.28
Leveled DFDs
Most systems are far too complex to depict on one DFD
CSE3308 - Software Engineering: Analysis and Design, 2001 Lecture 2B.29
Leveled DFDs (2)
Break each process down into sub-processes
CSE3308 - Software Engineering: Analysis and Design, 2001 Lecture 2B.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
CSE3308 - Software Engineering: Analysis and Design, 2001 Lecture 2B.31
Balanced DFDs
CSE3308 - Software Engineering: Analysis and Design, 2001 Lecture 2B.32
An Unbalanced DFD
CSE3308 - Software Engineering: Analysis and Design, 2001 Lecture 2B.33
Data Stores and Leveled DFDs
Show the data store at all relevant levels