๊Use Case Diagram

รหสั วชิ า 30204-2003 Use Case Diagram เป็นไดอะแกรมท่ีช่วยใหผ้ พู้ ฒั นาทราบถงึ ความสามารถของระบบว่า ตอ้ งทำ อะไรได้บ้าง ทราบถึงผใู้ ช้งานในแตล่ ะสว่ นของระบบและเกดิ ความง่ายในการ สอ่ื สารระหวา่ ง ผพู้ ฒั นากับผ้ใู ชร้ ะบบ จัดทำโดย นาย ธรณ์เทพ ฤกษส์ ะเสน เลขท่ี 13 นาย ราชนั ย์ ปานนยิ ม เลขท่ี 16 นาย ณฎั ฐากร ชญั ถาวร เลขท่ี 17

นำเสนอ อาจารย์ สุรพี ร เมืองมงุ คณุ จัดทำโดย เลขที่ 17 นาย ณัฎฐากร ชญั ถาวร เลขที่ 13 นาย ธรณ์เทพ ฤกษ์สะเสน เลขท่ี 16 นาย ราชันย์ ปานนยิ ม งานวิจยั นี้เปน็ สว่ นหนงึ่ ของการศกึ ษาหลักสตู รประกาศนียบตั รวิชาชพี ชน้ั สงู (ปวส.) ประเภทวิชาพาณชิ ยกรรม สาขาวิชาคอมพิวเตอรธ์ ุรกจิ วิทยาลยั เทคโนโลยเี กษมสันตบ์ รหิ ารธรุ กิจ ปกี ารศึกษา 2565

คำนำ รายงานหนังสือ E-BOOK เล่มนี้มีเนื้อหาเกี่ยวกับวิชา การวิเคราะห์ออกแบบระบบเชิงวัตถุ ซึ่งมีเนื้อหาของ หน่วยที่ 6 การเรียนรู้เรื่อง Use Case Diagram,สัญลักษณ์ความสัมพันธ์การสร้าง Use Case Diagram ขอ้ แนะนำในการสรา้ ง Use Case Diagram การเขียนคำอธิบาย Use Case และตวั อยา่ ง Use Case Diagram ซ่งึ เป็นการรวบรวมขอ้ มูลต่าง ๆ เพื่อการใชง้ านที่ถกู ตอ้ ง ผู้จัดทำหวังเป็นอย่างยิ่งว่าหนังสือ E-B00k เล่มนี้น่าจะมีประโยชน์ต่อผู้เรียนและผู้ที่สนใจเป็นอย่างยิ่ง หากมีขอ้ ผดิ พลาดประการใดผู้จดั ทำขอน้อมรับ และขออภัยมา ณ ทีน่ ด้ี ้วย คณะผู้จดั ทำ

สารบญั หนา้ 1 Use Case Diagram 2-9 สญั ลกั ษณ์ความสัมพนั ธ์ 9 การสร้าง Use Case Diagram 10-11 ขอ้ แนะนำในการสรา้ ง Use Case Diagram 11 การเขยี นคำอธิบาย Use Case 11-14 ตัวอย่าง Use Case Diagram

1 Use Case Diagram Use Case Diagram เป็นแผนภาพที่ใช้แสดงใหท้ ราบวา่ ระบบทำงานหรอื มหี น้าท่ใี ดบ้าง โดยมสี ญั ลกั ษณ์รปู วงรี แทน Use Case และสัญลักษณร์ ปู คน (Stick Man Icon) แทน Actor สำหรบั ชือ่ Use Case นั้น ใหใ้ ชค้ ำกรยิ า หรือกริยาวลี (คำกริยามกี รรมมารองรบั ) เชน่ ลงทะเบียนเรียน ตรวจสอบรายวิชาบันทกึ การชำระเงิน Generate Report, Enter Sales Data, Compute Commission เปน็ ต้น สว่ นการมปี ฏิสมั พนั ธร์ ะหวา่ ง Use Case และ Actor จะใชเ้ ส้นตรงลากเชอ่ื มตอ่ กัน หรือจะใช้เสน้ ตรงมหี ัวลกู ศรกไ็ ด้ ในทนี่ ี้เลอื กใชเ้ สน้ ตรงไม่มีหวั ลกู ศร สว่ นเสน้ แบ่งขอบเขตระหวา่ ง Actor กับ Use Case จะใชเ้ สน้ กรอบสี่เหล่ยี มเรียกวา่ “System Boundary” และส่ิงสำคญั สว่ นสุดทา้ ยกค็ ือ “ชือ่ ของระบบ (System Name)” ให้แสดงไว้ด้านบนสุดของ แผนภาพ Student Register Course Checkout Course Record Billing Registration staff Financial Staff รูปที่ 1 Use Case Diagram ของระบบลงทะเบียน นอกจากนี้ หากกลา่ วถึง Use Case Diagram ในดา้ นการพัฒนาระบบ นอกเหนอื จากการนำมาใชเ้ ก็บรวบรวม ความต้องการต่างๆ แล้ว Use Case Diagram ยงั ถูกนำไปใชเ้ ปน็ พื้นฐานเพ่ือการสร้างแผนภาพ (Diagram) ชนิดอน่ื ในขนั้ ตอนต่อๆ ไป และทมี งานยงั สามารถใช้ Use Case Diagram เพื่อตดิ ตามผลการดำเนนิ งานได้อีก ดว้ ย

