รายงาน Use case diagram

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

สารบญั ข เรือ่ ง หน้า คานา ก สารบญั ข 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 บรรณนานกุ รม ค

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

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/