Structured Analysis

y and Structured Design

g

- Introduction to SASD
- Structured Analysis
- Structured Design

Lecturer: JUNBEOM YOO

jbyoo@konkuk.ac.kr
Ver. 1.5 http://dslab.konkuk.ac.kr
References

Modern
M d S
Structured dAAnalysis,
l i Ed EdwarddY
Yourdon,
d 1989
1989.
Introduction to System Analysis and Design: a Structured
Approach,
pp , Pennyy A. Kendall,, 1996.

Zhou Qun, Kendra Hamilton, and Ibrahim Jadalowen (2002).

Structured Analysis and Structured Design (SASD) - Class Presentaion
http://pages.cpsc.ucalgary.ca/~jadalow/seng613/Group/

Konkuk University 2
Structured Analysis

S
Structured
d analysis
l i iis [Kendall 1996]

a set of techniques and graphical tools

that allow the analysts
y to develop
p a new kind of system
y specification
p
that are easily understandable to the users.
Analysts work primarily with their wits, pencil and paper.

SASD
Structured Analysis and Structured Design

Konkuk University 3
History of SASD

Developed
D l d iin the
h llate 1970
1970s by
b DeMarco,
D M Y d
Yourdon andd
Constantine after the emergence of structured programming.

IBM incorporated SASD into their development cycle in the late

1970s and early 1980s.

Yourdon published the book Modern Structured Analysis in

1989.

The availability of CASE tools in 1990s enabled analysts to

d
develop
l and
d modify
dif th
the graphical
hi l SASD models.
d l

Konkuk University 4
Philosophy of SASD

Analysts
A l attempt to di
divide
id llarge, complex
l problems
bl iinto smaller,
ll
more easily handled ones.
Divide and Conquer

Top-Down approach

Functional view of the problem

Analysts use graphics to illustrate their ideas whenever possible.

Analysts must keep a written record.

Konkuk University 5
Philosophy of SASD

The
Th purpose off SASD is
i to develop
d l a useful,
f l hi
high
h quality
li
information system that will meet the needs of the end user.
[Yourdon 1989]

Konkuk University 6
Goals of SASD

I
Improve quality
li and
d reduce
d the
h risk
i k off system ffailure.
il

Establish concrete requirements specifications and complete

requirements documentations.

Focus on reliability, flexibility and maintainability of system.

Konkuk University 7
Elements of SASD

Essential Model

Environmental Behavioral
Model Model

Implementation Model

Konkuk University 8
Essential Model

M d l off what
Model h the
h system must do
d

Not define how the system will accomplish its purpose.

purpose

A combination of environmental and behavioral models

Essential Model

Environmental Behavioral
Model Model

Konkuk University 9
Environmental Model

D fi
Defines the
h scope off the
h proposed
d system.

Defines the boundary and interaction between the system and

the outside world.

Composed of
Statement of purpose
System Context diagram
Event list

Konkuk University 10
Behavioral Model

M d l off the
Model h internal
i lbbehavior
h i andd data
d entities
i i off the
h system

Models functional requirements.

Composed of
Data Dictionary
Data Flow Diagram (DFD)
Entity Relationship Diagram (ERD)
Process Specification
State Transition Diagram

Konkuk University 11
Implementation Model

Maps the
M h functional
f i l requirements
i to h
hardware
d andd software.
f
Minimizes the cost of the development and maintenance.
Determines which functions should be manual vs vs. automated
automated.
Can be used to discuss the cost-benefits of functionality with
user/stakeholders.
Defines the Human-Computer interface.
Defines non-functional requirements.

Composed of
Structure Charts

Konkuk University 12
SASD Process
Activity
Environmental Model

Statement of
Purpose
System Context
Diagram

Event List Behavioral Model

Data Dictionary

ERD

DFD Process Specification

State Transition Implementation

Diagram Model

Structured Chart

Time
Konkuk University 13
Statement of Purpose

A clear
l and
d concise
i textuall d
description
i i off the
h purpose ffor the
h
system to develop
It should be deliberatelyy vague.
g
It is intended for top level management, user management and
others who are not directly involved in the system.

Konkuk University 14
Statement of Purpose RVC Example

Robot Vacuum Cleaner (RVC)

- An RVC automatically cleans and mops household surface.

- It goes straight forward while cleaning.
- If its sensors found an obstacle
obstacle, it stops cleaning
cleaning, turns aside,
aside and
goes forward with cleaning.
- If it detects dust, power up the cleaning for a while
- We do not consider the detail design and implementation on HW
controls.
- We only focus on the automatic cleaning function.

Konkuk University 15
System Context Diagram

Highlights
Hi hli h the
h boundary
b d between
b the
h system and d outside
id world.
ld
Highlights the people, organizations and outside systems that
interact with the system
y under development.
p

