Transcript ภาพนิ่ง 1

290355 Software Engineering
บทที่ 4
วิศวกรรมระบบ
เนือ้ หา




กิจกรรมหลักของวิศวกรรมระบบ
วิศวกรรมความต้องการ
กระบวนการวิศวกรรมความต้องการ
โมเดลการวิเคราะห์
 แบบจาลองตามแนวทางเชิ งโครงสร้าง
 แบบจาลองตามแนวทางเชิงวัตถุ
องค์ ประกอบของวิศวกรรมซอฟต์ แวร์


ส่ วนที่ 1 วิศวกรรมระบบ (System Engineering)
ส่ วนที่ 2 วิศวกรรมการผลิต (Development Engineering)
วิศวกรรมระบบ (System Engineering)

วิศวกรรมระบบ หมายถึง กระบวนการศึกษาและวิเคราะห์ของระบบทีม่ ี
ความสลับซับซ้อน เพือ่ สนับสนุนการทางานในส่วนของวิศวกรรมซอฟต์แวร์
กิจกรรมของวิศวกรรมระบบ จะถูกดาเนินการไปพร้อมๆ กับกิจกรรมของ
วิศวกรรมซอฟต์แวร์
วิศวกรรมการผลิต

วิศวกรรมการผลิต (Development Engineering) ซึ่งเป็ นกระบวนการแปร
สภาพความต้องการของระบบ (System Requirements) ให้กลายเป็ น
ซอฟต์แวร์อนั เป็ นเป้ าหมายสาคัญทางด้านวิศวกรรมซอฟต์แวร์
กิจกรรมหลักของวิศวกรรมระบบ
กิจกรรมหลักของวิศวกรรมระบบ มีดงั นี้
 กาหนดวัตถุประสงค์ของระบบ
 กาหนดขอบเขตของระบบ
 แบ่งระบบออกเป็ นส่วนๆ ตามฟงั ก์ชน
ั งานหรือคุณสมบัตริ ะบบ
 พิจารณาความสัมพันธ์ของส่วนประกอบต่างๆ ทีเ่ กีย
่ วข้องทัง้ หมด
 กาหนดความสัมพันธ์ของปจั จัยนาเข้า ประมวลผล และผลลัพธ์
กิจกรรมหลักของวิศวกรรมระบบ




พิจารณาปจั จัยทีม่ สี ว่ นเกีย่ วข้องในระบบ ไม่วา่ จะเป็ นฮาร์ดแวร์ ซอฟต์แวร์
ฐานข้อมูล หรือแม้แต่ผลิตภัณฑ์ซอฟต์แวร์อ่นื ๆ เป็ นต้น
กาหนดความต้องการในส่วนของการดาเนินการและฟงั ก์ชนั งานทัง้ ระบบ
สร้างแบบจาลอง เพือ่ ใช้วเิ คราะห์และพัฒนาให้สอดคล้องกับแบบจาลอง
ซอฟต์แวร์ทส่ี ร้างขึน้
นาเสนอและแลกเปลีย่ นข้อคิดเห็นกับผูท้ เ่ี กีย่ วข้องกับระบบ ไม่วา่ จะเป็ น
ผูใ้ ช้ระบบ เจ้าของระบบ หรือแม้แต่ผทู้ เ่ี กีย่ วข้องกับผลประโยชน์ทม่ี ตี ่อ
ระบบ
วิศวกรรมความต้ องการ
(Requirement Engineering)


การพัฒนา หรื อการผลิตซอฟต์แวร์น้ นั อาศัยความต้องการของผูใ้ ช้มาเป็ น
ตัวกาหนด รู ปลักษณ์ การทางาน ความสามารถ และรายละเอียดอื่น ๆ ของ
ระบบและซอฟต์แวร์
ข้อกาหนดความต้องการที่ไม่ถูกต้องจึงส่ งผลให้ซอฟต์แวร์ไม่ตรงกับความ
ต้องการของผูใ้ ช้
วิศวกรรมความต้ องการ

กระบวนการที่จะทาให้วิศวกรซอฟต์แวร์เข้าใจถึงความต้องการของ
ลูกค้าได้อย่างแท้จริ ง

เป้ าหมายคือ สร้างและบารุ งเอกสารข้อกาหนดความต้องการ ทั้งทาง
ระบบและซอฟต์แวร์ให้เป็ นเอสารที่มีคุณภาพมากที่สุด
วิศวกรรมความต้ องการ
(Requirement Engineering)
User Requirement
แสดงถึงความคาดหวังในการบริ การหรื อการทางานที่จะได้รับจากระบบ
เพื่อสนองความต้องการของตนเอง แสดงออกมาในรู ปแบบของภาษาพูด
หรื อภาษาเขียน


System Requirement
กาหนดความต้องการของการทางาน ฟังก์ชนั และการบริ การต่าง ๆ ของ
ระบบในระดับรายละเอียด ระบุเป็ นเอกสาร เรี ยกอีกอย่างว่า ข้อกาหนด
หน้าที่ของระบบ Functional Specification
กระบวนการวิศวกรรมความต้ องการ
ความต้องการประเภทต่างๆ
Requirement Elicitation
แบบจาลองความต้องการ
Requirement Analysis
ข้อกาหนดความต้องการ
Requirement Specification
เอกสารข้อกาหนดความต้องการ
Requirement Validation
Engineering Requirement Process