2 สัญลักษณ์และความสัมพนั ธ์ สญั ลกั ษณท์ ่สี ำคัญของ Use Case Diagram มดี งั ตอ่ ไปนี้ Use Case คอื หนา้ ท่ที ร่ี ะบบต้องกระทำ ใชส้ ญั ลักษณร์ ปู วงรี พรอ้ มทั้งเขยี นช่อื Use Case ซงึ่ ตอ้ งใช้คำกริยา หรือกรยิ าวลกี ไ็ ด้ Use Case Name รูปที่ 2 สญั ลกั ษณ์ Use Case Actor คือ ผเู้ ก่ยี วข้องกับระบบ ซง่ึ รวมทัง้ Primary Actor และ Stakeholder Actor ทเี่ ปน็ มนุษย์ ในท่ีน้ีจะใช้ สญั ลักษณ์รูปคน (Stick Man Icon) เหมอื นกนั พรอ้ มทั้งเขยี นชอื่ Actor ไว้ดา้ นล่างของสญั ลักษณด์ ้วย แต่หาก เปน็ Actor ทไี่ ม่ใชม่ นุษย์ เชน่ ระบบงานอนื่ ท่อี ยนู่ อกเหนอื ระบบทีเ่ ราสนใจ จะใช้รปู สเี่ หลยี่ มแล้วเขยี นคำวา่ “<<actor>>” ไวด้ ้านบน <<Actor>> Actor Name Actor Name Primary & Stakeholder Actor Primary & stakeholder Actor ท่ไี มใ่ ช่มนษุ ย์ ท่ีเป็นมนษุ ย์ รูปที่ 3 แสดงสัญลักษณ์ Actor รูปที่ 3 สญั ลักษณ์ Actor

3 System Boundary คือ เสน้ แบ่งขอบเขตระหว่างการทำงานระบบกับผกู้ ระทำต่อระบบ (Use Case กบั Actor) โดยใชร้ ูปสเ่ี หลย่ี มเปน็ สญั ลักษณพ์ รอ้ มทั้งเขียนชอื่ ระบบไว้ด้านใน โดยใสช่ อื่ ระบบที่ทำงานนั้น ๆ System Name รูปท่ี 4 สญั ลักษณ์ System Boundary Connection คือ เส้นทลี่ ากเชอ่ื มต่อระหวา่ ง Actor กบั Use Case ทมี่ ปี ฏิสัมพนั ธ์กัน ใช้เส้นตรงไมม่ ีหัวลกู ศร เปน็ สัญลักษณข์ อง Connection ส่วน Connection ที่ใช้เชอ่ื มตอ่ ระหว่าง Use Case กับ Use Case กรณีท่ี Use Case นน้ั มีความสมั พนั ธ์ซ่งึ กันและกัน จะใชส้ ญั ลักษณเ์ ส้นตรงมหี วั ลูกศร พรอ้ มทง้ั เขยี นชื่อความสัมพนั ธ์ ไวต้ รงกลางเส้นดว้ ย โดยเขยี นไวภ้ ายในเครอ่ื งหมาย <<...>> Connection ระหวา่ ง <<relationship name>> Actor กบั Use Case Connection ระหวา่ ง Use Case กบั Use Case รปู ท่ี 5 สญั ลักษณ์ Connection Extend Relationship เปน็ ความสัมพันธแ์ บบขยายหรอื เพิม่ เกิดขึน้ ในกรณที ่บี าง Use Case ดำเนนิ กิจกรรม ของตนเองไปตามปกติ แต่อาจจะมีเง่ือนไขหรือสงิ่ กระตุ้นบางอยา่ งทส่ี ่งผลใหก้ จิ กรรมตามปกตขิ อง Use Case นั้นถูกรบกวนจนเบ่ียงเบนไป ซึง่ สามารถแสดงเงื่อนไขหรอื

4 ส่ิงกระตุ้นเหลา่ น้นั ได้ในรูปของ “Use Case” และเรยี กความสัมพนั ธร์ ะหว่าง Use Case ในลกั ษณะนวี้ “Extend Relationship” โดยเรียก Use Case ทถ่ี ูกรบกวนหรือ Use Case ที่ดำเนนิ งานตามปกตวิ ่า “Base Use Case” และเรยี ก Use Case ทท่ี ำหน้าทรี่ บกวนหรือกระต้นุ Base Use Case วา่ “Extending Use Case” จากการศึกษาการทำงานของ Use Case ซึง่ ทำหน้าที่ตามปกติ เมื่อเกดิ เหตกุ ารณ์ผิดปกติขน้ึ จะตอ้ งทำ หน้าทีพ่ ิเศษเพ่ิม โดยหน้าท่พี เิ ศษทเี่ พิ่มขน้ึ กค็ ือ “Extending Use Case” น่ันเอง ดังนน้ั อาจกล่าวไดว้ ่า Use Case ท่เี ป็น Extending Use Case จะเกิดขนึ้ เพียงบางครั้งเท่านัน้ (ไม่ได้เกดิ ขนึ้ ทกุ ครั้งทด่ี ำเนนิ กิจกรรมตาม Base Use Case) การวาดเสน้ Connection เชอ่ื มระหว่าง Use Case ท้งั สอง ใหเ้ รมิ่ ตน้ ลากเสน้ ตรงจาก Extending Use Case โดยใชท้ ศิ ทางของลกู ศรไปที่ Base Use Case Base Use Case <<extends>> Extending Use Case รูปที่ 6 การวาดเส้น Connection เชอื่ มระหวา่ ง Extending Use Case กบั Base Use Case