A special case of DFD

Konkuk University 16
System Context Diagram - Notation

Process : represents the proposed system

Terminator : represents the external entities

Flow : represents the in/out data flows

Konkuk University 17
System Context Diagram RVC Example

Motor

RVCC
Sensor
Control

Cleaner

Konkuk University 18
Event List

A lilist off the

h event/stimuli
/ i li outside
id off the
h system to which
hi h iit must
respond.
Used to describe the context diagram
g in details.

Types of events
Flow-oriented event : triggered by incoming data
Temporal event : triggered by internal clock
Control event : triggered by an external unpredictable event

Konkuk University 19
Event List RVC Example

Input/ Output Event Description

Front Sensor Input Detects obstacles in front of the RVC

Left Sensor Input Detects obstacles in the left side of the RVC periodically

Right Sensor Input Detects obstacles in the right side of the RVC periodically

Dust Sensor Input Detects dust on the floor periodically

Direction commands to the motor

Direction
(go forward / turn left with an angle / turn right with an angle)

Clean Turn off / Turn on / Power-Up

Context Diagram for RVC

Konkuk University 20
System Context Diagram RVC Example

Direction Motor
Front Sensor Input
Left Sensor Input
Right Sensor Input
Dust Sensor Input

RVCC
Sensor
Control
Clean

Cleaner

Konkuk University 21
Data Flow Diagram (DFD)

Provides
P id a means for
f ffunctional
i lddecomposition.
ii
Composed of hierarchies(levels) of DFDs.

Notation (A kind of CDFD)

Data Process

Data Flow

Control Process

Control Flow
T
Terminator
i

Data Store

Konkuk University 22
DFD Level 0 RVC Example

Front Sensor Front Sensor Input

Motor
Direction

Left Sensor
Left Sensor Input
p RVC
Right Sensor Control
Right Sensor Input
0
Clean

Dust Sensor Dust Sensor Input Cleaner

Tick

Digital Clock

Konkuk University 23
DFD Level 0 RVC Example

(A kind of) Data Dictionary

Input/ Output
Description Format / Type
Event

Front Sensor Input Detects obstacles in front of the RVC True / False , Interrupt

Left Sensor Input Detects obstacles in the left side of the RVC periodically True / False , Periodic

Right Sensor Input Detects obstacles in the right side of the RVC periodically True / False , Periodic

Dust Sensor Input Detects dust on the floor periodically True / False , Periodic

Direction commands to the motor

Direction Forward / Left / Right / Stop
(go forward / turn left with an angle / turn right with an angle)

Clean Turn off / Turn on / Power-Up On / Off / Up

Konkuk University 24
DFD Level 1 RVC Example

Front Sensor Input

Direction

Left Sensor
Input
p Obstacle Cleaner &
& Dust Obstacle & Dust Motor
Right Sensor Location
Input
Detection Control
1 2
Clean

Dust Sensor Input

Tick

Konkuk University 25
DFD Level 2 RVC Example

Front Sensor Input

Front
Sensor
Interface Front Obstacle
1.1

Left Sensor Input

Left Determine
Sensor
Left Obstacle Obstacle
Obstacle
Interface
f L
Location
ti Location
Tick 1.2 1.5

Ri h
Right
Right Sensor Input Sensor Right Obstacle
Interface
1.3 Determine
Tick Dust Dust
Existence Existence
Dust 1.6
Dust Sensor Input Sensor Dust Existence
Interface
1.4
Tick
Konkuk University 26
DFD Level 2 RVC Example

Direction
Motor
Motor Command Interface
2.2
Obstacle
Location
Main
Control
2.1
Dust
Existence Cleaner
Clean
Cleaner Command Interface
2.3

Tick

Konkuk University 27
DFD Level 3 RVC Example

Tick
Move Motor Command
Forward
Enable 212
2.1.2

Obstacle Disable
Location

Controller Trigger
gg
M t C
Motor Command
d
2.1.1 Turn Left
2.1.3
Tick
Dust
Trigger
Existence Tick

Turn Motor Command

Right
Cleaner Command
214
2.1.4

Konkuk University 28
 DFD Level 4 RVC Example
State Transition Diagram for Controller 2.1.1
211

/ Enable Move Forward, Cleaner Command (On)

Move
Forward
Tick [F && !L] Tick [F && !R]
/ Disable Move Forward, / Disable Move Forward,
Cleaner Command (Off), Cleaner Command (Off),
Trigger Turn Left Trigger Turn Right

Tick Tick
/ Enable Move
Move Forward
Forward, / Enable Move
Move Forward
Forward,
Cleaner Command (On) Cleaner Command (On)

Turn Left
Turn Right

Tick [F && L && R]

