school of Information communication Tecnology,

school of Information communication Tecnology,
chatper 3 UML Wattanapong suttapak, Software Engineering, school of Information communication Tecnology, university of phayao

จุดประสงค์การเรียนรู้
เข้าใจความหมายของ use case diagram สามารถสร้าง use case diagram ได้ สามารถวิเคราะห์ use case diagram ที่เหมาะสม

UML2 Behavior model Structural model
Class Diagram คลาส ส่วนประกอบคลาส ความสัมพันธ์ Object Diagram ความสัมพันธ์ระหว่างวัตถุ ตาม class diagram Package Diagram แสดงกลุ่มของแพคเกจและการขึ้นต่อกันของแพคเกจ Composite Structure Diagram แผนภาพภายในของ component diagram หรือ use case Component Diagram แผนภาพขององค์ประกอบระบบ(self) โดยแสดงความสัมพันธ์ และส่วนต่อประสาน Deployment Diagram แผนภาพระบบ hardware & software เชื่อมต่อกัน Use Case Diagram แสดงการใช้งานและความสัมพันธ์ของผู้ใช้ระบบ(actor) และการใช้งาน Activity Diagram แสดงการทำงานของข้อมูลทั้งระบบ State Or Statechart Diagram แสดงสถานะของวัตถุเมื่อมีเหตุการณ์(event) เกิดขึ้น Sequence Diagram แสดงการโต้ตอบหรือการตอบสนองต่อผู้ใช้ Communication Diagram(Collaboration Diagram UML1.x) แสดงการโต้ตอบหรือการตอบสนองระหว่างวัตถุ Timing Diagram แสดงการเปลี่ยนสถานะหรือเงื่อนไขขององค์ประกอบต่างๆ ตามเวลา Interaction Overview Diagram แสดงภาพรวมตามกระบวนการธุรกิจ ตามการทำงานของระบบ

UML2 Use Case Diagram แสดงการใช้งานและความสัมพันธ์ของผู้ใช้ระบบ(actor) และการใช้งาน Class Diagram คลาส ส่วนประกอบคลาส ความสัมพันธ์ Sequence Diagram แสดงการโต้ตอบหรือการตอบสนองต่อผู้ใช้ Activity Diagram แสดงการทำงานของข้อมูลทั้งระบบ

ความหมาย เป็นแผนภาพอธิบายกระบวนการทำงานของระบบตามความต้องการของผู้ใช้(Actor) โดยแสดงการโต้ตอบ (interaction) กับระบบ หลักการสร้าง เน้นที่ความต้องการใช้งานระบบของผู้ใช้ ตัวอย่าง การใช้นาฬิกา เจ้าของนาฬิกา(ผู้ใช้)สามารถ ดูเวลา ตั้งเวลา และเปลี่ยนถ่านนาฬิกาได้ การลงทะเบียน นิสิต(ผู้ใช้) สามารถลงทะเบียนเรียน เพิ่ม-ถอน รายวิชา ดูผลการลงทะเบียน ผลการเรียนได้ ระบบขายหนังสือ เจ้าของ(ผู้ใช้คนที่ 1) เพิ่ม ลบ ค้นหา แก้ไขหนังสือได้ ลูกค้า (ผู้ใช้คนที่ 2) ค้นหา หนังสือได้

Requirement การสร้าง USE CASE ตอบสนองต่อการรับความต้องการ(requirement) ทั้งสองด้าน เน้นด้าน ความต้องการด้านหน้าที่(Functional requirement) เช่นการ เข้าสู่ระบบ การค้นหา การเพิ่มข้อมูล เป็นต้น ความต้องการด้านอื่นๆ (Nonfunctional requirement) ประสิทธิภาพระบบ(Performance) -> การใช้งาน(availability) เช่น ผู้ใช้ สามารถส่งงานได้ทุกวัน ศุกร์ ช่วงเวลา น. – น.

