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
กระบวนการวิศวกรรมความต้ องการ
• รวมอยูใ่ นระยะการวิเคราะห์ความต้องการของกระบวนการผลิต
ซอฟต์แวร์
• มีลกั ษณะการทาซ้ าในแต่ละระยะเพื่อให้เป็ นเอกสารความต้องการ
ที่มีประสิ ทธิภาพ
– แบบจาลองของกระบวนการวิศวกรรมความต้องการ มีหลาย
รู ปแบบตามการประยุกต์ใช้ของแต่ละองค์กร
– Water Fall
– Spiral
กระบวนการวิศวกรรมความต้ องการ
Requirement Elicitation
ความต้องการประเภทต่างๆ
Requirement Analysis
แบบจาลองความต้องการ
Requirement Specification
ข้อกาหนดความต้องการ
Requirement Validation
เอกสารข้อกาหนดความต้องการ
สกัดความต้ องการ (Requirement Elicitation)
• เก็บรวมรวมข้อเท็จจริ งเพื่อทาความเข้าใจกับปัญหาที่เกิดขึ้น
– ระบุความจาเป็ นของการนาซอฟท์แวร์ มาใช้ งาน
• ค้นหาความต้องการจากบุคคลที่เกี่ยวข้องด้วยเทคนิคต่าง ๆ
เทคนิคการเก็บรวบรวมความต้ องการ
•
•
•
•
•
•
•
การสัมภาษณ์ (Interview)
การออกแบบสอบถาม (Questinnaire)
การแสดงลาดับเหตุการณ์ (Scenario)
ทาต้นแบบ (Prototype)
การประชุม (Facilitated Meeting)
การสังเกต (Observation)
ฯลฯ
วิเคราะห์ ความต้ องการ(Requirement Analysis)
– ศึกษาและประเมินความต้องการที่รวบรวมได้เพื่อแบ่งกลุ่มของ
ความต้องการ
– จัดลาดับความสาคัญของความต้องการ
– ดูความสอดคล้อง ขจัดความขัดแย้ง
– สร้างแบบจาลองความต้องการ (Conceptual Modeling)
– ออกแบบสถาปัตยกรรมและจัดสรรความต้องการในเบื้องต้นเพื่อ
นาไปทดสอบการยอมรับจากลูกค้า
– เจรจาต่อรองความต้องการ
กาหนดความต้ องการ(Requirement Specification)
– นิยามความต้ องการของระบบในรูปแบบเอกสารข้ อกาหนดความ
ต้ องการ
– เอกสารข้ อกาหนดความต้ องการ ต้ องประกอบไปด้ วยส่วนต่าง ๆ
เช่น
• การนิยามระบบ
• ความต้ องการด้ านระบบ
• ความต้ องการด้ านซอฟต์แวร์
– แจกแจงในรูปแบบเอกสาร
กาหนดความต้ องการ(Requirement Specification)
– เอกสารข้อกาหนดความต้องการ แบ่งเป็ น 3 ประเภท
• เอกสารนิยามระบบ (System Definition Document)
• เอกสารข้อกาหนดความต้องการด้านระบบ (System Requirement
Specification)
• เอกสารข้อกาหนดความต้องการด้านซอฟต์แวร์ (Software Requirement
Specification : SRS)
– เอกสารข้อกาหนดความต้องการต้องผ่านการประเมินความต้องการ
ก่อนนาไปใช้เป็ นวัตถุดิบในการออกแบบต่อไป
เอกสารความต้ องการด้ านซอฟต์ แวร์
 เอกสารความต้ องการด้ านซอฟต์แวร์
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
ประเด็นที่อยูร่ ะหว่างศึกษา
แบบสารวจความต้องการ
...
ตรวจสอบความต้ องการ (Requirement Validation)
–
–
–
–
ทบทวนเอกสารทังหมด
้
วิเคราะห์และตรวจหาข้ อผิดพลาด
ตรวจสอบความสมบูรณ์
ตรงตามเป้าหมายของการพัฒนาซอฟท์แวร์
ตรวจสอบความต้ องการ (Requirement Validation)
– ควรตรวจสอบตามลักษณะ ต่อไปนี ้
•
•
•
•
•
ความเที่ยงตรง
ความสอดคล้ อง
ความครบถ้ วนสมบูรณ์
ความเป็ นไปได้
สามารถพิสจู น์ได้
เทคนิคในการตรวจสอบความต้ องการ
– การทบทวนความต้องการ (Requirement Review)
– การจัดทาต้นแบบ (Prototyping)
– การสร้างแบบทดสอบ (Test-case generation)
การจัดการกับการเปลีย่ นแปลงความต้ องการ
–
–
–
–
เกี่ยวข้องกับการวิเคราะห์ถึงความคุม้ ค่าเมื่อต้องเปลี่ยนแปลงตามข้อเสนอ
หากมีความคุม้ ค่าจะอนุมตั ิให้ดาเนินการเปลี่ยนแปลงได้
หากพบว่าไม่ได้รับผลตอบแทนคุม้ ค่าก็ยกเลิกข้อเสนอนั้นไป
ควรมีการวางแผนการจัดการความต้องการก่อนเริ่ มดาเนินงาน แต่เป็ น
กระบวนการที่ใช้งบประมาณค่อนข้างสูง ประกอบด้วยกิจกรรม ดังนี้
• จาแนกความต้องการ
• กระบวนการจัดการการเปลี่ยนแปลง
• กาหนดนโยบายการสื บหาส่ วนที่ได้รับผลกระทบ
• ใช้ Case Tool ช่วย
แบบจำลองกำรวิเครำะห์ (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
ั
สญล
ักษณ์ทใี่ ชใ้ น DFD
DeMarco&Your
don
Gene & Sarson
ความหมาย
Process – ขัน
้ ตอนการทางาน
ภายในระบบ
Data Store – แหล่งข ้อมูลสามารถ
เป็ นได ้ทัง้ ไฟล์ข ้อมูลและฐานข ้อมูล
External Entity - ปั จจัยหรือ
สงิ่ แวดล ้อมทีม
่ ผ
ี ลกระทบต่อระบบ
้
Data Flows – เสนทางการไหล
ของข ้อมูล แสดงทิศทางของข ้อมูล
จากขัน
้ ตอนการทางานหนึง่ ไปยังอีก
ขัน
้ ตอนหนึง่
กฎเกณฑ์การเขียนแผนภาพกระแสข้อมูล
• สัญลักษณ์ของแผนภาพไม่สามารถเชื่อมต่อกันได้ โดยตรง ซึง่ ต้ องมี
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 ช่อยในการเขียนแผนภาพ
Process
• คือ กระบวนการที่ต้องทาในระบบ
• โดยจะพิจารณาจากกิริยาหรื อการกระทาภายในระบบเป็ นหลัก
• ในการเขียน Process จะต้ องมีหมายเลขกากับอยูด่ ้ วย เป็ นลาดับชัน้
ไล่ไปเรื่ อย ๆ เพื่อให้ ทราบว่า Process ใด มาจาก Process ใด
กระบวนการ(Process)
Input
1
ขั้นตอนการทางาน
ของระบบ
Output
46
กฎของการเขียนกระบวนการ
ต ้องไม่มข
ี ้อมูลรับเข ้าเพียงอย่างเดียว
ต ้องไม่มข
ี ้อมูลออกเพียงอย่างเดียว
ข ้อมูลรับเข ้าจะต ้องเพียงพอในการสร ้างข ้อมูลสง่ ออก
ื่ Process ต ้องใช ้ คากริยา เชน
่ รับรายการ
การตัง้ ชอ
ื้ คานวณคะแนนเฉลีย
สงั่ ซอ
่ พิมพ์รายงาน เป็ นต ้น
• จานวนกระบวนการทีต
่ ้องทาในระบบไม่ควรมีมากน ้อย
เกินไป ควรอยูร่ ะหว่าง 2-7 (หรือ +/- 2) กระบวนการ
• มีหมายเลขกากับ
• นาเสนอว่าทาหน ้าทีอ
่ ะไรไม่ลงรายละเอียด (Black
Box)
•
•
•
•
้ ทางการไหล (Data Flow)
เสน
้
• เสนทางการไหลของข
้อมูล (Data Flow) เป็ นการ
ื่ สารระหว่างขัน
สอ
้ ตอนการทางาน (Process) ต่าง ๆ
และสภาพแวดล ้อมภายนอกหรือภายในระบบ โดย
แสดงถึงข ้อมูลทีน
่ าเข ้าในแต่ละ Process และข ้อมูลที่
้
สง่ ออกจาก Process ใชในการแสดงถึ
งการบันทึก
ข ้อมูล การลบข ้อมูล การแก ้ไขข ้อมูลต่าง ๆ ใช ้
้ ลูกศรทีไ่ ปพร ้อมกับข ้อมูล ดัง
ั ลักษณ์แทนด ้วยเสน
สญ
รูป
แผนกการเงิน
เงินเดือน, ภาษี,
ค่าประกันสังคม
1
คานวณเงินเดือน
สุ ทธิ
เงินเดือนสุ ทธิ
พนั กงาน
กฎของ Data Flow
ื่ ของ Data Flow คือชอ
ื่ ของข ้อมูลทีส
• ชอ
่ ง่ โดยไม่ต ้องอธิบายว่าสง่
อย่างไร
ิ้ สุดที่ Process
• Data Flow ต้องมีจด
ุ เริม
่ ต้นหรือสน
• Data Flow จะเดินทางระหว่าง External Entity กับ External
Entity ไม่ได ้
• Data Flow จะเดินทางจาก External Entity ไป Data Store ไม่ได ้
• Data Flow จะเดินทางจาก Data Store ไป External Entity ไม่ได ้
• Data Flow จะเดินทางระหว่าง Data Store กับ Data Store ไม่ได ้
ื่ ต ้องใช ้ คานาม ทีส
ื่ ความหมาย เชน
่ ใบกากับสน
ิ ค ้า
• การตัง้ ชอ
่ อ
้ อนทั
้
• ไม่ควรเขียนเสนซ
บกัน
ปัจจ ัยภายนอกหรือเอ็กเทอร์น ัลเอ็นทิต ี
(External Entity)
• หมายถึง บุคคล หน่วยงานในองค์กร องค์กร
อืน
่ ๆ หรือระบบงานอืน
่ ๆ ทีอ
่ ยูภ
่ ายนอก
ั พันธ์กบ
ขอบเขตของระบบ แต่มค
ี วามสม
ั
ระบบ โดยมีการสง่ ข ้อมูลเข ้าสูร่ ะบบเพือ
่
ดาเนินงาน และรับข ้อมูลทีผ
่ า่ นการ
ดาเนินงานเรียบร ้อยแล ้วจากระบบ ใน
บางครัง้ เรียก “External Agent”
• กฎของ External Entities
External
Entity
– ข ้อมูลจาก External Entities หนึง่ จะวิง่ ไปสู่
อีก External Entities หนึง่ โดยตรงไม่ได ้
(จะต ้องผ่าน Process ก่อน)
ื่ ต ้องใช ้ คานาม ทีส
ื่ ความหมาย
– การตัง้ ชอ
่ อ
่ ลูกค ้า
เชน
– มักจัดวางด ้านนอกหรือรอบแผนาภาพ
50
ปัจจ ัยภายนอกหรือเอ็ กเทอร์น ัล
เอ็นทิต ี (External Entity) (ต่อ)
• ในบางครัง้ External Entities อาจจาเป็ นต ้องกระทา
ซ้า (Duplicate) เนือ
่ งจากข ้อจากัดในด ้านการ
ื่ มโยง Data Flows ทีซ
้
เชอ
่ อนทั
บและข ้ามกันไปมา จะ
ทาให ้แผนภาพดูยงุ่ เหยิง ไม่เป็ นระเบียบ และอ่านหรือ
ทาความเข ้าใจได ้ยาก
• โดย External Entities ทีก
่ ระทาซ้าสามารถทาได ้โดย
้ อ
ใชเครื
่ งหมาย \ (back slash) ไว้ทม
ี่ ม
ุ ล่างซา้ ย
ดังรูป
ึ ษา
น ักศก
แบบปกติ
ึ ษา
น ักศก
แบบการทาซ้า
51
แหล่งจ ัดเก็บข้อมูล (Data Store)
• แหล่งจัดเก็บข ้อมูล (Data Store) เป็ นแหล่งเก็บ /
ิ ค ้า (เทียบเท่ากับ
บันทึกข ้อมูล เปรียบเสมือนคลังสน
ไฟล์ข ้อมูล และฐานข ้อมูล) โดยมีรายละเอียดและ
คุณสมบัตเิ ฉพาะตัวของ สงิ่ ทีต
่ ้องการเก็บ / บันทึก
• กฎของ Data Store
่ ก
– ข ้อมูลจาก Data Store หนึง่ จะวิง่ ไปสูอ
ี Data Store หนึง่
โดยตรงไม่ได ้ (จะต ้องผ่าน Process ก่อน)
– ข ้อมูลจาก Data Store หนึง่ จะวิง่ ไป หรือ กลับจาก
External Entity หนึง่ โดยตรงไม่ได ้ (จะต ้องผ่าน Process
่ กัน)
ก่อนเชน
ื่ ต ้องใช ้ คานาม ทีส
ื่ ความหมาย เชน
่ ไฟล์ข ้อมูล
– การตัง้ ชอ
่ อ
ลูกค ้า
รหัส
Dตัวเลข
52
ระด ับของ DFD
• ในการเขียน DFD สามารถแยกรายละเอียดของ
แผนภาพออกเป็ นหลายระดับ เพือ
่ ง่ายต่อการ
กาหนดขอบเขตในการพิจารณาและง่ายต่อการ
ทาความเข ้าใจ
• ระดับของ DFD
– DFD
– DFD
– DFD
– DFD
Level
Level
Level
Level
0 (Context Diagram )
1
2
n
Context Diagram
• คือการออกแบบในระดับบนสุดของ DFD เป็ นแผนภาพที่แสดง
ภาพรวมสูงสุดของระบบ
• ซึง่ จะแสดงถึงสิง่ แวดล้ อมของระบบและองค์ประกอบหลัก ๆ เท่านัน้
• โดยที่จะมีเพียง 1 Process ซึง่ เป็ นชื่อของระบบ (0) และจะไม่มี Data
Store ปรากฏอยูใ่ น Context Diagram โดยเด็ดขาด
การสร้างแผนภาพบริบท (Context
Diagram)
ั ลักษณ์สร ้างแผนภาพกระแสข ้อมูล
• หลักเกณฑ์การใชส้ ญ
– Context diagram ต ้องสมดุลอยูภ
่ ายในหนึง่
หน ้ากระดาษ
ื่ ของกระบวนการใน context diagram ควรเป็ นชอ
ื่
– ชอ
ของระบบงานหรือโครงงาน และแสดงหมายเลขศูนย์
(0)
– มีการแสดง entity และการไหลของข ้อมูลทีแ
่ สดงการ
ติดต่อระหว่างระบบกับสงิ่ ทีอ
่ ยูภ
่ ายนอก
– ไม่มก
ี ารแสดงแหล่งจัดเก็บข ้อมูล (Data Store)
– ขอบเขตของระบบพิจารณาได ้จากจานวน
Input/Output ทัง้ หมด
ต ัวอย่างContext diagram
อาจารย์
ผลคะแนน
ิ
รหัสนิสต
ระบบทะเบียน
ผลการเรียน
ิ
นิสต
การสร้างแผนภาพการไหลของข้อมูล ระด ับที่ 1
Data Flow Diagram Level-1 หรือ DFD 1
• จะเป็ นแผนภาพทีใ่ ห ้รายละเอียดในระดับแรกสุดรองจาก
Context diagram เพือ
่ ให ้เห็นภาพรวมของระบบมากขึน
้
ั ลักษณ์การเก็บข ้อมูล (data store) ,
โดยจะมีสญ
ั ลักษณ์การไหลของข ้อมูล (data flow) , และ
สญ
ั ลักษณ์การประมวลผล(process)
สญ
• DFD 1 สามารถแสดงให ้เห็นรายละเอียดของ
กระบวนการทางานหลักๆ ถัดจาก Context Diagram
• แต่ละกระบวนการจะมีหมายเลขกากับด ้านบนของ
ั ลักษณ์ เริม
สญ
่ ตัง้ แต่ หมายเลข 1 เป็ นต ้นไป
• จานวนกระบวนการทีต
่ อ
้ งทาในระบบไม่ควรมีมากน้อย
เกินไป ควรอยูร่ ะหว่าง 2-7 (หรือ +/- 2) กระบวนการ
การแบ่งย่อยแผนภาพ
(Decomposition Diagram)
• เป็ นวิธก
ี ารแบ่งระบบใหญ่ออกเป็ นระบบย่อยๆ โดยระบบ
หนึง่ ทีแ
่ สดงใน Context Diagram ไม่สามารถอธิบาย
ไม่สามารถอธิบายการทางานของระบบได ้ทัง้ หมด จึง
ต ้องมีการแบ่งเป็ นระบบย่อยทีม
่ ข
ี นาดเล็กลงเรือ
่ ยๆจน
สามารถอธิบายระบบทัง้ หมดได ้
• การแบ่ง DFD ไปเรือ
่ ยๆจนถึงระดับทีไ่ ม่สามารถแบ่งได ้
อีกแล ้ว เรียกว่า Primitive Diagram
• ระดับของแผนภาพทีแ
่ บ่งย่อยมาจาก Context
Diagram เรียกว่า DFD Level-1 และเป็ น 2 , 3 ….
• ซงึ่ การแบ่งย่อยระดับถัดมาจะต ้องมีกระบวนการอย่าง
น ้อย 2 กระบวนการขึน
้ ไป
ความสมดุลของแผนภาพ DFD
(DFD Balancing)
• ความสมดุลของแผนภาพ DFD หมายถึง
– จานวน Input data flows ทีเ่ ข ้าไปยัง Process ใน
ระดับทีส
่ งู กว่า จะต ้องเท่ากับจานวน Input data flows
ของ DFD ทีแ
่ ตกจาก Process ดังกล่าว
– จานวน Output data flows ทีอ
่ อกจาก Process ใน
ระดับทีส
่ งู กว่า จะต ้องเท่ากับจานวน Output data
flows ของ DFD ทีแ
่ ตกจาก Process ดังกล่าว
• การแตกระดับของ DFD ไปยังระดับตา่ จาเป็ นต ้อง
รักษาความสมดุลของแผนภาพไว ้เสมอ
Process Hierarchy Chart : PHC
• เป็ นการเขียนผังแสดงความสัมพันธ์ของกระบวนการที่ปรากฏใน
Context Diagramหรื อ DFD เพื่อลดความสับสน
ตัวอย่างการแบ่งหมวดหมู่เพื่อ PHC
• List of Object in DFD
หลักการแบ่ง PHC
• แบ่งตามลักษณะของกิจกรรม
• โดยแบ่งตามความสาคัญเป็ นลาดับชันในลั
้ กษณะของ Sub Set
• ข้ อควรระวัง !!
– ไม่ควรนาเอารายละเอียดที่ตา่ งความสาคัญมาไว้ ในชันเดี
้ ยวกัน
(ความสัมพันธ์ตา่ งระดับ เพราะจะทาให้ เกิดความสับสน ในการ
ออกแบบหรื อเขียน DFD ในระดับอื่น ๆ)
ตัวอย่าง PHC
แบบจาลองข้อมูล (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)
getting data
getCustInfo
Ready
In getting
data
process
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”