cse3308 - software engineering: analysis and design, 2005lecture 4a.1 software engineering: analysis...

CSE3308 - Software Engineering: Analysis and Design, 2005 Lecture 4A.1

Software Engineering: Analysis and Design - CSE3308

Structured Analysis - Part 1

CSE3308/DMS/2005/10

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

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

Since much — if not most — expenditure of software organizations is on maintenance, there is still a lot of work being done on systems produced using SA, and coded in languages such as Fortran, COBOL and C


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


( or )

Constructing a Context Diagram Four components

The System

Terminators

» also know as external entities

Data Flows

Data Stores Students

S tu d en tE n r o lm en t

S y s tem

S tu d en t

s tu d en t- id

S tu d en ts


CD for Student Enrolment System

Stude nt

Staff M e m be r

pe r s o nal -de tai l s ,c o ur s e -c o de

s tude nt- i ds ubje c t -c o de

pas s w o r d,s ubje c t -c o de

s tude nt- l i s t

s tude nt- i d ,m ar k

pas s w o r d,s ubje c t -c o des ubje c t -nam e ,ye ar ,

c o r e - fl ag ,pr e r e qui s i te s

s tude nt- i d

s taff- i d

Adm i ni s tr ato r

Subje c ts InC o ur s e s

Subje c tD ataF o r Stude nt

Stude nts

Stude nts InC o ur s e s

P r e r e qui s i te s

Subje c ts

F i nanc e Sys te m

s tude nt- i d

fe e s -pai d

S tu d en t E n ro lm en tS ystem


Guidelines for Context Diagrams

Use appropriate names

Don’t be too specific with names

StudentFred

Flintstone

Yes No

Student

StudentEnrolment

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

StudentEnrolment

System

FinanceSystem

Check fees paid

fees checkresponse

Duplicate terminators if necessary to simplify the diagram


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 terminator’s point of view


Event examples

Student enrolls in subject (Flow) Administrator creates subject (Flow) Administrator receives student transcript

(Flow) Subject creation is disabled because

semester starts in one month (Temporal)

There is no control event in this list since they are unusual in business systems. They are, however, common in real-time systems (see slide 4A.23)


Constructing the Event List

Examine each terminator, and ask what effects the terminator’s actions can have on the system

Take care to distinguish between separate events coincidently “packaged” together in the requirements specification

Event “Customer places order” might in fact be both “Customer places order” and “Salesperson places customer order”

» Clue could be different data present in the two cases

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

» A process is a part of the system that transforms inputs to outputs. It has:

Number - identifies process and indicates place in DFD level hierarchy

Name - what the process does

Data Flows Data Stores Terminators

as in Context Diagram}


Indicate movement of packets of information from one part of the system to another part

Flows are named

Input flow

Output flow

Diverging flows - see next slide

Data Flows

ValidatePhone

No.

Phone No.

GenerateFlight

Schedule

Flight Schedule Information


Diverging Data Flows

Validatepostcode

Validatephone

no.

Validatestreet

address

personal-details

postcode

phone no.

streetaddress

Produce ValidOrder

GenerateInvoice

UpdateInventory

Generate Shipping

Docs

Order

Invalidorders

Order details


Typical Figure 0 DFDNote:some analysts do notshow terminators on theFigure 0 DFD

Stude nt

Staff M e m be r

6 . As s i g ns taff

m e m be r tos ubje c t

2 . E nr o ls tude nt i n

s ubje c t

1 . E nr o ls tude nt atU ni ve r s i ty

4 . C r e atene w

s ubje c t

3 . R e c o r dm ar k fo rs tude nt

5 . P r i nts tude nt

tr ans c r i pt

pe r s o nal -de tai l s ,c o ur s e -c o de

s tude nt- i d

s tude nt- i d , s ubje c t -c o des tude nt- i d ,s ubje c t -c o de

pas s w o r d,s ubje c t -c o de

s tude nt- l i s t

s tude nt- i d , m ar k

pas s w o r d, s ubje c t -c o de

s ubje c t -nam e , c o ur s e -c o de , ye ar ,c o r e - fl ag , pr e r e qui s i te s

pas s w o r d, s tude nt- i dpas s w o r d, s ubje c t -c o de

s taff- i dAdm i ni s tr ato r

Stude nts


Subje c tD ataF o r Stude nt

Stude nts


P r e r e qui s i te s

Subje c ts

F i nanc e Sys te m

s tude nt- i dfe e s -pai d


s tude nt- tr ans c r i pt


Note: some flows may be physical, such as the student-transcript


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-7 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 Make sure that incoming and outgoing flows from the

DFD match those on the DFD at the level above


Control Flows and Processes 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


Example

ControlSurveillance

System

ProcessRadarData

ProcessSatellite

Data

Surveillance data

radar data

satellite data

enable satelliteprocessing

enable radarprocessing

satellite signal

radar signal


Action Game Example

Administer Game

Play GameGame Details

ControlGame

startadministrating

start playing

enteradministrationmode

enter playmode


Levelled DFDs

Most systems are far too complex to depict on one DFD


Levelled DFDs (2) Break each process

down into sub-processes Numbering of processes

indicates their parents process, and thus their position in the hierarchy of levelled DFDs

T heS ys te m

Te rm inato r 1

Te rm inato r 3

Te rm inato r 2

D atas to re 1

Context Diagram

Te rm inato r 1

Te rm inato r 3

Te rm inato r 2

D atas to re 1

Figure 0 DFD

1 . W iggleW idge t

3 . D angleD o o ve r

2 . G r indG adge t

D atas to re 1

Figure 3 DFD

3 .1 C re ateD o o ve r

3 .3W angleD o o ve r

3 .2 M angleD o o ve r


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

Te rm inato r 1

Te rm inato r 3

Te rm inato r 2

D atas to re 1

B

D

Figure 0 DFD

1 . W iggleW idge t


2 . G r indG adge t

E

F

H

A

G

C

C

D atas to re 1

D

Figure 3 DFD

F

H

G

C




JK

I

Balanced DFDs

T heS ys te m

Te rm inato r 1

Te rm inato r 3

Te rm inato r 2

D atas to re 1

A, GB

CD

Context Diagram


Unbalanced DFDs

Can you see the problems?

T heS ys te m

Te rm inato r 1

Te rm inato r 3

Te rm inato r 2

D atas to re 1

A, GB

CD

Context Diagram

Te rm inato r 1

Te rm inato r 3

Te rm inato r 2

D atas to re 1

B

Q

Figure 0 DFD

1 . W iggleW idge t


2 . G r indG adge t

E

F

H

A

G

C

Z

D atas to re 1

Figure 3 DFD

F

H

G

C




JK

I

XC

W


Data Stores and Levelled DFDs

Te rm inato r 1

Te rm inato r 3

Te rm inato r 2

D atas to r e 1

B

D

Figure 0 DFD

1 . W iggleW idge t


2 . G r indG adge t

E

F

H

A

G

C

C

D atas to r e 1

D

Figure 3 DFD

F

H

G

C


3 .3 W angleD o o ve r


JK

I

Show datastores at every level at which they are used

T he S ys te m

Te rm inato r 1

Te rm inato r 3

Te rm inato r 2

D atas to r e 1

A, GB

CD

Context Diagram


References

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

There is now a condensed edition, called Just Enough Structured Analysis, available online via the Resources page on the unit web site.

cse3308 - software engineering: analysis and design, 2005lecture 4a.1 software engineering: analysis...

Documents

system u

objectoriented analysis

processes u

cse3308 software engineering

software engineering

outside world u

terminators u events

context diagram u