หนังสือ Use case Diagram

USE CASE DIAGRAM

OVERVIEW ▪ ส่วนประกอบของ use case diagram ▪ Use case กบั Scenario ▪ ตวั อยา่ งการเขียน use case diagram ▪ ขอ้ ควรระวงั ในการเขยี น use case diagram ▪ Use case description 2

การวิเคราะหค์ วามตอ้ งการของระบบ โดยใช้ Use case Diagram ▪ มีวตั ถุประสงคเ์ พื่ออธิบายเรื่องราวของ Problem Domain ท้งั หมด ▪ บอกความสมั พนั ธข์ องส่วนต่าง ๆ ในระบบ ▪ เป็ นการเริ่มตน้ การวเิ คราะหร์ ะบบงานวา่ สามารถทาอะไรใหก้ บั ผูใ้ ชไ้ ดบ้ า้ ง ▪ ชว่ ยใหผ้ พู้ ฒั นาระบบสามารถแยกแยะกิจกรรมที่อาจเกิดข้ ึนในระบบ ▪ แต่ละสถานการณท์ ่ีระบบสามารถบริการใหผ้ ูใ้ ชส้ าเร็จลุลว่ งตามที่ตอ้ งการได้ เรียกวา่ Use case ▪ แต่ละ Use case จะแสดงสถานการณ(์ Scenario) ที่สามารถบรรยายไดว้ า่ ผใู้ ช้ (Actor) โตต้ อบกบั ระบบอยา่ งไร 3

Use Case Diagram ▪ Use Case  ความสามารถ/หนา้ ที่ของระบบ  ใน 1 Use Case Diagram มกั มีหลาย Use Case ▪ Actor  ผูก้ ระทา/ผูใ้ ชง้ าน Use Case น้ันๆ  Actor ไมจ่ าเป็ นตอ้ งเป็ นคนเสมอไป อาจจะเป็ นส่ิงอื่นหรือระบบอ่ืนๆ ก็ได้ เช่น ระบบบญั ชี ระบบโทรศพั ท์ เป็ นตน้ 4

Use Case Diagram ▪ Relationship  เสน้ แสดงความสมั พนั ธร์ ะหวา่ ง Use Case กบั Actor ▪ System  ระบบท่ีกาลงั พฒั นา 5

Use Case Modeling : Core Elements Construct Description Syntax use case A sequence of actions, including UseCaseName actor variants, that a system (or other ActorName entity) can perform, interacting with actors of the system. A coherent set of roles that users of use cases play when interacting with these use cases. system Represents the boundary between boundary the physical system and the actors who interact with the physical system. 6

Use Case Modeling : Core Relationships Construct Description Syntax association The participation of an actor in a use generalization case. i.e., instance of an actor and extend instances of a use case communicate with each other. A taxonomic relationship between a <<extend>> more general use case and a more specific use case. A relationship from an extension use case to a base use case, specifying how the behavior for the extension use case can be inserted into the behavior defined for the base use case. 7

Use Case Modeling : Core Relationships Construct Description Syntax include An relationship from a base use case to an inclusion use case, specifying how the behavior for the inclusion use <<include>> case is inserted into the behavior defined for the base use case. 8

Use Cases V.S. Scenario ▪ Use Case (Class)  ความสามารถ หรือ หน้าที่การทางานของระบบ  แต่ละ Use Case แทนชุดของ transactions ที่ระบบทางานโตต้ อบกบั ผูใ้ ชง้ าน หรอื ระบบอื่นๆ ภายนอก ▪ Scenario (Object)  สถานการณ์ หรอื ตวั อยา่ งเรือ่ งราวการใชง้ านระบบ  Scenario จดั เป็ น instance ของ use case  เชน่ a user withdrawals $200 withdrawal cash 9

Use Cases V.S. Scenario ▪Use Case จะอธิบายทุกกรณีที่เกดิ ข้ ึนไดท้ ้งั หมด ▪Scenario จะแสดงถึงเหตุการณจ์ ริงที่เกดิ ข้ นึ ภายใตเ้ งือ่ นไขต่าง ๆ ของ Use Case ซึ่งอาจจะไม่ไดเ้ กิดทุกกรณีที่ระบุไวใ้ น Use Case กไ็ ด้ ▪จุดประสงคข์ องการเขียน Use Case Diagram เพ่อื เล่าเร่ืองราวของ Problem Domain ท้งั หมดวา่ มสี ว่ นประกอบอะไรบา้ ง และเกี่ยวขอ้ งกนั เป็ นระบบไดอ้ ยา่ งไร 10

