UsecaseDigram

รายงาน เรอ่ื ง Use Case Diagram จดั ทำโดย นายชนาวีร์ เพช็ รนารถ เลขที่ 1 ปวส 1.1 นายฐติ ิวฒุ ิ โมจนยรรยง เลขที่ 2 ปวส 1.1 นางสาวปรษิ ฐา สอนผง้ึ เลขที่ 5 ปวส 1.1 เสนอ อาจารยพ์ วงมาลัย จนั ทรเสนา รายงานฉบบั นเี้ ป็นสว่ นหนึง่ ของการเรยี นวิชาการวเิ คราะห์และออกแบบเชิงวตั ถุ รหัสวิชา 30901-2002 ภาคเรยี นท่ี 2 ปีการศกึ ษาท่ี 2563 ระดบั ช้นั ประกาศนียบตั รวชิ าชพี ชั้นสงู (ปวส.) สาขาเทคโนโลยสี ารสนเทศ วิทยาลัยอาชีวศกึ ษาพษิ ณุโลก

ก คำนำ รายงานฉบับนี้เป็นส่วนหนึ่งของการเรียนวิชาการวิเคราะห์และออกแบบเชิงวัตถุ รหัส 30901-2002 ระดับชั้นประกาศนียบัตรวิชาชีพชั้นสูง (ปวส.) สาขาเทคโนโลยี สารสนเทศ โดยมีจุดประสงค์เพื่อรวบรวมข้อมูล ความหมายของ Use Case Diagram สัญลักษณและความสมั พันธ การสรา้ ง ประโยชน์ และตัวอย่าง ในการจดั ทำรายงานฉบับน้ีผู้จดั ทำตอ้ งขอขอบคณุ อาจารยพ์ วงมาลัย จนั ทรเสนา ที่ให้ข้อมูลตลอดจนความรู้ทั้งหมด ได้มารวบรวมเป็นรูปเล่มรายงานนี้ หวังว่าความรู้ ตา่ งๆ ทอี่ ยใู่ นรายงานฉบบั นี้ จะเป็นประโยชนต์ ่อผู้ได้อา่ น และผูท้ ีเ่ รยี นวิชาวเิ คราะห์และ ออกแบบเชงิ วตั ถตุ อ่ ไป นายชนาวีร์ เพช็ รนารถ นายฐิติวุฒิ โมจนยรรยง นางสาวปริษฐา สอนผง้ึ ปวส.1.1 แผนกเทคโนโลยสี ารสนเทศ

สารบญั ข เรือ่ ง หน้า คานา ก สารบญั ข Use Case Diagram 1 1.สัญลักษณความสัมพนั ธ 2 2.การสราง Use Case Diagram 8 3.ขอแนะนาในการสราง Use Case Diagram 9 4.การเขยี นคาอธบิ าย Use Case 11 5.ตัวอยาง Use Case Diagram ของระบบลงทะเบยี น 12 บรรณนานกุ รม ค

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)” ให้แสดงไว้ ด้านบนสดุ ของแผนภาพ ตวั อยา่ งดังรปู ที่ 1 รปู ที่ 1 แสดง Use Case Diagram ของระบบลงทะเบียน นอกจากนี้ หากกลา่ วถึง Use Case Diagram ในดา้ นการพัฒนาระบบ นอกเหนือจากการนามา ใช้เก็บรวบรวมความต้องการต่างๆ แล้ว Use Case Diagram ยงั ถกู นาไปใชเ้ ปน็ พ้ืนฐานเพอื่ การสร้างแผนภาพ (Diagram) ชนิดอน่ื ในขัน้ ตอนต่อๆ ไป และทีมงานยังสามารถใช้ Use Case Diagram เพ่อื ติดตามผลการดา เนนิ งานได้อกี ดว้ ย

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