5 ตวั อยา่ งแสดง Extend Relationship ของระบบลงทะเบียนไดด้ ังภาพที่ 6 Student Register Course <<extends>> Checkout Course Registration Staff Register Regrade Record Billing Financial Staff รูปที่ 7 Use Case Diagram ทม่ี ีความสมั พันธ์แบบ Extend Relationship จากรูปท่ี 7 สังเกตท่ี Use Case “Register Course” ซงึ่ เปน็ Base Use Case คือ ทำหน้าท่ี รับ ลงทะเบยี นตามปกตแิ ตเ่ มอ่ื มเี งอื่ นไขหรอื มเี หตกุ ารณพ์ เิ ศษเกดิ ขน้ึ คอื “นักศึกษาบางคนอาจมีการลงทะเบยี น เรยี นซ้ำเพอ่ื ปรับเกรดด้วย (Regrade)” จึงได้เพ่ิม Extending Use Case เพ่อื มารองรับหน้าที่พเิ ศษดังกลา่ ว นน่ั คือ“Register Regrade”

6 Include Relationship ความสมั พนั ธ์อีกรูปแบบหนึ่งของ Use Case Diagram กค็ ือ ความสัมพันธแ์ บบเรียกใช้ เกดิ ขึ้นในกรณีที่ Use Case หนึง่ ไปเรยี กหรือดงึ กจิ กรรมของอีก Use Case หน่งึ มา ใช้ เพ่อื ให้กจิ กรรมน้นั เกดิ ขนึ้ จรงิ ใน Use Case ของตนเอง หรอื กล่าวใหง้ ่ายกว่าน้ันคือ กจิ กรรมใน Use Case หนง่ึ อาจจะถูกผนวกเข้าไปรวมกบั กจิ กรรมของอีก Use Case หน่ึง เราเรียกความสมั พันธ์ระหว่าง Use Case ในลักษณะนวี้ า่ “Include Relationship” โดย Use Case ที่ทำหน้าท่ีดึงกิจกรรมมาจาก Use Case อื่นๆ เรียกว่า “Base Use Case” ในขณะที่ Use Case ทถี่ ูกเรียก หรือถกู ดงึ กจิ กรรมมาใช้ เรียกวา่ “Included Use Case” สามารถเขยี นเส้น Connection ได้ในทศิ ทางตรงกนั ข้ามกบั Extend Relationship โดยเร่มิ ต้นลากเส้น ตรงจาก Base Use Case หนั ลูกศรช้ีไปท่ี Included Use Case แล้วเขียนชอื่ Relationship “<<uses>>” (บางตารางจะใช้คำวา่ <<include>>) ไวต้ รงกลางเสน้ ดว้ ย Extending Use Case <<Uses>> Base Use Case รูปที่ 8 การลากเส้น Connection ระหว่าง Base Use Case กบั Included Use Case ความสมั พนั ธร์ ะหวา่ ง Use Case แบบ Include เปน็ การสนับสนนุ หลักการนำกลับมาใชใ้ หม่ของ Use Case (Use Case Reusability) กล่าวคอื Use Case หนึ่งสามารถถกู Include ได้โดย Base Use Case หลายๆ ตัว และสามารถถูก Include ได้มากกว่าหนึ่งครง้ั ดว้ ย เชน่ ในการทำงานชองระบบเอทีเอ็ม Use Case “การ ตรวจสอบผเู้ ข้าใช้ระบบ (Validate User)” สามารถเปน็ Included Use Case ใหก้ ับ Base Use Case หลายๆ ตัว ได้แก่ Base Use Case “การถอนเงนิ (Withdraw Money)” และ Base Use Case “การโอนเงิน (Transfer Money)”ดังนนั้ จากรูปท่ี 7 เมอื่ พิจารณาแล้ว Use Case “ตรวจสอบรายวิชา (Checkout Course)” สามารถ ถูกเรียกใช้จาก Use Case “ลงทะเบยี นเรียน (Register Course)” ได้ ดังนั้น Use Case “Checkout Course” มคี วามสัมพันธก์ ับ Use Case “Register Course” แบบ Include แสดง Use Case Diagram อกี ครงั้

