ก่อนการสร้างบ้าน ผู้สร้างย่อมมีความต้องการทราบรายละเอียดถึงตัวอาคารที่จะจัดสร้าง เพื่อให้ตรงตามความต้องการของผู้อยู่อาศัย
- เช่นเดียวกันกับระบบ ก่อนจะมีการสร้างระบบ ผู้สร้างระบบก็ย่อมต้องการทราบความเป็นไปและเป็นมาของระบบ เพื่อการออกแบบระบบใหม่ที่ตรงตามความต้องการของผู้ใช้ให้มากที่สุด
*
ความสำคัญของการวิเคราะห์ (ต่อ)
- อุปกรณ์ที่มักนำเอามาพิจารณาและวิเคราะห์ระบบ (แบบแปลนระบบ)
- Context Diagram
- Data Flow Diagram
- E-R Diagram
- System Flow Chart / Flow Chart
- etc.
- ความผิดพลาดของโปรแกรมเมอร์มากมายที่ออกแบบระบบโดยไม่ผ่านการวิเคราะห์ ก่อให้เกิดผลเสียมากมาย เช่น เวลา, ค่าใช้จ่าย
*
แผนภาพกระแสข้อมูล (Data Flow Diagram)
- DFD คือ แผนภาพกระแสข้อมูลที่มีการวิเคราะห์แบบในเชิงโครงสร้าง (Structure) ซึ่งเป็นแผนภาพที่บอกถึงรายละเอียดของระบบ โดยเฉพาะข้อมูล และผังการไหลของข้อมูล
- สิ่งที่ DFD บอกเรา
- ข้อมูลมาจากไหน
- ข้อมูลไปที่ใด
- ข้อมูลเก็บที่ใด
- เกิดเหตุการณ์ใดกับข้อมูลบ้าง
*
DFD (ต่อ)
- ขั้นตอนของการวิเคราะห์เพื่อสร้าง DFD
1. ศึกษารูปแบบการทำงานในลักษณะ Physical ระบบงานเดิม
2. ดำเนินการวิเคราะห์เพื่อให้ได้แบบจำลอง Logical ระบบงานเดิม
3. เพิ่มเติมการทำงานใหม่ภายในแบบจำลอง Logical ระบบงานเดิม
4. พัฒนาระบบงานใหม่ในรูปแบบของ Physical
*
วัตถุประสงค์ของ DFD
- เป็นแผนภาพสรุปรวมข้อมูลทั้งหมดที่ได้จากการวิเคราะห์
- เป็นข้อตกลงร่วมกันระหว่าง SA และ User
- เป็นแผนภาพที่ใช้ในการพัฒนาต่อในขั้นตอนออกแบบ
- เป็นแผนภาพที่ใช้ในการอ้างอิง หรือเพื่อใช้พัฒนาต่อ
- ทราบที่ไปที่มาของกระบวนการต่าง ๆ
*
ดังนั้น DFD จึงมีความสำคัญมากต่อการพัฒนาระบบ
ซึ่ง SA หรือ Programmer ไม่สามารถมองข้ามได้
สัญลักษณ์ที่ใช้ในแผนภาพกระแสข้อมูล
*
DFD Format (เปรียบเทียบ)
*
กฎเกณฑ์การเขียนแผนภาพกระแสข้อมูล
- สัญลักษณ์ของแผนภาพไม่สามารถเชื่อมต่อกันได้โดยตรง ซึ่งต้องมี Flow บอกทิศทางของกระแส (Flow ระบุข้อมูล)
- และการ Flow ทุกครั้งจะต้องผ่าน Process ก่อนทุกครั้ง (ไม่ผ่านไม่ได้)
- Process = กิริยา
- Flow = ข้อมูล
- Boundaries, Entity = องค์กร, หน่วยงาน
*
ขั้นตอนการเขียน DFD
1. วิเคราะห์ให้ได้ว่าระบบประกอบไปด้วย Boundaries ใดบ้างที่เกี่ยวข้อง
2. ดำเนินการออกแบบระบบในระดับหลักการ หรือ Context Diagram
3. วิเคราะห์ข้อมูลในระบบว่าควรมีข้อมูลใดบ้าง
4. วิเคราะห์กระบวนการหรือ Process ในระบบว่า ควรมี Process หลักใด และประกอบไปด้วย Process ย่อยใดบ้าง (ควรสร้างแบบมีหลักการของระบบ)
5. ดำเนินการเขียนแผนภาพกระแสข้อมูลในระดับต่าง ๆ
6. ทำการตรวจสอบ Balancing และปรับแก้ Redraw จนได้แผนภาพที่สมบูรณ์
7. อาจใช้ CASE Tools ช่อยในการเขียนแผนภาพ
*
Boundaries
- สามารถเป็นได้ทั้ง บุคคล, องค์กร, หน่วยงาน
- ซึ่งในการพิจารณาเพื่อระบุลงไปใน DFD จะพิจารณาถึงส่วนที่ระบบไม่สามารถควบคุมได้ แต่มีส่วนเกี่ยวข้องกับระบบ
*
Data Store
- คือแหล่งเก็บข้อมูล เช่น ข้อมูลนักศึกษา, ข้อมูลบุคลากร
- โดยภายในสัญลักษณ์สามารถที่จะมีเลขประจำข้อมูลระบุได้
- ลูกศรจาก Data Store หมายถึง Input
- ลูกศร Process ไปยัง Data Store หมายถึง Output
- ลูกศรสองทาง หมายถึง Input/Output
*
Process
- คือ กระบวนการที่ต้องทำในระบบ
- โดยจะพิจารณาจะกิริยาหรือการกระทำภายในระบบเป็นหลัก
- ซึ่งภายใน 1 แผนภาพ ไม่ควรมี Process มากเกินไป(7-2)
- ในการเขียน Process จะต้องมีหมายเลขกำกับอยู่ด้วย เป็นลำดับชั้นไล่ไปเรื่อย ๆ เพื่อให้ทราบว่า Process ใด มาจาก Process ใด
*
Context Diagram (แผนภาพสิ่งแวดล้อม)
- คือการออกแบบในระดับบนสุดของ DFD
- เป็นแผนภาพที่แสดงภาพรวมสูงสุดของระบบ ซึ่งจะแสดงถึงสิ่งแวดล้อมของระบบและองค์ประกอบหลัก ๆ เท่านั้น
- โดยที่จะมีเพียง 1 Process ซึ่งเป็นชื่อของระบบ (0) และจะไม่มี Data Store ปรากฏอยู่ใน Context Diagram โดยเด็ดขาด
*
ตัวอย่าง Context Diagram
*
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 ในระดับอื่น ๆ)
*
DFD Level 2
- เป็นแผนภาพ DFD ในระดับย่อยลงมา ที่แสดงรายละเอียด Data Flow และ Process ย่อยลงมาของ Level 1 เพื่อเพิ่มความละเอียดของกระบวนการมากยิ่งขึ้น แต่ตั้งแต่ Level ที่ 2 ลงไป จะมีแผนภาพนี้ขึ้นตามความจำเป็นเท่านั้น (ซึ่งขึ้นอยู่กับความซับซ้อนของข้อมูล และกิจกรรมที่ต้องการแตกรายละเอียด)