3 Connection คือ เสน้ ท่ีลากเชื่อมต่อระหว่าง Actor กบั Use Case ทมี่ ปี ฏสิ ัมพันธ์กัน ใชเ้ ส้นตรงไม่มีหวั ลกู ศร เปน็ สญั ลักษณ์ของ Connection สว่ น Connection ทีใ่ ช้เชอ่ื มต่อระหว่าง Use Case กับ Use Case กรณีที่ Use Case นน้ั มีความสัมพนั ธซ์ ึ่งกันและกัน จะใช้สญั ลกั ษณ์เส้นตรงมหี ัวลูกศร พร้อมท้ังเขยี นช่อื ความสมั พนั ธ์ ไวต้ รงกลางเส้นด้วย โดยเขยี นไว้ภายในเครื่องหมาย <<...>> ดังรูปที่ 5 รูปที่ 5 แสดงสัญลักษณ์ Connection Extend Relationship เปน็ ความสมั พันธ์แบบขยายหรือเพ่ิม เกดิ ขึน้ ในกรณีท่ีบาง Use Case ดาเนินกิจกรรม ของตนเองไปตามปกติ แต่อาจจะมีเง่ือนไขหรอื สงิ่ กระตุ้นบางอย่างท่ีสง่ ผลใหก้ จิ กรรมตามปกติของ Use Case นัน้ ถกู รบกวนจนเบย่ี งเบนไป ซึ่งเราสามารถแสดงเงื่อนไขหรือสิง่ กระตุ้นเหลา่ นน้ั ได้ในรูปของ “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 ดังรูปที่ 6 รปู ที่ 6 แสดงการวาดเสน้ Connection เช่อื มระหวา่ ง Extending Use Case กบั Base Use Case

4 แสดงตวั อย่าง Extend Relationship ของระบบลงทะเบียนได้ดังรูปท่ี 7 รปู ที่ 7 แสดง Use Case Diagram ทม่ี ีความสัมพันธแ์ บบ Extend Relationship จากรปู ที่ 7 สังเกตท่ี Use Case “Register Course” ซง่ึ เป็น Base Use Case คือ ทาหนา้ ท่รี บั ลงทะเบยี น ตามปกติ แต่เมือ่ มีเงื่อนไขหรือมเี หตุการณ์พิเศษเกิดขนึ้ คือ “นกั ศึกษาบางคนอาจมกี ารลงทะเบียนเรียนซา้ เพื่อ ปรบั เกรดด้วย (Regrade)” จึงได้เพม่ิ Extending Use Case เพอ่ื มารองรับหนา้ ท่ีพิเศษดังกลา่ ว น่นั คือ “Register Regrade” 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>>) ไว้ตรงกลางเส้นด้วย ดงั รูปที่ 8

5 รูปที่ 8 แสดงการลากเสน้ Connection ระหวา่ ง Base Use Case กับ Included Use Case ความสมั พนั ธ์ระหวา่ ง Use Case แบบ Include เป็นการสนบั สนนุ หลักการนากลับมาใช้ใหม่ของ Use Case (Use Case Reusability) กลา่ วคือ Use Case หนึ่งสามารถถูก Include ไดโ้ ดย Base UseCase หลายๆ ตวั และสามารถถูก 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 อีก คร้ังดงั รปู ท่ี 9 รปู ที่ 9 แสดง Use Case Diagram ท่ีมี Included Relationship