สกัดความต้องการ (Requirement Elicitation)




รวบรวมความต้องการและเข้าใจปั ญหาของระบบงาน
ความจาเป็ นของการนาซอฟท์แวร์มาใช้งาน
ความต้องการจากกลุ่มผูใ้ ช้
วิเคราะห์ความต้องการ(Requirement Analysis)




ศึกษาและประเมินความต้องการที่รวบรวมได้
จัดลาดับความสาคัญของความต้องการ
สร้างแบบจาลองระดับแนวคิด (Conceptual Model)
ประชุมและนาเสนอ
Engineering Requirement Process

กาหนดความต้องการ(Requirement Specification)




นิยามความต้องการของระบบ
กาหนดความต้องการด้านระบบ
แจกแจงในรู ปแบบเอกสาร
ตรวจสอบความต้องการ (Requirement Validation)



ทบทวนเอกสารทั้งหมด
ตรวจสอบความสมบูรณ์
ตรงตามเป้ าหมายของการพัฒนาซอฟท์แวร์
เอกสารความต้ องการด้ านซอฟต์ แวร์


เอกสารความต้องการด้านซอฟต์แวร์
Software Requirement Document
หรื อ ข้อกาหนดความต้องการด้านซอฟต์แวร์
Software Requirement Specification: SRS
เอกสารความต้ องการไม่ ใช่ เอกสารประกอบการ
ออกแบบแต่ เป็ นเอกสารของกลุ่มความต้ องการทีก่ ล่ าวว่ า
ระบบควรต้ องทาอะไรบ้ าง จึงเป็ นเสมือนสั ญญาหรือ
ข้ อตกลงระหว่ างผู้พฒ
ั นากับผู้ว่าจ้ าง เพือ่ ให้ ทราบถึง
ขอบเขตในการพัฒนา
เอกสารความต้ องการด้ านซอฟต์ แวร์

เอกสารความต้องการด้านซอฟต์แวร์ ต้องมีรูปแบบที่เป็ นทางการ เพื่อความ
เข้าใจตรงกัน ดังนั้น IEEE และกระทรวงกลาโหมของสหรัฐ จึงได้กาหนด
โครงสร้างของเอกสารไว้ดงั นี้ (Davis, 1993)
โครงสร้ างของเอกสาร SRS
1.
2.
บทนา (Introduction)
- วัตถุประสงค์ของผลิตภัณฑ์
- ขอบเขตของผลิตภัณฑ์
- นิยาม คาย่อ หรื อ อักษรย่อ
- เอกสารอ้างอิง
- สรุ ปส่ วนอื่น ๆ ของเอกสาร
รายละเอียดทัว่ ไป (General Description)
- มุมมองเกี่ยวกับผลิตภัณฑ์
- ฟังก์ชนั ของผลิตภัณฑ์
- คุณสมบัติของผูใ้ ช้
- ข้อบังคับทัว่ ไป
- สมมุติฐานและส่ วนเพิ่มเติม
3.
4.
5.
ข้ อกาหนดความต้ องการ (Specification
Requirement)
- กล่าวถึงความต้องการที่เป็ นหน้าที่หลัก
และไม่ใช่หน้าที่หลัก
- ข้อบังคับในการออกแบบ และการ
แสดงผล เป็ นต้น
ภาคผนวก (Appendices)
ดัชนี (Index)
เอกสาร SRS ที่ดดั แปลงมาจาก
IEEE830,1993[Javadekar,2005]
Chapter/Section
1
1.1
1.2
1.3
1.4
1.5
Topic
Introduction
บทคัดย่อ
วัตถุประสงค์ของเอกสาร
โครงสร้างของเอกสาร
นิยามศัพท์
อื่น ๆ ที่ตอ้ งการอ้างอิงถึง
เอกสาร SRS ที่ดดั แปลงมาจาก
IEEE830,1993[Javadekar,2005]
Chapter/Section
2
2.1
2.2
2.3
2.4
2.5
2.6
Topic
System Description
ภาพรวมของระบบในปั จจุบนั
ปั ญหาที่พบในระบบปั จจุบนั
เป้ าหมายของระบบที่พึงประสงค์
ภาพรวมของระบบที่พึงประสงค์
คุณลักษณะของผูใ้ ช้ระบบ
ข้อสมมุติฐาน
เอกสาร SRS ที่ดดั แปลงมาจาก
IEEE830,1993[Javadekar,2005]
Chapter/Section
3
3.1
3.2
3.2.1
3.2.2
3.2.3
3.3
3.3.1
Topic
Functional Requirements
ฟังก์ชนั หลักของระบบทั้งหมด
ฟังก์ชนั /โมดูล 1
รายละเอียด (สร้างแผนผังประกอบ)
การบรรลุเป้ าหมายที่ตอ้ งการ
ตัวอย่างความต้องการ
ฟังก์ชนั /โมดูล 2
...
เอกสาร SRS ที่ดดั แปลงมาจาก
IEEE830,1993[Javadekar,2005]
Chapter/S
ection
4
4.1
4.2
4.3
4.4
4.5
4.6
4.7
4.8
4.9
Topic
Non-Functional Requirements
ประสิ ทธิ ภาพ
ประโยชน์
ระบบรักษาความปลอดภัยของระบบ
ความปลอดภัยในการใช้งาน
สมรรถภาพ
ส่ วนประสานกับผูใ้ ช้
ความน่าเชื่อถือ
ข้อกาหนดความเป็ นส่ วนตัว
ความสามารถในการดูแลรักษา
Chapter/Se
ction
4.10
4.11
4.12
…
Topic
ความสามารถในการตรวจสอบ
การขยายระบบในอนาคต
การนากลับมาใช้งานได้อีก
...
เอกสาร SRS ที่ดดั แปลงมาจาก
IEEE830,1993[Javadekar,2005]
Chapter/Section
5
6
6.1
6.2
6.3
6.4
6.5
6.6
Topic
Design Constraint
Project Requirement (Optional)
การประมาณการขนาดของซอฟต์แวร์
การประมาณการแรงงานในการผลิต
การประมาณการต้นทุน
ตารางการทางาน
Platform ที่ใช้ในการพัฒนา
เงื่อนไขการยอมรับ
เอกสาร SRS ที่ดดั แปลงมาจาก
IEEE830,1993[Javadekar,2005]
Chapter/Section
A
B
...
Topic
Appendices
ประเด็นที่อยูร่ ะหว่างศึกษา
แบบสารวจความต้องการ
...
แบบจำลองกำรวิเครำะห์ (Analysis Model)


