Transcript uml
Object-Oriented Analysis การวิเคราะห ์และออกแบบระบบ เชิงวัตถุ (OOAD) Lec07 # Requirement Modeling with UML โดย อ. นัฐพงศ ์ สง่ เนียม http://www.siam2dev.com [email protected] 1 Lecture Outline • Software Modeling • Require and Domain Analysis Model • Design Model • Brief Overview of Unified Modeling Language (UML) • Use Case Model What is Modeling? • การสร ้างแบบจาลอง (Modeling) • เป็ นวิธก ี ารวิเคราะห ์ และออกแบบ ่ น (Analysis and Design) วิธก ี ารหนึ่งทีเน้ ่ สามารถเข้าใน การสร ้างแบบจาลอง เพือให้ ปั ญหาของระบบ ่ ่ • ใช้เป็ นเครืองมื อในการสือสาร แนวคิดใน ่ การพัฒนาระบบ กับบุคคลอืนๆ • Visual Modeling ใช้สญ ั ลักษณ์รูปภาพในการสร ้าง แบบจาลอง Software Modeling User Requirement Modeling (Analysis and Design) Model (Specification) Manually Coding Tools Program Models • Requirement Analysis Models (Requirement Specification) ได้จากกระบวนการวิเคราะห ์ความต้องการ ของผู ใ้ ช้ระบบ (Requirement Analysis) • Analysis Model ่ ได้จากกระบวนการวิเคราะห ์หน้าทีการ ทางานของระบบ (System Analysis) • Design Model ได้จากกระบวนการออกแบบการทางาน ของระบบ (System Design) Software Development Process • Requirement Specification : define problem domain • Analysis : what problem to be solved? • Design : how to solve the problem? • Implementation : how to implement the solution? • Testing : how to ensure that the solution can solve the problem? • Maintenance : how to adjust the solution to accomodate change? • Retirement : when does the system Structured Analysis Models • Data Flow Diagrams • Entity Relationship Diagrams • State-Transition Diagrams Object-Oriented Analysis Models • Use-case Diagrams • Class and Object Diagrams • Behavioral Diagrams The Unified Modeling Language (UML) What is UML? ่ ในการสร ้างแบบจาลอง • เป็ นภาษาทีใช้ (Modeling Language) ที่ ่ ในการ ประกอบด้วยองค ์ความรู ้ทีใช้ นาเสนอและออกแบบเอกสารประกอบ โปรแกรม • รวม 3 แนวคิด/วิธก ี ารเชิงวัตถุท ี่ ได้แก่ Booch, Rumbaugh และ Jacobson ้ ่ รวมทังจากบุ คคลอืน • จัดเป็ นมาตรฐานสาหร ับการ What is NOT UML? • ไม่ใช่ภาษาโปรแกรม (Programming Language) • ใช่ method หรือ methodology ่ ในการทางาน • ไม่ระบุ Process ทีใช้ • UML ใช้ในการสร ้างแบบจาลองการ วิเคราะห ์ และออกแบบระบบ โดยไม่ ้ บ Process ขึนกั • แต่ละโครงงานสามารถเลือก Process ่ History of UML • 1970s วิธเี ชิงวัตถุ (Object-oriented method) • 1970s, 1980s, 1990s “Method Wars” Grady Booch, Jim Rumbaugh, Ivar Jacobson ่ ยมใช้ • 3 แนวคิด/วิธก ี ารเชิงวัตถุทเป็ ี่ นทีนิ ในช่วงกลางทศวรรษ 1990s ได้แก่ • OOSE (Object-Oriented Software Engineering) โดย Ivar Jacobson • OMT (Object Modelling Technique) Histroy of UML • ในปี 1994/5 Booch, Rumbaugh และ Jacobson (เรียกตัวเองว่า “three amigos”) ร่วมกันทาการรวบรวมแนวคิด องค ์ความรู ้ และเทคนิ คต่างๆ เข้าด้วยกัน ที่ Rational Software • Three Amigos เสนอ Unified Modelling Language (UML) ไปยัง หน่ วยงาน OMG ่ (Object Management Group) เพือให้ เป็ นภาษามาตรฐานสาหร ับสร ้าง แบบจาลองเชิงวัตถุ Histroy of UML • • • • • ปี 1998 พัฒา UML Version 1.2 ปี 1999 พัฒา UML Version 1.3 ปี 2000 พัฒา UML Version 1.4 ปี 2001 พัฒา UML Version 2.0 http://www.uml.org/ Models and Diagrams A model is a complete description of a system from a particular perspective Use Case Use Case Diagrams Sequence Diagrams Diagrams Scenario Scenario Diagrams Collaboration Diagrams Diagrams Scenario Scenario Diagrams Statechart Diagrams Diagrams Use Case Use Case Diagrams Use Case Diagrams Diagrams State State Diagrams Class Diagrams Diagrams Models State State Diagrams Object Diagrams Diagrams State State Diagrams Component Diagrams Diagrams Component Component Diagrams Deployment Diagrams Activity Diagrams Diagrams Lifecycle Phases Inception Elaboration Construction Transition time • Inception Define the scope of the project and • Elaborationdevelop Plan project, specify business casefeatures, and • Construction Build product baseline the the architecture • Transition Transition the product to its users UML has 9 kinds of diagrams Class Diagram Object Diagram Structural Component Diagram Diagrams Deployment Diagram Use Case Diagram Sequence Diagram Behavioral Diagrams Collaboration Diagram StateTransition Diagram Activity Diagram UML(Unified Modeling Language) • 5 มุมมองหลักของ UML ่ • Use-case view : หน้าทีการท างานของ ระบบซอฟต ์แวร ์ โดยพิจารณาจากมุมมอง ของผู ใ้ ช้ภายนอก หรือ ระบบภายนอก • use-case diagram ่ • Logical view : หน้าทีการท างานของระบบมี โครงสร ้างอย่างไร มองในรู ปของ static structure และdynamic behavior • class diagram, object diagram, state, sequence, collaboration, activity diagrams UML(Unified Modeling Language) • Component view : องค ์ประกอบย่อยในการ ่ implement ทีประกอบเป็ นระบบ และ ้ dependency ระหว่างองค ์ประกอบเหล่านัน • component diagram • Concurrency view: การแบ่งแยก process และ processors โดยพิจารณาทัง้ communication และ synchronization • dynamic diagrams (state, sequence, collaboration activity) • implementation diagrams(component และ Class Diagrams • Class diagrams • แสดงรายละเอียดของ Class และ ความสัมพันธ ์ระหว่าง Class ในมุมมอง แบบ logical view • องค ์ประกอบของ UML class diagrams ได้แก่ • Class, โครงสร ้างของ Class และ พฤติกรรมของ Class • ต ัวบ่งชี ้ Multiplicity และ navigation ่ • ชือของ Role Classes in UML • เขียนได้ 2 รู ปแบบ Class name Person Person Attributes attribute name : type Operations operation name(parameter : type) : result type - TaxIDNo : String - Name : String + Income : double + TaxPaid : Boolean + calcTax() + calcTaxBal() A Class Diagram Actuator startUp( ) shutDown( ) generalization aggregation Light Heater off( ) on( ) 1 Cooler Temperature 1 0..* 1 1 1 Environmental Controller define_climate( ) terminate_climate( ) SystemLog display( ) recordEvent( ) An Object Diagram Account #31421123 Victoria High Street Branch (A Branch Object) Account #741421123 Account #521665423 London Road Branch (A Branch Object) Account #31421123 Account #31421123 Account #714559543 Component Diagram • Component Diagram เป็ น ่ อธิบายถึงซอฟต ์แวร ์ ไดอะแกรมทีใช้ ่ น Component ของระบบ ต่างๆ ทีเป็ A Component Diagram Register.exe Billing.exe Billing System People.dll Course.dll Course Student Course Course Offering User Professor Deployment Diagram • Deployment Diagram ใช้สาหร ับ แสดงสถาปั ตยกรรมของระบบใน ่ น physical ลักษณะทีเป็ Architecture คือแสดงว่ามี คอมพิวเตอร ์และอุปกรณ์อะไรบ้างที่ ต้องการใช้ในระบบ • ใช้รูปลู กบาศก ์แทน โดย 1 ลู กบาศก ์จะ แทน 1 โหนด และแต่ละโหนดก็จะมี A Deployment Diagram Account Server Account Server Deploys AccountDB.java AccountMgt.java AccountDB.java AccountMgt.java Use Case Diagram • Use Case แปลตรงตัวมีความหมายว่า ่ ดจากมุมมองของ กรณี ของการใช้งานทีเกิ ผู ใ้ ช้ระบบ ตัวอย่างง่ ายๆ ของ Use Case ก็ คือ ่ อ้ - Create Order (ทาการลงใบสังซื สินค้า) ่ - Modify Order (ทาการเปลียนแปลง ่ อสิ ้ นค้ ้ า) หรือแก้ไขใบสังซื ่ อ้ - Delete Order (ทาการลบใบสังซื Use Case Diagram • Use Case อาจหมายถึง การอธิบาย ฟั งก ์ช ันการทางานต่างๆ ของระบบนั่นเอง • Use Case Diagram จะแสดงแผนผังการ ใช้งานของระบบ โดยมีองค ์ประกอบ 2 ส่วน คือ actor และ use case A Use Case Diagram <<include>> Validate Client Track Order <<include>> Trader Place Order Stock Exchange <<extend>> Place Rush Order Retinal Scan Check Password <<include>> Establis h Credit Financial Officer Sequence Diagram • Sequence Diagram จะแสดงการ ่ ดการ ทางานของออบเจ็กต ์ต่างๆเมือเกิ ่ ส่งข่าวสารหรือ massage และเมือ เกิดเหตุการณ์ตา ่ งๆ โดยทิศทางของ ลู กศรจะเป็ นการบ่งบอกถึงทิศทางการ ส่ง messageระหว่างออบเจ็กต ์ A Sequence Diagram : Student registration form registration manager math 101 math 101 section 1 1: fill in info 2: submit 3: add course(joe, math 01) 4: are you open? 5: are you open? 6: add (joe) 7: add (joe) Collaboration Diagram • Collaboration Diagram จะแสดง ่ การติดต่อสือสารระหว่ างออบเจ็กต ์ ่ ต่างๆ และความสัมพันธ ์ระหว่างทีแต่ ่ ละออบเจ็กต ์ติดต่อสือสารกั น A Collaboration Diagram 1: set course info 2: process course form : CourseForm 3: add course : Registrar theManager : CurriculumManager aCourse : Course 4: new course State-Transition Diagram State-Transition Diagram ทาหน้าที่ ต่อไปนี ้ • แสดงวงจรชีวต ิ ของออบเจ็กต ์ ระบบ ย่อยต่างๆ และระบบโดยรวม • บ่งบอกว่าเหตุการณ์ตา ่ งๆ จะส่งผล ้ างในระบบ กระทบให้เกิดอะไรขึนบ้ ่ นและและจุดจบได้หลาย • อาจมีจด ุ เริมต้ จุด A State-Transition Diagram Add student[ count < 10 ] Initialization do: Initialize course Add Student / Set count = 0 Open entry: Register student exit: Increment count Cancel Cancel [ count = 10 ] Canceled do: Notify registered students Cancel Closed do: Finalize course Activity diagram • ใช้สาหร ับ • อธิบาย กระแสการไหลของการทางาน (workflow) ้ างานของระบบ • แสดงขันตอนการท ้ • แต่ละขันตอนการท างาน เรียกว่า Activity ตัวอย่าง ได้แก่ • การคานวณผลลัพธ ์บางอย่าง ่ • การเปลียนแปลงสถานะ (State) ของ ระบบ • การส่งค่ากลับคืน • การส่งสัญญาณ An Activity Diagram Ordinary Example Swimlane Example Show MessageBox “Printing” on Screen Create postscript file Remove MessageBox Send postscript file to printer displayer sampler Benefits of UML ่ ในการสร ้าง • เป็ นภาษามาตรฐานทีใช้ แบบจาลองเชิงวัตถุ โดยใช้รูปภาพ (Standard Visual Modeling Language) ่ • ใช้ในการแลกเปลียนข้ อมู ล แบบจาลองกัน ระหว่างทีมผู พ ้ ฒ ั นา และระหว่างผู ใ้ ช้ กับ ทีมผู พ ้ ฒ ั นา • นาเสนอ และ สนับสนุ นหลักการเชิงวัตถุได้ ครบถ้วน ช ัดเจน • ไม่ผูกติดกับภาษาโปรแกรม (Programming Language) ภาษาใด Use Case Model System Analysis • กระบวนการวิเคราะห ์ระบบ (system analysis phase) ่ • มุ่งเน้น “what” ทีระบบจะต้ องมี และต้อง ทาให้ก ับผู ใ้ ช้ ไม่เน้น “how” ว่าจะทา อย่างไร • กระบวนการวิเคราะห ์ความต้องการของผู ใ้ ช้ ระบบ (Requirement analysis phase) ่ • ใช้ในการสร ้างแบบจาลองหน้าทีการ ทางานของระบบซอฟต ์แวร ์ จากมุมมอง ของผู ใ้ ช้ภายนอก หรือ ระบบภายนอก • System Analysis and Use Case Use Case Model • แบบจาลองความต้องการของระบบ ที่ นาเสนอ functional requirement ของ ระบบโดยรวม จากมุมมองของผู ใ้ ช้ ภายนอก หรือ ระบบภายนอก ่ • ระบุพฤติกรรม หรือหน้าทีการท างานของ ่ ระบบ (เน้น “what”) ทีระบบต้ องมี • ใช้ในการทดสอบ และตรวจสอบ ่ โครงสร ้าง และหน้าทีการท างานของระบบ • ใน UML ระบุเป็ น Use Case Description (Text) หรือ Use Case Use Case Example Place Order Stock Exchange Market ้ • Name: การส่งรายการซือขายหลั กทร ัพย ์ (Place Order) Trader • Main flow of events: ่ และรหัสของ client 1. Traderป้ อนชือ ่ รหัส 2. System ตรวจสอบ (Validate) ชือ และcredit ของ client 3. Trader ป้ อนรหัสหลักทร ัพย ์ จานวน หลักทร ัพย ์ และราคาหลักทร ัพย ์ ที่ Client ้ ต้องการซือขาย 4. System ตรวจสอบเงื่อนไขราคาของ หลักทร ัพย ์ Use Case Diagram • นาเสนอ Use Case และการปฏิสม ั พันธ ์ โต้ตอบกันระหว่างระบบ และ ผู ใ้ ช้ภายนอก (อาจเป็ นคน หรือระบบก็ได้) • ประกอบด้วย ่ • Use Case - ความสามารถ/หน้าทีของ ระบบ • Actor - ผู ก ้ ระทา/ผู ใ้ ช้งาน Use Case ้ นันๆ • Relationship - เส้นแสดงความสัมพันธ ์ ระหว่าง Use Case กับ Actor Use Case Modeling : Core Elements Construct Description Syntax use case actor A sequence of actions, including variants, that a system (or other 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. UseCaseName ActorName system boundary Represents the boundary between the physical system and the actors who interact with the physical system. Use Case Modeling : Core Relationships Construct Description The participation of an actor in a use case. i.e., instance of an actor and instances of a use case communicate with each other. generalization A taxonomic relationship between a more general use case and a more specific use case. A relationship from an extension use extend 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. Syntax association <<extend>> Use Case Modeling : Core Relationships (cont’d) Construct Description include An relationship from a base use case to an inclusion use case, specifying how the behavior for the inclusion use case is inserted into the behavior defined for the base use case. Syntax <<include>> Use Cases v.s. Scenario • Use Case ่ • ความสามารถ หรือ หน้าทีการท างานของ ระบบ • แต่ละ Use Case แทนชุดของ transactions ่ ทีระบบท างานโต้ตอบกับ ผู ใ้ ช้งาน หรือระบบ ่ ภายนอก อืนๆ • Scenario ่ • สถานการณ์ หรือต ัวอย่างเรืองราวการใช้ งานระบบ a user withdrawals $200 • Scenario จัดเป็ น instance ของ use case withdrawal cash • เช่น Actors • Actor หมายถึง someone หรือ some ่ การปฏิสม thing ทีมี ั พันธ ์ โต้ตอบกับระบบ ่ ่ ความต้องการในการ • สิงใดก็ ตามทีมี ่ แลกเปลียน information กับระบบ หรือ ่ ่ ่ภายนอกระบบ และมีการ สิงใดก็ ตามทีอยู ใช้งาน Use Case ของระบบ ่ • กาหนดบทบาทหน้าทีของผู ใ้ ช้ระบบ ่ ่ • กาหนดการเชีอมโยงกับระบบอื นๆ ภายนอก • ตัวอย่างของ Actors Customer Cashier • Customer -- maintain their account Actors • Actors สามารถอธิบายโดยใช้ Specialization Relationship Customer ATM Customer specialization relationship Cashier Customer • อาจพิจารณา Actors เป็ นคลาส ใน UML เนื่องจากมี relationships เช่นเดียวกับที่ คลาสมี Actors ่ • เชือมต่ อกับ use cases โดยใช้เส้นแสดง ่ ความเกียวข้ อง ปฏิสม ั พันธ ์(association) ่ การ • association = ความสัมพันธ ์ทีมี ่ ้ ติดต่อสือสารกัน (ทังการร ับ และส่ง messages ให้แก่ก ันและก ัน) Customer withdrawal cash • ใช้ generalization relationships อธิบาย ความสัมพันธ ์ ระหว่าง actors ไม่ จาเป็ นต้องอธิบายรายละเอียดของ System • System • อาจหมายถึง Software system, business, hardware,.. • วัตถุประสงค ์ใน use-case modeling ่ ่ าลังพัฒนา เพือระบุ ขอบเขตของระบบทีก (system boundary) • ใช้สญ ั ลักษณ์ System Relationships between Use Case • Extends : เป็ น generalization relationships ในกรณี ท ี่ Use Case หนึ่งๆ ่ โดยการเพิม ่ ขยาย (extends) Use Case อืน การกระทา (actions) • Includes/Uses : เป็ น generalization relationship ในกรณี ท ี่ Use Case หนึ่งๆ ่ ทีพิ ่ จารณาให้ เรียกใช้ (uses) Use Case อืน ้ เป็ นส่วนหนึ่งของ Use Case นันๆ Generalization Relationship Validate client Check passwor d Retinal scan • Child Use case ร ับ ถ่ายทอดคุณสมบัตม ิ าจาก Parent Use Case • Child สามารถ ่ เปลียนแปลงพฤติ กรรมที่ ่ ร ับจาก Parent หรือเพิม ่ เติมพฤติ กรรม • Child อาจนาไปแทนที่ ใน ทีๆ่ Parent ปรากฏ “Include” relationship ่ • มักใช้ในการหลีกเลียงการอธิ บายการไหล ของเหตุการณ์ (flow of events) เดิม ซา้ กันหลายๆ ครง้ั โดยรวบรวมพฤติกรรมร่วม ใน Use Case <<include>> Validate client Place order <<include>> Track order ่ • หลีกเลียงการ copy & paste ของ Use “Include” Example Track Order • <<include>> Validate Client ้ Name : การตรวจสอบรายการซือขาย หลักทร ัพย ์ (Track Order) • Main flow: 1. ใช้หมายเลข order ในการตรวจสอบ ่ ร ับจากตลาดหลักทร ัพย ์ Obtain ทีได้ and verify order number 2. Include ส่วนของ “Validate client” 3. ในแต่ละส่วนของ Order … “Extend” relationship Place order Extension points: Set priority <<extend>> (set priority) Place rush order • ใช้สร ้างแบบจาลองบางส่วน ของ Use Case ที่ user อาจ มองเป็ น optional • ใช้ สร ้างแบบจาลอง conditional subflows • ใช้ในการแทรก subflows ่ ในจุดทีระบุโดยพิ จารณา ปฏิสม ั พันธ ์ระหว่าง Actors “Extend” Example <<extend>> Place Order Place Rush Order ้ กทร ัพย ์ • Name : การส่งรายการซือขายหลั (Place Order) • Main flow of events: 1. … 2. Trader ป้ อนเงื่อนไขของหลักทร ัพย ์ ้ ที่ Client ต้องการซือขาย 3. กาหนดลาดับความสาค ัญ โดย (set priority) 4. System ส่ง order ให้ก ับตลาด หลักทร ัพย ์ Relationships between Use Case Validate Account <<include>> Withdrawal Cash Ship Order <<extend>> Ship Partial Order Comparing extends/uses • extend • ใช้แยกความแตกต่างของ Use Case ่ ยวข้ ่ • actors ทีเกี องมักเป็ นคนกระทา Use ่ ้ case และUse Case ทีextend ทังหมด ่ • actor มักเชือมต่ อกับ “base” Use Case • include/use • ใช้ extract พฤติกรรมร่วม ่ • มักไม่ม ี actor เกียวข้ องโดยตรงกับ Use ่ พฤติกรรมร่วม Case ทีมี • actors ทีแตกต่างกัน for “caller” use A Use Case Diagram <<include>> Validate Client Track Order <<include>> Trader Place Order Stock Exchange <<extend>> Place Rush Order Retinal Scan Check Password <<include>> Establis h Credit Financial Officer Customer A Use Case Diagram Deposit Transfe r Validate Account <<include>> <<include>> Withdraw <<include>> Balance Checking Verify withdrawa l Bank Teller When and how? • Requirements capture • ใช้ในการกาหนด Reuqirement ของระบบ • สร ้างแบบจาลอง (Model) ของ ser requirements ด้วย Use Case • Test Scenarios • สร ้างแบบจาลอง (Model) ของสถานการณ์การ ทดสอบระบบ (test scenarios) ด้วย Use Case • Use Case: ระบุสงที ิ่ ่ customer ต้องการให้มใี นระบบ ้ อให้ ่ • ตังชื Use Case ้ • เขียนคาอธิบายสันๆ ่ • เพิมรายละเอี ยดในภายหลัง Finding Actors • สามารถระบุ actor ได้โดยตอบคาถามต่อไปนี ้ ่ • ใครเป็ นคนใช้งานหน้าทีการท างานหลักของระบบ (primary actors)? • ใครต้องการการสนับสนุ นการทางานจากระบบ? • ใครต้องการบารุงร ักษา และบริหารระบบ (secondary actors)? ่ องการให้ระบบจัดการ • Hardware devices ใดทีต้ ดู แล? • ระบบภายนอกระบบใดที่ ต้องการให้ระบบมี ปฏิสม ั พันธ ์ด้วย? ่ องการได้ร ับผลประโยชน์ จาก • ใคร หรือ อะไรทีต้ output ของระบบ? Finding Use Cases • สาหร ับแต่ละ actor ตอบคาถามต่อไปนี ้ ่ • หน้าทีการท างานอะไรที่ actor ต้องการจากระบบ? • ข้อมู ลใดบ้างที่ actor ต้องการสร ้าง อ่าน ลบ ่ เปลียนแปลง หรือเก็บอยู ่ภายในระบบ? ่ • เหตุการณ์ใดบ้างทีระบบต้ องแจ้งให้ actor ทราบ? หรือ actor ต้องแจ้งให้ระบบทราบ? ่ • หน้าทีการท างานของระบบ ช่วยทาให้งานประจาวน ั ้ อไม่? ของ actor ง่ ายขึนหรื • ถ้าไม่พจ ิ ารณา actors • อะไรคือ input/output ของระบบ ? input/output ้ เหล่านันมาจากไหน หรือใครเป็ นคนนาไปใช้งาน? ่ งานอยู ่ คืออะไร? • ปั ญหาหลักของระบบทีใช้ Recipe ่ ปฏิสม • ระบุ actors ทีมี ั พันธ ์กับระบบ • พิจารณาแนวทางของระบบ ในการ ปฏิสม ั พันธ ์กับ actors • จาแนกพฤติกรรมของระบบใน การ ปฏิสม ั พันธ ์กับ actors ให้เป็ น use cases โดยกาหนดความสัมพันธ ์ระหว่าง Use Case ต ัวอย่างการเขียน Use case การเขียน Use case องค ์ประกอบมีด ังนี ้ ่ - ชือของ 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) Use Case : Create Order ภาพรวมของการทางาน (Overview) ่ ำกำรลง จุดประสงค ์หลักของ Use Case นี ้ เพือท ่ อสิ ้ นค ้ำจำกลูกค ้ำ ข ้อมูลในใบสังซื Actor หลัก (Primary Actor) ตัวแทนฝ่ ำยขำยสินค ้ำ Actor รอง (Secondary Actor) ไม่มี ่ น (Starting Point) จุดเริมต้ ่ Actor ตัวแทนฝ่ ำย ่ ้นเมือ ้ มต Use Case ตัวนี เริ ่ อ้ ขำยสินค ้ำขอให ้ระบบทำกำรลงข ้อมูลกำรสังซื สินค ้ำ ้ ด (End point) จุดสินสุ ่ ำกำรลงข ้อมูลกำรสังซื ่ อสิ ้ นค ้ำเสร็จสิน้ คำขอเพือท สมบูรณ์หรือไม่ก็ถก ู ยกเลิก Use Case : Create Order การทางานของ Use Case (Flow of Events) ่ ำกำรลงข ้อมูลกำร จำก User Interface บนจอเพือท ่ อ้ Actor จะต ้องทำกำรใส่ข ้อมูลเกียวกั ่ บกำรสังซื ่ อ้ สังซื ่ กค้าต้องการให้สน ิ ค้าส่งมอบถึง เป็ นต ้นว่ำ วันทีลู ่ องการสังซื ่ อ้ มือ (Required Date) ปริมาณทีต้ (Quantity) ต้องการให้ส่งมอบสินค้าโดยบริษท ั ส่งสินค้าไหน (ShipVia) ต้องการให้ให้ส่งมอบ ่ สินค้าทีไหน (ShipAddress) หลังจำกนั้นแล ้ว ่ ำกำรบันทึกข ้อมูลลงไปไว ้ Actor สำมำรถเลือกทีจะท ้ ในฐำนข ้อมูล หรือยกเลิกกำรทำงำนทังหมด ถ ้ำ ่ อใบใหม่ ้ Actor เลือกทำกำรบันทึก ใบสังซื ก็จะถูกสร ้ำง Use Case : Create Order ่ ปัญหา การทางานของ Use Case เมือมี ้ (Alternative Flow of Events) เกิดขึน ่ ้องกำรอยูใ่ นคลังสินค ้ำ ระบบ ถ ้ำไม่มส ี น ิ ค ้ำทีต จะต ้องแจ ้งให ้ Actor ทรำบพร ้อมกันนั้นก็ต ้อง ่ อของ Use Case นี ้ ยกเลิกกำรทำงำนทีเหลื ผลของการทางานของ Use Case (Measurable Result) ่ อสิ ้ นค ้ำใหม่ 1 ใบขึนมำในระบบ ้ จะมีใบสังซื Cash Register Example Use Case: Buy items Actors: Customer, Cashier Type: Primary Description: A Customer arrives at a checkout with items to purchase. The Cashier records the purchase items and collects payment. On completion, the Customer leaves with the items Expanded Use Case Example Use Case: Buy Items with Cash Actors: Customer (initiator), Cashier Purpose: Capture a sale and its cash payment Overview: A Customer arrives at a checkout with items to purchase. The Cashier records the purchase items and collects a cash payment. On completion, the Customer leaves with the items. Type: primary and essential Cross references: R1.1, R1.2, R1.7 Expanded Use Case (2) TYPICAL COURSE OF EVENTS ACTOR ACTION 1. This use case begins when a Customer arrives at the register with items to purchase. 2. The cashier records the identifier from each item. If more than one of the same item, the Cashier can enter the quantity as well. SYSTEM RESPONSE 3. Determines the item price and adds the item information to the running sales transaction. 5. CalculatesThe and presents description sale total. and price of the item are presented. Expanded Use Case (3) ACTOR ACTION 7. The Customer gives a cash payment possibly greater than the sale total. 8. The Cashier records the cash received amount. 10. The Cashier SYSTEM RESPONSE 9. Show the balance due back to the Customer. Generates a receipt. 11. Logs the completed sale. Expanded Use Case (4) • Alternative Courses • Line 2: Invalid identifier entered. Indicate error • Line 7: Customer didn’t have enough cash. Cancel sales transaction • If a Typical Course of Events has multiple equally likely courses of action • indicate branches in Use case • write a subsection for each branch indicating the typical course of events • have alternatives for each subsection if