7 Student Register Course <<extends>> <<uses>> Checkout Course Registration Staff Register Regrade Record Billing Financial Staff รูปที่ 9 Use Case Diagram ทมี่ ี Included Relationship หมายเหตุ 1. ในบางตาราจะเรียกความสัมพนั ธ์แบบ Include ได้อีกอย่างหน่ึงวา่ “Use Relationship” 2. ความแตกตา่ งระหว่างความสมั พนั ธ์แบบ Extend กับ Include คือ Extend จะเป็น Use Case ที่ ถูกเรียกใชเ้ ฉพาะบางกรณีเท่าน้ัน แต่ Include จะถูกเรยี กใชท้ ุกครั้งที่ Base Use Case มกี ารดำเนนิ กจิ กรรม Generalization หรอื Specialization ที่เกิดขน้ึ ระหวา่ ง Use Case มคี ณุ สมบตั ิแตกตา่ งจาก Generalization/Specialization ท่ีเกดิ ขน้ึ ระหวา่ งคลาส คือ ความสมั พันธล์ ักษณะดังกล่าวทเ่ี กิดขน้ึ ใน Use Case น้ีจะไม่มกี ารถ่ายทอดคุณลักษณะ (ไมม่ ีการ Inherit) แต่จะใชเ้ พ่ือแสดงความสมั พนั ธ์แบบจำแนกแยกแยะ ประเภทของ Use Case เท่าน้ัน อยา่ งไรกต็ าม Use Case ทเ่ี ปน็ Use Caseหลักในการจำแนกประเภทจะ เรยี กวา่ “Parent Use Case” ส่วน Use Case ที่ถูกจำแนกแยกแยะออกมา จะเรยี กว่า “Child Use Case”

8 ส่วนสญั ลักษณเ์ ชอื่ มความสัมพนั ธ์ ใหใ้ ช้เส้นตรงลูกศรโปร่ง ลากจาก Child Use Case ใหล้ ูกศรชี้ไปที่ Parent Use Case Parent Use Case <<Uses>> Child Use Case รูปที่ 10 ความสัมพันธร์ ะหว่าง Use Case แบบ Parent Use Case และ Child Use Case ดงั ที่กล่าวไปแล้ววา่ เราจะใช้ Generalization / Specialization ในกรณีท่ตี ้องการแสดงความสัมพันธ์ ในเชงิ การจำแนกแยกแยะประเภทของ Use Case เชน่ การตรวจสอบความถูกตอ้ งของผู้ใช้งานระบบ (Validate user) สามารถกระท าได้หลายวธิ ี ไดแ้ ก่ การตรวจสอบจากรหัสผา่ น (Verify Password) และการ ตรวจจากลายน้วิ มือ (Fingerprint Recognition) เป็นตน้ แสดงความสัมพนั ธ์ได้ Validate User Verify Password Fingerprint Recognition รปู ท่ี 11 ความสัมพันธ์ระหวา่ ง Use Case แบบ Generalization / Specialization

9 นอกจากเราจะใช้ความสัมพนั ธแ์ บบ Generalization / Specialization กบั Use Caseแลว้ เรายังสามารถใช้ ความสมั พันธล์ กั ษณะนีก้ ับ Actor ได้เช่นเดยี วกนั ตวั อยา่ งเชน่ เราสามารถใช้ UML อธบิ ายขอ้ เท็จจริง “คนคุม งาน (Worker Supervisor) จดั เปน็ คนงานประเภทพิเศษทีม่ หี น้าท่พี ิเศษกวา่ คนงาน (Worker) ท่ัวไป” Worker Supervisor รูปที่ 12 ความสัมพันธแ์ บบ Generalization / Specialization ระหว่าง Actor การสร้าง Use Case Diagram เร่มิ ตน้ การสรา้ ง Use Case Diagram ด้วยการวเิ คราะหห์ าขอบเขตของระบบ (Problem Domain) ซึง่ ประกอบไปด้วยการคน้ หา Actor ทค่ี วรมีในระบบ และ Use Case ทม่ี ปี ฏสิ มั พันธ์โดยตรงกบั Actor เหล่านัน้ ขึน้ มากอ่ น จากนนั้ จึงเพิ่มเติม Use Case อ่นื ๆ เข้าไปจนครบหน้าทีก่ ารทำงานของระบบ 1. คน้ หา Actor 2. ค้นหา Use Case ทมี่ ีปฏิสัมพันธ์กับ Actor น้ันโดยตรง 3. คน้ หาและสร้างความสมั พันธร์ ะหวา่ ง Use Case หรือ Actor (ถ้าม)ี แล้วเพิ่มเตมิ Use Caseใหม่ซงึ่ อาจเปน็ Included Use Case, Extending Use Case ท่เี พิ่มเติมจาก Base Use Case ทมี่ อี ยู่แล้ว หรือจะเพ่มิ Base Use Case ใหม่กไ็ ด้ (ถา้ ม)ี 4. ตอ้ งไม่มี Actor ใดเลยท่ีไม่มีปฏสิ มั พนั ธก์ ับ Use Case 5. ตอ้ งไมม่ ี Use Case ใดเลยที่ไม่มีปฏสิ มั พนั ธ์กบั Actor 6. Use Case ทุกตัวตอ้ งมปี ฏิสัมพนั ธ์อยา่ งใดอย่างหนึง่ กบั Actor หรือ Use Case ตวั อ่นื ๆ เสมอ 7. เขียนคำอธิบายแตล่ ะ Use Case จนครบถ้วน