แบบจำลอง คือ สัญลักษณ์ทใ่ี ช้จาลองข้อเท็จจริงต่างๆ ทีเ่ กิดขึน้ ในระบบ
เป็ นแผนภาพทีแ่ สดงให้เห็นในแต่ละมุมมอง
แบบจำลองกำรวิเครำะห์ คือ แบบจาลองทีเ่ ขียนขึน้ จากข้อกาหนดความ
ต้องการของระบบ สะท้อนให้เห็นถึงหน้าทีก่ ารทางานของระบบด้านต่างๆ
และจะถูกนาไปใช้ในระยะการออกแบบต่อไป
ความสาคัญของการวิเคราะห์



เพื่อให้ทราบถึงความเป็ นไปและเป็ นมาของระบบ และขั้นตอนในการ
ปฏิบตั ิงานของระบบ
ก่อนการสร้างบ้าน ผูส้ ร้างย่อมมีความต้องการทราบรายละเอียดถึงตัว
อาคารที่จะจัดสร้าง เพื่อให้ตรงตามความต้องการของผูอ้ ยูอ่ าศัย
เช่นเดียวกันกับระบบ ก่อนจะมีการสร้างระบบ ผูส้ ร้างระบบก็ยอ่ ม
ต้องการทราบความเป็ นไปและเป็ นมาของระบบ เพื่อการออกแบบ
ระบบใหม่ที่ตรงตามความต้องการของผูใ้ ช้ให้มากที่สุด
ความสาคัญของการวิเคราะห์ (ต่อ)


โมเดลที่มกั นาเอามาพิจารณาและวิเคราะห์ระบบ
 Context Diagram
 Data Flow Diagram
 E-R Diagram
 System Flow Chart / Flow Chart
 etc.
ความผิดพลาดของโปรแกรมเมอร์มากมายที่ออกแบบระบบโดยไม่ผา่ น
การวิเคราะห์ ก่อให้เกิดผลเสี ยมากมาย เช่น เวลา, ค่าใช้จ่าย
แบบจำลองกำรวิเครำะห์ (Analysis Model)
แบบจาลองตามแนวทางเชิงโครงสร้าง (Structured Analysis) – Process
Model(DFD) + Data Model (ER)
 แบบจาลองตามแนวทางเชิงวัตถุ (Object Oriented Analysis) – UML
(Unified Modeling Language)
แบบจำลองเชิงโครงสร้ำง (Structure Analysis)


พิจารณาข้อมูล (Data) และกระบวนการ (Process) ทีเ่ ปลีย่ นรูปข้อมูล วัตถุ
ข้อมูลถูกจาลองในลักษณะทีก่ าหนด แอตทริบวิ ส์และความสัมพันธ์
กระบวนการทีจ่ ดั การกับข้อมูล ถูกจาลองในลักษณะทีแ่ สดงว่าสามารถเปลีย่ น
ข้อมูลทีเ่ ป็ นเป็ นวัตถุขอ้ มูลผ่านระบบได้อย่างไร
แบ่งออกเป็ น 2 ชนิด คือ


แบบจาลองกระบวนการ (Process Model) จาลองขัน้ ตอนการทางานของระบบ DFD
แบบจาลองข้อมูล (Data Model) จาลองโครงสร้างข้อมูลทัง้ หมดในระบบ - ERD
แผนภาพกระแสข้อมูล (Data Flow Diagram)