Actor แบ่งเป็น 3 ประเภท Primary Actor เป็น ผู้ขอใช้บริการหลักจาก Use Case เช่น แคชเชียร์ Supporting Actor เป็น ผู้ขอใช้บริการจากระบบ แต่ไม่ใช้ผู้ใช้หลัก เช่น ลูกค้า Offstage Actor เป็น ผู้มีส่วนเกี่ยวข้องกับการทำงาน ใน Use Case เช่น สรรพากร ตัวอย่าง ระบบลงทะเบียน Primary Actor : ผู้ดูแลระบบ Supporting Actor : นิสิตลงทะเบียน Offstage Actor : อาจารย์ประจำรายวิชา ทั้งนี้อาจารย์ประจำรายวิชา จะสามารถดูผลการ ลงทะเบียนได้เท่านั้น

Use case document เอกสารคำอธิบาย Use Case
รูปแบบสั้น(Brief) มักมีไม่เกิน 1 หน้า แสดงวัตถุประสงค์หลัก(Main Success Scenarios) รูปแบบลำลอง(Casual Format) ยาวกว่าแบบสั้นโดยเพิ่มสถานการณ์ทางเลือก(Alternative Scenarios) รูปแบบเต็ม(Fully-dress Format) แสดงรายละเอียดตามหัวข้อย่อย

USE CASE Document : Brief
Use Case การขายสินค้า (Sale) ลูกค้านำสินค้าที่ต้องการซื้อมาส่งให้กับแคชเชียร์ แคชเชียร์จะใช้ระบบการขายสินค้าแบบ POS ใน การบันทึกรายการสินค้าที่ลูกค้าต้องการซื้อ โดยระบบจะแสดงราคารวมและรายละเอียดของสินค้าที่ลูกค้า ต้องการซื้อทุกรายการ ลูกค้าชำระเงินค่าสินค้าซึ่งระบบจะบันทึกการรับชำระค่าสินค้า ตัดสต๊อก และพิมพ์ใน เสร็จรับเงินส่งให้กับลูกค้า สรุป Use Case แบบ Brief ลูกค้านำสินค้า -> แคชเชียร์ -> ระบบการขายสินค้าแบบ POS -> บันทึกรายการสินค้าที่ลูกค้าต้องการ ซื้อ -> แสดงราคารวมและรายละเอียดของสินค้าที่ลูกค้าต้องการซื้อทุกรายการ -> ลูกค้าชำระเงินค่าสินค้า -> ระบบบันทึกการรับชำระค่าสินค้า -> ตัดสต๊อก -> พิมพ์ในเสร็จรับเงิน -> ส่งให้กับลูกค้า

USE CASE Document : Casual Format
Use Case การขายสินค้า (Sale) Main Success Scenario : ลูกค้านำสินค้าที่ต้องการซื้อมาส่งให้กับแคชเชียร์ แคชเชียร์จะใช้ระบบการขายสินค้าแบบ POS ใน การบันทึกรายการสินค้าที่ลูกค้าต้องการซื้อ โดยระบบจะแสดงราคารวมและรายละเอียดของสินค้าที่ลูกค้า ต้องการซื้อทุกรายการ ลูกค้าชำระเงินค่าสินค้าซึ่งระบบจะบันทึกการรับชำระค่าสินค้า ตัดสต๊อก และพิมพ์ใน เสร็จรับเงินส่งให้กับลูกค้า Alternate Scenario : ถ้าระบบไม่พบรหัสสินค้าที่ลูกค้าต้องการซื้อ ระบบแจ้งให้แคชเชียร์ทราบ เพื่อตรวจสอบรหัสสินค้า และป้อนรหัสสินค้าใหม่

USE CASE Document : Fully-dress Format
ประกอบไปด้วยหัวข้อต่อไปนี้ หัวข้อ คำอธิบาย Use Case Name ชื่อ Use Case Scope ขอบเขตระบบ Level User-goal ถ้า Use Case เป็นการทำงานตามวัตถุประสงค์ของ Actor Subfunction ถ้า Use Case เป็นการทำงานเนื่องจาก Use Case อื่นๆ Primary Actor ผู้ใช้หลัก Stakeholder and their interests ผู้ใช้ทั้งหมดโดยระบุความต้องการใช้งานหรือวัตถุประสงค์ของผู้ใช้แต่ละกลุ่ม Pre-condition เงื่อนไขหรือสถานะของระบบ ที่ต้องเป็นจริง เมื่อจะเริ่มทำงานตาม Use Case นี้ Success Guarantee (Post-condition) ผลการทำงาน อธิบายจากสิ่งที่เกิดขึ้นในการทำงานตาม Use Case