/ Disable Move Forward,
Cleaner Command (Off),
Many problems in this model:
1 Stop
1. Stop state
St
Stop
2. Do not consider Dust
3.
Konkuk University 29
DFD RVC Example

Konkuk University 30
Process Specification

Shows process details

Sh d il which
hi h are implied
i li d but
b not shown
h in
i a DFD.
DFD
Specifies the input, output, and algorithm of a module in a DFD.
Normally written in pseudo-code
pseudo code or table format.
format

Example Apply Payment

For all payments
If payment is to be applied today or earlier and has not yet been applied
Read account
Read amount
Add amount to accounts open to buy
Add amount to account
accountss balance
Update payment as applied
Zhou Qun, Kendra Hamilton, and Ibrahim Jadalowen (2002)

Konkuk University 31
Process Specification RVC Example

Reference No. 1.2

Name Left Sensor Interface

Input Left Sensor Input (+Data structure if possible) , Tick

O t t
Output L ft Obstacle
Left Ob t l (+Data
( D t structure)
t t )

Left Sensor Input process reads a analog value of the left sensor
Process Description periodically, converts it into a digital value such as True/False, and
assigns it into output variable Left Obstacle.

Konkuk University 32
Data Dictionary

Defines
D fi d
data elements
l to avoid
id diff
different iinterpretations.
i
Not used widely in recent years.

Example [Yourdon 1989]

A: Whats a name?
B: Well, you know, its just a name. Its what we call each other.
A: Does that mean you can call them something different when you are angry or
happy?
B N
B: No, off course not.
t A name iis ththe same allll th
the ti
time.
A: Now I understand. My name is 3.141592653.
B: Oh your name is PIBut thats a number, not a name. But what about your
first and last name
name. Or
Or, is your first name 3 and your last name 141592653?

Konkuk University 33
Data Dictionary

N
Notation
i
= : is composed of
+ : and
( ) : optional element
{ } : iteration
[ ] : selects one of the elements list
| : separation of elements choice
** : comments
@ : identifier for a store (unique
q ID)

Konkuk University 34
Data Dictionary

E
Example
l
Element Name = Card Number
Definition = *Uniquely identifies a card*
Alias = None
Format = LD+LD+LD+LD+SP+LD+LD+LD+LD+SP+
LD+LD+LD+LD+SP+LD+LD+LD+LD
SP = *Space*
LD = {0-9} *Legal Digits*
Range = 5191 0000 0000 0000 ~ 5191 9999 9999 9999

Konkuk University 35
Entity Relationship Diagram (ERD)

A graphical
hi l representation
i off the
h ddata llayout off a system at a
high level of abstraction
Defines data elements and their inter-relationships p in the system.
y
Similar with the class diagram in UML.

Notation (Original)
Associated Object

Data Element Cardinality Exactly one

Cardinality Zero or one

Relationship
Cardinality Mandatory Many

Cardinality Optional Many

Konkuk University 36
Entity Relationship Diagram - Example

Konkuk University 37
State Transition Diagram

Shows the
Sh h time
i ordering
d i between
b processes.
More primitive than the Statechart diagram in UML.
Different from the State transition diagram used in DFD.
DFD
Not widely used.

Notation

Objects Transitions

Konkuk University 38
State Transition Diagram - Example

Konkuk University 39
Practice

C
Complete
l the
h RVC analysis
l i ini more details.
d il
Consider the Dust.
You mayy have several controller.

Konkuk University 40
Structure Charts

S
Structured
dDDesign
i (SD)

Functional decomposition (Divide and Conquer)

Information hiding
Modularity
Low coupling
High internal cohesion

Needs a transform analysis.

Konkuk University 41
Structured Charts Transform Analysis

Afferent Flow Central Transformation Efferent Flow

(Input) (Control) (Output)

Konkuk University 42
Structured Charts Transform Analysis

Input Process Output

(Afferent Flo
Flow)) (C t l Transformation)
(Central T f ti ) (Efferent Flo
Flow))

Control

Input Process Output

Konkuk University 43
Structured Charts Notation
Basic Notation [Yourdon 1989]

Variations
Modules
Data module

Libraryy modules
Asynchronous
module call

Module call
Iteration

Data Flow
Decision

Control Flow

Konkuk University 44
Structured Charts - Example

Zhou Qun, Kendra Hamilton, and Ibrahim Jadalowen (2002)

Konkuk University 45
 Structured Charts RVC Example (Basic)

Main
i

Controller

Obstacle Location Dust Existence

Enable Trigger Trigger

Disable
Determine Determine
Obstacle Location Dust Existence

Front Sensor Left Sensor Right Sensor Dust Sensor

Move Forward Turn Left Turn Right
Interface Interface Interface Interface

Konkuk University 46
 Structured Charts RVC Example (Advanced)

