Professional Documents
Culture Documents
- Introduction to SASD
- Structured Analysis
- Structured Design
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.
Konkuk University 2
Structured Analysis
S
Structured
d analysis
l i iis [Kendall 1996]
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.
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
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
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
Essential Model
Environmental Behavioral
Model Model
Konkuk University 9
Environmental Model
D fi
Defines the
h scope off the
h proposed
d system.
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
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
Data Dictionary
ERD
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
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
Konkuk University 16
System Context Diagram - Notation
Konkuk University 17
System Context Diagram RVC Example
Motor
RVCC
Sensor
Control
Cleaner
Konkuk University 18
Event List
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
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
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.
Data Process
Data Flow
Control Process
Control Flow
T
Terminator
i
Data Store
Konkuk University 22
DFD Level 0 RVC Example
Left Sensor
Left Sensor Input
p RVC
Right Sensor Control
Right Sensor Input
0
Clean
Digital Clock
Konkuk University 23
DFD Level 0 RVC Example
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
Konkuk University 24
DFD Level 1 RVC Example
Left Sensor
Input
p Obstacle Cleaner &
& Dust Obstacle & Dust Motor
Right Sensor Location
Input
Detection Control
1 2
Clean
Tick
Konkuk University 25
DFD Level 2 RVC Example
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
Konkuk University 28
DFD Level 4 RVC Example
State Transition Diagram for Controller 2.1.1
211
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
Konkuk University 30
Process Specification
Konkuk University 31
Process Specification RVC Example
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.
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
Relationship
Cardinality Mandatory 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)
Konkuk University 41
Structured Charts Transform Analysis
Konkuk University 42
Structured Charts Transform Analysis
Control
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
Konkuk University 45
Structured Charts RVC Example (Basic)
Main
i
Controller
Konkuk University 46
Structured Charts RVC Example (Advanced)
Main
i
Controller
Obstacle Location
Dust Existence
Trigger
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.)
Konkuk University 49
Pros of SASD
D
Data Di
Dictionary
i
Simplifies data requirements
Used at high or low level analysis
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.
Konkuk University 53
Cons of SASD
D
Data Di
Dictionary
i
No functional details
Formal language is confusing to users.
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.
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.
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?
Konkuk University 58
Summary
SASD
Konkuk University 59
Final Presentation (OOAD vs. SASD)
E li h presentation
English i
Konkuk University 60