ตัวอย่าง Use Case ▪ผใู้ ชง้ านสอดบตั ร ATM เขา้ ส่เู ครือ่ งรบั บตั ร หากบตั รใชง้ านไดจ้ ึงเขา้ สู่ หน้าจอ Main Menu หากใชง้ านไม่ไดบ้ ตั ร ATM จะถูกปล่อยคืน (Reject) ออกมา หากบตั รใชไ้ ด้ ผใู้ ชง้ านตอ้ งระบุประเภทบญั ชีและจานวน เงนิ ที่ตอ้ งการถอน หากมเี งนิ ในบญั ชีมากกวา่ หรอื เท่ากบั จานวนท่ีระบุ ผใู้ ชง้ านสามารถนาเงนิ ออกจากเคร่ือง ATM ได้ 11

ตวั อย่าง Scenario Scenario ที่ 1 ▪นายสมชายสอดบตั ร ATM ของ ธ.กรุงเทพ สาขาหาดใหญ่ แต่บตั รเสีย บตั รจึงถูก reject ออกมา 12

ตวั อย่าง Scenario Scenario ท่ี 2 ▪นางสมใจสอดบตั ร ATM ของ ธ.ทหารไทย สาขาบางเขน บตั รสามารถใช้ การได้ แต่เงนิ ในบญั ชีไมพ่ อจา่ ย จึงไมส่ ามารถนาเงนิ ไปใชไ้ ด้ 13

ตัวอย่าง Scenario Scenario ท่ี 3 ▪นายสมบตั ิสอดบตั ร ATM ของ ธ.ทหารไทย สาขาบางเขน บตั รสามารถ ใชก้ ารได้ และมเี งินในบญั ชีเพยี งพอ เขาตอ้ งการถอน 100 บาท และใน บญั ชีมเี งนิ จานวน 250 บาท ดงั น้ันนายสมบตั ิจึงสามารถนาเงินออกจาก เคร่อื ง ATM ไปใชไ้ ด้ 14

Actors ▪ Actor หมายถึง someone หรือ some thing ที่มีการปฏิสมั พนั ธ์ โตต้ อบกบั ระบบ  สิ่งใดกต็ ามท่ีมีความตอ้ งการในการแลกเปลี่ยน information กบั ระบบ หรือ สิ่งใดก็ตามท่ีอยภู่ ายนอก ระบบ และมีการใชง้ าน Use Case ของระบบ ▪ ตวั อยา่ งของ Actors  Customer -- maintain their account  Cashier -- verify withdrawal amount Customer Cashier 15

Actors ▪ Actors สามารถอธิบายโดยใช้ Generalization/Specialization Relationship Customer Generalization relationship ATM Customer Cashier Customer ▪ อาจพิจารณา Actors เป็ นคลาส ใน UML เน่ืองจากมี relationships เชน่ เดียวกบั ที่ คลาสมี 16

Actors ▪ เชื่อมต่อกบั use cases โดยใชเ้ สน้ แสดงความเกย่ี วขอ้ ง ปฏสิ มั พนั ธ์ (association) ▪ Association = ความสมั พนั ธท์ ่ีมีการติดต่อสื่อสารกนั (ท้งั การรบั และส่ง messages ใหแ้ ก่กนั และกนั ) Customer withdrawal cash ▪ ไมจ่ าเป็ นตอ้ งอธิบายรายละเอียดของ Association เนื่องจากไมม่ ีการ Implement ส่วน ของ Actor ในระบบ 17

System ▪ วตั ถุประสงคใ์ น use-case modeling คือ เพอ่ื ระบุขอบเขตของ ระบบที่กาลงั พฒั นา (system boundary) วา่ จะตอ้ งประกอบดว้ ย Use case อะไรบา้ ง ▪ ใชส้ ญั ลกั ษณเ์ ป็ นรปู สี่เหล่ียมท่ีลอ้ มรอบ Use case ไว้ System 18