10 ขอ้ แนะนำในการสรา้ ง Use Case Diagram ปญั หาสำคญั ทเ่ี กดิ ขึน้ ในระหว่างการสร้าง Use Case Diagram ก็คือ การทีน่ กั วเิ คราะหร์ ะบบหรือ ทีมงานทีร่ บั ผดิ ชอบไมส่ ามารถระบุได้ชัดเจนว่าจะต้องแสดง Use Case ให้ละเอียดมากน้อยเพยี งใด จะตอ้ ง แสดง Use Case ใดบ้าง ไมแ่ สดง Use Case ใดบ้าง หรือต้องแสดง Use Caseท้งั หมดท่ีเป็นหนา้ ท่ีที่ระบบต้อง กระทำทำให้บางครั้งทมี งานตอ้ งเสียเวลาไปกับกระบวนการสรา้ ง Use Case Diagram มากเกนิ ความจำเปน็ เนอ่ื งจากสดุ ทา้ ยแล้ว Use Case Diagram ท่ีไดม้ าก็ไม่ได้ถูกนำไปใชใ้ นขนั้ ตอนต่อไปของการพฒั นาระบบ หรือ หากถูกนำ ไปใช้เป็นพ้ืนฐานในการสร้างแผนภาพชนดิ อื่นตอ่ ไป กจ็ ะทำให้การดำเนนิ งานในข้นั ตอนอ่ืนล่าช้าไป ด้วย ดงั นนั้ ในท่ีน้จี ึงมีขอ้ แนะนำบางประการท่จี ะทำให้ขน้ั ตอนการสรา้ ง Use Case Diagram เปน็ ขนั้ ตอนทีไ่ ม่ ต้องใช้เวลามากจนเกนิ ไป ดังน้ี 1. Use Case Diagram ใช้เพ่ือแสดงให้เห็นถึงขอ้ มูลความตอ้ งการของผู้ใช้ระบบเท่านัน้ หรอื อาจกล่าวไดว้ า่ Use Case Diagram ใช้เพ่ือเกบ็ รวบรวมขอ้ มลู ความต้องการจากผู้ใช้เทา่ น้นั เน่ืองจากหาก Use Case Diagram ทไี่ ด้ในรอบแรกยังไมส่ ามารถครอบคลมุ ความต้องการของผูใ้ ช้ กส็ ามารถนำมาปรับปรงุ แก้ไขเพม่ิ เตมิ ไดจ้ นกวา่ จะครบถว้ น เมือ่ ครบถ้วนแล้ว นัน่ หมายความวา่ ทีมงานมีความเขา้ ใจกบั ขอ้ มูลความต้องการในระบบใหม่ขอ ผูใ้ ช้แล้ว จึงอาจนำ Use Case Diagram ไปใชเ้ ป็นพืน้ ฐานในการสรา้ งแผนภาพชนดิ อ่ืนหรือไมก่ ไ็ ด้ (ข้ึนอย่กู บั ทมี งาน) 2. Use Case Diagram อาจมคี วามละเอยี ดมากหรือน้อยกไ็ ด้ ข้นึ อยูก่ ับมมุ มอง เทคนคิ และประสบการณข์ อง ทมี งานหรือนกั วิเคราะห์ระบบ จงึ ไมม่ ขี อ้ สรปุ ใดระบุไดว้ ่า Use Case Diagram ลกั ษณะใดถกู ตอ้ ง หรอื ลกั ษณะ ใดไมถ่ กู ตอ้ ง เนือ่ งจาก สุดท้ายแล้วไมว่ ่าจะเปน็ Use Case Diagram ลกั ษณะใดกต็ าม ยอ่ มสง่ ผลใหท้ มี งานเกิด ความเข้าใจในข้อมูลความต้องการระบบใหมข่ องผู้ใชไ้ ดอ้ ยา่ งถูกตอ้ งเช่นเดียวกนั 3. ให้ตระหนกั อยเู่ สมอวา่ Use Case Diagram นน้ั ใชเ้ พ่ือการสือ่ สารระหว่างนักวเิ คราะห์ระบบกบั ผใู้ ช้ ไมไ่ ด้ใช้ สอ่ื สารระหว่างนกั วิเคราะหร์ ะบบกับโปรแกรมเมอร์ ดังนนั้ Use Case Diagram จึงควรท าให้ผใู้ ชเ้ หน็ ภาพรวม ของระบบในเชิงกว้างมากกวา่ เชงิ ลกึ (ในเชงิ กวา้ ง คอื ในระดบั ทีท่ ราบไดว้ ่าครอบคลมุ ความต้องการของผ้ใู ช้ หรอื ไม่ ในเชงิ ลกึ คอื ในระดบั รายละเอยี ดการทำงานของระบบ) ซ่ึงจะท าใหผ้ ู้ใช้ทราบว่านักวเิ คราะหร์ ะบบ เข้าใจความต้องการของตนเองไดอ้ ยา่ งครบถ้วนหรือไม่น่ันเอง 4. Use Case Diagram โดยส่วนใหญจ่ ะไม่แสดงใหเ้ หน็ ถึงการทำงานในระดับการจัดการขอ้ มูลในฐานขอ้ มูล เช่น การเพ่ิม ลบ แก้ไข หรอื ปรบั ปรงุ ข้อมูล เปน็ ตน้ ทั้งนี้ เนือ่ งจากโปรแกรมของระบบงานทกุ ระบบจะต้องมี หนา้ ท่ีในส่วนของการจัดการขอ้ มูลเปน็ หนา้ ทพี่ ้ืนฐานอยแู่ ล้ว ไมจ่ ำเปน็ ตอ้ งนำมาแสดงใหเ้ ห็นใน Use Case Diagram กไ็ ด้ 5. จากข้อ 3 สงิ่ ทคี่ วรนำมาแสดงใน Use Case Diagram กค็ ือ หนา้ ทีห่ ลกั ๆ หรอื หน้าทท่ี ่เี ปน็ จดุ เดน่ ของระบบ ที่ผู้ใชง้ านต้องการให้ระบบกระทำได้อย่างแทจ้ รงิ เทา่ นนั้ (เปน็ การสนับสนนุ ข้อความทีว่ า่ “หนา้ ที่ในการเพิ่ม ลบ แก้ไข หรอื ปรบั ปรงุ ขอ้ มูลนัน้ เปน็ หนา้ ทพี่ ืน้ ฐานทีท่ ุกระบบตอ้ งมีอยู่แลว้ ”) 6. จากขอ้ 4 คำว่า “หน้าทห่ี ลักหรือหน้าทท่ี เ่ี ปน็ จดุ เด่นของระบบ” ในท่นี ้ีหมายถึง หน้าท่ีท่รี ะบบจะตอ้ งกระทำ (System Operate) ตามความตอ้ งการของผใู้ ช้ ไม่ใชห่ น้าทีท่ ่ีผใู้ ชจ้ ะตอ้ งกระทำ (Human Operate) อัน เนื่องจากการทำงานของระบบ