6 หมายเหตุ 1. ในบางตาราจะเรยี กความสัมพนั ธแ์ บบ Include ได้อีกอย่างหนงึ่ ว่า “Use Relationship” 2. ความแตกตา่ งระหวา่ งความสมั พนั ธ์แบบ Extend กับ Include คอื Extend จะเปน็ Use Case ท่ถี ูกเรียกใชเ้ ฉพาะบางกรณีเท่าน้นั แต่ Include จะถูกเรียกใชท้ กุ คร้ังที่ Base Use Case มกี ารดาเนิน กิจกรรม • Generalization/Specialization Relationship Generalization หรอื Specialization ทเ่ี กดิ ข้ึนระหวา่ ง Use Case มคี ณุ สมบัตแิ ตกตา่ งจาก Generalization/ Specialization ทเี่ กดิ ข้ึนระหวา่ งคลาสคอื ความสมั พันธ์ลกั ษณะดังกล่าวที่เกดิ ขน้ึ ใน Use Case นีจ้ ะไม่มีการถา่ ยทอดคุณลักษณะ (ไม่มีการ Inherit) แตจ่ ะใช้เพอ่ื แสดงความสัมพันธแ์ บบจาแนก แยกแยะประเภทของ Use Case เทา่ นั้น อย่างไรก็ตาม Use Case ท่เี ปน็ Use Case หลกั ในการจาแนก ประเภทจะเรียกว่า “Parent Use Case” สว่ น Use Case ท่ีถกู จำแนกแยกแยะออกมา จะเรยี กว่า “Child Use Case” สว่ นสัญลักษณ์เชอ่ื มความสมั พนั ธ์ ให้ใชเ้ สน้ ตรงลูกศรโปรง่ ลากจาก Child Use Case ให้ลกู ศรชี้ ไปท่ี Parent Use Case ดังรปู ที่ 10 รปู ท่ี 10 แสดงความสัมพนั ธ์ระหว่าง Use Case แบบ Generalization / Specialization ตามทีก่ ลา่ วไปแล้ววา่ เราจะใช้ Generalization / Specialization ในกรณีท่ีตอ้ งการแสดง ความสัมพนั ธใ์ นเชิงการจาแนกแยกแยะประเภทของ Use Case เชน่ การตรวจสอบความถกู ต้องของผ้ใู ช้งาน ระบบ (Validate user) สามารถกระทาไดห้ ลายวธิ ี ได้แก่ การตรวจสอบจากรหสั ผ่าน (Verify Password) และการตรวจจากลายนวิ้ มือ (Fingerprint Recognition) เป็นต้น แสดงความสัมพันธ์ได้ดงั รูปที่ 11 รูปที่ 11 แสดงความสัมพนั ธ์ระหวา่ ง Use Case แบบ Generalization / Specialization

7 นอกจากเราจะใชค้ วามสัมพันธ์แบบ Generalization / Specialization กบั Use Case แลว้ เรายังสามารถใช้ความสัมพันธ์ลักษณะนีก้ บั Actor ได้เช่นเดียวกัน ตัวอย่างเช่น เราสามารถใช้ UML อธิบาย ข้อเท็จจรงิ “คนคุมงาน (Worker Supervisor) จดั เป็นคนงานประเภทพเิ ศษท่ีมีหนา้ ที่พิเศษกว่าคนงาน (Worker) ท่วั ไป” ได้ดังรปู ท่ี 12 รปู ท่ี 12 แสดงความสัมพันธ์แบบ Generalization / Specialization ระหวา่ ง Actor

8 2.การสรา้ ง 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 จนครบถว้ น

9 3.ขอ้ แนะนำในการสรา้ ง 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 ก็คือ หน้าท่หี ลกั ๆ หรือหน้าท่ที เี่ ป็น จดุ เดน่ ของระบบทผี่ ู้ใชง้ านต้องการใหร้ ะบบกระทาได้อย่างแทจ้ ริงเทา่ น้นั (เปน็ การสนบั สนุนขอ้ ความทีว่ า่ “หน้าทใ่ี นการเพิ่ม ลบ แก้ไข หรือปรับปรุงข้อมูลน้ันเปน็ หน้าที่พน้ื ฐานท่ีทุกระบบต้องมีอยแู่ ล้ว”)

10 6. จากขอ้ 4 คำว่า “หนา้ ทห่ี ลกั หรือหน้าที่ท่เี ปน็ จุดเด่นของระบบ” ในทนี่ ้ีหมายถึง หนา้ ที่ที่ระบบ จะตอ้ งกระทำ (System Operate) ตามความตอ้ งการของผู้ใช้ ไม่ใช่หน้าทีท่ ีผ่ ใู้ ช้จะต้องกระทำ (Human Operate) อนั เนื่องจากการทำงานของระบบ

11 4.การเขยี นคำอธบิ าย 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 ดว้ ย

