งานนำเสนอกำลังจะดาวน์โหลด โปรดรอ

งานนำเสนอกำลังจะดาวน์โหลด โปรดรอ

UML Diagrams Functional Model Seree Chinodom

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


งานนำเสนอเรื่อง: "UML Diagrams Functional Model Seree Chinodom"— ใบสำเนางานนำเสนอ:

1 UML Diagrams Functional Model Seree Chinodom
Object Oriented Analysis and Design UML Diagrams Functional Model Seree Chinodom

2 UML has 9 kinds of diagrams
Class Diagram Object Diagram Component Diagram Deployment Diagram Use Case Diagram Sequence Diagram Collaboration Diagram StateTransition Diagram Activity Diagram Structural Diagrams Functional Diagrams Behavioral Diagrams

3 Functional Modeling

4 Use Case Diagram นำเสนอ Use Case และการปฏิสัมพันธ์โต้ตอบกันระหว่างระบบ และ ผู้ใช้ภายนอก (อาจเป็นคน หรือระบบก็ได้) ประกอบด้วย Use Case - ความสามารถ/หน้าที่ของระบบ Actor - ผู้กระทำ/ผู้ใช้งาน Use Case นั้นๆ Relationship - เส้นแสดงความสัมพันธ์ระหว่าง Use Case กับ Actor System - ระบบที่กำลังพัฒนา

5 Use Case Modeling : Core Elements

6 Use Case Modeling : Core Relationships
<<extend>>

7 Use Case Modeling : Core Relationships (cont’d)
<<include>>

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

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

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

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

12 System ใช้สัญลักษณ์ System
อาจหมายถึง Software system, business, hardware,.. วัตถุประสงค์ใน use-case modeling เพื่อระบุขอบเขตของระบบที่กำลังพัฒนา (system boundary) ใช้สัญลักษณ์ System

13 Relationships between Use Case
Extends : เป็น generalization relationships ในกรณีที่ Use Case หนึ่งๆ ขยาย (extends) Use Case อื่น โดยการเพิ่มการกระทำ (actions) Includes/Uses : เป็น generalization relationship ในกรณีที่ Use Case หนึ่งๆ เรียกใช้ (uses) Use Case อื่น ที่พิจารณาให้เป็นส่วนหนึ่งของ Use Case นั้นๆ

14 Generalization Relationship
Child Use case รับถ่ายทอดคุณสมบัติมาจาก Parent Use Case Child สามารถเปลี่ยนแปลงพฤติกรรมที่รับจาก Parent หรือเพิ่มเติ่มพฤติกรรม Child อาจนำไปแทนที่ ในที่ๆ Parent ปรากฏ Validate client Check password Retinal scan

15 “Include” relationship
มักใช้ในการหลีกเลี่ยงการอธิบายการไหลของเหตุการณ์ (flow of events) เดิม ซ้ำกันหลายๆ ครั้ง โดยรวบรวมพฤติกรรมร่วม ใน Use Case หลีกเลี่ยงการ copy & paste ของ Use Case Descriptions Validate client Place order <<include>> Track order

16 Example of Include in a Track Order Use Case
Validate Client <<include>> System Response Actor Action 1. Input order number 2. Verify Order Number Include (Validate User) 3. For each part in the order, query its status 4. Report back to user Note: includes should also be mentioned in the overview and cross-reference section of the Use Case

17 “Extend” relationship
ใช้สร้างแบบจำลองบางส่วนของ Use Case ที่ user อาจมองเป็น optional ใช้ สร้างแบบจำลอง conditional subflows ใช้ในการแทรก subflows ในจุดที่ระบุโดยพิจารณา ปฏิสัมพันธ์ระหว่าง Actors Place order Extension points: Set priority <<extend>> (set priority) Place rush order

18 Example of Extends in a Use Case
Place Order Place Rush Order <<extend>> Actor Action System Response 1. Ask for order to be place 2. Verify customer details. Include (Validate User) 3. Collect the user’s order items. (set priority) 4. Submit order for processing Note: extends should also be mentioned in the overview and cross-reference section of the Use Case