11 การเขียนคำอธบิ าย Use Case เชน่ เดยี วกับการวเิ คราะห์ระบบแบบเดมิ ท่ีจะต้องมีการเขยี นคำอธบิ าย Context Diagramเพื่อให้ ทราบรายละเอยี ดปลกี ยอ่ ยของแต่ละระบบย่อยด้วย สำหรบั ในแต่ละ Use Case ตามที่กล่าวไปแลว้ วา่ ประกอบ ไปดว้ ยการกระทำหลายๆ อย่างตอ่ เนอ่ื งกนั เป็นล าดับข้นั ตอน ดงั นัน้ การแสดงแผนภาพแทนความคดิ ของ นกั วิเคราะหร์ ะบบท่มี ตี ่อระบบเพยี งอย่างเดียวนนั้ อาจไม่เพียงพอ จำเป็นต้องมกี ารเขยี นอธบิ ายรายละเอียด ควบคู่กนั ไปดว้ ย เรียกคำอธิบาย Use Case ดงั กลา่ วว่า “กระแสของเหตุการณ์ (Flow of Event)”การเขยี นคา อธิบาย Use Case หรอื Flow of Event น้ัน ปจั จบุ ันมรี ูปแบบแตกตา่ งกันออกไป แตใ่ นท่ีนีจ้ ะเขยี นคำอธบิ าย โดยมีสว่ นประกอบ 2 ส่วนสำคัญ ได้แก่ Main Flow และ Exceptional Flow 1. Main Flow คือ ลำดับกจิ กรรม เม่ือ Use Case ดำเนนิ กิจกรรมตามปกติ โดยการเขยี นคำอธบิ ายใน ลกั ษณะเปน็ ย่อหน้า (Paragraph) และ Main Flow จะตอ้ งมเี พียงหนงึ่ เดียวเท่าน้ัน 2. Exceptional Flow คอื ลำดับกิจกรรม เมอื่ Use Case ดำเนินกจิ กรรมผิดจากปกติ โดยสามารถมีมากกว่า 1 Flow ได้ท้งั Main Flow และ Exceptional Flow จะต้องระบถุ งึ สาเหตุของการเริ่มตน้ และสน้ิ สดุ กิจกรรม ด้วยเสมอ นอกจากการระบุถึง Main Flow และ Exceptional Flow แลว้ เราสามารถเพ่มิ เตมิ สว่ นประกอบ อ่นื ๆไดต้ ามความเหมาะสม โดยในท่ีน้ีจะเพิม่ Use Case Title, Use Case Id, Primary Actor และ Stakeholder Actor ดว้ ย ดว้ ยตวั อยา่ ง Use Case Diagram ของระบบลงทะเบยี นของนักศึกษา ระบบลงทะเบียนมีกล่มุ บคุ คลทเ่ี ก่ยี วขอ้ ง 2 กลุม่ ไดแ้ ก่ นกั ศกึ ษา และพนกั งานของมหาวทิ ยาลยั (เจา้ หนา้ ทฝ่ี ่ายทะเบยี นและเจ้าหนา้ ทีฝ่ า่ ยการเงิน) ในแต่ละเทอมจะตอ้ งมนี ักศึกษามาลงทะเบยี นเรียนของภาค เรยี นปกติ โดยนักศกึ ษาจะต้องกรอกแบบฟอรม์ ลงทะเบียนให้เรียบร้อยแลว้ นำไปยน่ื กบั เจา้ หนา้ ทีฝ่ า่ ยทะเบยี น ในวนั และเวลาทีป่ ระกาศไวเ้ ม่ือเจา้ หน้าทีร่ บั แบบฟอรม์ ลงทะเบียนมาแลว้ จะทำการตรวจสอบวชิ าท่ีนกั ศกึ ษา ไดล้ งไวใ้ นแบบฟอร์มกบั ประวัตกิ ารเรยี นว่าถกู ตอ้ งหรอื ไม่ เนือ่ งจาก บางวิชาของแต่ละเทอมมเี ง่อื นไขวา่ จะ ลงทะเบยี นไดก้ ต็ อ่ เม่ือสอบผ่านอกี วชิ าหนง่ึ มากอ่ น เม่ือตรวจสอบพบวา่ ถูกต้องแล้ว เจา้ หนา้ ที่ฝา่ ยทะเบยี นจะ คำนวณเงนิ คา่ ลงทะเบียนเรียน แลว้ บันทกึ ลงในฐานขอ้ มลู สง่ั พิมพใ์ บรบั ลงทะเบยี นโดยแบง่ ออกเป็น 2 ส่วน สว่ นท่ี 1 นกั ศกึ ษาเกบ็ ไวเ้ อง ส่วนท่ี 2 นำไปชำระเงนิ โดยโอนผ่านทางธนาคาร แลว้ นำใบรับชำระเงินกลบั มาให้ เจา้ หนา้ ทฝ่ี า่ ยการเงนิ บันทึกสถานะการชำระเงินเปน็ ข้นั ตอนสุดทา้ ย

