State​ ​Diagram​ ​คือ​อะไร​:​ ​ใช้​ออกแบบ​สถานะ​ของ​ ​Order​,​ ​Ticket​ ​และ​ ​Workflow

State Diagram หรือภาพสถานะ แสดงว่ารายการหนึ่งอยู่ในสถานะใด เปลี่ยนไปสถานะอื่นได้เมื่อมีเหตุการณ์หรือเงื่อนไขอะไร และสถานะใดเป็นปลายทาง เหมาะกับ Order, Ticket, คำขออนุมัติ หรือ Workflow ที่กฎการเปลี่ยนสถานะสำคัญต่อธุรกิจ

แยก State, Event และ Guard

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

ภาพที่ 1: เหตุการณ์และเงื่อนไขบนลูกศรช่วยกันการเปลี่ยนสถานะที่ไม่ถูกต้อง

ตัวอย่างสมมติ: คำสั่งซื้อ

คำสั่งซื้อเริ่ม “รอชำระ” จากนั้นไป “ชำระแล้ว” เมื่อระบบได้รับผลที่ตรวจได้ หรือไป “ยกเลิก” ตามกฎเวลาที่กำหนด หลังชำระแล้วอาจไป “เตรียมส่ง” และ “ส่งแล้ว” ต้องตัดสินใจว่าการคืนเงินเป็นสถานะใหม่ เหตุการณ์แยก หรือกระบวนการอีกชุด ไม่ควรใช้คำว่า “ปิดแล้ว” รวมกรณีสำเร็จ ยกเลิก และคืนเงินจนรายงานแยกไม่ออก

ใช้ภาพหาเงื่อนไขที่ตกหล่น

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

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

ระบุวัตถุที่แผนภาพติดตามเพียงชนิดเดียวต่อภาพ แสดง State เริ่มและจบ พร้อมเหตุการณ์และข้อห้ามที่สำคัญ จับคู่ลูกศรกับ Test Case อย่างน้อยกรณีผ่านและกรณีถูกปฏิเสธ อย่าสับสน State Diagram ที่ติดตามชีวิตของรายการกับ Flowchart ที่ติดตามขั้นตอนของคนหลายฝ่าย

อ่าน Flowchart และ 5 Diagram สำคัญ หรือดู บริการระบบหลังบ้าน

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

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

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

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

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

• Object Management Group: UML 2.5.1 — แนวคิด State Machine, Event และ Transition