Transcript Chapter 10 : Finalizing Design Specification

Chapter 10 : Finalizing Design Specification
Learning Objective
Introduction
The Process of Finalizing Design
Specification
Representing Design Specifications
Chapter 10 : Finalizing Design Specification
Introduction
เนื่องจากความต้ องการระบบในปัจจุบันนีม้ กี ารพัฒนาเป็ นไป
อย่างรวดเร็วมากยิง่ ขึน้ กว่ าในอดีต
การทาการตรวจสอบในแบบดั้งเดิมนั้นมักจะกระทาระหว่ างการ
Design และการ Implement โดยมักทาเมื่อเสร็จขั้นตอน
การ Design แล้ว
ส่ วนวิธีการอืน่ ๆนั้นมักมีการทาในระหว่ างขั้นการ Design
และขั้นการ Implement ไปพร้ อมๆกัน
Chapter 10 : Finalizing Design Specification
The Process of Finalizing Design Specifications
Less costly to correct and detect errors
during the design phase
Quality requirement statements
Quality requirements
Deliverables and outcome
Chapter 10 : Finalizing Design Specification
Quality requirement statements
Correct
Feasible
Necessary
Prioritized
Unambiguous
Verifiable
Chapter 10 : Finalizing Design Specification
Quality requirements
Completely
Do not conflict with other requirement
Easy to change without adversely
affecting other requirements
Traceable back to origin
Chapter 10 : Finalizing Design Specification
Deliverables and outcome
Set of physical design specification
contain detailed specifications for
each part of the system
Chapter 10 : Finalizing Design Specification
Representing Design Specifications
Traditional Methods
1.Pre-CASE
2.Documents written natural
language and augmented with
graphical models
3.specification documents
Chapter 10 : Finalizing Design Specification
Representing Design Specifications
Structure Charts
Shows how an information is
organized in hierarchical models
Shoes how part of the system are
related to one another
Shows breakdown of s system into
programs and internal structures of
programs written in 3 or 4 GLs
Chapter 10 : Finalizing Design Specification
Structure Charts
Module
เป็ นส่ วนประกอบการทางานของระบบของเราในส่ วน
ของหน้ าที่งานต่ างๆที่มีความสาคัญ
ในการเขียนทุกครั้งต้ องมีโหนดเริ่มต้ นเสมอ (Root
node)
การเข้ าและออกของข้ อมูลไปยังโมดูลอืน่ เป็ นไปแบบ
ทางเดียวเท่ านั้น (One way)
การสื่ อสารระหว่ างโมดูลทาได้ โดยการส่ งผ่ าน
Parameters
Chapter 10 : Finalizing Design Specification
Structure Charts
Symbol of Module
Name
Types of communication parameters
Data couple : เป็ นเครื่องมือทีใ่ ช้ ในการส่ งผ่ าน
ข้ อมูลกันระหว่ างโมดูลต่ างๆ
Flag : เป็ นเครื่องมือทีใ่ ช้ ควบคุมการทางานของ
โปรแกรมว่ าจะทางานอย่างไร เช่ น Error message
Chapter 10 : Finalizing Design Specification
Structure Charts
Symbol of communication parameters
Data couple
Flag
Chapter 10 : Finalizing Design Specification
Structure Charts
Symbol of Specials Module
Diamond : Have condition to
selected
Name
Chapter 10 : Finalizing Design Specification
Structure Charts
Symbol of Specials Module
Curve line : Repeatedly until
terminating condition is met
Name
Chapter 10 : Finalizing Design Specification
Structure Charts
Symbol of Specials Module
Predefined Module : เป็ นโมดูลทีเ่ ราเคย
กล่ าวถึงหรือมีอยู่ก่อนหน้ านีแ้ ล้ ว
Name
Chapter 10 : Finalizing Design Specification
Structure Charts
Symbol of Specials Module
Embedded Module (Hat) : เป็ นโมดูลที่
อยู่ด้านล่ างทีม่ คี วามสาคัญแต่ มีคาสั่ งไม่ เยอะเลยฝังไว้ กบั ตัว
ด้ านบนแทน
Name
Name
Chapter 10 : Finalizing Design Specification
Design Structure Charts Approach
การออกแบบนั้นมีพ้ืนฐานมาจาก DFD ที่ออกแบบมาแล้ว
ข้า งต้น แล้ว ท าการปรั บ ให้ มี คุ ณ ภาพจากนั้น ท าการแบ่ ง ประเภทของ
Structure Charts โดยสามารถแบ่งได้ 2 รู ปแบบตามการไหล
ของข้อมูล
Type of Structure Charts
Transform flow
Transaction flow
Chapter 10 : Finalizing Design Specification
Design Structure Charts Approach
Transform flow
Find the processing process
Find the Input (Afferent) and the
Output (Efferent)
Chapter 10 : Finalizing Design Specification
Design Structure Charts Approach
Steps to design Transform flow and
Transaction flow
Find the processing process
Find the Input (Afferent) and the
Output (Efferent)
Chapter 10 : Finalizing Design Specification
Design Structure Charts Approach
Steps to design Transform flow
Step 1 : ทาการตั้ง Module Commander อยูใ่ นระดับที่ 1 ซึ่งเป็ น
process module ที่เรี ยกใช้ process module อื่นๆ เรามักตั้งชื่อว่า
Main Menu
Step 2 : ทาการตั้งระดับที่ 2 ซึ่งเป็ น Process Afferent สุ ดท้ายที่เจอ
หรื อก็คือในส่ วนของ Input นั้นเอง และทาไปเรื่ อยๆจนกว่าจะครบในส่ วนของ
Afferent ทั้งหมด
Step 3 : ตั้ง Transformation process module ซึ่งถ้ามีเพียง
Process เดียวก็เขียนได้เลยแต่ถา้ มีมากกว่า ต้องมี Transformation
Controller ก่อน
Chapter 10 : Finalizing Design Specification
Design Structure Charts Approach
Steps to design Transform flow
Step 4 : พิจารณาหา Efferent (Output) เช่นเดียวกันกับกรณี ของ
Afferent (Input) แต่ในส่ วนนี้เราจะทาการเขียนไว้ในส่ วนขวามือของ
Transform module
Main Menu
Input
Controller
A
Transform
Controller
C
TA
B
Output
Controller
D
TB
OA
OB
Chapter 10 : Finalizing Design Specification
Design Structure Charts Approach
Transform flow
G
B
D
A
E
F
C
INPUT
H
TRANSFORMATION
OUTPUT
Chapter 10 : Finalizing Design Specification
Design Structure Charts Approach
Steps to design Transaction flow
Step 1 : ทาการตั้ง Module Commander อยูใ่ นระดับที่ 1 ซึ่งเป็ น
process module ที่เรี ยกใช้ process module อื่นๆ เรามักตั้งชื่อว่า
Main Menu
Step 2 : ทาการตั้งระดับที่ 2 ซึ่งเป็ น Process Afferent สุ ดท้ายที่เจอ
หรื อก็คือในส่ วนของ Input นั้นเอง และทาไปเรื่ อยๆจนกว่าจะครบในส่ วนของ
Afferent ทั้งหมด
Step 3 : ตั้ง Transaction process module ซึ่งถ้ามีเพียง
Process เดียวก็เขียนได้เลยแต่ถา้ มีมากกว่า ต้องมี Transaction
Controller ก่อน
Chapter 10 : Finalizing Design Specification
Design Structure Charts Approach
Steps to design Transaction flow
Step 4 : พิจารณาหา Efferent (Output) เช่นเดียวกันกับกรณี ของ
Afferent (Input) แต่ในส่ วนนี้เราจะทาการเขียนไว้ในส่ วนขวามือของ
Transaction module
Main Menu
Input
Controller
A
Transaction
Controller
C
TA
B
Output
Controller
D
TB
OA
OB
Chapter 10 : Finalizing Design Specification
Design Structure Charts Approach
Transaction flow
C
A
B
D
E
H
F
INPUT
TRANSACTION
OUTPUT
Chapter 10 : Finalizing Design Specification
Structure Chart Quality
Assurance Checks
Coupling
Cohesion
Chapter 10 : Finalizing Design Specification
• Coupling:
– Types of coupling: (from best to worst)
• Data coupling — two modules are said to be
data coupled if their dependency is based on
the fact that they communicate by passing of
data.
• Stamp coupling — two modules are said to be
stamp coupled if their communication of data is
in the form of an entire data structure or record.
Chapter 10 : Finalizing Design Specification
• Coupling:
– Types of coupling: (from best to worst)
• Control coupling — two modules are said to be
control coupled if their dependency is based on the
fact that they communicate by passing of control
information or flags.
• Common coupling — modules are said to be
common coupled if they refer to the same global
data area.
• Content coupling — two modules are said to be
content coupled (also referred to as hybrid coupled)
when one module actually modifies the procedural
contents of another module.
Chapter 10 : Finalizing Design Specification
• Cohesion: (from most desirable to least
desirable)
– Functional cohesion — are modules whose
instruction are related because they
collectively work together to accomplish a
single well-define function.
– Sequential cohesion — are modules
whose instructions are related because the
output data from one instruction is used as
input data to the next instruction.
Chapter 10 : Finalizing Design Specification
• Cohesion: (from most desirable to least
desirable)
– Communicational cohesion — are
modules whose instructions accomplish
tasks that utilize the same piece(s) of data.
– Procedural cohesion — are modules
whose instructions accomplish different
tasks, yet have been combined because
there is a specific order in which the tasks
are to be completed.
Chapter 10 : Finalizing Design Specification
• Cohesion: (continued)
– Temporal cohesion — are modules whose
instructions appear to have been grouped
together into a module because of “time”.
– Logical cohesion — are modules that
contain instructions that appear to be
related because they fall into the same
logical class of functions.
– Coincidental cohesion — are modules that
contain instructions that have little or no
relationship to one another.
Types of Data Flow
Transform flow
Transaction
flow
P
BOUNDARY
A
P
A
Central
Transform
INPUT
FUNCTION
A
Afferent
L
OUTPUT
FUNCTION
A
BOUNDARY
B
C
K
Efferent
P
D
P
INPUT
FUNCTION
B
DATA STORE B
E
P
P
F
B
INPUT
OUTPUT
FUNCTION
B
J
TRANSFORM
FUNCTION
A
FUNCTION
C
D
DATA STORE E
H
D
M
DATA STORE D
P
P
I
D
INPUT
FUNCTION
D
GTRANSFORM
FUNCTION B
P
OUTPUT
FUNCTION
C
BOUNDARY
A
P
P
INPUT
FUNCTION
A
OUTPUT
FUNCTION
A
A
START FOR
TRACING
INPUT A
D
K
P
C
INPUT
FUNCTION
B
DATA STORE B
B
F
INPUT
FUNCTION
C
START FOR
TRACING
INPUT B
E
P
OUTPUT
FUNCTION
B
FINISH POINTS
FOR TRACING
INPUTS A & B
P
P
TRANSFORM
FUNCTION
A
J
D
H
D
BOUNDARY
B
L
DATA STORE E
M
DATA STORE D
D
START FOR
TRACING
INPUT D
INPUT
FUNCTION
D
P
P
P
G
TRANSFORM
FUNCTION B
I
FINISH POINT
FOR TRACING
INPUT D
OUTPUT
FUNCTION
C
Example of Transform
BOSS
E
J
F
INPUT
FUNCTION
B
C
INPUT
FUNCTION
C
G
E, F, & G
INPUT
FUNCTION
D
I
CENTRAL
TRANSFORM
CONTROLLER
OUTPUT
FUNCTION
C
OUTPUT
FUNCTION
B
K
E&F
J
INPUT
FUNCTION
A
J&I
TRANSFORM
FUNCTION
A
G&H
I
TRANSFORM
FUNCTION
B
OUTPUT
FUNCTION
A
Example of Transaction
BOUNDARY
A
TRANSACTION
BOUNDARY
B
P
P
INPUT
FUNCTION
A
PROCESS
TRANSACTION
TYPE A
TYPE A
RESULT
RESULT
TRANSACTION
TYPE A
VALID
TRANSACTION
P
P
TRANSACTION
TYPE B
PROCESS
TRANSACTION
TYPE B
P
TYPE B
RESULT
TRANSACTION
CENTER
A
TRANSACTION
TYPE C
TYPE C
RESULT
P
PROCESS
TRANSACTION
TYPE C
DISPLAY
RESULT
Example of Transaction
BOSS
TRANSACTION
TYPE A, B, OR
C RESULT
INPUT
FUNCTION
A
TYPE A, B, OR
C RESULT
VALID
TRANSACTION
TRANSACTION
CENTER
TYPE A
RESULT
TRANSACTION
TYPE A
PROCESS
TRANSACTION
TYPE A
DISPLAY
RESULT
TYPE C
RESULT
TRANSACTION
TYPE B
TYPE B
RESULT
PROCESS
TRANSACTION
TYPE B
TRANSACTION
TYPE C
PROCESS
TRANSACTION
TYPE C