Chapter 10 : Finalizing Design Specification

Chapter 10 : Finalizing Design Specification
Learning Objective Introduction The Process of Finalizing Design Specification Representing Design Specifications

Introduction เนื่องจากความต้องการระบบในปัจจุบันนี้มีการพัฒนาเป็นไปอย่างรวดเร็วมากยิ่งขึ้นกว่าในอดีต การทำการตรวจสอบในแบบดั้งเดิมนั้นมักจะกระทำระหว่างการ Design และการ Implement โดยมักทำเมื่อเสร็จขั้นตอนการ Design แล้ว ส่วนวิธีการอื่นๆนั้นมักมีการทำในระหว่างขั้นการ Design และขั้นการ Implement ไปพร้อมๆกัน

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

Quality requirement statements Correct Feasible Necessary Prioritized Unambiguous Verifiable

Quality requirements Completely Do not conflict with other requirement Easy to change without adversely affecting other requirements Traceable back to origin

Deliverables and outcome Set of physical design specification contain detailed specifications for each part of the system

Representing Design Specifications Traditional Methods 1.Pre-CASE 2.Documents written natural language and augmented with graphical models 3.specification documents

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

Structure Charts Module เป็นส่วนประกอบการทำงานของระบบของเราในส่วนของหน้าที่งานต่างๆที่มีความสำคัญ ในการเขียนทุกครั้งต้องมีโหนดเริ่มต้นเสมอ (Root node) การเข้าและออกของข้อมูลไปยังโมดูลอื่นเป็นไปแบบทางเดียวเท่านั้น (One way) การสื่อสารระหว่างโมดูลทำได้โดยการส่งผ่าน Parameters

Structure Charts Symbol of Module Name Types of communication parameters Data couple : เป็นเครื่องมือที่ใช้ในการส่งผ่านข้อมูลกันระหว่างโมดูลต่างๆ Flag : เป็นเครื่องมือที่ใช้ควบคุมการทำงานของโปรแกรมว่าจะทำงานอย่างไร เช่น Error message

Structure Charts Symbol of communication parameters Data couple Flag

Structure Charts Symbol of Specials Module Diamond : Have condition to selected Name

Structure Charts Symbol of Specials Module Curve line : Repeatedly until terminating condition is met Name

Structure Charts Symbol of Specials Module Predefined Module : เป็นโมดูลที่เราเคยกล่าวถึงหรือมีอยู่ก่อนหน้านี้แล้ว Name

Structure Charts Symbol of Specials Module Embedded Module (Hat) : เป็นโมดูลที่อยู่ด้านล่างที่มีความสำคัญแต่มีคำสั่งไม่เยอะเลยฝังไว้กับตัวด้านบนแทน Name

Design Structure Charts Approach การออกแบบนั้นมีพื้นฐานมาจาก DFD ที่ออกแบบมาแล้วข้างต้นแล้วทำการปรับให้มีคุณภาพจากนั้นทำการแบ่งประเภทของStructure Charts โดยสามารถแบ่งได้ 2 รูปแบบตามการไหลของข้อมูล Type of Structure Charts Transform flow Transaction flow

Design Structure Charts Approach Transform flow Find the processing process Find the Input (Afferent) and the Output (Efferent)

Design Structure Charts Approach Steps to design Transform flow and Transaction flow Find the processing process Find the Input (Afferent) and the Output (Efferent)

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 ก่อน

Design Structure Charts Approach Steps to design Transform flow Step 4 : พิจารณาหา Efferent (Output) เช่นเดียวกันกับกรณีของ Afferent (Input) แต่ในส่วนนี้เราจะทำการเขียนไว้ในส่วนขวามือของTransform module Main Menu Transform Controller Input Output B A D C TA TB OA OB

Design Structure Charts Approach Transform flow A C B D E F H G INPUT TRANSFORMATION OUTPUT

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 ก่อน

Design Structure Charts Approach Steps to design Transaction flow Step 4 : พิจารณาหา Efferent (Output) เช่นเดียวกันกับกรณีของ Afferent (Input) แต่ในส่วนนี้เราจะทำการเขียนไว้ในส่วนขวามือของTransaction module Main Menu Transaction Controller Input Output B A D C TA TB OA OB

Design Structure Charts Approach Transaction flow A C B D E F H INPUT TRANSACTION OUTPUT

Structure Chart Quality Assurance Checks
Chapter 10 : Finalizing Design Specification Structure Chart Quality Assurance Checks Coupling Cohesion

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.

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.

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.

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.

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

Central Transform Afferent Efferent

Example of Transform

Example of Transaction

Chapter 10 : Finalizing Design Specification

งานนำเสนอที่คล้ายกัน

งานนำเสนอเรื่อง: "Chapter 10 : Finalizing Design Specification"— ใบสำเนางานนำเสนอ:

งานนำเสนอที่คล้ายกัน

เรื่องโครงการ

การติดต่อกลับ

เข้าสู่ระบบ

ลงทะเบียนผ่านเครือข่ายสังคม:

Chapter 10 : Finalizing Design Specification

งานนำเสนอที่คล้ายกัน

งานนำเสนอเรื่อง: "Chapter 10 : Finalizing Design Specification"— ใบสำเนางานนำเสนอ:

งานนำเสนอที่คล้ายกัน

เรื่องโครงการ

การติดต่อกลับ