12 Register Course Student <<uses>> Checkout Course Registration Staff Record Billing Financial Staff รูปที่ 13 Use Case Diagram ของระบบลงทะเบียนเรยี น จาก Use Case Diagram ระบบลงทะเบียนท่ีสรา้ งเสรจ็ เรียบร้อยแล้ว ทำใหส้ ามารถทราบได้ว่าระบบ ลงทะเบยี นจะต้องมีหนา้ ท่หี ลักๆ อยู่ 3 หนา้ ที่ ไดแ้ ก่ ลงทะเบยี นเรียน ตรวจสอบรายวชิ า และบนั ทกึ การชำระ เงนิ คา่ ลงทะเบียน โดยผู้ทมี่ หี น้าทีล่ งทะเบยี นก็คือ “นกั ศกึ ษา” สว่ นผู้ทม่ี ีหน้าท่ีรบั ลงทะเบียนก็คือ “เจา้ หน้าท่ี ฝา่ ยทะเบียน” และผู้ท่มี ีหน้าท่บี ันทึกการชำระเงนิ คา่ ลงทะเบยี น ก็คือ “เจ้าหน้าทฝ่ี ่ายการเงิน” ซึง่ เป็นพนักงาน ของวิทยาลัยเชน่ เดียวกัน คำอธิบาย Use Case ระบบลงทะเบียนของนักศกึ ษา จากรายละเอยี ด “ระบบลงทะเบยี น” และ Use Case Diagram ทแี่ สดงในรูปท่ี 13 คำอธบิ ายของแต่ ละ Use Case มดี งั นี้

13 Use Case Title : Register Course Use Case Id : 1 Primary Actor : Registration Staff Stakeholder Actor : Student Main Flow : ระบบลงทะเบียนมีกลมุ่ บคุ คลทเ่ี กี่ยวขอ้ ง 2 กลมุ่ ไดแ้ ก่ นักศึกษา และเจา้ หน้าทฝี่ ่ายทะเบยี นและเจา้ หนา้ ท่ี ฝ่ายการเงิน ในแตล่ ะเทอมจะต้องมีนกั ศึกษามาลงทะเบยี นเรียนของภาคเรียนปกติ โดยนักศกึ ษาจะต้องกรอก แบบฟอร์มลงทะเบียนไมเ่ กนิ 8 วิชา แลว้ นำไปยน่ื กบั เจา้ หนา้ ทีฝ่ า่ ยทะเบยี นในวนั และเวลาทป่ี ระกาศไว้ เมอ่ื เจา้ หน้าที่รับแบบฟอร์มลงทะเบยี นมาแล้ว จะปอ้ นรหสั นกั ศึกษาเพอื่ ทำการตรวจสอบวชิ าทน่ี กั ศึกษาได้ลงไวใ้ น แบบฟอร์มกับประวตั กิ ารเรยี นว่าถกู ตอ้ งหรอื ไม่ เนอื่ งจาก บางวิชาของแต่ละเทอมมีเงื่อนไขว่าจะลงทะเบียนไดก้ ็ ต่อเม่ือสอบผ่านอกี วิชาหน่งึ มากอ่ น เม่อื ตรวจสอบพบว่าถูกตอ้ งแล้ว เจา้ หนา้ ทฝี่ า่ ยทะเบยี นจะคำนวณเงิน คา่ ลงทะเบียนเรยี น จากน้ันบันทึกลงในฐานขอ้ มลู ระบบแสดงขอ้ ความบนั ทกึ ข้อมูลเรยี บรอ้ ยแลว้ สงั่ พมิ พใ์ บรบั ลงทะเบียนโดยแบง่ ออกเป็น 2 สว่ น สว่ นท่ี 1 นกั ศึกษาเก็บไว้ ส่วนที่ 2 นำไปชำระเงินทหี่ ้องการเงนิ กบั เจ้าหนา้ ท่ี การเงนิ Exceptional Flow ที่ 1 : กรณที เี่ จา้ หน้าทฝ่ี ่ายทะเบยี นป้อนรหสั นักศึกษาผิดพลาด ระบบจะแสดงข้อความแจ้งเตอื น “ไมพ่ บข้อมูล นักศกึ ษา” เพอื่ ให้เจา้ หน้าท่ีทราบว่ามขี อ้ ผิดพลาดเกดิ ข้นึ และให้เจ้าหนา้ ทป่ี ้อนรหัสนกั ศึกษาใหมอ่ ีกครั้ง Exceptional Flow ที่ 2 : กรณที เ่ี จา้ หน้าที่ป้อนขอ้ มลู สำคญั ไมค่ รบถ้วน ระบบจะไม่สามารถบนั ทกึ รายการลงทะเบียนเรียนได้ ดงั น้ัน ระบบจะมีข้อความแจง้ เตอื น “ป้อนขอ้ มูลสำคญั ไมค่ รบถ้วน กรุณากลับไปป้อนข้อมลู ใหค้ รบ” ให้เจา้ หน้าที่ป้อน ข้อมูลสำคญั ใหค้ รบถ้วนระบบจงึ จะสามารถบันทกึ ข้อมลู ได้