ความสัมพนั ธ์ของ Use Case ▪ Extend  Use Case หนึ่งไปมีผลต่อการทางานตามปกติของอีก Use Case หน่ึง  Use Case ท่ี Extend จากอกี Use case หน่ึง จะเป็ น Use case ท่ี เกิดข้ ึนในกรณีเดียวกนั แต่เป็ นกรณีท่ีพิเศษมากกวา่  Use Case ท่ีมา Extend น้ันจะมีผลทาใหก้ ารดาเนินการของ Use Case ที่ถูก Extend ถูกรบกวนหรือมกี ารสะดุด หรือมกี ารเปล่ียนกิจกรรมไป 19

ตย. Use Case Diagram ท่ีมี Extend ▪Use case diagram ที่แสดงการรบั โทรศพั ท์ ซ่งึ ขณะท่ีรบั โทรศพั ท์ ปกติ หากมีสายเรยี กซอ้ นเขา้ มา อาจทาใหต้ อ้ งมีการรบั สายเรียกซอ้ นก่อน ซ่ึงทาใหก้ ารรบั สายโทรศพั ทต์ ามปกติตอ้ งชะงกั ชวั่ คราว 20

ข้นั ตอนที่ 1 : หา Use Case และ Actor ของระบบ ▪ Use case ของระบบคือ การรบั โทรศพั ท์ การรบั สายเรียกซอ้ น ▪ actor ของระบบคือ ผรู้ บั โทรศพั ท์ 21

ข้นั ตอนที่ 2 : เขียน Scenario ของระบบ ▪scenario ที่ 1 : เกดิ สายเรียกซอ้ น เม่อื เกิดสายเรียกซอ้ น ทาให้ use case การรบั โทรศพั ท์ เกิดการชะงกั งนั ซึ่งผูร้ บั อาจหยุดการสนทนาชวั่ ขณะ หรือผูร้ บั เปลี่ยนไปรบั สายท่ีเรียกซอ้ นแทน ▪scenario ท่ี 2 : ไมเ่ กดิ สายเรยี กซอ้ น 22

ข้นั ตอนท่ี 3 : เขียน Use Case Diagram รับโทรศพั ท์ <<extend>> รับสายเรียกซอ้ น ผรู้ ับโทรศพั ท์ การรับโทรศพั ท์ 23

ความสมั พนั ธ์ของ Use Case (ต่อ) ▪ Include/Use ▪ Use case ที่ถูก includes จะถูกรวมการทางานเขา้ ไวก้ บั Use case ท่ีเป็ นตวั หลกั ดว้ ยเสมอ ▪ คลา้ ยกบั การเรียกใชง้ านโปรแกรมยอ่ ยโดยโปรแกรมหลกั 24

ตย. Use Case Diagram ท่ีมี Include/Use ▪use case diagram เพอื่ อธิบายการตรวจสอบ user ท่ีเขา้ มาในระบบคอมพวิ เตอรข์ ององคก์ รต่าง ๆ ตอ้ งมีการตรวจสอบ รหสั ผ่านรวมอยดู่ ว้ ย โดย actor ของระบบน้ ีคือผูจ้ ดั การระบบ 25

ข้นั ตอนที่ 1 : หา Use Case และ Actor ของระบบ ▪Use Case ของระบบคือ การตรวจสอบ User (Validate User) การตรวจสอบรหสั ผ่าน (Check Password) ▪Actor ของระบบคือ ผจู้ ดั การระบบ (System Administrator) 26

ข้นั ตอนท่ี 2 : เขียน Scenario ของระบบ ▪scenario ท่ี 1 : user ป้อน password ที่ถูกตอ้ ง การตรวจสอบ password ใน use case ชอ่ื check password ตรวจสอบไดถ้ ูกตอ้ ง ทาใหก้ ิจกรรมใน validate user ดาเนินต่อไปได้ 27

ข้นั ตอนท่ี 2 : เขียน Scenario ของระบบ ▪scenario ที่ 2 : user ป้อน password ท่ีไมถ่ ูกตอ้ ง ทาให้ use case ช่ือ check password ถูกเรยี กใชอ้ ีกหลายคร้งั จนกวา่ จะถูก หรอื จนกวา่ จะครบ 3 คร้งั จึงตดั user คนน้ันออกจาก ระบบ 28

ข้นั ตอนที่ 3 : เขียน Use Case Diagram Validate Users <<include>> Check Password System User Authorization Administrator 29

