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

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

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 Diagram 4 components The System External Entities also know as terminators Data Flows Data Stores Airline Booking System Customer reservation Flights

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

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

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

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

Your answer?

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

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)

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

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 Name - what the process does Part of system which transforms inputs to outputs Data Stores As in context diagrams Terminators

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

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

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

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 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 Beware read-only/write-only stores

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

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

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

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

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

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

Balanced DFDs

An Unbalanced DFD

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