Use​ ​Case​ ​Diagram​ ​คือ​อะไร​:​ ​สัญลักษณ์​ ​Include​ ​Extend​ ​และ​ตัวอย่าง

Use Case Diagram คือแผนภาพที่แสดงกรณีใช้งานของระบบและความสัมพันธ์กับผู้มีปฏิสัมพันธ์ภายนอกระบบ ใช้ตอบคำถามว่า ใครเกี่ยวข้องกับระบบ และระบบสนับสนุนเป้าหมายใดของผู้เกี่ยวข้องเหล่านั้น นิยามและสัญลักษณ์ของ Use Case อยู่ในข้อกำหนด Unified Modeling Language หรือ UML ของ Object Management Group โดยบทความนี้อ้างอิง UML 2.5.1 บทที่ 18 [1]

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

Use Case, Actor และขอบเขตระบบหมายถึงอะไร

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

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

ขอบเขตระบบ หรือ System Boundary ใช้แยกสิ่งที่ระบบรับผิดชอบออกจากสภาพแวดล้อม โดยทั่วไปวาดเป็นกรอบสี่เหลี่ยมที่มีชื่อระบบ วาง Use Case ภายในและ Actor ภายนอก คำว่า “ภายนอก” ในที่นี้อ้างถึงขอบเขตที่กำลังสร้างแบบจำลอง เจ้าหน้าที่ของหน่วยงานจึงยังเป็น Actor ภายนอกซอฟต์แวร์ได้ แม้ทำงานอยู่ในองค์กรเจ้าของระบบ

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

สัญลักษณ์พื้นฐานที่ควรอ่านให้ถูกต้อง

• Actor: มักแสดงด้วยรูปคนและชื่อบทบาท ใช้แทนผู้มีปฏิสัมพันธ์ ไม่ใช่ตัวอย่างบัญชีผู้ใช้จริง
• Use Case: มักแสดงเป็นวงรีพร้อมชื่อการกระทำและสิ่งที่กระทำ เช่น “ตรวจสอบสิทธิ์ผู้ยืม”
• Association: เส้นทึบเชื่อม Actor กับ Use Case แสดงการมีส่วนร่วม ไม่ได้แสดงลำดับเวลาก่อนและหลัง
• Include: เส้นประพร้อมหัวลูกศรชี้จากกรณีใช้งานหลักไปยังกรณีใช้งานที่ถูกรวม พร้อมคำว่า «include»
• Extend: เส้นประพร้อมหัวลูกศรชี้จากกรณีใช้งานส่วนขยายไปยังกรณีใช้งานฐาน พร้อมคำว่า «extend»

หลักการของ Actor และ Use Case อ้างอิง [1] ส่วนทิศทางเส้น Include และ Extend สามารถตรวจสอบจากเอกสาร IBM [2] และ [3] ตามลำดับ ในตัวอย่างนี้ใช้ Association แบบเส้นทึบไม่มีหัวลูกศรเพื่อไม่ให้ผู้อ่านสับสนกับการส่งข้อมูล

Include กับ Extend ต่างกันอย่างไร

Include: นำพฤติกรรมหนึ่งเข้ามาเป็นส่วนหนึ่งของอีกกรณีใช้งาน

Include ใช้แสดงว่ากรณีใช้งานหลักนำพฤติกรรมของกรณีใช้งานอีกส่วนหนึ่งมาใช้ ไม่ใช่เพียงมีเงื่อนไขว่าเคยทำสิ่งนั้นสำเร็จในอดีต ความสัมพันธ์นี้ช่วยอธิบายพฤติกรรมที่นำกลับมาใช้ร่วมกัน โดยลูกศรชี้ จากกรณีใช้งานหลักไปยังกรณีใช้งานที่ถูกรวม [2]

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

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

Extend: เพิ่มพฤติกรรมที่จุดขยายของกรณีใช้งานฐาน

Extend ใช้เพิ่มพฤติกรรมลงในกรณีใช้งานฐาน ณ จุดขยาย หรือ Extension Point ที่กำหนด กรณีใช้งานฐานมีความหมายได้ด้วยตัวเอง ส่วนการเพิ่มพฤติกรรมอาจขึ้นกับเงื่อนไขของการทำงาน ลูกศรชี้ จากกรณีใช้งานส่วนขยายเข้าหากรณีใช้งานฐาน จึงเป็นทิศกลับกันเมื่อเทียบกับการอ่าน Include จากกรณีหลัก [3]

สมมติว่าอุปกรณ์บางประเภทต้องแนบเอกสารเพิ่มเติม กำหนด “แนบเอกสารเพิ่มเติม” ให้ Extend “ยื่นคำขอยืม” ที่จุดขยายชื่อ “เพิ่มเอกสาร” ภายใต้เงื่อนไข “ชนิดอุปกรณ์กำหนดให้แนบเอกสาร” นักศึกษาที่ยืมอุปกรณ์ประเภทอื่นยังยื่นคำขอได้โดยไม่เกิดพฤติกรรมส่วนนี้

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

