cse3308 - software engineering: analysis and design, 2001lecture 2b.1 software engineering: analysis...

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


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

Airline Reservation

System

Management FinanceSystem

CustomerAirline

Credit Card Data

Reports

Requestfor

reservation

Flight confirmation

Creditdetails

Flight details

Request forreservation

Transactiondetails


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


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


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


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 As in context diagrams


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


Diverging Data Flows

Validatepostcode

Validatephone

no.

Validatestreet

address

CustomerAddress

postcode

phone no.

streetaddress

Produce ValidOrder

GenerateInvoice

UpdateInventory

Generate Shipping

Docs

Order

Invalidorders

Order details


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


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

ControlSurveillance

System

ProcessRadarData

ProcessSatellite

Data

Surveillance data

radar data

satellite data

enable satelliteprocessing

enable radarprocessing

satellite signal

radar signal


Doom Example

Administer Game

Play GameGame Details

ControlGame

start administratingstart playing


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

cse3308 - software engineering: analysis and design, 2001lecture 2b.1 software engineering: analysis...

Documents

objectoriented analysis

processes u

components u

system u external entities

outside world u

context diagram u

cse3308 software engineering

software engineering