analisis terstruktur

8/8/2019 Analisis Terstruktur

1/32

Software Engineering:

Analysis and Design -CSE3308Structured Analysis - Part 1


2/32

Lecture Outline

History of Structured Analysis

Context Diagrams

Event Lists

Data Flow Diagrams

Control Flows and Processes

Levelled Data Flow Diagrams


3/32

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 Chens 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 onmaintenance, there is still a lot of work being done on systems producedusing SA, and coded in languages such as Fortran, COBOL and C


4/32

Context Diagrams Indicate the people, organisations and

systems which communicate with oursystem

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 thesystem with the outside world

Show the boundary between the systemand the rest of the world


5/32

( or )

Constructing a Context

Diagram Four components The System

Terminators also know as external entities

Data Flows

Data StoresStudents

Student

Enrolment

System

Student

student-id

Students


6/32

CD for Student Enrolment

SystemStudent

Staff Member

personal-details,

course-code

student-id

subject-code

password,subject-code

student-list

student-id,mark

password,subject-codesubject-name,year,

core-flag,prerequisites

student-id

staff

-id

Administrator

SubjectsInCourses

SubjectDataForStudent

Students

StudentsInCourses

Prerequisites

Subjects

Finance System

student-id

fees-paid

Student Enrolment

System


7/32

Guidelines for Context

Diagrams

Use appropriate names

Dont be too specific with names

StudentFred

Flintstone

Yes No

Student

Student

EnrolmentSystem

Ready to send input

Okay, send input

Heres the input

Great, I got the input


8/32

Guidelines (2)

Can have Dialogue Flows

representing two-way data flow

Student

Enrolment

System

Finance

System

Check fees paid

fees check

response

Duplicate terminators if necessary to simplifythe diagram


9/32

Event Lists

List of the external events that occur in theoutside world which affect the system, i.e.events generated by terminators

Events can be

Flow - some data flows between the external worldand the system

Temporal - an event occurs as a result of sometiming

Control - special case of a temporal event, anexternal stimulus that occurs at someunpredictable point in time

Events are always viewed from the terminators

point of view


10/32

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)


11/32

Constructing the Event

List Examine each terminator, and ask what effects the

terminators actions can have on the system

Take care to distinguish between separate events

coincidently packaged together in the requirementsspecification

Event Customer places order might in fact be both Customerplaces 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


12/32

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?


13/32

Your answer?


14/32

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 thattransforms inputs to outputs. It has:

Number - identifies process and indicatesplace in DFD level hierarchy

Name - what the process does

Data Flows

as in Context Diagram}


15/32

Indicate movement of packets ofinformation from one part of the

system to another part Flows are named

Input flow

Output flow

Data Flows

Validate

Phone

No.

Phone No.

Generate

Flight

Schedule

Flight Schedule

Information


16/32

Diverging Data Flows

Validate

postcode

Validate

phone

no.

Validate

street

address

personal-details

postcode

phone no.

street

address

Produce

Valid

Order

Generate

Invoice

UpdateInventory

Generate

ShippingDocs

Order

Invalid

orders

Order details


17/32

Typical Figure 0 DFDNote:

some analysts do notshow terminators on theFigure 0 DFD

St

e t

Staff em

er

6. ssig staff

mem

er tos

ject

2. rolst

e t i s

ject

1.

rolst

e t atU iversity

4.

reate e

s

ject

3. Recor

mark forst

e t

5. ri tst

e ttra scri t

erso al-

etails,co

rse-co

e

st

e t-i

st

e t-i

, s

ject-co

e

st

e t-i

,s

ject-co

e

ass

or

,s

ject-co

e

st

e t-list

st

e t-i

, mark

ass

or

, s

ject-co

e

s

ject- ame, co

rse-co

e, year,

core-flag,

rere

isites

ass or

, st

e t-i

ass or

, s

ject-co

estaff-i

mi istrator

St

e

ts

SubjectsI ourses

Subject ata orStude t

Stude ts

Stude tsI ourses

rere

uisites

Subjects

i a ce System

stude t-id

fees- aid

Stude tsI ourses

stude t-tra scri t

SubjectsI

ourses

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


18/32

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


19/32

Your elements


20/32

Your DFD


21/32

Guidelines for

constructing DFDs Choose meaningful names

Number the processes

Redraw the DFD as many times asnecessary for aesthetics

Avoid overly complex DFDs

Fit on one A4 page approximately 6-7 processes and

related data stores and terminators


22/32

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 outputsbut no inputs (possible exception is arandom number generator)

Beware of unlabelled flows and

processes


23/32

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 dormantprocess

Internal behaviour of a control

process described by a state-


24/32

Example

Control

Surveillance

System

Process

Radar

Data

Process

Satellite

Data

Surveillance data

radar data

satellite data

enable satellite

processing

enable radar

processing

satellite signal

radar signal


25/32

ActionG

ame Example

Administer

GamePlay Game

Game Details

Control

Game

start

administrating

start playing

enter

administration

mode

enter play

mode


26/32

Levelled DFDs Most systems are far too complex to

depict on one DFD


27/32

Levelled DFDs (2) Break each process down

into sub-processes Numbering of processes

indicates their parentsprocess, and thus their

position in the hierarchyof levelled DFDs

The

System

Terminator 1

Terminator 3

Terminator 2

Datastore 1

Cont t i r

Terminator 1

Terminator 3

Terminator 2

Datastore 1

i r

1. Wiggle

Widget

3. DangleDoover

2. Grind

Gadget

Datastore 1

i r

3.1 Create

Doover

3.3Wangle

Doover

3.2 Mangle

Doover


28/32

Guidelines forLevelled

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 notneed the same numbers of levels

Levels mustbe consistent with each

other


29/32

Balanced DFDs

Terminator 1

Terminator 3

Terminator 2

atastore 1

B

Figure 0 DFD

1. Wiggle

Widget

3. angle

oover

2. rind

adget

E

F

H

A

atastore 1

Figure DFD

F

H

3 .1

reate

oover

3.3Wangle

oover

3.2 Mangle

oover

JK

I

Balanced DFDs

The

System

Terminator 1

Terminator 3

Terminator 2

atastore 1

A,B

Context Diagram


30/32

Unbalanced DFDs

Can you see the

problems?

The

System

Terminator 1

Terminator 3

Terminator 2

Datastore 1

, G

CD

Cont t i r

Terminator 1

Terminator 3

Terminator 2

atastore 1

B

Q

Fi ur 0 F

1. Wiggle

Widget

3. angle

oover

2. rind

adget

E

F

H

AZ

atastore 1

Fi ur F

F

H

3.1

reate

oover

3.3

Wangle

oover

3.2 Mangle

oover

JK

I

X

W


31/32

Data Stores and Levelled DFDs

Terminator 1

Terminator 3

Terminator 2

Datastore 1

B

Figure 0 DFD

1. Wiggle

Widget

3.!

angle!

oover

2."

rind"

adget

E

F

H

A

"

#

#

Datastore 1

D

Figure 3 DFD

F

H

$

%

3.1%

reate

Doover

3.3 Wangle

Doover

3.2&

angle

Doover

J'

I

Show datastores at

every level at which

they are used

The System

Terminator 1

Terminator 3

Terminator 2

Datastore 1

A,

B

D

Context Diagram


32/32

References Yourdon, E., Modern Structured

Analysis, PrenticeHall, 1989.

There is now a condensed edition,

called Just Enough Structured

Analysis, available online via the

Resources page on the unit web site.

analisis terstruktur

Documents