ตัวอย่าง Use Case Diagram ระบบยืมคืนอุปกรณ์

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

ภาพที่ 1: ผู้เขียนจัดทำแผนภาพเชิงแนวคิดของส่วนยื่นและพิจารณาคำขอยืม โดยประยุกต์สัญลักษณ์ UML จาก [1]–[3] ไม่ใช่แบบจำลองครบทั้งระบบยืมคืนอุปกรณ์

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

ความสัมพันธ์ Include ไปยัง “ตรวจสอบสิทธิ์ผู้ยืม” แสดงส่วนพฤติกรรมที่ต้องใช้ในคำขอนี้ ส่วน Extend จาก “แนบเอกสารเพิ่มเติม” แสดงส่วนเพิ่มเติมตามเงื่อนไขที่อธิบายไว้ ไม่มีความจำเป็นต้องลากเส้น Include จาก “ยื่นคำขอยืม” ไป “พิจารณาคำขอ” เพียงเพราะฝ่ายเจ้าหน้าที่ต้องทำงานภายหลัง เพราะความสัมพันธ์ตามลำดับธุรกิจไม่เท่ากับการรวมพฤติกรรมของ Use Case

เขียนคำอธิบายกรณีใช้งานประกอบภาพอย่างไร

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

รหัสและชื่อ: UC-01 ยื่นคำขอยืม

ผู้เกี่ยวข้องหลัก: นักศึกษา โดยเจ้าหน้าที่เป็นผู้พิจารณาในอีกกรณีใช้งานหนึ่ง

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

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

เหตุเริ่มต้น: นักศึกษาเลือกยื่นคำขอพร้อมรายการอุปกรณ์และช่วงเวลาที่ต้องการ

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

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

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

รายละเอียดข้อมูลในคำขอควรเชื่อมกับ Data Dictionary ส่วนการส่งข้อมูลระหว่างนักศึกษา ระบบ และเจ้าหน้าที่สามารถอธิบายต่อด้วย Data Flow Diagram ซึ่งตอบคำถามคนละมุมกับ Use Case

Login จำเป็นต้องเป็น Include ของทุก Use Case หรือไม่

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

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

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

การนำไปใช้ในรายงานโครงงาน

เริ่มจากอธิบายขอบเขตและที่มาของความต้องการก่อนแสดงภาพ เช่น ข้อมูลจากการสัมภาษณ์เจ้าหน้าที่หรือการศึกษาระเบียบการยืม หากยังไม่ได้เก็บข้อมูลจริง ให้เขียนว่าเป็นข้อกำหนดสมมติสำหรับการออกแบบ จากนั้นกำหนดรหัสความต้องการและเชื่อมกับ Use Case เช่น FR-01 ยื่นคำขอ เชื่อมกับ UC-01

ใต้ภาพควรระบุว่าผู้จัดทำวาดเอง ประยุกต์จากหลักการใด และภาพครอบคลุมส่วนใดของโครงงาน เมื่ออธิบายทฤษฎีให้ใช้นิยามและมาตรฐานต้นฉบับ [1] เป็นหลัก ส่วนบทความนี้ใช้ประกอบการทำความเข้าใจและตัวอย่างประยุกต์ ไม่ควรอ้างว่าแผนภาพตัวอย่างเป็นข้อกำหนดที่หน่วยงานภายนอกรับรอง

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

ตัวอย่างรายการอ้างอิงบทความนี้หลังเผยแพร่: Waihaus Studio. (2026, 2 ตุลาคม). Use Case Diagram คืออะไร: สัญลักษณ์ Include Extend และตัวอย่าง. https://www.waihaus.site/blog/use-case-diagram-guide ควรเปิดตรวจฉบับที่เผยแพร่ก่อนใช้อ้างอิง และปรับรูปแบบตามคู่มือของสถาบัน

คำถามที่พบบ่อย

Use Case Diagram เป็น Flowchart หรือไม่

ไม่ใช่ Use Case Diagram เน้นกรณีใช้งานกับผู้เกี่ยวข้อง ส่วน Flowchart เน้นขั้นตอนและทางเลือกของกระบวนการ เส้น Association ใน Use Case จึงไม่ได้แทนลูกศร “ทำขั้นตอนถัดไป”

ทุก Use Case ต้องมี Include หรือ Extend หรือไม่

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

Actor ต้องเป็นคนหรือไม่

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

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

เอกสารอ้างอิง

• [1] Object Management Group. (2017). OMG Unified Modeling Language (OMG UML), Version 2.5.1. บทที่ 18 UseCases โดยเฉพาะหัวข้อ 18.1.3 Semantics และ 18.1.4 Notation. ข้อกำหนด UML 2.5.1 และ ข้อมูลรุ่นจาก OMG
• [2] IBM. (ม.ป.ป.). Include relationships. IBM Documentation. เอกสาร Include relationships สืบค้น 2 ตุลาคม 2026.
• [3] IBM. (ม.ป.ป.). Extend relationships. IBM Documentation. เอกสาร Extend relationships สืบค้น 2 ตุลาคม 2026.