USE CASE Document : Fully-dress Format
ประกอบไปด้วยหัวข้อต่อไปนี้(ต่อ) หัวข้อ คำอธิบาย Main Success Scenario ตาม Use Case Doc : Brief Extensions เหตุการณ์ที่อาจเกิดขึ้น ในบางกรณี ทำให้ระบบไม่สมบูรณ์ Special Requirements ความต้องการพิเศษ(ไม่ใช่ฟังก์ชันการทำงาน) Technology and data Variation List การรับหรือแสดงข้อมูล(Input/Output) และรูปแบบของข้อมูลที่ต้องการกำหนด Frequency of Occurrence ความถี่ของการใช้งานระบบ Open Issues ประเด็นที่อาจเกี่ยวข้องกับ Use Case

start for generating code
Use CASE LEVEL Level Level Name Description Cloud High Summary such as Sell books online Far too high level to generate code Kite Summary Sea User goal single elementary business process, familiar use case start for generating code Fish Sub-Function often used ,such as validating credit cards Camp Too low not be defined as use cases ,steps in another use case such as Inserting new customers in the database

USE CASE Document : Fully-dress Format Example
Use Case : การขายสินค้า(Sale) 1. Scope : ระบบขายแบบ POS 2. Level : User-goal 3. Primary Actor : แคชเชียร์ 4. Stakeholders and their interests : แคชเชียร์ ต้องการทำงานได้อย่างถูกต้อง ไม่ผิดพลาดโดยเฉพาะอย่างยิ่งการรับชำระเงิน ลูกค้า ต้องการซื้อสินค้าและรับบริการอย่างรวดเร็ว และสามารถตรวจสอบราคาสินค้าและรายการสินค้า ที่ซื้อได้ บริษัท ต้องการให้มีการบันทึกรายการขายและชำระเงินอย่างถูกต้องและลูกค้าพอใจ รวมทั้งต้องการให้มี การตัดสต๊อคและบันทึกรายการบัญชีอย่างอัตโนมัติ

Use Case : การขายสินค้า(Sale) (ต่อ) 4. Stakeholders and their interests : ผู้จัดการร้าน ต้องการให้สามารถแก้ปัญหาที่อาจเกิดขึ้นกับแคชเชียร์ได้ กรมสรรพากร ต้องการเก็บภาษีได้อย่างถูกต้องในทุกรายการขายที่เกิดขึ้น 5. Pre-condition : 1. แคชเชียร์ได้รับสิทธิในการใช้งานระบบ 2. มีรายการสินค้าในระบบ 6. Success Guarantee: รายการขายถูกบันทึก ภาษีถูกคำนวณอย่างถูกต้อง สต๊อกสินค้าได้รับการปรับปรุงจำนวนคงเหลือ รายบัญชีถูกบันทึก ใบเสร็จถูกพิมพ์

Use Case : การขายสินค้า(Sale) (ต่อ) 7. Main Success Scenario : ลูกค้านำสินค้ามาส่งให้แคชเชียร์ แคชเชียร์เปิดรายการขายใหม่ในระบบ แคชเชียร์ป้อนรหัสสินค้าทีละชิ้นในเครื่องรับชำระเงิน ระบบรับรหัสของสินค้าและค้นหารายการสินค้าเพื่อแสดงชื่อสินค้าและราคา บันทึกรายการย่อย พร้อมกับแสดงยอดรวมรายการนี้ แคชเชียร์ทำซ้ำขั้น 3 – 5 จนกว่าสินค้าหมด แคชเชียร์ปิดรายการขาย

Use Case : การขายสินค้า(Sale) (ต่อ) 7. Main Success Scenario : ระบบแสดงยอดรวมราคาสินค้าทั้งหมดรวมทั้งภาษีขายที่คำนวณได้ แคชเชียร์แจ้งยอดรวมราคาสินค้าแก่ลูกค้าและรอรับเงิน ลูกค้าชำระเงิน และระบบบันทึกการรับชำระเงินนั้น ระบบบันทึกการปิดรายการขาย และส่งข้อมูลไปยังระบบสินค้าคงคลัง (เพื่อลดจำนวนสินค้าในสต๊อค) และระบบบัญชี (เพื่อ บันทึกบัญชี) ระบบพิมพ์ใบเสร็จรับเงิน ลูกค้ารับใบเสร็จรับเงินพร้อมกับสินค้าที่ซื้อและเดินออกจากร้าน

