Transcript วิศวกรรมซอฟต์แวร์ Software Engineering

แบบจำลองระบบและแบบจำลองขั้นตอนกำรทำงำน
(System Model & Process Model)
อ.ดร.มหศักดิ์ เกตุฉ่ำ
Faculty of Information
Technology
Outline
1
ควำมสำคัญของแบบจำลอง
2
แบบจำลองตำมแนวทำงเชิงโครงสร้ ำง
3
แบบจำลองตำมแนวทำงเชิงวัตถุ
2
ทำไมต้องมีแบบจำลอง
•เป็ นเครื่ องมือที่ใช้แทนกำรสื่ อสำรด้วยข้อควำมหรื อคำูด
•เป็ นเครื่ องมือที่ช่วยให้กำรสื่ อสำรระหว่ำงกลุ่มบุคคล
มีควำมถกต้องตรงกัน
•เกิดขึ้นระหว่ำงกำรวิเครำะห์ควำมต้องกำร และนำไปใช้
ในกำรออกแบบระบบ
แบบจำลองกำรวิเครำะห์ (Analysis Model)
แบบจำลอง คือ สัญลักษณ์ที่ใช้จำลองข้อเท็จจริ ง
ต่ำงๆ ที่เกิดขึ้นในระบบ เป็ นแผนภำูที่แสดงให้เห็นใน
แต่ละมุมมองของระบบ
แบบจำลองกำรวิเครำะห์ คือ แบบจำลองที่เขียนขึ้น
จำกข้อกำหนดควำมต้องกำรของระบบ สะท้อนให้เห็น
ถึงหน้ำที่กำรทำงำนของระบบด้ำนต่ำงๆ และจะถก
นำไปใช้ในระยะกำรออกแบบต่อไป
ควำมสำคัญของแบบจำลอง
•แบบจำลองเป็ นเครื่องมือสำคัญที่ช่วยให้ กำรสื่ อสำร
ระหว่ ำงบุคคลทุกฝ่ ำยมีควำมถูกต้ องตรงกันมำกขึน้
•แบบจำลองประกอบด้ วยรู ปภำพสั ญลักษณ์ แสดงให้ เห็น
กำรทำงำนของระบบ หรือแสดงให้ เห็นหน้ ำทีข่ องระบบ
โครงสร้ ำง และส่ วนประกอบต่ ำง ๆ
•แบบจำลองเป็ นสิ่ งทีไ่ ด้ จำกกำรวิเครำะห์ ควำมต้ องกำร
ของผู้ใช้ ท้งั ในด้ ำนระบบและซอฟต์ แวร์
ควำมสำคัญของแบบจำลอง
•แบบจำลองสะท้ อนให้ เห็นหน้ ำที่กำรทำงำนของระบบในด้ ำนต่ ำง
ๆ ได้ อย่ ำงชัดเจน
•ระบบทำหน้ ำที่อะไร (What) และอย่ ำงไร (How)
• มีกำรสร้ ำงแบบจำลองในระยะกำรวิเครำะห์ ควำมต้ องกำร และ
เป็ นจุดเริ่มต้ นของกำรสร้ ำงแบบจำลองระยะอืน่ ๆ
•นำแบบจำลองจำกระยะกำรวิเครำะห์ ไปใช้ เพือ่ กำหนดรำยละเอียด
ทำงด้ ำนเทคนิคเพิม่ เติม เพือ่ นำไปเขียนโปรแกรม
•สิ่ งที่ได้ จำกระยะกำรออกแบบ คือ แบบจำลองของกำรออกแบบ
ควำมสั มพันธ์ ระหว่ ำงแบบจำลองของกำรวิเครำะห์ และกำรออกแบบ
•เนื่องจำกเอกสำรข้ อกำหนดควำมต้ องกำรเป็ นเครื่องมือที่ผ้ ูใช้ หรือ
ลูกค้ ำนำมำประเมินระบบหรือซอฟต์ แวร์ เพือ่ พิจำรณำยอมรับให้
นำมำใช้ งำนได้
•ข้ อกำหนดควำมต้ องกำรหรือรำยละเอียดของระบบ (System
Description) แบบจำลองของกำรวิเครำะห์ (Analysis Model)
และแบบจำลองของกำรออกแบบ (Design Model) มี
ควำมสั มพันธ์ กนั อย่ ำงต่ อเนื่องเป็ นลูกโซ่
ควำมสั มพันธ์ ระหว่ ำงแบบจำลองของกำรวิเครำะห์ และกำรออกแบบ
System
Description
Analysis
Model
Design
Model
แบบจำลองกำรวิเครำะห์ (Analysis Model)
ประเภท
•แบบจำลองตำมแนวทำงเชิงโครงสร้ำง (Structured Analysis) –
Process Model (DFD) + Data Model (ER)
•แบบจำลองตำมแนวทำงเชิงวัตถุ (Object Oriented Analysis) –
UML (Unified Modeling Language)
แบบจำลองเชิงโครงสร้ำง (Structured Analysis)
•ูิจำรณำข้อมล (Data) และกระบวนกำร (Process) แยกกัน
•แบ่งออกเป็ น 2 ชนิด คือ
•แบบจำลองกระบวนกำร (Process Model) จำลองขั้นตอน
กำรทำงำนของระบบ - DFD
•แบบจำลองข้อมล (Data Model) จำลองโครงสร้ำงข้อมล
ทั้งหมดในระบบ - ERD
แบบจำลองกระบวนกำร (Process Model)
แผนภำพกระแสข้ อมูล (Data Flow Diagram : DFD)
•แผนภำูที่แสดงถึงทิศทำงกำรไหลของข้อมลที่มีอยใ่ นระบบ
• จำกกระบวนกำรทำงำนหนึ่งไปอีกกระบวนกำรหนึ่ง หรื อ
ไปยังส่ วนอื่นที่เกี่ยวข้อง เช่น แหล่งจัดเก็บข้อมล (Data
Store) ผท้ ี่เกี่ยวข้องที่อยน่ อกระบบ (External Agent)
•นำ DFD ไปเป็ นแนวทำงในกำรออกแบบ ฐำนข้อมล
แบบจำลองกระบวนกำร (Process Model)
•ประเภทของแผนภำพกระแสข้ อมูล
- แผนภำพกระแสข้ อมูล เชิงตรรกะ (Logical DFD) –
แสดงกระบวนกำรของระบบในระดับแนวคิด (Conceptual)
เท่ำนั้น
- แผนภำพกระแสข้ อมูล เชิงกำยภำพ (Physical DFD) –
แสดงรำยละเอียดภำยในกระบวนกำร เช่น ชื่อกระบวนกำร
วิธีกำรทำงำน แหล่งกำเนิด และปลำยทำง เป็ นต้น
สัญลักษณ์ของ DFD
Process id
Process name
External
Agent
Flow Direction
ID Data Store
หลักกำรของ DFD
•แบ่งกำรทำงำนจำกกระบวนกำรหลักที่อยร่ ะดับบน ลง
ไปส่ กระบวนกำรย่อยที่อยร่ ะดับล่ำง
•DFD ระดับบนสุ ด Context Diagram
•เริ่ มสร้ำง DFD ต้องเริ่ มจำก Context Diagram เูื่อแสดง
ให้เห็นภำูรวมของระบบ
Context Diagram
•แผนภำูกระแสข้อมลระดับบนสุ ด
•แสดงภำูรวมกำรทำงำนของระบบที่สมั ูันธ์กบั
สภำูแวดล้อมภำยนอกระบบ
•กำหนดขอบเขตของระบบที่จะูัฒนำได้
ตัวอย่ำง Context Diagram
0
บริษัทคู่ค้ำ
สิ นค้ำใหม่
ระบบ
ร้ ำนขำยสิ นค้ ำ
กำหนดรำคำขำย
สิ นค้ำที่ตอ้ งกำร
ลูกค้ ำ
ใบเสร็จรับเงิน
รำยงำนกำรขำย
รำยงำนสต๊อกสิ นค้ำ
เจ้ ำของร้ ำน
Context Diagram ของระบบร้ ำนขำยสิ นค้ ำ (Seller System)
อธิบำย Context Diagram
•ระบบร้ำนขำยสิ นค้ำจะต้องปฏิสมั ูันธ์กบั บุคคลอื่น หรื อ
หน่วยงำนอื่นที่อยน่ อกระบบ 3 กลุ่ม คือ
•บริษทั คู่ค้ำ หมำยถึง ร้ำนค้ำ หรื อบริ ษทั ที่ระบบจัดซื้ อสิ นค้ำเข้ำ
มำขำย
•ลูกค้ ำ หมำยถึง ผท้ ี่มำซื้อ หรื อมำชมสิ นค้ำ
•เจ้ ำของร้ ำน หมำยถึง ผท้ ี่กำหนดรำคำขำย และ ต้องกำรรำยงำน
ต่ำงๆ จำกระบบ เช่น รำยงำนกำรขำยประจำวัน รำยงำนสต๊อก
สิ นค้ำคงเหลือ
Data Flow Diagram Level 0
•จำกภำูรวมของระบบร้ำนขำยสิ นค้ำ จะต้องมีกำรขยำย หรื ออธิบำย
ระบบย่อย หรื อรำยละเอียดย่อยของระบบ
•สร้ำง DFD ระดับถัดมำ คือ ระดับ 0 เูื่อแสดงให้เห็นกระบวนกำร
ทำงำนภำยในของระบบ
•หำกกระบวนกำรในระดับ 0 แต่ละกระบวนกำร ยังมีกำรอธิบำย
รำยละเอียดหรื อกำรทำงำนปลีกย่อยลงไปอีก สำมำรถเขียน DFD ใน
ระดับ 1 หรื อ 2 หรื อ 3 ต่อไปได้อีก
*** กำรแตกระบบ ระบบนั้นควรแตกได้อย่ำงน้อย 2 กระบวนกำร
ตัวอย่ำง Data Flow Diagram Level 0
บริษัทคู่ค้ำ
รองเท้ำใหม่
สิ นค้ำที่ตอ้ งกำร
2.0
ใบเสร็จรับเงิน
ขำยสิ นค้ ำ
1.0
ข้ อมูล
สิ นค้ ำ
ข้อมลสิ นค้ำ
ลูกค้ ำ
ข้อมลกำรขำย
ข้อมลสิ นค้ำ
D2 รำยกำรขำย
D1 สิ นค้ ำ
ข้อมลกำรขำย
3.0
ข้อมลสิ นค้ำ
กำหนดรำคำขำย
เจ้ ำของร้ ำน
รำยงำนสต๊อกสิ นค้ำ
รำยงำนกำรขำย
DFD Level 0 ของระบบร้ ำนขำยสิ นค้ ำ
รำยงำน
ตัวอย่ำง Data Flow Diagram Level 1
2.1
ข้อมลสิ นค้ำ
ตรวจสอบ
สิ นค้ ำ
D1 สิ นค้ ำ
รำคำ
2.2
ลดจำนวนสิ นค้ำ
ลูกค้ ำ
สิ นค้ำที่ตอ้ งกำร
บันทักกำรขำย
ใบเสร็จรับเงิน
ข้อมลกำรขำย
D2 รำยกำรขำย
2.2
ข้อมลกำรขำย
DFD Level 1 ของกระบวนกำร 2.0 ขำยสิ นค้ ำ
พิมพ์ใบเสร็จ
แผนภำูแสดงควำมสัมูันธ์ระหว่ำงข้อมล
•เรี ยกว่ำ Entity Relationship Diagram
•หรื อเรี ยกย่อๆ ว่ำ E-R Diagram
•เป็ นแผนภำูที่ใช้เป็ นเครื่ องมือสำหรับจำลองข้อมล
•ประกอบด้วย Entity (กลุ่มของข้อมลที่เป็ นเรื่ องเดียวกัน)
•และ Relationship หรื อ ควำมสัมูันธ์ระหว่ำงข้อมลใน entity
•ทุก Entity จะมี Attribute บอกลักษณะหรื อคุณสมบัติ
สัญลักษณ์ที่ใช้ใน E-R Diagram
Attribute2
Attribute1
Entity2
Relation Name
Entity1
Attribute3
Attribute4
ระบบงำนขำย
•Customer (Customer_ID, Name, Address)
•Order (Order_ID, Product_ID)
•Sale Order (Sale_ID, Order_ID, Customer_ID)
E-R Diagram ระบบงำนขำย
Order_ID
Order
Customer_ID
Product
1
Order_ID
1
Get Order
Data
Sale_ID
Sale Order
M
ลกค้ำทำกำรสั่งซื้ อสิ นค้ำ (order) และ
ใบสั่งซื้ อจะถกเปลี่ยนเป็ นใบขำยสิ นค้ำ (sale order)
โดยในใบขำยสิ นค้ำ จะมีรหัสของลกค้ำ และ รหัสของ
ใบสั่งซื้ อ เูื่อใช้อำ้ งอิง
Get Customer
Data
Customer
Address
Name
Customer_ID
E-R Diagram ระบบงำนขำย
คำอธิบำย
•Entity Sale Order จะดึงข้อมลใบสัง่ ซื้ อ (Order Data) มำจำก
Entity Order และดึงข้อมลลกค้ำ (Customer Data) มำจำก Entity
Customer
แผนผังโครงสร้ำง (Structure Chart)
•แสดงให้เห็นกำรแบ่งกำรทำงำนของระบบออกเป็ นส่ วนย่อยๆ ที่เรี ยกว่ำ
โมดล (Module)
•เป็ นแผนผังลำดับชั้น แสดงควำมสัมูันธ์ระหว่ำงฟังก์ชนั ของโปรแกรม
•แต่ละโมดลจะมีกำรเรี ยกใช้ขอ้ มลระหว่ำงกันตำมลำดับชั้น
•โมดลระดับบน จะเรี ยกใช้โมดลที่อยร่ ะดับล่ำง
•มีโมดลระดับบนสุ ดเูียงโมดลเดียว เป็ นโมดลหลัก
•โมดลระดับล่ำงสุ ดจะประกอบไปด้วยอัลกอริ ธึมและลอจิกของโปรแกรม
สัญลักษณ์ของ Structure Chart
ชื่อโมดูล
ชื่อโมดูล
โมดล
ชื่อข้อมล
ไลบรำรี โมดล ใช้เก็บฟังก์ชนั กำรทำงำนทั้งหมดของโปรแกรม
ชื่อข้อมล
ข้อมลที่ส่งไปมำระหว่ำงโมดล (couple)
ชื่อข้อมล
ชื่อข้อมล
ข้อมลควบคุม หรื อ Flag
ชื่อโมดูล
กำรเรี ยกใช้งำนโมดลอย่ำงมีเงื่อนไข
เรี ยกใช้โมดลซ้ ำ
กำรอ่ำนและเรี ยกใช้
z
A
z
x
B
x
D
y
C
• A ส่ งข้ อมูล x ไปยัง B
• B ส่ งข้ อมูล x ไปยัง C เพือ่ ประมวลผล
จนได้ ผลลัพธ์ y
• ส่ งข้ อมูล y กลับไปยัง B
• B จะใช้ ข้อมูล y ประมวลผลจนได้ ผล
ลัพธ์ เป็ นข้ อมูล z ที่ A ต้ องกำร
• A ส่ งข้ อมูล z ไป D เพือ่ ประมวลผล
แบบจำลองตำมแนวเชิงวัตถุ
•เชิงโครงสร้ ำง  ทีมงำนจะต้องูิจำรณำกระบวนกำรทำงำน
และข้อมลของระบบแยกส่ วนกัน
•เชิงวัตถุ  ูิจำรณำทุกๆ สิ่ งในระบบที่สนใจเป็ น วัตถุ
(Object) ซึ่งประกอบไปด้วยข้อมล (คุณลักษณะ) และ
กระบวนกำรทำงำน (ูฤติกรรม) นัน่ คือ ูิจำรณำทั้งข้อมลและ
กระบวนกำรไปูร้อมๆ กัน
ระบบตำมแบบจำลองตำมแนวคิดเชิงวัตถุ
•ประกอบด้ วย Object จำนวนมำกทีส่ ั มพันธ์ กนั เพือ่ ทำงำนร่ วมกัน
ให้ เกิดเป็ นกำรทำงำนของระบบ
•Object ทีม่ ีคุณลักษณะและพฤติกรรมเหมือนกัน จะถูกจัดอยู่ใน
คลำส (Class) เดียวกัน
•เช่ น object “นักศึกษำ” , “อำจำรย์ ” , “เจ้ ำหน้ ำที่”
จะถูกจัดอยู่ในคลำส “คน“ เนื่องจำกบุคลำกรจะมีลกั ษณะ หู ตำ
จมูก หรือแขนขำ เหมือนกัน
•คลำส เป็ นเหมือนแม่ พมิ พ์ที่ใช้ สร้ ำง object ของคลำสนั้นๆ
ภำูจำลองของ class Customer
Customer
custId
custName
addCust()
deleteCust()
editCust()
displayInfo()
Class Name
Attribute
Method
(Behavior/
Operation)
UML
•Unified Modeling Language
•ภำษำรปภำูเูื่อใช้สร้ำงแบบจำลองเชิงวัตถุ
•ได้รับกำรยอมรับจำกองค์กร OMG (Object
Management Group)
UML แบ่งเป็ น 2 กลุ่ม
•Structure Diagram
เป็ นกลุ่มแผนภำูที่แสดงให้เห็นโครงสร้ำงเชิงสถิตของระบบ
(Static) หมำยถึง โครงสร้ำงที่ไม่มีกำรเปลี่ยนแปลงหรื อเคลื่อนไหว
แม้จะมีเหตุกำรณ์ใดๆ เกิดขึ้น
•Behavioral Diagram
เป็ นกลุ่มแผนภำูที่แสดงให้เห็นภำูเชิงกิจกรรมของระบบ
(Dynamic) คือ แสดงให้เห็นูฤติกรรมของระบบที่มีกำร
เปลี่ยนแปลงไปเมื่อมีเหตุกำรณ์ใดๆ เกิดขึ้น และแสดงให้เห็นถึง
ควำมสำมำรถของระบบที่ดำเนินกำรในหน้ำที่บำงอย่ำงได้
UML แบ่งเป็ น 2 กลุ่ม
• Structure Diagram
•
•
•
•
Class Diagram
Object Diagram
Component Diagram
Deployment Diagram
• Behavioral Diagram
•
•
•
•
•
Use Case Diagram
Sequence Diagram
Collaboration Diagram
State Diagram
Activity Diagram
Class Diagram
•ประกอบด้วย Class และควำมสัมูันธ์ระหว่ำง Class เช่น
Dependency, Generalization, Association เป็ นต้น
• Class Diagram สำมำรถแสดงรำยละเอียดว่ำมี Method และ
Attribute อย่ำงไร
Class Diagram
ที่มา http://www.thaiall.com/uml/indexo.html
Class Diagram
ที่มา http://www.thaiall.com/uml/indexo.html
Object Diagram
•ประกอบด้วย Object และ Relation ระหว่ำง Object โดยแต่ละ Object จะ
แสดง Instance ของแต่ละ class ที่มีในระบบ และควำมสัมูันธ์ระหว่ำง
Class เช่น Dependency, Generalization หรื อ Association ซึ่งมีลกั ษณะ
เช่นเดียวกับ Class Diagram
•Class
Object
- ประชำชน
- บุรินทร์
- แม่น้ ำ
- วัง
- รถยนต์
- นิสสัน
- กีฬำ
- โยคะ
Object Diagram
ที่มำ http://www.thaiall.com/uml/indexo.html
Component Diagram
•เป็ น Diagram ซึ่งแสดงโครงสร้ำงทำงกำยภำูของ
Software โดยจะประกอบด้วยองค์ประกอบซึ่ งอยใ่ นรป
ต่ำงๆ เช่น Binary, text และ executable ภำยใน
Component Diagram ก็จะมีควำมสัมูันธ์แสดงอย่
เช่นเดียวกับ Class Diagram, Object Diagram
Component Diagram
ที่มำ http://www.thaiall.com/uml/indexo.html
Deployment Diagram
•เป็ นสิ่ งที่สำมำรถทำกำรแสดงระบบสถำปั ตยกรรมของ
Hardware/Software ตลอดจนควำมสัมูันธ์ระหว่ำง
hardware/software
ที่มา http://www.thaiall.com/uml/indexo.html
Use case Diagram
เป็ น Diagram ที่ทำหน้ำที่ Capture requirement
1. เป็ นเทคนิคในกำรสร้ำงแบบจำลอง เูื่อใช้อธิบำยหน้ำที่ของระบบ
ใหม่ หรื อระบบปัจจุบนั
2. กระบวนกำรสร้ำง Use case เป็ นแบบวนซ้ ำ (Iteration)
3. องค์ประกอบมี Use case, Actor, Use case Relation และ System
4. ควำมต้องกำรของระบบจะได้จำก ลกค้ำ ผใ้ ช้ + ผู้ ฒั นำระบบ
Use case Diagram
ที่มา http://www.thaiall.com/uml/indexo.html
Use case Diagram
ที่มา http://www.thaiall.com/uml/indexo.html
Use case Diagram
ที่มา http://www.thaiall.com/uml/indexo.html
Sequence Diagram
•แสดงลำดับกำรทำงำนของระบบ โดยมี Object และ
เวลำ เป็ นตัวกำหนดลำดับของงำน และเน้นไปที่ instant
ของ Object
1. Simple : ย้ำยกำรควบคุมระหว่ำงวัตถุ
2. Synchronous : ติดต่อแบบรอคำตอบ ก่อนทำงำนอื่นต่อไป
3. Asynchronous : ติดต่อแบบไม่รอคำตอบที่กลับมำ
Sequence Diagram
ที่มา http://www.thaiall.com/uml/indexo.html
Collaboration Diagram
•แสดงลำดับกำรทำงำนของ วัตถุ ผเ้ กี่ยวข้อง และกิจกรรม โดย
ลำดับกำรทำงำนไม่ข้ ึนกับเวลำ เูรำะกำรแสดงควำมสัมูันธ์
ของ Object กับเวลำเป็ นหน้ำที่ของ Sequence Diagram
Collaboration Diagram
เส้ นลูกศรครึ่งเดียว คือ ติดต่อแบบไม่รอคำตอบที่กลับมำ
ที่มา http://www.thaiall.com/uml/indexo.html
State Diagram
•ประกอบด้วย State ต่ำงๆ ของ Object และเหตุกำรณ์ต่ำงๆ ที่ทำ
ให้สถำนะของ Object เปลี่ยนและกำรกระทำที่เกิดขึ้นเมื่อ
สถำนะของระบบเปลี่ยนไป สำมำรถบอกสถำนะของ Object
ได้ โดยจะให้ควำมสนใจว่ำ ณ เวลำใดๆ Object นั้นมี status
เป็ นแบบใด
ที่มา http://www.thaiall.com/uml/indexo.html
Activities Diagram
•แสดงลำดับ กิจกรรมของกำรทำงำน(Work Flow) สำมำรถแสดง
ทำงเลือกที่เกิดขึ้นได้ Activity Diagram จะแสดงขั้นตอนกำรทำงำน
ในกำรปฏิบตั ิกำร โดยประกอบไปด้วยสถำนะต่ำงๆ ที่เกิดขึ้น
ระหว่ำงกำรทำงำน และผลจำกกำรทำงำนในขั้นตอนต่ำง ๆ
•วงกลมสี ดำ คือ จุดเริ่ มต้น เรี ยก Initial State
•วงกลมสี ดำ มีวงล้อมอีกชั้น คือ จุดสิ้ นสุ ด เรี ยก Final State
Activities Diagram
ที่มา http://www.thaiall.com/uml/indexo.html
Start
Stop
สรุ ป
•ทีมงำนจำเป็ นต้องสร้ำงแบบจำลองชนิดต่ำง ๆ เูื่อช่วยให้กำรสื่ อสำรมี
ควำมถกต้อง ตรงกัน
•แบบจำลอง (Model) จะประกอบด้วยรปภำูสัญลักษณ์ เูื่อใช้อธิบำย
แทนสิ่ งต่ำง ๆ ในระบบ ทำให้เข้ำใจง่ำยขึ้น
•เมื่อเข้ำส่ ระยะกำรออกแบบ ทีมงำนจะต้องนำแบบจำลองที่ได้จำกระยะ
กำรวิเครำะห์มำใช้ เูื่อกำหนดรำยละเอียดต่ำง ๆ ด้ำนเทคนิคเูิ่มเติม
ให้สำมำรถสื่ อสำรกับโปรแกรมเมอร์ต่อไปได้ง่ำยขึ้น
•แบบจำลองตำมแนวทำงกำรวิเครำะห์และออกแบบระบบมี 2 แนวทำง
ได้แก่ แนวทำงเชิงโครงสร้ำง (Structured System Approach) และ
แนวทำงเชิงวัตถุ (Object-Oriented Approach)
สรุ ป
•แนวทำงเชิงโครงสร้ำงจะูิจำรณำขั้นตอนกำรทำงำนของระบบแยก
ส่ วนจำกข้อมลของระบบ
•แบบจำลองเชิงโครงสร้ำง มี 2 ประเภท
•แบบจำลองกระบวนกำรทำงำนของระบบ (Process Model)
•แบบจำลองข้อมล (Data Model)
•แบบจำลองกระบวนกำรทำงำนของระบบ จะแสดงให้เห็นขั้นตอนกำร
ทำงำนทั้งหมดของระบบ
•แผนภำูที่ใช้ คือ แผนภำูกระแสข้อมล (Data Flow Diagram :
DFD)
สรุ ป
•แบบจำลองข้อมล ใช้แสดงข้อมลและควำมสัมูันธ์ระหว่ำงข้อมล
ทั้งหมด
•แผนภำูที่ใช้คือ แผนภำูแสดงควำมสัมูันธ์ระหว่ำงข้อมล
(Entity Relationship Diagram : ERD)
•ทีมงำนสำมำรถสร้ำงแบบจำลองใดก่อนก็ได้ และเมื่อเข้ำส่ ระยะ
กำรออกแบบแล้ว ทีมงำนสำมำรถนำ DFD และ ERD จำกกำร
วิเครำะห์ไปกำหนดรำยละเอียดทำงเทคนิคเูิ่มเติมได้
•DFD ที่สร้ำงในระยะกำรออกแบบ เรี ยกว่ำ DFD ระดับกำยภำู
(Physical DFD)
สรุ ป
•แนวทำงเชิงวัตถุ จะูิจำรณำสิ่ งต่ำง ๆ ในระบบเป็ นวัตถุ (Object)
•แต่ละอ็อบเจ็กต์จะประกอบด้วยข้อมลและขั้นตอนกำรทำงำนรวมอย่
ด้วยกัน
•แนวทำงเชิงวัตถุ ช่วยให้ทีมงำนวิเครำะห์ควำมต้องกำรได้รวดเร็ วขึ้น
•แบบจำลองเชิงวัตถุ (Object Model) ที่สะท้อนให้เห็นมุมมองด้ำนต่ำง
ๆ ของอ็อบเจ็กต์ในระบบได้
•ภำษำที่ใช้สร้ำงแบบจำลองเชิงวัตถุที่นิยมใช้คือ UML (Unified
Modeling Language)
สรุ ป
•UML แบ่งออกเป็ น 2 กลุ่ม
•Structural Diagram ใช้แสดงโครงสร้ำงของระบบ เป็ นโครงสร้ำงที่ไม่
มีกำรเปลี่ยนแปลง
• Class Diagram, Object Diagram, Component Diagram และ Deployment
Diagram
•Behavioral Diagram ใช้แสดงูฤติกรรมของระบบที่มีกำร
เปลี่ยนแปลงตำมเหตุกำรณ์
• Use Case Diagram, Sequence Diagram, Collaboration Diagram,
Statechart Diagram และ Activity Diagram
แบบจำลองขั้นตอนกำรทำงำนของระบบ
Process Model
แบบจำลองขั้นตอนกำรทำงำนของระบบ
• แบบจำลองที่แสดงให้เห็นขั้นตอนกำรทำงำนของระบบ
• เูื่อจำลองขั้นตอนกำรทำงำนของระบบที่อยใ่ นรปข้อควำม
ให้เป็ นแผนภำูเูื่อควำมสะดวกในกำรสื่ อสำรระหว่ำง
นักวิเครำะห์ระบบกับผเ้ กี่ยวข้อง
• ใช้เครื่ องมือ “แผนภำูกระแสข้อมล” (Data Flow
Diagram : DFD)
• เป็ นแบบจำลองทำงตรรกะ (Logical Model)
แผนภำูกระแสข้อมล (DFD)
•แผนภำูที่แสดงให้เห็นกำรเคลื่อนที่ของข้อมลระหว่ำงผท้ ี่เกี่ยวข้องกับ
ระบบ (External Agent) และขั้นตอนกำรทำงำน (Process)
ตลอดจนแหล่งจัดเก็บข้อมล (Data Store) ภำยในระบบ
•นำ DFD ไปเป็ นแนวทำงในกำรออกแบบ ฐำนข้อมล
ตัวอย่ำง
ควำมต้องกำรสื บค้น
ลูกค้ ำ
ข้อมลประเภทสิ นค้ำ
1.0
ข้อมลสิ นค้ำ
ตรวจสอบสิ นค้ ำ
ทีม่ ีจำหน่ ำย
จำนวนสิ นค้ำในสต๊อก
ข้อมลสิ นค้ำที่ตอ้ งกำรค้น
ประเภทสิ นค้ ำ
สิ นค้ ำ
สต๊ อกสิ นค้ ำ
ตัวอย่ำง
Item Inquiry
Catalog Data
1.0
Cutstomer
Product Data
Look up item
availability
Inventory Data
Item Availability Detail
Catalog
Product
Inventory
ตัวอย่ำง
Invoice, Product
Delivery No.
4.1
Sale Order Data
Sale Order
Compute
Customer
Invoice Data
4.2
Printing
Invoice
Sale
Management
Invoice Amount
สัญลักษณ์ที่ใช้ใน DFD
DeMarco &
Yourdon
Gane & Sarson
ควำมหมำย
Process – ขั้นตอนกำรทำงำนภำยในระบบ
Data Store – แหล่ งข้ อมูลสำมำรถเป็ นได้
ทั้งไฟล์ ข้อมูลและฐำนข้ อมูล
External Entity - ปัจจัยหรือ
สิ่ งแวดล้ อมที่มีผลกระทบต่ อระบบ
Data Flows – เส้ นทำงกำรไหลของข้ อมูล
แสดงทิศทำงของข้ อมูลจำกขั้นตอนกำร
ทำงำนหนึ่งไปยังอีกขั้นตอนหนึ่ง
กระบวนกำร (Process)
• คือ งำนที่ดำเนินกำร หรื อ ตอบสนองข้อมลที่รับเข้ำ เงื่อนไข หรื อ
สภำวะใด ๆ ที่เกิดขึ้น ไม่วำ่ ขั้นตอนกำรดำเนิ นงำนนั้นจะกระทำโดย
บุคคล หน่วยงำน หุ่นยนต์ เครื่ องจักร หรื อ เครื่ องคอมูิวเตอร์ ก็ตำม
Input
ขั้นตอนกำรทำงำน
ของระบบ
สภำวะแวดล้อมของระบบ (System’s Environment)
Output
กฎของกำรเขียนกระบวนกำร
X.X
• ต้ องไม่มีข้อมูลรับเข้ าเพียงอย่างเดียว
ชื่อ Process
• ต้ องไม่มีข้อมูลออกเพียงอย่างเดียว
• ข้ อมูลรับเข้ าจะต้ องเพียงพอในการสร้ างข้ อมูลส่งออก
• การตังชื
้ ่อ Process ต้ องใช้ คากริยา เช่น รายรับการสัง่ ซื ้อ คานวณคะแนนเฉลี่ย
พิมพ์รายงาน เป็ นต้ น
• จานวนกระบวนการที่ต้องทาในระบบไม่ควรมีมากน้ อยเกินไป ควรอยูร่ ะหว่าง 27 (หรื อ +/- 2) กระบวนการ
แหล่งจัดเก็บข้อมล (Data Store)
รหัส
ชื่อ Data Store
• แหล่งจัดเก็บข้ อมูล (Data Store) เป็ นแหล่งเก็บ / บันทึกข้ อมูล เปรี ยบเสมือนคลังสินค้ า
(เทียบเท่ากับไฟล์ข้อมูล และฐานข้ อมูล) โดยมีรายละเอียดและคุณสมบัติเฉพาะตัวของ สิ่งที่ต้องการ
เก็บ / บันทึก
• กฎของ Data Store
• ข้ อมูลจาก Data Store หนึง่ จะวิ่งไปสู่อีก Data Store หนึง่ โดยตรงไม่ได้ (จะต้ องผ่าน Process
ก่อน)
• ข้ อมูลจาก Data Store หนึง่ จะวิ่งไป หรื อ กลับจาก External Entity หนึง่ โดยตรงไม่ได้ (จะต้ องผ่าน
Process ก่อนเช่นกัน)
• การตังชื
้ ่อต้ องใช้ คานาม ที่สื่อความหมาย เช่น ไฟล์ข้อมูลลูกค้ า
ปัจจัยภำยนอกหรื อเอ็นทิตี (External Entity)
• ตัวแทนภายนอก (External Entities) หมายถึง บุคคล หน่วยงานใน
องค์กร องค์กรอื่น ๆ หรื อระบบงานอื่น ๆ ที่อยูภ่ ายนอกขอบเขตของระบบ แต่
มีความสัมพันธ์กบั ระบบ โดยมีการส่งข้ อมูลเข้ าสูร่ ะบบเพื่อดาเนินงาน และ
รับข้ อมูลที่ผา่ นการดาเนินงานเรี ยบร้ อยแล้ วจากระบบ ในบางครัง้ เรี ยก
“External Agent”
• กฎของ External Entities
• ข้ อมูลจาก External Entities หนึง่ จะวิ่งไปสู่อีก External Entities
หนึง่ โดยตรงไม่ได้ (จะต้ องผ่าน Process ก่อน)
• การตังชื
้ ่อต้ องใช้ คานาม ที่สื่อความหมาย เช่น ลูกค้ า
External
Entity
เส้นทำงกำรไหล (Data Flow)
• เส้ นทางการไหลของข้ อมูล (Data Flow) เป็ นการสื่อสารระหว่าง
ขันตอนการท
้
างาน (Process) ต่าง ๆ และสภาพแวดล้ อมภายนอก
หรื อภายในระบบ โดยแสดงถึงข้ อมูลที่นาเข้ าในแต่ละ Process และ
ข้ อมูลที่สง่ ออกจาก Process ใช้ ในการแสดงถึงการบันทึกข้ อมูล การ
ลบข้ อมูล การแก้ ไขข้ อมูลต่าง ๆ
กฎของ Data Flow
• ชื่อของ Data Flow คือชื่อของข้ อมูลที่ส่งโดยไม่ ต้องอธิบำยว่ ำส่ งอย่ ำงไร
• Data Flow ต้ องมีจุดเริ่มต้ นหรือสิน้ สุดที่ Process
• Data Flow จะเดินทำงระหว่ ำง External Entity กับ External Entity ไม่ ได้
• Data Flow จะเดินทำงจำก External Entity ไป Data Store ไม่ ได้
• Data Flow จะเดินทำงจำก Data Store ไป External Entity ไม่ ได้
• Data Flow จะเดินทำงระหว่ ำง Data Store กับ Data Store ไม่ ได้
• กำรตัง้ ชื่อต้ องใช้ คำนำม ที่ส่ ือควำมหมำย เช่ น ใบกำกับสินค้ ำ
ตัวอย่ำงกำรเขียนสัญลักษณ์ใน DFD
ตัวอย่ำงกำรเขียนสัญลักษณ์ใน DFD
ตัวอย่ำงกำรเขียนสัญลักษณ์ใน DFD
ตัวอย่ำงกำรเขียนสัญลักษณ์ใน DFD
ตัวอย่ำงกำรเขียนสัญลักษณ์ใน DFD
ตัวอย่ำงกำรเขียนสัญลักษณ์ใน DFD
ตัวอย่ำงกำรเขียนสัญลักษณ์ใน DFD
หลักกำรของ DFD
•แบ่งกำรทำงำนจำกกระบวนกำรหลักที่อยร่ ะดับบน ลง
ไปส่ กระบวนกำรย่อยที่อยร่ ะดับล่ำง
•DFD ระดับบนสุ ด 
Context Diagram
Context Diagram
•แผนภำูกระแสข้อมลระดับบนสุ ด
•แสดงภำูรวมกำรทำงำนของระบบที่สมั ูันธ์กบั
สภำูแวดล้อมภำยนอกระบบ
•กำหนดขอบเขตของระบบที่จะูัฒนำได้
กำรสร้ำงแผนภำูบริ บท (Context Diagram)
• เป็ นโครงสร้ ำงแรกเริ่มในระบบงำนที่จะชีใ้ ห้ เห็นลักษณะงำนและ
ขอบเขตของระบบงำน
• หลักเกณฑ์ กำรใช้ สัญลักษณ์ สร้ ำงแผนภำพกระแสข้ อมูล
• Context diagram ต้ องสมดุลอยู่ภำยในหนึ่งหน้ ำกระดำษ
• ชื่อของกระบวนกำรใน context diagram ควรเป็ นชื่อของ
ระบบงำนหรื อโครงงำน และแสดงหมำยเลขศูนย์ (0)
• มีกำรแสดง entity และกำรไหลของข้ อมูลที่แสดงกำรติดต่ อ
ระหว่ ำงระบบกับสิ่งที่อยู่ภำยนอก
• ไม่ มีกำรแสดงแหล่ งจัดเก็บข้ อมูล (Data Store)
ตัวอย่ำง Context Diagram
Context Diagram ของระบบเช่ำ DVD ของร้ำน ABC บน
Internet
จดหมำย
ยืนยันกำร
สมัคร
กระทู้ทตี่ ้ องกำรเขียน
กระทู้ข่ำว
เงือ่ นไข DVD ทีต่ ้ องกำรค้ น
เงือ่ นไข DVD ทีต่ ้ องกำรค้ น
0
ข้ อมูล DVD ทีค่ ้ นเจอ
ข้ อมูล DVD ทีค่ ้ นเจอ
กระทู้ข่ำว ระบบเช่ ำ
ข้ อมูลกำร Log in
ผู้ใช้ ทวั่ ไป กระทู้ทตี่ ้ องกำรเขียนDVD ของร้ ำน ผลกำร Log in สมำชิก
ข้ อมูลส่ วนตัว
ข้ อมูลสมัครสมำชิก ABC บน
ข้ อมูลส่ วนตัวทีต่ ้ องกำรแก้
ผลกำรสมัครสมำชิก internet
ข้ อมูลกำรค้ ำงคืนแผ่ น DVD
Mail Server
ระบบร้ำนขำยรองเท้ำ
0
บริษัทคู่ค้ำ
รองเท้ำใหม่
รองเท้ำที่ตอ้ งกำร
ลูกค้ ำ
ระบบ
ร้ ำนขำยรองเท้ ำ ใบยืนยันกำรขำย
กำหนดรำคำขำย
รำยงำนกำรขำย
รำยงำนสต๊อกสิ นค้ำ
เจ้ ำของร้ ำน
Context Diagram ของระบบร้ ำนขำยรองเท้ ำ (Shoes Shop System)
ระบบร้ำนขำยรองเท้ำ
• ระบบร้ำนขำยรองเท้ำจะต้องปฏิสมั ูันธ์กบั บุคคลอื่น หรื อหน่วยงำนอื่นที่
อยน่ อกระบบ 3 กลุ่ม คือ
• บริษทั คู่ค้ำ หมำยถึง ร้ำนค้ำ หรื อบริ ษทั ที่ระบบจัดซื้อรองเท้ำเข้ำมำขำย
• ลูกค้ ำ หมำยถึง ผท้ ี่มำซื้อ หรื อมำชมรองเท้ำ
• เจ้ ำของร้ ำน หมำยถึง ผท้ ี่กำหนดรำคำขำย และ ต้องกำรรำยงำนต่ำงๆ จำก
ระบบ เช่น รำยงำนกำรขำยประจำวัน รำยงำนสต๊อกสิ นค้ำคงเหลือ
ระบบร้ำนขำยรองเท้ำ
• จำกภำูรวมของระบบร้ำนขำยรองเท้ำ จะต้องมีกำรขยำย หรื ออธิบำย
ระบบย่อย หรื อรำยละเอียดย่อยของระบบ
• สร้ำง DFD ระดับถัดมำ คือ ระดับ 0 เูื่อแสดงให้เห็นกระบวนกำร
ทำงำนภำยในของระบบ
• หำกกระบวนกำรในระดับ 0 แต่ละกระบวนกำร ยังมีกำรอธิ บำย
รำยละเอียดหรื อกำรทำงำนปลีกย่อยลงไปอีก สำมำรถเขียน DFD ใน
ระดับ 1 หรื อ 2 หรื อ 3 ต่อไปได้อีก
*** กำรแตกระบบ ระบบนั้นควรแตกได้อย่ำงน้อย 2 กระบวนกำร
กำรสร้ำงแผนภำูกำรไหลของข้อมล ระดับที่ 0
Data Flow Diagram Level-0 หรื อ Diagram 0
• จะเป็ นแผนภาพที่ให้ รายละเอียดในระดับแรกสุดรองจาก Context
diagram เพื่อให้ เห็นภาพรวมของระบบมากขึ ้น โดยจะมีสญ
ั ลักษณ์
การเก็บข้ อมูล (data store) , สัญลักษณ์การไหลของข้ อมูล (data
flow) , และสัญลักษณ์การประมวลผล(process)
• Diagram 0 สามารถแสดงให้ เห็นรายละเอียดของกระบวนการทางาน
หลักๆถัดจาก Context Diagram
• แต่ละกระบวนการจะมีหมายเลขกากับด้ านบนของสัญลักษณ์ เริ่มตังแต่
้
หมายเลข 1 เป็ นต้ นไป
• จานวนกระบวนการที่ต้องทาในระบบไม่ควรมีมากน้ อยเกินไป ควรอยู่
ระหว่าง 2-7 (หรื อ +/- 2) กระบวนการ
ตัวอย่ำง Data Flow Diagram Level 0สิ นค้ำที่ตอ้ งกำร ลูกค้ ำ
2.0
บริษัทคู่ค้ำ
1.0
รองเท้ำใหม่
ข้ อมูล
สิ นค้ ำ
ข้อมลสิ นค้ำ
ข้อมลกำรขำย
ข้อมลสิ นค้ำ
D1
ใบเสร็จรับเงิน
ขำย
สิ นค้ ำ
D2
รำยกำรขำย
สิ นค้ ำ
ข้อมลกำรขำย
3.0
ข้อมลสิ นค้ำ
กำหนดรำคำขำย
เจ้ ำของร้ ำน
รำยงำนสต๊อกสิ นค้ำ
รำยงำนกำรขำย
DFD Level 0 ของระบบร้ ำนขำยสิ นค้ ำ
รำยงำน
ตัวอย่ำงของ Data Flow Diagram Level-0 หรื อ Diagram 0
แสดงกำรแบ่งย่อยแผนภำู
Context Diagram
Data Flow Diagram Level-0
กำรแบ่งย่อยแผนภำู (Decomposition Diagram)
• เป็ นวิธีการแบ่งระบบใหญ่ออกเป็ นระบบย่อยๆ โดยระบบหนึ่งที่แสดงใน
Context Diagram ไม่สามารถอธิบาย ไม่สามารถอธิบายการทางาน
ของระบบได้ ทงหมด
ั้
จึงต้ องมีการแบ่งเป็ นระบบย่อยที่มีขนาดเล็กลงเรื่ อยๆจน
สามารถอธิบายระบบทังหมดได้
้
• การแบ่ง DFD ไปเรื่ อยๆจนถึงระดับที่ไม่สามารถแบ่งได้ อีกแล้ ว เรี ยกว่า
Primitive Diagram
• ระดับของแผนภาพที่แบ่งย่อยมาจาก Diagram 0 เรี ยกว่า DFD
Level-1 หรื อเรี ยกว่า Diagram 1 และเป็ น 2 , 3 ….
• ซึง่ การแบ่งย่อยระดับถัดมาจะต้ องมีกระบวนการอย่างน้ อย 2 กระบวนการขึ ้น
ไป
ระบบลงทะเบียนเรี ยน
(Course Registration System)
รำยชื่อนักศึกษำในชั้นเรี ยน
อำจำรย์
ตำรำงสอน
0
ระบบ
ลงทะเบียนเรียน
รำยวิชำที่ตอ้ งกำรลงทะเบียน
นักศึกษำ
ตำรำงเรี ยน
ข้อมลกำรจัดกำรสอน
สำขำวิชำ
Context Diagram ของระบบลงทะเบียนเรี ยน
รำยวิชำที่ตอ้ งกำรลงทะเบียน
สำขำวิชำ
2.0
ลงทะเบียน
1.0
ข้อมลกำรจัดกำรสอน
นักศึกษำ
ตำรำงเรี ยน
จัดตำรำงสอน
ข้อมลรำยวิชำตำม
ตำรำงสอน
ข้อมลตำรำงสอน
D1
ข้อมลกำรลงทะเบียน
D2
ตำรำงสอน
กำรลงทะเบียน
ข้อมลลงทะเบียน
3.0
ข้อมลตำรำงสอน
อำจำรย์
รำยงำน
รำยชื่อนักศึกษำในชั้นเรี ยน
ตำรำงสอน
DFD Level 0 ของระบบลงทะเบียนเรียน
สำขำวิชำ
ข้ อมูลกำรจัดกำรสอน
ข้อมลรำยวิชำ
อำจำรย์ผส้ อน
ห้องที่ใช้สอน
1.1
กำหนด
วันและเวลำ
1.2
กำหนดชื่อ
ผู้สอน
1.3
กำหนด
ห้ องทีใ่ ช้ สอน
ตำรำงสอน
DFD Level 1 ของ Process1.0 จัดตำรำงสอน
D1
ตำรำงสอน
ตัวอย่ำง DFD Level-1
ORDER
REJECT
NOTICE
ORDER
D2 Customers
CREDIT STATUS
PRODUCT DETAIL
D3 Products
PICKING
DETAIL
REJECTED
ORDER
1.1
Verify
Order
1.2
Prepare Reject
Notice
ACCEPTED
ORDER
1.3
Assemble
Order
INVENTORY CHANGE
PICKING LIST
กำรระบุหมำยเลขของแผนภำู
0
1.0
1.1
1.1.1
2.0
1.2
1.1.2
3.0
1.3
1.1.3