14 Use Case Title : Checkout Course Use Case Id : 2 Primary Actor : Registration Staff Stakeholder Actor : - Main Flow : การตรวจสอบรายวิชา หลังจากเจ้าหน้าทีไ่ ด้รับแบบฟอรม์ ลงทะเบยี น และป้อนรหสั นักศกึ ษาไดอ้ ยา่ ง ถูกต้องแลว้ เจา้ หน้าทต่ี อ้ งปอ้ นรายวิชาทนี่ กั ศกึ ษาลงทะเบยี น จากน้ันระบบจะนำรหสั วิชาท่ีได้รบั มาตรวจสอบ รายวชิ าท่ีต้องผ่านมาก่อน โดยเม่อื ทราบรายวิชาที่ตอ้ งผ่านมากอ่ นของวชิ าที่นักศกึ ษาลงทะเบียนแล้ว ระบบจะ เปรียบเทียบกับรายวชิ าทน่ี ักศึกษาเคยเรยี นผ่านมาทง้ั หมด เม่ือระบบตรวจสอบพบว่ารายวิชาที่นกั ศึกษา ลงทะเบยี นน้นั ถกู ต้อง ระบบจึงทำการคำนวณเงินคา่ ลงทะเบียนเปน็ ลำดับตอ่ ไป Exceptional Flow ที่ 1 : กรณกี ารตรวจสอบรายวิชาท่ีลงทะเบยี นไมถ่ กู ตอ้ ง เจ้าหนา้ ท่ีแจ้งนักศกึ ษาวา่ มีบางรายวิชายังไม่สามารถ ลงทะเบยี นได้เนอ่ื งจากยงั ไม่ผา่ นบางรายวิชามาก่อน ให้นักศกึ ษากลบั ไปแกไ้ ขแลว้ นำใบลงทะเบยี นมาย่ืนที่ ฝ่ายทะเบียนอกี คร้งั ภายในระยะเวลาท่กี ำหนด Use Case Title : Record Billing Use Case Id : 3 Primary Actor : Financial Staff Stakeholder Actor : Student Main Flow : เจา้ หนา้ ทฝ่ี า่ ยการเงินรับสำเนาใบรบั ชำระเงินค่าลงทะเบียนจากนักศกึ ษา ปอ้ นรหัสนกั ศกึ ษาเพอ่ื ใหร้ ะบบ แสดงข้อมลู การลงทะเบยี น ตรวจสอบจำนวนเงินถูกต้องตรงกัน แลว้ ทำการบันทึกข้อมลู การชำระเงินและ สถานการณช์ ำระเงิน ระบบแสดงข้อความยืนยนั การบันทกึ ขอ้ มูลเรยี บรอ้ ยแลว้ Exceptional Flow ที่ 1 : กรณเี จา้ หนา้ ทป่ี อ้ นรหสั นกั ศกึ ษาผดิ พลาด ระบบจะแสดงขอ้ ความแจง้ เตอื น “ไมพ่ บขอ้ มลู นักศกึ ษา” เพอ่ื ให้เจ้าหนา้ ท่ที ราบว่ามีข้อผดิ พลาดเกิดขึน้ และให้เจ้าหนา้ ท่ปี ้อนรหสั นักศึกษาใหมอ่ กี ครั้ง Exceptional Flow ที่ 2 : กรณจี ำนวนเงินทีน่ ักศึกษาชำระไมต่ รงกับขอ้ มลู ที่แสดงบนหน้าจอคอมพวิ เตอร์ เจ้าหน้าทจี่ ะตอ้ งสอบถาม นกั ศกึ ษา และแจ้งวนั ทชี่ ำระเงนิ งวดต่อไปใหน้ กั ศกึ ษาทราบ จากน้ันเจ้าหน้าที่บันทึกขอ้ มูลการชำระเงนิ และ สถานะการชำระเงนิ ระบบแสดงข้อความยืนยันการบันทกึ ขอ้ มลู เรียบรอ้ ยแล้ว Exceptional Flow ที่ 3 : กรณที ่ีระบบไม่สามารถบันทึกข้อมลู ได้ เนื่องจาก เจา้ หนา้ ทีฝ่ ่ายการเงินปอ้ นขอ้ มูลการชำระเงนิ ไม่ ครบถว้ น ให้เจา้ หนา้ ทป่ี ้อนข้อมูลสำคญั ใหค้ รบถว้ น แลว้ บันทึกข้อมูลอกี ครัง้ .