ความสัมพนั ธข์ อง Use Case (ต่อ) Validate client ▪ Generalization Check Finger  Child Use case รบั ถ่ายทอดคุณสมบตั ิมาจาก Parent password scan Use Case  Child สามารถเปล่ียนแปลงพฤติกรรมท่ีรบั จาก Parent หรือเพมิ่ เติมพฤติกรรม  Child อาจนาไปแทนที่ ในที่ๆ Parent ปรากฏ 30

ตวั อย่าง การเขียน Use Case Diagram ▪จงสรา้ ง use case diagram เพื่ออธิบายการลงทะเบียนของนักเรียน ซึ่งเกดิ จากผลของการวเิ คราะหค์ วามตอ้ งการเบ้ ืองตน้ สามารถเขียนเป็ น รายการไดด้ งั น้ ี 31

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

ความตอ้ งการ... ▪สาหรบั นักศึกษาบางคนที่ไดร้ บั สิทธิพิเศษเช่น ไดร้ บั ทุนเรยี นฟรี เป็ นนักกีฬาของสถาบนั หรือเป็ นผทู้ าชื่อเสียงใหส้ ถาบนั จะมสี ิทธิไดร้ บั ยกเวน้ ค่าเล่าเรียนในบางภาคการศึกษา 33

หา Use Case ของระบบ ▪use case ของระบบคือ การลงทะเบียนเรยี น การเก็บหลกั ฐาน การชาระคา่ เล่าเรียน 34

หา Use Case อ่ืนที่เก่ียวขอ้ ง ▪หา use case อื่นท่ีเกี่ยวขอ้ งคือ การเก็บหลกั ฐาน  หลกั ฐานไมพ่ รอ้ ม  การชาระค่าเล่าเรียน  มีเงินไม่พอชาระค่าเล่าเรียน  ไดร้ บั การยกเวน้ ค่าเล่าเรียน 35

หา Actor ของระบบ ▪Actor ของระบบคือ เจา้ หนา้ ที่ นักศึกษา 36

เขียน Use Case Diagram การลงทะเบียนเรียนของนักเรียน มีเงนิ ไม่พอชาระ ได้รับยกเว้นค่า ค่าเล่าเรียน เล่าเรียน <<extend>> <<extend>> ลงทะเบยี นเรียน <<include>> ชาระเงนิ ค่า ลงทะเบยี นเรยี น นักศกึ ษา <<include>> เจา้ หน้าที่ เกบ็ หลักฐาน <<extend>> หลักฐานไม่พร้อม 37

Use Case Diagram ทาเมื่อไรและทาอย่างไร ▪ Requirements capture  ใชใ้ นการกาหนด Requirement ของระบบ  สรา้ งแบบจาลอง (Model) ของ User requirements ดว้ ย Use Case ▪ Test Scenarios  สรา้ งแบบจาลอง (Model) ของสถานการณก์ ารทดสอบระบบ (test scenarios) ดว้ ย Use Case ▪ Use Case: ระบุสิ่งที่ตอ้ งการใหม้ ีในระบบ  ต้งั ช่ือให้ Use Case  เขยี นคาอธิบายส้นั ๆ  เพิ่มรายละเอียดในภายหลงั 38

สรุปการสรา้ ง Use Case Diagram ▪ ระบุ actors ท่ีมปี ฏิสมั พนั ธก์ บั ระบบ ▪ พิจารณาแนวทางของระบบ ในการปฏิสมั พนั ธก์ บั actors ▪ จาแนกพฤติกรรมของระบบใน การปฏสิ มั พนั ธก์ บั actors ให้ เป็ น use cases โดยกาหนดความสมั พนั ธร์ ะหวา่ ง Use Case 39

ขอ้ ควรระวงั ในการเขียน Use Case Diagram ▪Use Case ใชเ้ ป็ นเครื่องมือส่ือสารกบั ผใู้ ช้ ดงั น้ันตอ้ งใหง้ ่ายท่ีสุดเท่าท่ีจะ ทาได้ ▪ไมค่ วรใช้ <<include>>,<<extend>> และ inheritance โดยที่ไมจ่ าเป็ น ▪จานวน Use Case ไมค่ วรเกิน 20 Use Case โดยนับจาก Use Case ที่ไมม่ คี วามสมั พนั ธ์ 40