Use Case : การขายสินค้า(Sale) (ต่อ) 8. Extensions : กรณีระบบล่ม แคชเชียร์รีสตาร์ทระบบและล๊อคอินเข้าสู่ระบบ ระบบตรวจสอบความผิดปกติเพื่อแจ้งสาเหตุและผลการแก้ไขข้อผิดพลาด แคชเชียร์เริ่มการบันทึการขายใหม่อีกครั้ง กรณีผู้จัดการต้องการแก้ไขรายการขาย ผู้จัดการเปลี่ยนสถานะระบบ เป็นระบบแก้ไข ระบบพร้อมแก้ไข ผู้จัดการเปลี่ยนแปลงรายการ การขายต่อเนื่อง ...

Use Case : การขายสินค้า(Sale) (ต่อ) 9. Special Requirement : จอภาพใหญ่พอสำหรับการอ่าน 1 เมตร การกู้ระบบต้องแม่นยำ โดยเฉพาะการส่งข้อมูลไประบบอื่น 10. Technology and Data Variation List : ผู้จัดการสามารถเปลี่ยนระบบเพื่อแก้ไขได้ ผ่านทางบัตรแม่เหล็ก หรือ การพิมพ์รหัสผ่าน รหัสสินค้าถูกป้อนโดยเครื่องอ่านบาร์โค้ด รหัสสินค้าเป็นไปตามมาตรฐาน UPC EAN JAN หรือ SKU

Use Case : การขายสินค้า(Sale) (ต่อ) 11. Frequency of Occurrence : ใช้งานต่อเนื่อง 12. Open Issues: การคำนวณภาษีขายมีวิธีอื่นๆ หรือไม่ เมื่อแคชเชียร์เลิกใช้งานระบบหรือปิดช่องชำระเงิน ต้องทำอย่างไรกับเงินค่าขายสินค้าในลิ้นชัก

สัญลักษณ์ สัญลักษณ์ใน Use Case Diagram สัญลักษณ์ ชื่อเรียก การใช้งาน
Actor เป็นผู้ใช้ use case Use Case เป็นเหตุการณ์หรือการกระทำที่จะเกิดขึ้น เมื่อมีการเรียกใช้ โดย Actor หรือ Use Case อื่นๆ Association แสดงความสัมพันธ์ระหว่าง Actor กับ Use Case System Boundary แสดงขอบเขตของระบบที่จะพัฒนา

ตัวอย่างการใช้งาน

SUB USE CASE association stereotype แบ่งเป็น 3 ประเภทหลัก
communicate เป็นการสื่อสารโดยมีการส่ง message ระหว่าง object include การเรียกใช้ Use Case ย่อย ที่ถูกใช้บ่อยครั้งหรือบังคับให้ต้องเรียกใช้ extend การเรียกใช้ Use Case ย่อย ที่ไม่ถูกเรียกบ่อยหรือเป็นการเรียกเสริม(มีเงื่อนไขในการเรียกใช้)

association : include

association : Extend extend ทิศทางลูกศรกลับด้าน เมื่อ เทียบกับ include
หรือกล่าวได้ว่า extend use case จะไม่เกิดขึ้นหากไม่มี use case ที่เรียกมา เช่น Gift Voucher จะไม่เกิดขึ้นหากไม่มี Sales แต่ Sales จะสมบูรณ์เมื่อมีการชำระเงินด้วย Cash หรือ Credit

Use Case

Use case ที่เหมาะสม อ้างอิงตาม(Larman, 2005) 1. กำหนดขอบเขตของระบบ
กำหนดว่าระบบมีขอบเขตอย่างไร ทำอะไรได้บ้าง ผู้ใช้แต่ละกลุ่มทำงานต่างกันอย่างไร งานใดที่ยัง กำหนดขอบเขตได้ไม่ชัดเจน ให้ถือว่าเป็นงานที่นอกเหนือขอบเขต 2. วิเคราะห์ Primary Actor และเป้าหมายระบบ วิเคระห์ Primary Actor และ ค้นหาเป้าหมายของแต่ละ Actor