DFD คือ แผนภาพกระแสข้อมูลที่มีการวิเคราะห์แบบในเชิงโครงสร้าง
(Structure) ซึ่งเป็ นแผนภาพที่บอกถึงรายละเอียดของระบบ โดยเฉพาะ
ข้อมูล และผังการไหลของข้อมูล
สิ่ งที่ DFD บอกเรา
 ข้อมูลมาจากไหน
 ข้อมูลไปที่ใด
 ข้อมูลเก็บที่ใด
 เกิดเหตุการณ์ใดกับข้อมูลบ้าง
แบบจำลองกระบวนกำร (Process Model)
 แผนภำพกระแสข้อมูล (Data Flow Diagram)
แผนภาพทีแ่ สดงถึงทิศทางการไหลของข้อมูลทีม่ อี ยูใ่ นระบบ จาก
กระบวนการทางานหนึ่งไปอีกกระบวนการหนึ่ง หรือไปยังส่วนอื่นที่
เกีย่ วข้อง เช่น แหล่งจัดเก็บข้อมูล (Data Store) ผูท้ เ่ี กีย่ วข้องทีอ่ ยูน่ อก
ระบบ (External Agent)
วัตถุประสงค์ของ DFD





เป็ นแผนภาพสรุ ปรวมข้อมูลทั้งหมดที่ได้จากการวิเคราะห์
เป็ นข้อตกลงร่ วมกันระหว่าง SA และ User
เป็ นแผนภาพที่ใช้ในการพัฒนาต่อในขั้นตอนออกแบบ
เป็ นแผนภาพที่ใช้ในการอ้างอิง หรื อเพื่อใช้พฒั นาต่อ
ทราบที่มาที่ไปของกระบวนการต่าง ๆ
ดังนั้น DFD จึงมีความสาคัญมากต่ อการพัฒนาระบบ
ซึ่ง SA หรือ Programmer ไม่ สามารถมองข้ ามได้
ขั้นตอนการวิเคราะห์เพื่อไปสู่การออกแบบ
ความต้ องการ
แผนภำพกระแสข้อมูล (Data Flow Diagram)
•
•
•
เป็ นรูปภาพ สือ่ ความเข้าใจง่าย
มีเพียง 4 สัญญลักษณ์
มีลกั ษณะTop-Down
สัญลักษณ์ที่ใช้ในการออกแบบ
กฎเกณฑ์การเขียนแผนภาพกระแสข้อมูล


สัญลักษณ์ของแผนภาพไม่สามารถเชื่อมต่อกันได้โดยตรง ซึ่งต้องมี
Flow บอกทิศทางของกระแส (Flow ระบุขอ้ มูล)
และการ Flow ทุกครั้งจะต้องผ่าน Process ก่อนทุกครั้ง (ไม่ผา่ นไม่ได้)
 Process = กิริยา
 Flow = ข้อมูล
 Boundaries, Entity = องค์กร, หน่วยงาน
แผนภาพ DFD ที่ถูกต้อง
แผนภาพ DFD ที่ไม่ถูกต้อง
ขั้นตอนการเขียน DFD
1. วิเคราะห์ให้ได้วา่ ระบบประกอบไปด้วย Boundaries ใดบ้างที่เกี่ยวข้อง
2. ดาเนินการออกแบบระบบในระดับหลักการ หรื อ Context Diagram
3. วิเคราะห์ขอ้ มูลในระบบว่าควรมีขอ้ มูลใดบ้าง
4. วิเคราะห์กระบวนการหรื อ Process ในระบบว่า ควรมี Process หลักใด และ
ประกอบไปด้วย Process ย่อยใดบ้าง
5. ดาเนินการเขียนแผนภาพกระแสข้อมูลในระดับต่าง ๆ
6. ทาการตรวจสอบ และปรับแก้ จนได้แผนภาพที่สมบูรณ์
7. อาจใช้ CASE Tools ช่อยในการเขียนแผนภาพ
Data Store


คือแหล่งเก็บข้อมูล เช่น ข้อมูลนักศึกษา, ข้อมูลบุคลากร
โดยภายในสัญลักษณ์สามารถที่จะมีเลขประจาข้อมูลระบุได้
 ลูกศรจาก Data Store หมายถึง Input
 ลูกศร Process ไปยัง Data Store หมายถึง Output
 ลูกศรสองทาง หมายถึง Input/Output
