Use Case Diagram

นำเสนอ อาจารย์ สุรีพร เมอื งมุงคณุ นาย ธรณเ์ ทพ ฤกษส์ ะเสน ปวส.1/6 เลขที่ 13 นาย ราชนั ย์ ปานนิยม ปวส.1/6 เลขที่ 16 นาย ณัฎฐากร ชญั ถาวร ปวส.1/6 เลขท่ี 17

คำนำ รายงานหนังสือ 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 : กรณที ี่ระบบไม่สามารถบนั ทกึ ข้อมลู ได้ เนื่องจาก เจา้ หน้าทฝี่ ่ายการเงินป้อนขอ้ มลู การชำระเงนิ ไม่ ครบถ้วน ให้เจา้ หนา้ ทีป่ ้อนข้อมลู สำคญั ใหค้ รบถ้วน แล้วบนั ทึกขอ้ มูลอกี ครัง้