Use case diagram Primary Actor และเป้าหมายระบบ Primary Actor
เป้าหมายในระบบ แคชเชียร์ บันทึกการขาย รับคืนสินค้า เปิดเครื่องรับชำระเงิน ปิดเครื่องรับชำระเงินและส่งเงินรายได้ ผู้จัดการสาขา เปิดร้าน ปิดร้าน ดูรายงานการขาย ผู้ดูแลระบบ เพิ่มผู้ใช้ระบบ แก้ไขข้อมูลผู้ใช้ระบบ ลบผู้ใช้ระบบ

Use case ที่เหมาะสม 3. การกำหนด Use Case การกำหนด Main Success Scenario 4. การทดสอบความเหมาะสมของ Use Case ทดสอบขนาด เช่น Use Case การเข้าสู่ระบบ ต้องทำได้แค่ เข้าสู่ระบบ ทดสอบ Elementary Business Process(EBP) ระบบที่ได้ในแต่ละกระบวนการต้องไม่ใหญ่ เกินไป เช่น การชำระเงินของแคชเชียร์สำหรับลูกค้าแต่ละราย สิ้นสุดตามจำนวนสินค้าแล้วจบ การทำงาน 1 รายการ

10 Tips for create professional use case diagram
1. Think from end user’s perspective It is clear that you need to know users’ expectation in order to build a software system that works, and this principle is particular important in use case modeling. Many people has mistakenly treats use case modeling as a process to model system functions, which can be wrong. To be accurate, use case modeling is a way to model what the users want. Each of the use cases in a use case diagram should yield an observable goal through users’ interaction with the final software or system. Sometimes, a user goal is the same as a system function but this is not always true. For instance, “Login” is a system function but it is definitely not a user goal – No one will start a program, login and go away! So the more system functions you draw in a use case diagram, the less effective the use case model can be used to express users’ real expectation throughout the entire software development process. Therefore, when you develop a use case model, try to express everything by first thinking from end user’s perspective.

2. Avoid long use case name

3. Actor is a role, not a real person

4. Model common use case with <<include>> relationship

5. Model exceptional behavior with <<extend>>

6. Model scenario with flow of events, not directly on diagram

7. Make good use of stereotype for categorization

8. Model detailed system flow with sequence diagram Sequence diagram allows you to model the system behavior by representing the communication and interchange of messages between objects over time. But where to begin with? Instead of guessing what interaction to model, you can start by referring to what the user need, which is exactly what a use case model aimed to present. We know that every single use case represents a unique user goal. To draw sequence diagram from a use case implies that you are going to model what the computer system should do to fulfill the user. Ideally there will not be any redundant design as all the sequence diagrams are created from use cases, which represent what the user wanted.

9. Apply same width on use cases when appropriate Since the names of use cases are different in length, it is normal to have the use cases in different width. To make the diagram more pretty and easier to read, it would be nice to resize them to same width.

10. Position actors and use cases in a meaningful way A use case diagram with randomly placed actors and use cases is definitely a nightmare for readers. One has to examine the diagram carefully in order to find out the information he want from the scattered actors and use cases. It would be nice to place shapes in a discipline manner. You may also group use cases with package shapes if necessary

Use case in Unified Process
Inception : Brief format Main Use case Full format(10-20%) Elaboration : Full format(80-90%) Construction : ปรับปรุงและแก้ไข Use Case ที่เหลือ Transition: ไม่มี

จบบทที่ 3

school of Information communication Tecnology,

งานนำเสนอที่คล้ายกัน

งานนำเสนอเรื่อง: "school of Information communication Tecnology,"— ใบสำเนางานนำเสนอ:

งานนำเสนอที่คล้ายกัน

เรื่องโครงการ

การติดต่อกลับ

เข้าสู่ระบบ

ลงทะเบียนผ่านเครือข่ายสังคม:

school of Information communication Tecnology,

งานนำเสนอที่คล้ายกัน

งานนำเสนอเรื่อง: "school of Information communication Tecnology,"— ใบสำเนางานนำเสนอ:

งานนำเสนอที่คล้ายกัน

เรื่องโครงการ

การติดต่อกลับ