Process
คือ กระบวนการที่ตอ้ งทาในระบบ
โดยจะพิจารณาจากกิริยาหรื อการกระทาภายในระบบเป็ นหลัก
ซึ่งภายใน 1 แผนภาพ ไม่ควรมี Process มากเกินไป(7-2)
ในการเขียน Process จะต้องมีหมายเลขกากับอยูด่ ว้ ย เป็ นลาดับชั้นไล่ไป
เรื่ อย ๆ เพื่อให้ทราบว่า Process ใด มาจาก Process ใด
กฎในการเขียน Data Flow Diagram
ผิด
ถูก
Process ไม่ สามารถมีเฉพาะข้ อมูลออก(output)อย่ างเดียว
เท่ านัน้ ต้ องมีทงั ้ ข้ อมูลเข้ า(input) และข้ อมูลออก
กฎในการเขียน Data Flow Diagram
ผิด
ถูก
Process ไม่ สามารถมีเฉพาะข้ อมูลเข้ า(input)อย่ างเดียว
เท่ านัน้ ต้ องมีทงั ้ ข้ อมูลเข้ า(input) และข้ อมูลออก
กฎในการเขียน Data Flow Diagram
ผิด
ถูก
ข้ อมูลไม่ สามารถเคลื่อนย้ ายจาก Data store หนึ่งไปยังอีก
Data storeหนึ่งได้ โดยตรง ข้ อมูลต้ องถูกย้ ายโดย Process
กฎในการเขียน Data Flow Diagram
ผิด
ถูก
ข้ อมูลไม่ สามารถเคลื่อนย้ ายจากแหล่ งข้ อมูลภายนอก
ระบบ(Entity) เข้ าไปยัง Data store ได้ โดยตรง ข้ อมูลต้ อง
ผ่ าน Process การรับข้ อมูลจากภายนอกแล้ วย้ ายไป
จัดเก็บใน Data store
กฎในการเขียน Data Flow Diagram
ผิด
ถูก
ข้ อมูลไม่ สามารถเคลื่อนย้ ายจาก Data store ออกไปยัง
แหล่ งรับข้ อมูลภายนอก(Entity) ได้ โดยตรง ต้ องมี
Process เพื่อย้ ายข้ อมูลออก
กฎในการเขียน Data Flow Diagram
ผิด
ถูก
ข้ อมูลไม่ สามารถเคลื่อนย้ ายจาก Entity ไปยัง Entity ได้
โดยตรง ต้ องมี Process เพื่อส่ งต่ อข้ อมูล
***แต่ ถ้าข้ อมูลนัน้ ไม่ ได้ เกี่ยวข้ องกับระบบงาน ก็ไม่
จาเป็ นต้ องแสดงข้ อมูลนัน้ ใน DFD
กฎในการเขียน Data Flow Diagram
ผิด
ถูก
Data flow จะมีทศิ ทางใดทิศทางหนึ่งระหว่ างแต่ ละสัญลักษณ์
ถึงแม้ ว่าข้ อมูลเดียวกันจะเข้ าและออกจาก Process ไปยัง Data
store เช่ น การดึงข้ อมูลจาก Data store มาแก้ ไขแล้ วจัดเก็บลงที่
เดิม แต่ ข้อมูลก็ถกู ใช้ งานคนละเวลากัน ไม่ ได้ เกิดขึน้ พร้ อมกัน
กฎในการเขียน Data Flow Diagram
A
A
B
A
ผิด
ถูก
เส้ นข้ อมูลที่แยกจากเส้ นเดียวกัน หมายถึงข้ อมูลเดียวกันที่ออก
จากแหล่ งเดียวกันออกไปยัง หลาย ๆ Process / Data store /
Entity
กฎในการเขียน Data Flow Diagram
A
A
B
ผิด
A
ถูก
เส้ นข้ อมูลที่รวมเป็ นเส้ นเดียวกัน หมายถึงข้ อมูลเดียวกันที่มาจาก
หลาย ๆ Process / Data store / Entity เพื่อเข้ าไปยังที่เดียวกัน
กฎในการเขียน Data Flow Diagram
A
A
A
B
A
C
ผิด
ถูก
ข้ อมูลไม่ สามารถเคลื่อนย้ ายโดยตรงออกจาก Process เข้ ามายัง
Process เดียวกันได้ ซึ่งจาเป็ นต้ องมี Process อย่ างน้ อย 1
Process ในการจัดการข้ อมูลนัน้ ๆ เพื่อสร้ างข้ อมูลอื่น ๆ หรือ
อาจจะส่ งข้ อมูลเดิมกลับมายัง Process เดิมได้
กฎในการเขียน Data Flow Diagram




