Sequence​ ​Diagram​ ​คือ​อะไร​:​ ​อธิบาย​การ​ทำงาน​ระหว่าง​ ​User​,​ ​Frontend​,​ ​Backend​ ​และ​ ​Database

Sequence Diagram แสดงว่าองค์ประกอบของระบบส่งข้อความถึงกันตามลำดับเวลาอย่างไร มักวางผู้ร่วมงาน เช่น User, Frontend, Backend และ Database เรียงแนวนอน แล้วให้เวลาลงจากบนสู่ล่าง เหมาะกับคำถามว่า “เมื่อผู้ใช้กดส่ง ระบบใดทำอะไรก่อนและตอบกลับอย่างไร”

องค์ประกอบที่ควรรู้

ผู้ร่วมงานแต่ละตัวมีเส้นชีวิต (lifeline) ข้อความหรือการเรียกใช้งานแสดงด้วยลูกศร และผลตอบกลับแสดงตามความจำเป็น ไม่ต้องใส่ทุกฟังก์ชันภายในระบบ เพราะภาพจะอ่านยาก ควรตั้งชื่อข้อความเป็นการกระทำหรือข้อมูลที่สื่อจริง เช่น POST /requests, “ตรวจสิทธิ์”, “บันทึกคำขอ” มากกว่าคำว่า “ทำงาน”

ภาพที่ 1: ลำดับการส่งคำขอและผลตอบกลับระหว่าง User, Frontend, Backend และ Database

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

User กรอกข้อมูลบน Frontend → Frontend ส่ง Request ให้ Backend → Backend ตรวจตัวตนและข้อมูล → Backend บันทึกที่ Database → Database ตอบรหัสรายการ → Backend ส่งผลสำเร็จ → Frontend แสดงเลขอ้างอิง ต้องวาดทางเลือกเมื่อข้อมูลไม่ครบหรือผู้ใช้ไม่มีสิทธิ์ด้วย โดยในทางผิดพลาดนั้นฐานข้อมูลไม่ควรถูกบันทึกอย่างไม่ตั้งใจ

ใช้ภาพตอบคำถามเชิงออกแบบ

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

สำหรับรายงาน

กำหนดหนึ่ง use case ต่อภาพ ระบุทางปกติและทางผิดพลาดที่สำคัญ อธิบายขอบเขตว่าภาพละรายละเอียดใด เช่น ไม่แสดงขั้นตอนภายในฐานข้อมูล หากต้องอธิบายกฎอนุมัติในงานธุรกิจ ใช้ Flowchart เสริม เพราะ Sequence Diagram เน้นการสื่อสารระหว่างองค์ประกอบมากกว่าแผนผังขั้นตอนของคน

อ่าน Flowchart กับ Sequence Diagram และ REST API คืออะไร หรือดู บริการ Web Application

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

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

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

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

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

• Object Management Group: UML 2.5.1 — ข้อกำหนดของ Interaction และ Sequence Diagram