12 5.ตัวอย่าง Use Case Diagram ของระบบลงทะเบียน ระบบลงทะเบยี นมีกลุ่มบคุ คลท่เี กยี่ วขอ้ ง 2 กลมุ่ ไดแ้ ก่ นักศกึ ษา และพนักงานของมหาวทิ ยาลยั (เจา้ หน้าทีฝ่ า่ ยทะเบยี นและเจ้าหน้าท่ีฝ่ายการเงิน) ในแตล่ ะเทอมจะต้องมนี ักศึกษามาลงทะเบียนเรียนของ ภาคเรยี นปกติ โดยนกั ศึกษาจะต้องกรอกแบบฟอรม์ ลงทะเบียนให้เรียบรอ้ ยแล้วนาไปยื่นกบั เจ้าหนา้ ที่ฝา่ ย ทะเบยี นในวนั และเวลาที่ประกาศไว้ เม่อื เจ้าหน้าที่รบั แบบฟอรม์ ลงทะเบยี นมาแล้ว จะทาการตรวจสอบวิชาที่ นกั ศึกษาไดล้ งไว้ในแบบฟอร์มกับประวตั ิการเรยี นวา่ ถูกตอ้ งหรอื ไม่ เน่อื งจาก บางวิชาของแตล่ ะเทอมมีเงอ่ื นไข ว่าจะลงทะเบยี นได้กต็ ่อเมือ่ สอบผา่ นอีกวิชาหนึ่งมาก่อน เม่ือตรวจสอบพบว่าถกู ต้องแล้ว เจ้าหนา้ ท่ีฝา่ ย ทะเบยี นจะคำนวณเงินคา่ ลงทะเบยี นเรยี น แล้วบนั ทกึ ลงในฐานขอ้ มลู ส่ังพิมพ์ใบรบั ลงทะเบียนโดยแบ่ง ออกเปน็ 2 สว่ น ส่วนท่ี 1 นกั ศกึ ษาเก็บไว้เอง สว่ นท่ี 2 นำไปชาระเงนิ โดยโอนผ่านทางธนาคาร แล้วนำใบรับ ชำระเงินกลับมาให้เจา้ หน้าที่ฝา่ ยการเงนิ บนั ทึกสถานะการชำระเงนิ เป็นขน้ั ตอนสุดทา้ ย รปู ท่ี 13 แสดง Use Case Diagram ของระบบลงทะเบยี นเรียน จากรูปที่ 13 เป็น 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 : กรณที เี่ จ้าหน้าท่ปี อ้ นข้อมลู สาคญั ไม่ครบถว้ น ระบบจะไม่สามารถบนั ทึกรายการลงทะเบยี นเรียนได้ ดังนั้น ระบบจะมขี ้อความแจ้งเตือน “ป้อนข้อมลู สาคญั ไมค่ รบถ้วน กรุณากลบั ไปปอ้ นขอ้ มูลให้ครบ” ให้เจ้าหนา้ ท่ี ป้อนข้อมูลสาคญั ใหค้ รบถ้วนระบบจงึ จะสามารถบันทกึ ข้อมูลได้ Use Case Title : Checkout Course Use Case Id : 2 Primary Actor : Registration Staff Stakeholder Actor : - Main Flow : การตรวจสอบรายวชิ า หลังจากเจา้ หนา้ ที่ได้รบั แบบฟอร์มลงทะเบยี น และปอ้ นรหัสนักศึกษาได้อยา่ งถูกต้อง แล้ว เจ้าหน้าท่ตี ้องป้อนรายวชิ าทนี่ ักศกึ ษาลงทะเบียน จากนั้นระบบจะนารหัสวิชาทไ่ี ด้รับมาตรวจสอบ รายวชิ าทต่ี ้องผ่านมากอ่ น โดยเม่อื ทราบรายวิชาทีต่ ้องผ่านมาก่อนของวิชาทีน่ กั ศึกษาลงทะเบียนแล้ว ระบบ

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

ค บรรณนานกุ รม 1.https://sites.google.com/site/itentertainer/use-case-diagram/saylaksn- khwam-samphanth 2.https://sites.google.com/site/itinfinityprj/project 3. https://www.glurgeek.com/education/use-case-diagram-2/