ข้อความที่อยูใ่ น Process ต้องเป็ นคากริ ยาเพื่อบอกการทางานของ
Process นั้น
ข้อความที่อยูใ่ น Data store / Data flow / Entity ต้องเป็ น
คานาม
Data flow ที่ช้ ีเข้า Data store หมายถึง การนาข้อมูลนั้นไป
จัดเก็บ(เพิ่ม/ลบ/แก้ไข)
Data flow ที่ออกมาจาก Data store หมายถึงการดึงข้อมูล
ออกมาใช้งาน
1
นักศึกษา
ข้ อมูลนักศึกษา
ข้ อมูลนักศึกษา
ปรั บปรุ งข้ อมูล ที่ปรั บปรุ งแล้ ว D1
แฟ้มข้ อมูลนักศึกษา
ที่ต้องการปรั บปรุ ง
นักศึกษา
ข้ อมูลนักศึกษา
ก่ อนปรั บปรุ ง
ตัวอย่ างของ Data Flow Diagram ทีไ่ ม่
สมดุล
0
A
Entity 1
B
Entity 2
Context Diagram
A
Entity 1
1.0
Formatted C
ข ้อมูล C ไม่มใี น Context
Diagram
Formatted A
2.0
Entity 3
Entity 3 ไม่มใี น Context
Diagram
C
B
D
DFD Level 0
ข ้อมูล D ไม่มใี น
Context Diagram
Entity 2
Context Diagram
คือการออกแบบในระดับบนสุ ดของ DFD เป็ นแผนภาพที่แสดงภาพรวม
สู งสุ ดของระบบ ซึ่งจะแสดงถึงสิ่ งแวดล้อมของระบบและองค์ประกอบ
หลัก ๆ เท่านั้น
โดยที่จะมีเพียง 1 Process ซึ่งเป็ นชื่อของระบบ (0) และจะไม่มี Data
Store ปรากฏอยูใ่ น Context Diagram โดยเด็ดขาด
ตัวอย่าง Context Diagram
แผนภาพกระแสข้อมูลระดับที่1
DFD Level 1




จะนา Context Diagram มาแตกรายละเอียดภายใน ซึ่งจะแสดงถึง
Process หลัก ๆ, ผูเ้ กี่ยวข้อง, ข้อมูลภายใน ที่มีความละเอียดมากขึ้น (Top
down Design)
ในระดับนี้จะปรากฎทุก ๆ ชนิดของ Object DFD
ต้องมีการกากับหมายเลข Process ด้วยทุกครั้ง
หลักการ



เขียนในกระดาษแผ่นเดียว
ลูกศรไม่ทบั กัน โดยนาเอามาเฉพาะ Object ที่จาเป็ น
ควรจัดการลาดับแผนภาพเป็ นลาดับแบบ Process Hierarchy Chart (นาภาพ
ออกมาทีละลาดับขั้น ลดความสับสน)
ตัวอย่างการแบ่งหมวดหมู่เพื่อ PHC

List of Object in DFD
หลักการแบ่ง PHC



แบ่งตามลักษณะของกิจกรรม
โดยแบ่งตามความสาคัญเป็ นลาดับชั้นในลักษณะของ Sub Set
ข้อควรระวัง !!
 ไม่ควรนาเอารายละเอียดที่ต่างความสาคัญมาไว้ในชั้นเดียวกัน
(ความสัมพันธ์ต่างระดับ เพราะจะทาให้เกิดความสับสน ในการ
ออกแบบหรื อเขียน DFD ในระดับอื่น ๆ)
ตัวอย่าง PHC
ตัวอย่าง DFD Level 1
DFD Level 2


เป็ นแผนภาพ DFD ในระดับย่อยลงมา ที่แสดงรายละเอียด Data Flow
และ Process ย่อยลงมาของ Level 1 เพื่อเพิ่มความละเอียดของ
กระบวนการมากยิง่ ขึ้น
ตั้งแต่ Level ที่ 2 ลงไป จะมีแผนภาพนี้ข้ ึนตามความจาเป็ นเท่านั้น (ซึ่ง
ขึ้นอยูก่ บั ความซับซ้อนของข้อมูล และกิจกรรมที่ตอ้ งการแตก
รายละเอียด)
ตัวอย่าง DFD Level 2 (P.1)
DFD Level 3 (P 2.2)
แบบจาลองข้อมูล (Data Modeling)
การวิเคราะห์ดว้ ยการเขียนแผนภาพกระแสข้อมูลเพียงอย่างเดียวนั้น
โอกาสที่จะทาให้เกิดข้อผิดพลาดได้สูง ซึ่ งแผนภาพกระแสข้อมูล
ไม่ได้แสดงความสัมพันธ์ของข้อมูลในระบบ จึงเป็ นที่มาของ Entity
Relationship Diagram (ERD)
Relationship Model
เป็ นเครื่องมือที่แสดงให้ เห็นถึงความสั มพันธ์ ของข้ อมูลต่ างๆทีม่ ีต่อกันในระบบงาน โดย
ไดอะแกรมนีม้ ี Cardinality เป็ นสิ่ งกาหนดค่ าความสั มพันธ์ ของเอนติตใี้ นความสั มพันธ์
แต่ ละลักษณะ เช่ น 1:1 , 1:m และ m:n ซึ่งอาจใช้ สัญลักษณ์ แทนได้ ดังรู ป
ความสัมพันธ์ของเอนติต้ ี
ความสัมพันธ์ของเอนติต้ ี (ต่อ)
Entity Relationship Diagram
พจนานุกรมข้อมูล (Data Dictionary)
พจนานุกรมข้ อมูล แฟ้ มที่เก็บรวบรวมรายละเอียดต่างๆ เกี่ยวกับข้อมูลที่จดั เก็บ
อยูภ่ ายในฐานข้อมูล รายละเอียดพื้นฐานประกอบด้วย
1. ชื่อข้อมูล (name and alias of the data item)
2. คาอธิบายชื่อข้อมูล (description of the data item)
3. ชนิดของข้อมูล (data type)
4. ขนาดของข้อมูล (length of item)
5. รายละเอียดอื่นๆ (other additional information)
แบบจำลองเชิงวัตถุ (Object Oriented Analysis)


