5​ ​Diagram​ ​สำคัญ​ที่​ควร​รู้​ก่อน​พัฒนา​ระบบ​:​ ​Flowchart​,​ ​Sequence​,​ ​Class​,​ ​State​ ​และ​ ​ER​ ​Diagram

Software Diagram ช่วยให้คนต่างบทบาทคุยเรื่องระบบได้ตรงกัน แต่แต่ละชนิดตอบคำถามต่างกัน การเลือกภาพจากความคุ้นเคยโดยไม่รู้คำถามอาจทำให้แผนภาพสวยแต่ไม่ได้ช่วยตัดสินใจ ก่อนวาด ให้เขียนประโยคว่า “อยากให้ผู้อ่านตอบอะไรได้หลังดูภาพนี้”

Diagram แต่ละแบบตอบคำถามอะไร

1. Flowchart: ขั้นตอนงานและจุดตัดสินใจเป็นอย่างไร เช่น คำขอถูกส่งกลับเมื่อข้อมูลไม่ครบ
2. Sequence Diagram: ใครส่งข้อความถึงใครตามลำดับเวลา เช่น Browser เรียก API แล้ว API ตรวจฐานข้อมูล
3. Class Diagram: ชนิดของวัตถุในซอฟต์แวร์มีหน้าที่และความสัมพันธ์อย่างไร
4. State Diagram: รายการหนึ่งเปลี่ยนสถานะได้เมื่อใด เช่น คำสั่งซื้อจากรอชำระไปชำระแล้ว
5. ER Diagram: ข้อมูลที่ต้องเก็บมี Entity อะไรและสัมพันธ์กันอย่างไร เช่น ลูกค้าหนึ่งรายมีหลายคำสั่งซื้อ

ภาพที่ 1: เริ่มจากคำถามที่ต้องตอบ แล้วเลือก Diagram ที่แสดงข้อมูลชนิดนั้นได้ชัดที่สุด

ตัวอย่างสมมติ: ระบบรับคำขอ

ฝ่ายปฏิบัติการอาจเริ่มจาก Flowchart ว่าใครรับ ตรวจ และส่งกลับงาน จากนั้นใช้ State Diagram กำหนดสถานะ “ใหม่–รอข้อมูล–กำลังทำ–ปิด” ฝ่ายพัฒนาทำ Sequence Diagram ของการส่งคำขอผ่านเว็บและ API แล้วใช้ ER Diagram ออกแบบคำขอ ผู้ใช้ และประวัติสถานะ Class Diagram จำเป็นเมื่อโครงสร้างซอฟต์แวร์มีความสัมพันธ์ที่ต้องสื่อสารเพิ่ม ไม่ต้องวาดเพราะรายการเช็กบอกให้ครบห้าอย่าง

ข้อผิดพลาดที่พบและการใช้ในรายงาน

อย่าใช้ลูกศรเดียวกันแทนทั้ง “ขั้นตอนถัดไป” “เรียก API” และ “Foreign Key” โดยไม่บอกความหมาย ภาพควรมีขอบเขต ชื่อที่ตรงกับระบบจริง และเวอร์ชันเมื่อระบบเปลี่ยน สำหรับรายงาน ให้แสดง Requirement ที่ภาพแต่ละใบช่วยอธิบาย ข้อสรุปจากภาพ และข้อจำกัดที่ยังไม่รู้ ภาพไม่มีประโยชน์หากผู้อ่านต้องเดาว่าสัญลักษณ์แทนอะไร

อ่านรายละเอียด Flowchart, Sequence Diagram, Class Diagram, State Diagram และ ER Diagram หรือดู บริการพัฒนา Web Application

วิเคราะห์กรณีศึกษาเพื่อนำไปเขียนรายงาน

ลองกำหนดกรณีศึกษาเป็น ออกแบบระบบคำขอที่มีคน กระบวนการ ข้อมูล และสถานะ และเขียนขอบเขตให้ชัดว่ามีผู้ใช้กลุ่มใด ข้อมูลใดเข้าสู่ระบบ และต้องการผลลัพธ์อะไร เริ่มจากสภาพก่อนพัฒนา แล้วอธิบายการตัดสินใจที่บทความนี้เกี่ยวข้องโดยใช้ตัวอย่างข้อมูลหรือเหตุการณ์ที่สมมติขึ้นอย่างระบุว่าเป็นตัวอย่าง การกำหนดขอบเขตเช่นนี้ช่วยให้ผู้อ่านแยกหลักการทั่วไปออกจากข้อเท็จจริงของโครงการได้

หลักฐานที่ควรแสดงคือ Flowchart, Sequence, Class, State และ ER โดยระบุคำถามของแต่ละภาพ ควรอธิบายสัญลักษณ์ คำย่อ หรือเงื่อนไขในหลักฐานนั้นให้ผู้อ่านที่ไม่อยู่ในทีมเข้าใจ และบอกว่ามันเชื่อมกับ Requirement ข้อใด ถ้ามีหลายทางเลือก ให้ระบุเหตุผลที่เลือกทางหนึ่งและผลกระทบต่อผู้ใช้ ทีมพัฒนา หรือผู้ดูแลระบบ แทนการเขียนเพียงว่าใช้แนวทางที่ “ดีที่สุด” โดยไม่มีเกณฑ์เปรียบเทียบ

เกณฑ์ประเมินตัวอย่างคือ ผู้อ่านเลือกภาพที่ตอบคำถามได้โดยไม่ซ้ำหน้าที่กัน ส่วนข้อจำกัดที่ต้องระบุคือ ภาพใดภาพหนึ่งไม่อธิบายทุกมิติของระบบ หากยังไม่ได้ทดลองกับผู้ใช้หรือข้อมูลจริง ให้เขียนว่าเป็นข้อเสนอเชิงออกแบบ ไม่สรุปเป็นผลที่พิสูจน์แล้ว การมีทั้งเกณฑ์และข้อจำกัดช่วยให้รายงานตรวจสอบเหตุผลได้ และเปิดทางให้ผู้อื่นนำกรณีเดียวกันไปทดสอบซ้ำในบริบทของตน

แหล่งข้อมูลประกอบ

• Object Management Group: UML 2.5.1 — นิยาม Sequence, Class และ State Machine
• IBM: What is a flowchart? — การใช้ภาพขั้นตอนกระบวนการ
• PostgreSQL: Constraints — ความสัมพันธ์ของข้อมูลที่ใช้ตรวจแบบ ER ก่อนสร้างตาราง