19 Relationships between Use Case
Ship Order Validate Account <<extend>> <<include>> Ship Partial Order Withdrawal Cash

20 Comparing extends/uses
ใช้แยกความแตกต่างของ Use Case actors ที่เกี่ยวข้องมักเป็นคนกระทำ Use case รวมทั้ง Use Case ที่ extend ทั้งหมด actor มักเชื่อมต่อกับ “base” Use Case include/use ใช้กำหนด Use Case ที่มีพฤติกรรมร่วม มักไม่มี actor เกี่ยวข้องโดยตรงกับ Use Case ที่มีพฤติกรรมร่วม

21 A Use Case Diagram Retinal Scan <<include>> Track Order
Validate Client Check Password <<include>> Trader Place Order <<include>> Establish Credit Stock Exchange Financial Officer <<extend>> Place Rush Order

22 A Use Case Diagram Deposit Transfer Validate Account Customer
<<include>> Customer Validate Account Bank Teller Deposit Balance Checking Transfer Withdraw Verify withdrawal

23 When and how? Requirements capture ใช้ในการกำหนด Reuqirement ของระบบ
สร้างแบบจำลอง (Model) ของ requirements ด้วย Use Case Test Scenarios สร้างแบบจำลอง (Model) ของสถานการณ์การทดสอบระบบ (test scenarios) ด้วย Use Case Use Case: ระบุสิ่งที่ customer ต้องการให้มีในระบบ ตั้งชื่อให้ Use Case โดยเขียนคำอธิบายสั้นๆ เพิ่มรายละเอียดในภายหลัง Sources for identifying use cases: Think about potential actors Think about potential external events

24 Finding Actors สามารถระบุ actor ได้โดยตอบคำถามต่อไปนี้
ใครเป็นคนใช้งานหน้าที่การทำงานหลักของระบบ (primary actors)? ใครต้องการการสนับสนุนการทำงานจากระบบ? ใครต้องการบำรุงรักษา และบริหารระบบ (secondary actors)? Hardware devices ใดที่ต้องการให้ระบบจัดการดูแล? ระบบภายนอกระบบใดที่ ต้องการให้ระบบมีปฏิสัมพันธ์ด้วย? ใคร หรือ อะไรที่ต้องการได้รับผลประโยชน์ จาก output ของระบบ? Tips ไม่ควรพิจารณาเฉพาะ users ที่ใช้งานระบบโดยตรง แต่ พิจารณา users อื่นๆ ที่ต้องการใช้บริการจากระบบด้วย

25 Finding Use Cases สำหรับแต่ละ actor ตอบคำถามต่อไปนี้
เหตุการณ์ใดบ้างที่ระบบต้องแจ้งให้ actor ทราบ? หรือ actor ต้องแจ้งให้ระบบทราบ? หน้าที่การทำงานของระบบ ช่วยทำให้งานประจำวันของ actor ง่ายขึ้นหรือไม่? ถ้าไม่พิจารณา actors อะไรคือ input/output ของระบบ ? input/output เหล่านั้นมาจากไหน หรือใครเป็นคนนำไปใช้งาน? ปัญหาหลักของระบบที่ใช้งานอยู่ คืออะไร?

26 Recipe ระบุ actors ที่มีปฏิสัมพันธ์กับระบบ
สำหรับแต่ละ actor ให้ระบุกระบวนการที่ actor เริ่มต้นกระทำ หรือมีส่วนร่วม สำหรับ event ให้ระบุ เหตุการณ์ภายนอกที่ระบบต้องตอบสนอง ให้หาความสัมพันธ์ระหว่างเหตุการณ์ และ actor เพื่อสร้างเป็น use case


ดาวน์โหลด ppt UML Diagrams Functional Model Seree Chinodom

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


Ads by Google