มุง่ ทีน่ ิยามของคลาสและลักษณะทีค่ ลาสทางานร่วมกัน แทนทีเ่ ราจะมอง
ปญั หาในลักษณะอินพุต โพรเซส เอาท์พตุ แบบดัง้ เดิม ซึง่ เป็ นลักษณะของ
กระแสข้อมูล เราจะมองปญั หาในแง่ของโครงสร้างข้อมูลตามลาดับชัน้
แบบจาลองเชิงวัตถุ UML (Unified Modeling Language) มี 9 แผนภาพ
แบบจำลองเชิงวัตถุ (Object Oriented Analysis)


Structural Diagram เป็ นกลุม่ แผนภาพทีแ่ สดงให้เห็นโครงสร้างเชิงสถิต
(Static) ของระบบ คือ โครงสร้างในส่วนทีไ่ ม่มกี ารเปลีย่ นแปลงหรือ
เคลือ่ นไหวแม้จะมีเหตุการณ์ใดๆ เกิดขึน้
Behavioral Diagram เป็ นกลุม่ แผนภาพให้เห็นภาพเชิงกิจกรรมของระบบ
(Dynamic) คือแสดงให้เห็นถึงพฤติกรรมของระบบทีม่ กี ารเปลีย่ นแปลงใน
เมือ่ มีเหตุการณ์ใดๆ เกิดขึน้ และแสดงให้เห็นถึงความสามารถของระบบที่
ดาเนินการในหน้าทีบ่ างอย่างได้
แบบจำลองเชิงวัตถุ (Object Oriented Analysis)

Class Diagram

Object Diagram

Component Diagram

Deployment Diagram

*Use Case Diagram

Sequence Diagram

Collaboration Diagram

Statechart Diagram

Activity Diagram
Structural Diagrams
Behavioral Diagrams
ตัวอย่ำง

Use Case Diagrams ของระบบส่งข่ำวผ่ำน SMS/E-Mail ถึงศิษย์เก่ำ
SMS/ E-Mail
«uses»
«uses»
«uses»
«uses»
SMS/E-Mail
Activity Diagram

เป็ นแผนภาพทีแ่ สดงให้เห็นลาดับการดาเนินกิจกรรม (Activity) จาก
กิจกรรมหนึ่งไปยังกิจกรรมหนึ่ง ซึง่ เกิดจากการทางานของอ๊อบเจ็คภายใน
ระบบ มีลกั ษณะคล้ายกับ Flow Chart
Activity Diagram
N
Y
/
N
Y
N
Y
Y
sms/e-mail
sms/e-mail
N
Deployment Diagram

เป็ นแผนภาพแสดงระบบสถาปตั ยกรรมของ Hardware/Software
<<Processor>>
Regional Server
Internet
<<Processor>>
Regional Server
Database
Sequence Diagram

เป็ นแผนภาพทีแ่ สดงให้เห็นถึงการปฎิสมั พันธ์ (Interaction) ระหว่าง Object
โดยเฉพาะการส่ง Message ระหว่าง Object ซึง่ มีลาดับของเวลา เรียกว่า
Sequence ทีเ่ กิดเหตุการณ์ขนั ้ โดยจะมีสญ
ั ลักษณ์แสดงให้เห็นลาดับการส่ง
Message ตามเวลาอย่างชัดเจน
Sequence Diagram (1)
Sequence Diagram (2)
Collaboration Diagram

เป็ นแผนภาพทีแ่ สดงให้เห็นถึงการปฎิสมั พันธ์เช่นเดียวกับ Sequence
Diagram แต่แตกต่างกันทีจ่ ะไม่มสี ญ
ั ลักษณ์แสดงถึงลาดับการส่ง message
อย่างชัดเจน ดังนัน้ ขึน้ อยูก่ บั ทีมงานว่าจะเลือกแผนภาพแบบใด หาก
ทีมงานต้องการให้เห็นถึงการส่ง Message ตามลาดับเวลาเป็ นสาคัญก็ให้
เลือก Sequence Diagram
Login()
:Interface
Check()
displayCheck()
Admin
CheckNews()
sendNews()
:News
Alumni
:Administrator
Class Diagram

