Software Engineering: Analysis and Design

Structured Analysis - Part 1

Paul Dunne GMIT

Lecture Outline
u Structured Analysis v Other courses will deal with Object Oriented analysis u Context

Diagrams u Event Lists u Data Flow Diagrams u Control Flows and Processes u Levelled Data Flow Diagrams

Paul Dunne GMIT

Page 1

Structured Analysis
u Definition
v Structured Analysis is a data-oriented approach to conceptual modelling We worry about the data the system processes NOT how it processes the data. Data is the king vCommon feature is the centrality of the dataflow diagram (DFD) vMainly used for information systems variants have been adapted for real-time systems

Paul Dunne GMIT

History of Structured Analysis (SA)

First texts appeared in 1977

v v

Tom de Marco - Structured Analysis and System Specification Gane and Sarson - Structured Systems Analysis McMenamin and Palmer - Essential Structured Analysis Yourdon Publishes Modern Structured Analysis Integrates Chens Entity-Relationship Models

u u

1984 - SA is extended
v

1989 - SA reaches its peak

v

u u

1991 - Yourdon moves to Object-Oriented Analysis 1995 - 38% of organisations used SA

Paul Dunne GMIT

Page 2

Modeling tools

Paul Dunne GMIT

Context Diagrams
u Indicate

the people, organisations and systems which communicate with our system u Show the data which our system receives from the outside world u Show the data produced by the system and sent to the outside world u Show the data which is shared by the system with the outside world u Show the boundary between the system and the rest of the world

Paul Dunne GMIT

Page 3

Constructing a Context Diagram

u

4 components
v The System
Airline Booking System

v Terminators

also know as external entities

Customer

v Data Flows

reservation

v Data Stores
Paul Dunne GMIT

Flights

Airline Reservation System

Airline
Flight confirmation Request for reservation

Customer

Request for reservation

Flight details

Airline Reservation System

Credit details

Credit Card Data

Reports Transaction details

Management

Finance System

Exercise: Indicate the type of each component

Paul Dunne GMIT

Page 4

Guidelines for Context Diagrams

u Use

appropriate names

Yes

No Fred Flintstone

u Dont

be too specific with namesCustomer

Ready to send input Okay, send input

Customer

Heres the input Great, I got the input

Order Entry System

Much too fussy!

Paul Dunne GMIT

Guidelines (2)
u Can

have Dialogue Flows representing two-way data

flow

Finance System

Credit check request Credit check response

Flight status response Airline Reservation System

Customer
Flight status request

Duplicate terminators if necessary to simplify the diagram

u

Paul Dunne GMIT

Page 5

Exercise: Student Enrolment System

u u

System
v

Student Enrolment system Student University Management University Staff Student Results 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 system, student results from Student Results database to system

Terminators
v v v

u u

Data Stores
v

Data Flows (7)

v

Paul Dunne GMIT

Your answer?

Paul Dunne GMIT

Page 6

Event Lists
u List

of the external events that occur in the outside world which affect the system, i.e. events generated by terminators u Events can be
v v v

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

u Events

are always viewed from the terminators point

of view

Paul Dunne GMIT

Event examples
u Customer

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

Paul Dunne GMIT

Page 7

Constructing the Event List

u Examine

each terminator in turn u Decide whether it generates a single event or possibly multiple events
v v

Customer places order Can be Customer places order and Salesperson places order

u Need

to allow for failure conditions on the part of the terminator, but no need to allow for system failures

Paul Dunne GMIT

Events
u Look

at a system which controls the sales of goods at a supermarket u Entities to think about
v Cash register v Checkout Operator v Customer v Scanner v Receipt printer u What

events can you identify?

Paul Dunne GMIT

Page 8

Your answer?

Paul Dunne GMIT

Modeling tools -DFDs

Paul Dunne GMIT

Page 9

Data Flow Diagrams

u Extends

the Context Diagram by defining the processes which make up a system u 4 components
v Processes Number - identifies process and indicates place in DFD level heirarchy Name - what the process does Part of system which transforms inputs to outputs v Data Flows v Data Stores v Terminators

as in context diagram

Paul Dunne GMIT

Data Flows
u Indicate

movement of packets of information from one part of the system to another part u Flows are named
v Input flow
Phone No. Validate Phone No.

v Output flow
Generate Flight Schedule Flight Schedule Information

v Diverging flows - see next slide

Paul Dunne GMIT

Page 10

Diverging Data Flows

Order Customer Address postcode Validate postcode Invalid orders

Produce Valid Order Order details

Generate Shipping Docs

phone no.

street address Validate street address

Validate phone no. Generate Invoice

Update Inventory

Paul Dunne GMIT

Typical Figure 0 DFD

Customers name, orders
Note: some analysts do not show terminators on the Figure 0 DFD

Orders Order

Warehouse

Order books

invalid orders

1. Receive Order Customer 2. Ship Books Customer

Invoice

Note: physical flows

Customers Invoices Customer Invoice 3. Collect Payment

books

invoices, statements payments, inquiries Customers

Paul Dunne GMIT

Page 11

An example
u For

the checkout operator example

v What are the terminators? v What are the main processes? v What are the main data flows? u Draw

a data flow diagram to put the above elements together

Paul Dunne GMIT

Your elements

Paul Dunne GMIT

Page 12

Your DFD

Paul Dunne GMIT

Guidelines for constructing DFDs

u Choose

meaningful names u Number the processes u Redraw the DFD as many times as necessary for aesthetics u Avoid overly complex DFDs
v v

Fit on one A4 page approximately 6 processes and related data stores and terminators

Paul Dunne GMIT

Page 13

Guidelines (2)
u Make
v v v v v

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 Make sure that incoming and outgoing flows from the DFD match those on the DFD at the level above

Paul Dunne GMIT

Control Flows and Processes

u

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-transition diagram Generally one control process in a DFD inputs and outputs of control process consist only of control flows

u u u

u u

Paul Dunne GMIT

Page 14

Example

satellite signal

Process Satellite Data

satellite data

Control Surveillance System radar signal

enable satellite processing Surveillance data

enable radar processing

Process Radar Data

radar data

Paul Dunne GMIT

Doom Example

Control Game start playing enter play mode

start administrating enter administration mode Play Game

Game Details

Administer Game

Paul Dunne GMIT

Page 15

Leveled DFDs
u Most

systems are far too complex to depict on one

DFD

Paul Dunne GMIT

Leveled DFDs (2)

u Break

each process down into sub-processes u Numbering of processes indicates their parents process, and thus their position in the hierarchy of levelled DFDs

Paul Dunne GMIT

Page 16

Guidelines for Levelled DFDs

u How many levels? v Each level should have approximately 6 processes v Simple systems: 2-3 levels v Medium size: 3-6 levels v Large size: 5-8 levels u All

parts of the system may not need the same numbers of levels u Levels must be consistent with each other
v

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

Paul Dunne GMIT

Balanced DFDs

Paul Dunne GMIT

Page 17

An Unbalanced DFD

Can you see the problem?

Paul Dunne GMIT

Data Stores and Levelled DFDs

u Show

the data store at all relevant levels

Paul Dunne GMIT

Page 18

References
u Yourdon,

E., Modern Structured Analysis, Prentice Hall, 1989.

Paul Dunne GMIT

Page 19