Use case Description ▪เน่ืองจากรายละเอียดที่ปรากฏใน Use case Diagram เป็ น เพยี งภาพรวมของระบบ แต่ยงั ไมม่ คี าอธิบายการทางานของแต่ละ Use case ▪การเขยี น Requirement Specification ใหส้ มบรู ณจ์ ะ เพม่ิ เติมส่วนท่ีเป็ น Use case Description เขา้ ไปเพือ่ ใหท้ ีม พฒั นาเขา้ ใจ Use case ไดด้ ียง่ิ ข้ ึน ▪Use case Description ไมไ่ ดเ้ ป็ นมาตรฐานของ UML 41

Use case Description ▪ ชื่อของ Use Case ▪ ภาพรวมของการทางาน (Overview) ▪ Actor หลกั (Primary Actor) ▪ Actor รอง (Secondary Actor) ▪ จุดเริ่มตน้ (Starting Point) ▪ จุดส้ ินสุด (End point) ▪ การทางานของ Use Case (Flow of Events) ▪ การทางานของ Use Case เมื่อมีปัญหาเกิดข้ ึน (Alternative flow of Events) ▪ ผลของการทางานของ Use Case (Measurable Result) 42

Use Case : Create Order ▪ ภาพรวมของการทางาน (Overview)  จุดประสงคห์ ลกั ของ Use Case น้ ี เพอื่ ทาการลงขอ้ มลู ในใบสงั่ ซ้ ือสินคา้ จากลูกคา้ ▪ Actor หลกั (Primary Actor)  ตวั แทนฝ่ ายขายสินคา้ ▪ Actor รอง (Secondary Actor)  ไมม่ ี ▪ จุดเร่ิมตน้ (Starting Point)  Use Case ตวั น้ ีเริม่ ตน้ เม่อื Actor ตวั แทนฝ่ ายขายสินคา้ ขอใหร้ ะบบทาการลงขอ้ มลู การสัง่ ซ้ ือสินคา้ ▪ จุดส้ ินสุด (End point)  คาขอเพอื่ ทาการลงขอ้ มูลการสงั่ ซ้ ือสินคา้ เสรจ็ ส้ ินสมบรู ณห์ รือไมก่ ถ็ ูกยกเลิก 43

Use Case : Create Order ▪ การทางานของ Use Case (Flow of Events)  จาก User Interface บนจอเพือ่ ทาการลงขอ้ มลู การสงั่ ซ้ ือ Actor จะตอ้ งทาการใส่ ขอ้ มูลเก่ียวกบั การสงั่ ซ้ ือ เป็ นตน้ วา่ วนั ที่ลกู คา้ ตอ้ งการใหส้ ินคา้ สง่ มอบถึงมือ (Required Date) ปริมาณท่ีตอ้ งการสงั่ ซ้ ือ (Quantity) ตอ้ งการใหส้ ่งมอบสินคา้ โดยบริษัทส่งสินคา้ ไหน (ShipVia) ตอ้ งการใหใ้ หส้ ง่ มอบสินคา้ ที่ไหน (ShipAddress) หลงั จากน้ันแลว้ Actor สามารถเลือกท่ีจะทาการบนั ทึกขอ้ มลู ลงไปไวใ้ นฐานขอ้ มูล หรือยกเลิกการทางาน ท้งั หมด ถา้ Actor เลือกทาการบนั ทึก ใบสงั่ ซ้ ือใบใหม่ก็จะถูกสรา้ งข้ ึนมาในฐานขอ้ มูล 44

Use Case : Create Order ▪ การทางานของ Use Case เม่อื มีปัญหาเกดิ ข้ นึ (Alternative Flow of Events)  ถา้ ไมม่ สี ินคา้ ที่ตอ้ งการอยใู่ นคลงั สินคา้ ระบบจะตอ้ งแจง้ ให้ Actor ทราบพรอ้ ม กนั น้ันก็ตอ้ งยกเลิกการทางานที่เหลือของ Use Case น้ ี ▪ ผลของการทางานของ Use Case (Measurable Result)  จะมีใบสงั่ ซ้ ือสินคา้ ใหม่ 1 ใบข้ ึนมาในระบบ 45

ผู้จัดทำ นาย สถิรพันธุ์ ชำปฏิ สทท.1/3 เลขที่ 08

THANK YOU