เป็ นแผนภาพทีใ่ ช้ในการแสดงกลุ่มของคลาส โครงสร้างคลาส และ Interface
ตลอดจนแสดงความสาพันธ์ระหว่างคลาส ซึง่ เทคนิคทีใ่ ช้ในการค้นหาจะ
แตกต่างออกไปตามประสบการณ์ของทีมงาน
Class Diagram
e_arm_t01_member
+e_arm_t01_membeer_id : int
+e_arm_t01_member_CFname : char
+e_arm_t01_member_CLname : char
+e_arm_t01_member_OFname_ : char
+e_arm_t01_member_OLname : char
+e_arm_t01_member_adress : string
+e_arm_t01_member_idcard : int
+e_arm_t01_member_gender : string
+e_arm_t01_member_birthdate : string
+e_arm_t01_member_job : string
+e_arm_t01_member_email : string
+e_arm_t01_member_telephone : int
+e_arm_t01_member_mobile : int
+e_arm_t01_member_graduatedyear : int
+e_arm_t01_member_stdid : int
+e_arm_t01_member_generation : int
+e_arm_t01_member_oldschool : string
+e_arm_t01_member_position : string
+e_arm_t01_member_officename : string
+e_arm_t01_member_username : string
-e_arm_t01_member_password : string
+record_mem()
1..*
1..*
e_arm_t04_news
+e_arm_t04_news_id : int
+e_arm_t03_boss_id : int
+e_arm_t02_administrator_id : int
+e_arm_t06_type_id : int
+e_news_t03_news_id : int
+e_arm_t04_news_name : char
+e_arm_t04_news_detail : string
+e_arm_t04_news_date : string
+e_arm_t04_news_status : string
+e_arm_t04_news_senddate : string
+check_news ()
+detail_news()
+update_detail()
+record_news()
1..*
1
e_arm_t03_boss
+e_arm_t03_boss_id : int
+e_arm_t03_boss_Fname : string
+e_arm_t03_boss_Lname : string
+e_arm_t03_boss_positon : string
+e_arm_t03_boss_username : string
-e_arm_t03_boss_password : string
+check()
+display_checkStatus()
1..*
1..*
1
e_arm_t02_administrator
+e_arm_t02_administrator_id : int
+e_arm_t02_administrator_Fname : string
+e_arm_t02_administratorLname : string
+e_arm_t02_administrator_username : string
-e_arm_t02_administrator_password : string
+check()
1
1
1..*
1
1
e_arm_t05_graduatedStud
+e_arm_t05_graduatedStud__year : int
+e_arm_t01_member_id : int
+e_arm_t05_graduatedStud_Fname : string
+e_arm_t05_graduatedStud_Lname : string
+e_arm_t05_graduatedStud_stdid : int
+checkGradStd()
+detail_gradStd()
e_news_t03_news(From e-news)
+e_news_t03_news_id : int
+e_news_t03_news_subject : string
+e_news_t03_news_cats : string
+e_news_t03_news_details : string
+e_news_t03_news_images
+e_news_t03_news_attachment
+e_news_t03_news_news_reads
+e_news_t03_news_detestamp : string
+e_news_t03_news_status : string
e_arm_t06_type
+e_arm_t06_type_id : int
+e_arm_t06_type_name : string
Statechart Diagram

เป็ นแผนภาพทีแ่ สดงให้เห็นพฤติกรรมของ Object เช่นเดียวกับกลุ่ม
Behavioral Diagram อื่นๆ แต่ Statechart Diagram จะเน้นทีก่ ารแสดงใน
เห็นถึงสถานะ (State) การเปลีย่ นสถานะ (Transition) ทีม่ ตี ่อเหตุการณ์
(Event) ทีเ่ กิดขึน้ ในช่วงชีวติ ของ Object 1 ช่วง (1 Sequence)
getCustInfo
Ready
In getting
data
process
getting data
complete
Display
customer
info
Component Diagram

เป็ นแผนภาพทีแ่ สดงถึงโครงสร้างทางกายภาพของโปรแกรม ประกอบด้วย
ส่วนประกอบต่างๆ ทีเ่ รียกว่า “Component” ซึง่ หมายถึง ส่วนประกอบย่อย
ของซอฟต์แวร์ของระบบงานทัง้ หมด ดังนัน้ Component Diagram จึงเป็ น
แผนภาพทีแ่ สดงความสัมพันธ์ระหว่าง Component ของซอฟต์แวร์ทใ่ี ช้ใน
ระบบ ทาให้เห็นว่าประกอบไปด้วยไฟล์ใดบ้าง ส่วนใหญ่มกั จะแสดงไฟล์ท่ี
เป็ น Source Code, Binary Code หรือไฟล์ไบนารี
Component Diagram
Main.html
GoodBrowse.html
{หน้า Web page หลัก}
{Web page เพื่อการเลือกสิ นค้า}
www.ecommerce.com
GoodOrder.html
Paying.html
<<hyperlink>>
{Web page เพื่อการสัง่ สิ นค้า}
{Web page เพื่อจัดการเงื่อนไขการชาระค่าสิ นค้า}
Internet
Explorer.exe
Component Diagram
Object Diagram

เป็ นแผนภาพทีใ่ ช้ในการแสดงกลุ่มของ Object และความสัมพันธ์ระหว่าง
Object ทีเ่ กิดขึน้ ในคลาสต่างๆ ของ Class Diagram แสดงลักษณะของ
Object Diagram
ord1: Order
cust1: Customer
custId=“CA001”
custName= “Surachai Pakdee”
custSex=“Male”
orderId=“CA001”
orderDate= “2004/01/20”
custSex=“CA001”
orderItem= “p101, p102, p103”
ord2: Order
orderId=“CA001”
orderDate= “2004/01/20”
custSex=“CA001”
orderItem= “p102, p103”