Main
i

Controller

Obstacle Location

Dust Existence

Determine Determine Trigger

Enable
Obstacle Location Dust Existence Disable

Trigger

Front Sensor Left Sensor Right Sensor Dust Sensor

Move Forward Turn Left Turn Right
Interface Interface Interface Interface

Konkuk University 47
Pros of SASD

Has distinct
H di i milestones,
il allowing
ll i easier
i project
j management
tracking.
Veryy visual easier for users/programmers
/p g to understand
Makes good use of graphical tools
Well known in industry
A mature technique
Process-oriented way is a natural way of thinking
Flexible
Provides a means of requirements validation
Relativelyy simple
p and easyy to read

Konkuk University 48
Pros of SASD

S
System Context
C Diagram
Di
Provides a black box overview of the system and the environment

Event List
Provides a guidance for functionality
Provides a list of system inputs and outputs
A means of requirements summarization
Can be used to define test cases (as we will see soon.)

Data Flow Diagram (DFD)

Ability to represent data flows
Functional
F ti l decomposition
d iti (divide
(di id and
d conquer))

Konkuk University 49
Pros of SASD

D
Data Di
Dictionary
i
Simplifies data requirements
Used at high or low level analysis

Entity Relationship Diagram (ERD)

Commonly used and well understood
A graphical tool, so easy to read by analysts
Data objects and relationships are portrayed independently from the process
Can be used to design database architecture
Effective tool to communicate with DBAs

Process Specification
Expresses the process specifications in a form that can be verified

Konkuk University 50
Pros of SASD

S
State Transition
T ii Diagrams
Di
Models real-time behavior of the processes in the DFD

Structure Charts
Modularity improves the system maintainability
Provides a means for transition from analysis to design
Provides a synchronous hierarchy of modules

Konkuk University 51
Cons of SASD

IIgnores non-functional
f i l requirements.
i
Minimal management involvement
Non-iterative
Non iterative waterfall approach
Not enough use-analysts interaction
Does not provide a communication process with users.
Hard to decide when to stop decomposing.
Does not address stakeholders needs.
D
Does not work k wellll with
i h Obj
Object-Oriented
Oi d programming
i llanguages.

Konkuk University 52
Cons of SASD

S
System Context
C Diagram
Di
Does not provide a specific means to determine the scope of the system.

Event List
Does not define all functionalities.
Does not define specific mechanism for event interactions.

Data Flow Diagram (DFD)

Weak
W k display
di l off iinput/output
t/ t t details
d t il
Confused for users to understand.
Does not represent time.
N iimplied
No li d sequencing
i
Assigns data stores in the early analysis phase without much deliberation.

Konkuk University 53
Cons of SASD

D
Data Di
Dictionary
i
No functional details
Formal language is confusing to users.

Entity Relationship Diagram (ERD)

May be confused for users due to its formal notation.
Become complex in large systems.

Structure Chart
Does not work well for asynchronous processes such as networks.
Could be too large to be effectively understood with larger programs.

Konkuk University 54
Cons of SASD

P
Process Specification
S ifi i
They may be too technical for users to understand.
Difficult to stay away from the current How to implement.

State Transition Diagram

Explains what action causes a state change, but not when or how often.

Konkuk University 55
When to use SASD?

Well-known
W ll k problem
bl domains
d i
Contract projects where SRS should be specified in details
Real-time
Real time systems
Transaction processing systems
Not appropriate when time to market is short.

IIn recent years,

SASD is widely used in developing real-time embedded systems.

Konkuk University 56
SASD vs.
vs OOAD

Si il i i
Similarities
The both have started off from programming techniques.
The both use graphical design and tools to analyze and model requirements.
The both provide a systematic step-by-step process for developers.
The both focus on the documentation of requirements.

Differences
SASD is process-oriented.
OOAD is data(object)-oriented
data(object) oriented.
OOAD encapsulates as much of the systems data and processes into objects,
While SASD separates them as possible as it can.

Konkuk University 57
Class Questions

Wh is
What i your opinion
i i on ?
Does it reduce maintainability costs?
Is it useful?
Is it efficient?
Is it appropriate for E-commerce(business) development?

What is SASDs target domain?

Konkuk University 58
Summary

SASD iis a process-driven

di software
f analysis
l i technique.
h i
SASD has a long history in the industry and it is very mature.
It provides a good documentation for requirements.
requirements
In recent years, it is widely used for developing real-time
embedded systems software.

SASD
Konkuk University 59
Final Presentation (OOAD vs. SASD)

E li h presentation
English i

Compare OOAD with SASD using your elevator controller team

project.
Pros and Cons of SASD and OOAD for developing elevator controllers
respectively
Your opinion and suggestion!!!

Konkuk University 60