ควร​ใช้​ ​Flowchart​ ​หรือ​ ​Sequence​ ​Diagram​ ​เมื่อ​ใด

Flowchart กับ Sequence Diagram ไม่ใช่ภาพสองชื่อของเรื่องเดียวกัน Flowchart มอง ขั้นตอนและทางเลือกของกระบวนการ ส่วน Sequence Diagram มอง ข้อความที่ผู้ร่วมงานหรือระบบส่งถึงกันตามลำดับเวลา งานหนึ่งอาจใช้ทั้งสองภาพได้ หากผู้อ่านต้องตอบคนละคำถาม

ใช้ Flowchart เมื่อถามเรื่องงาน

ถามว่าใครเริ่ม ขั้นตอนไหนต้องอนุมัติ ถ้าข้อมูลไม่ครบกลับไปที่ใด และขั้นตอนไหนทำซ้ำ Flowchart ช่วยให้ฝ่ายปฏิบัติการเห็นขั้นตอนปัจจุบันและแบบใหม่ หากมีหลายทีม ใช้ swimlane แสดงผู้รับผิดชอบ แต่ไม่จำเป็นต้องลงรายละเอียดทุก Request ที่เว็บส่งถึง API

ภาพที่ 1: ภาพขั้นตอนใช้ตอบกฎการทำงาน ส่วนภาพลำดับใช้ตอบการสื่อสารระหว่าง User และระบบ

ใช้ Sequence Diagram เมื่อถามเรื่องการสื่อสาร

ถามว่า Frontend ส่งอะไรให้ Backend, Backend ตรวจสิทธิ์ก่อนหรือหลังอ่านข้อมูล, Database ตอบอย่างไร และถ้าบริการภายนอกล่มผลย้อนกลับที่ใด Sequence Diagram จัดเวลาแนวตั้ง จึงเหมาะกับการตรวจจุดรอและกรณีผิดพลาดของการเชื่อมต่อ

ตัวอย่างสมมติ: ลูกค้าส่งคำขอ

Flowchart อาจแสดง “รับคำขอ → ตรวจความครบ → ขอข้อมูลเพิ่มหรือมอบหมายงาน” ซึ่งเจ้าหน้าที่ใช้ทบทวนวิธีทำงาน Sequence Diagram ของกรณีเดียวกันจะแสดง “User → Frontend → Backend → Database → Backend → Frontend” เพื่อให้ทีมพัฒนารู้ว่าคำขอถูกบันทึกและเลขอ้างอิงถูกส่งกลับเมื่อไร ภาพแรกบอกกฎงาน ส่วนภาพหลังบอกการแลกข้อมูล

เกณฑ์เลือกและข้อควรระวัง

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

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

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

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

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

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

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

• IBM: What is a flowchart? — การแสดงกระบวนการและการตัดสินใจ
• Object Management Group: UML 2.5.1 — การแสดง Interaction ตามลำดับใน UML