Object Oriented Development with UML 11/14/2018 Object Oriented Development with UML 11-12, 18-19 November 2006 At Sipa Chiangmai Requirement with Use Case โดย รศ. รังสิต ศิริรังษี อ. สายัณห์ อุ่นนันกาศ

11/14/2018 What is a model? เนื่องจากมนุษย์มีข้อจำกัดในการจดจำรายละเอียดเพื่อใช้ในการแก้ไขปัญหา ดังนั้นจึงจำเป็นต้องสร้างแบบจำลองเพื่อให้มองเห็นรายละเอียดเพิ่มขึ้น แบบจำลองจะช่วยให้เห็นภาพของระบบที่ยังไม่เกิดขึ้น แบบจำลองจะช่วยให้มีแนวคิดที่ตรงประเด็นกับระบบ เพื่อที่จะเข้าใจว่า why ซอฟต์แวร์จึงเป็นที่ต้องการ what อะไรบ้างที่ต้องทำ และ how วิธีการอย่างไรในการทำ เพื่อป้องกันไม่ให้เกิดความเข้าใจผิดพลาดหรือสื่อสารผิดพลาด แบบจำลองในการพัฒนาซอฟต์แวร์ problem domain - solution domain

Object Oriented Analysis 11/14/2018 Object Oriented Analysis “การวิเคราะห์เชิงวัตถุเป็นวิธีการวิเคราะห์เพื่อกำหนดความต้องการของระบบจากมุมมองของคลาสและออปเจคที่ได้มาจากคำศัพท์ที่พบอยู่ในปัญหาที่ต้องการแก้ไข " โดยความต้องการของระบบจะต้องมีการระบุลำดับความสำคัญเพื่อให้ทราบว่าส่วนสำคัญที่สุดของระบบจะต้องทำคืออะไรบ้าง เมื่อรวบรวมความต้องการได้แล้ว ต่อไปจะเริ่มต้นการวิเคราะห์ปัญหา เพื่อให้สามารถกำหนดรายละเอียดต่าง ๆ เพื่อนำไปใช้ในการออกแบบและพัฒนาระบบต่อไป ขั้นตอนของการวิเคราะห์เริ่มต้นจากการพิจารณาถึงการทำงานของระบบ ซึ่งจะนำเสนอผ่านยูสเคสไดอาแกรม

11/14/2018 The objectives of OOAD สร้างโค้ดในสถาปัตยกรรมที่เหมาะสม และง่ายต่อการบำรุงรักษา สร้างโค้ดที่สามารถนำกลับมาใช้ใหม่ได้ สร้างแบบจำลองของซอฟต์แวร์ก่อนการพัฒนา (แบบจำลองสามารถ validated, verified….) ชะลอขั้นตอนการพัฒนาโปรแกรม และค้นหาปัญหาจากการออกแบบก่อนการพัฒนาโปรแกรม เอกสาร OOAD ถูกใช้เป็นเสมือนพิมพ์เขียว เพื่อเป็นแนวทางในการพัฒนาระบบ ใช้เป็นเครื่องมือในการสื่อสารระหว่างทีมงานพัฒนาระบบ

OO Analysis requirements model analysis model Analysis Design Users 11/14/2018 OO Analysis Users Generate Requests Problem Statement Developers requirements model Use case model User Interviews Conceptual Class Build use cases Domain knowledge Real-world experience analysis model Build Models Object Model Dynamic Model Interaction Diagrams Analysis Design

OO Analysis Requirement specification requirements model Analysis 11/14/2018 OO Analysis Conceptual Class Requirement specification use case model requirements model Analysis process interaction Costumers dynamic model object model analysis model

Classification of Diagram Types 11/14/2018 Classification of Diagram Types Diagram Static/Dynamic Phase Use case Dynamic Requirements Class Static Design Object Sequence Collaboration Statechart Activity Component Code Deployment Deploy

11/14/2018 Use Cases ยูสเคสไดอาแกรมเป็นเทคนิคในการพัฒนาแบบหนึ่งที่ถูกรวบรวมไว้ใน UML ถูกคิดค้นโดย Ivar Jacobson ในปี 1994 เน้นไปที่ความต้องการของระบบตามมุมมองของผู้ใช้ โดยอาศัยแนวความคิดที่ว่า “อะไรคือสิ่งที่ระบบจะต้องทำสำหรับผู้ใช้แต่ละคน” ใช้เป็นกลไกสำหรับขับเคลื่อนการดำเนินการของการพัฒนาระบบ ใช้เป็นพื้นฐานในการทดสอบระบบ ใช้สำหรับการตรวจสอบติดตามการเปลี่ยนความต้องการของระบบตามฟังก์ชันการทำงานให้อยู่ในรูปของคลาสและการทำงานจริงที่เกิดขึ้นภายในระบบ ใช้สำหรับการประเมินราคาของซอฟต์แวร์

Use Cases vs. Requirements 11/14/2018 Use Cases vs. Requirements เพื่อใช้ในการค้นหาความต้องการของระบบตามมุมมองของผู้ใช้ เอกสารประกอบความต้องการของระบบใช้สำหรับแสดงการทำงานของระบบ ส่วน Use Cases ใช้แสดงการกระทำที่เกิดขึ้นจากผู้ใช้และการตอบสนองจากระบบ ความต้องการของระบบอาจอยู่ในรูปของ Use Cases เพื่อ การตรวจสอบติดตามที่ดีขึ้น ง่ายต่อการตรวจสอบตามฟังก์ชันความต้องการของระบบ ช่วยในการสร้างเอกสารคู่มือใช้ เป็นเครื่องมือที่ใช้ในการค้นหาคลาส Use-Cases are ไม่เหมาะสำหรับการค้นความต้องการของระบบประเภท non-functional requirements.

11/14/2018 Graphical Notation สัญลักษณ์ของ actor ถูกนำเสนอโดย stick man โดยมีการระบุชื่อของ actor ไว้ด้านล่างในรูปของ role เป็นหลัก สัญลักษณ์ของ use case ถูกนำเสนอโดย ellipse ที่มีการระบุชื่อของยูสเคสไว้ภายใน สัญลักษณ์เส้นตรงที่ลากระหว่าง actor กับ use case ใช้เพื่อแสดงให้เห็นว่า actor มีการติดต่อกับ use case ส่วนจุดเริ่มต้นการทำงานอาจระบุได้จากหัวลูกศร actor use case actor use case The actor initiate the communication. actor use case The use case initiate the communication. Both actor and use case can initiate the communication.

11/14/2018 What is an Actor? โดยปกติจะอยู่ภายนอกระบบ แต่ต้องการติดต่อกับระบบโดยมีการแลกเปลี่ยนข้อมูลกับระบบระบบ Actor อาจอยู่ในรูปของผู้ใช้หรือระบบอื่นที่เกี่ยวข้อง เป็น role ของผู้ใช้ที่ติดต่อกับระบบ  multiple roles per user หรือ multiple users per role คุณสมบัติของ actor Actor อาจใช้ได้กับหลาย ๆ Use Cases Use Case อาจติดต่อได้กับหลาย ๆ Actors การติดต่อกันสามารถแสดงโดยผ่านสัญลักษณ์เส้นตรงได้ An Actor

ความสัมพันธ์ระหว่าง Actor 11/14/2018 ความสัมพันธ์ระหว่าง Actor เนื่องจาก Actor คือคลาส ดังนั้นจึงสามารถมีความสัมพันธ์กันได้เช่นเดียวกับคลาส แต่สำหรับใน Use Case ไดอาแกรมความสัมพันธ์ที่ถูกระบุไว้เพียงอย่างเดียว คือ Generalization เพื่อใช้สำหรับแสดงการโต้ตอบระหว่าง Actor จำนวนหนึ่งเท่านั้น Generalization จะเกิดขึ้นเมื่อบทบาทของ Actor จะถูกกำหนดให้อยู่ในรูปของ Actor Super-class ซึ่งจะมีลักษณะเป็นการสืบทอดจาก Actor นั่นเอง Officer Loan Officer

Use Cases เป็นการนำเสนอการทำงานที่สมบูรณ์ ซึ่งเกิดจาก Actor 11/14/2018 Use Cases use-case name เป็นการนำเสนอการทำงานที่สมบูรณ์ ซึ่งเกิดจาก Actor Use Case ใน UML จะถูกกำหนดในรูปของจำนวนและลำดับของการกระทำที่เกิดขึ้นในระบบ คุณลักษณะของ Use Case Use Case จะเกิดขึ้นจากการกระทำของ Actor เสมอ โดย Actor จะทำหน้าที่ในการออกคำสั่งทั้งทางตรงหรือทางอ้อมเพื่อให้ระบบทำงานตาม Use case ที่ปรากฏ Use Case จะต้องมีความสมบูรณ์ในตัว โดยไม่ต้องมีการแยกรายละเอียดให้ลึกลงไปในระดับถัดไป Use Case จะต้องให้ค่ากับ Actor ไม่ว่าจะเป็นทางใดทางหนึ่งเสมอ

Use Case Names การกำหนดชื่อยูสเคสจะใช้รูปแบบดังต่อไปนี้: 11/14/2018 Use Case Names การกำหนดชื่อยูสเคสจะใช้รูปแบบดังต่อไปนี้: คำกริยาที่มีความหมายชัดเจน เช่น เข้าสู่ระบบ (Login) หรือคำกริยา + คำนามในรูปของออปเจค เช่น สั่งซื้อ (Place order) ร้องขอบริการ (Request service) เป็นต้น ระมัดระวังการใช้คำกริยาที่มีความหมายคลุมเครือ เช่น ทำ (do) หรือ กระบวนการ (process) เลือกใช้คำกริยาที่มีความหมายชัดเจน เช่น ค้นหา (search) อนุมัติ (approve) แจ้งให้ทราบ (notify) เป็นต้น ระมัดระวังคำประเภทที่เป็นเทคนิคเฉพาะทาง เช่น คำกริยาที่เกี่ยวข้องกับระบบฐานข้อมูล เช่น สร้าง (create) อ่าน (read) แก้ไข (update) ลบ(delete) หรือ แทรก (insert) เป็นต้น

How Actors and Use Cases Interact 11/14/2018 How Actors and Use Cases Interact ขั้นตอนถัดไปจะเป็นการกำหนดทิศทางและความสัมพันธ์ระหว่าง actor และ use case ทิศทางความสัมพันธ์โดยปกติจะเป็นสองทิศทาง กำหนดความสัมพันธ์ระหว่างแต่ละ actor และ-use-case กำหนดรายละเอียดอย่างย่อสำหรับความสัมพันธ์ระหว่างกัน Use Case Actor

ความสัมพันธ์ระหว่าง Use Case 11/14/2018 ความสัมพันธ์ระหว่าง Use Case Use Case หนึ่ง ๆ อาจมีการใช้งานร่วมกับ Use Case อื่น ๆ Generalization : เมื่อ Use case จำนวนหนึ่งมี Behavior ที่เหมือนกัน Behavior ดังกล่าวสามารถที่จะนำมาทำการโมเดลให้อยู่ในรูปของ Use case เดี่ยวที่ถูกนำไปใช้ (Uses) โดย Use case อื่น ๆ และเมื่อ Use case ถูกใช้ (use) กับ use case อื่น ๆ Use case ทั้งหมดจึงจะถูกใช้ร่วมกัน Extends : เป็นความสัมพันธ์แบบ generalization ในกรณีที่ Use Case หนึ่งๆ ขยาย (extends) Use Case อื่น โดยการเพิ่มการกระทำ (actions) Includes/Uses : เป็นความสัมพันธ์แบบ generalization ในกรณีที่ Use Case หนึ่งๆ เรียกใช้ (uses) Use Case อื่น ที่พิจารณาให้เป็นส่วนหนึ่งของ Use Case นั้นๆ

ความสัมพันธ์แบบ Generalisation 11/14/2018 ความสัมพันธ์แบบ Generalisation โดยปกติแล้ว Use case แบบนี้จะใช้ในสถานะการณ์ที่เป็นทางเลือกอย่างใดอย่างหนึ่ง เช่นในกรณีของการ make payment ซึ่งอาจจะ generalized use case ที่เป็น Pay Cash หรือ Pay by Credit Card เป็นกรณีของ use cases พิเศษที่เกิดขึ้น ข้อควรจำประการหนึ่งก็คือ use case หนึ่งในจำนวนทั้งหมดจะต้องถูกใช้รวมกับ Use case หลักให้การทำงานของ Use case หลักสมบูรณ์ Pay by Credit Card Pay by Cash Make Payment

ความสัมพันธ์แบบ Includes 11/14/2018 ความสัมพันธ์แบบ Includes use case ที่มีความสัมพันธ์แบบ include จะต้องทำงานร่วมกับ Use case ที่ถูกกำหนดไว้ก่อนเสมอ ความสัมพันธ์แบบ include จะถูกใช้เพื่อป้องกันความสับสนที่เกิดขึ้นจากการกำหนดรายละเอียดของการ flow แบบเดียวกันของ events ที่เกิดขึ้นหลายครั้ง ความสัมพันธ์แบบนี้ use case ย่อยจะถูกประมวลผลโดยเป็นส่วนหนึ่งของ use case หลัก นั่นคือ use case หลักจะไม่สามารถสมบูรณ์ได้หากไม่มีการประมวลผล use case ย่อย does Something Does portion of something <<include>> User

ความสัมพันธ์แบบ Extends 11/14/2018 ความสัมพันธ์แบบ Extends ความสัมพันธ์แบบ Extends จะใช้สำหรับการกำหนด behaviour ที่เป็นทางเลือกออกจาก behaviour ปกติที่เกิดขึ้น โดย use caseหลักจะมี behavior ที่มีความสัมพันธ์กับ use case อื่น ในทางอ้อมที่ถูกระบุโดย extending use case การประมวลผลจะกระทำที่ use case หลักโดยตรงได้ แต่อาจอยู่ภายใต้เงื่อนไขที่กำหนดหรือ extend มาจาก use case อื่น หากเงื่อนไขไม่ถูกต้อง การประมวลผลจะกระทำที่ Use case หลักเท่านั้น does Something Does another thing if condition is true <<Extend>> User

Use Case Relationship: Include & Extend 11/14/2018 Use Case Relationship: Include & Extend Borrow Books <<include>> <<include>> Borrower Check Library Fine Check Borrow Limit Borrow Books Borrower <<extend>> Print out Loan Receipt

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

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

Use Case Names การกำหนดชื่อของ use cases ควรใช้รูปแบบดังต่อไปนี้: 11/14/2018 Use Case Names การกำหนดชื่อของ use cases ควรใช้รูปแบบดังต่อไปนี้: action verb + [qualified] object. ตัวอย่างเช่น “Place order,” “Request product,” “Monitor network usage” , “Assign resources to project” ระมัดระวังคำกริยาในรูปของ do หรือ process ใช้คำกริยาที่มีความหมายชัดเจน เช่น “query”, “approve”, “generate” ระมัดระวังคำกริยาที่เป็นศัพท์เทคนิคที่ใช้กับฐานข้อมูล เช่น read, delete, get, หรือ insert . ส่วนที่เป็น “object” ของชื่อ use case สามารถเป็นคำนาม (เช่น inventory) หรือคำนามแบบ qualified noun (เช่น in-stock inventory) ชื่อของแต่ละ object จะถูกกำหนดเข้าสู่ domain model ต่อไป (เช่น class, entity, หรือ attribute)

How do you know what to put in the "System" box? 11/14/2018 How do you know what to put in the "System" box? Example: จากไดอาแกรมในลำดับถัดไปจะเป็นการนำเสนอ use cases สำหรับ camera Open Shutter Take Picture Photographer Flash Photographer Change Film Close Shutter Correct Incorrect

Examples: Ski resort information system 11/14/2018 Examples: Ski resort information system Users should be able to query weather and snow condition forecasts for a date they enter. The system should allow to book single or double rooms at the resort hotel “Skier’s Luck” online (with credit card). Visitors should be able to book one-day beginners courses on snowboards. There is only one course a day. The max. size of a course is 8 persons. The resort offers special courses for kids. In order to built courses with kids of same age, the customer has to enter the kid’s age. Canceling of course or room bookings are only possible up to 10 days ahead.

Examples: Ski resort information system 11/14/2018 Examples: Ski resort information system Users จะต้องสามารถตรวจสอบสภาพอากาศและหิมะล่วงหน้าสำหรับวันที่เข้าพักได้ ระบบจะยอมให้จองห้องเดี่ยวหรือห้องคู่ของรีสอร์ท “Skier’s Luck” แบบ online โดยใช้ credit card ผู้เข้าพักสามารถจองชั้นเรียน snowboards แบบ 1 วันสำหรับผู้เริ่มต้นได้ ชั้นเรียนจะเป็นแบบ 1 course ต่อวัน จำนวนผู้เรียนไม่เกิน 8 persons ต่อชั้น รีสอร์ตจะมี courses พิเศษสำหรับเด็ก ในการเข้า courses เด็กจะต้องอายุเท่ากัน ดังนั้นผู้เข้าพักจะต้องระบุอายุของเด็ก การยกเลิกการจองห้องพักและ course จะต้องแจ้งล่วงหน้าก่อน 10 วัน

11/14/2018

Example Use Case Diagram 11/14/2018 Example Use Case Diagram Query weather&snow forecast <<include>> Book room Enter personal info Visitor Book SB course <<include>> <<extend>> Cancel course Book kids’ SB course Cancel room

Example: literature reference management system 11/14/2018 Example: literature reference management system การจัดเก็บและรับค่า references ต่าง ๆ เช่น Title: The unified modeling language user guide Authors: G. Booch, J. Rumbaugh, I Jacobson Publisher: Addison Wesley Publication year: 1998 Small exercise: Draw a Use Case Diagram (at least two use cases) Describe use cases (at least one) Title: Software engineering in the Internet age Authors: F. Maurer, G. Kaiser Publisher: IEEE Publication year: 1998 Journal: IEEE Internet Computing Magazine Volume: 2 Issue: 5

Use Case Diagram: literature reference management 11/14/2018 Use Case Diagram: literature reference management Add reference Remove reference User Search reference List references

Use case: Add journal paper 11/14/2018 Use case: Add journal paper <<extend>> Add journal paper Add Reference Remove Reference User Search Reference List Reference Add journal paper: ถูกเพิ่มเติมเข้ามาในกรณีที่ paper เป็น journal ระบบจะต้องร้องขอ name, volume number และ issue number.

Use Cases and Scenarios 11/14/2018 Use Cases and Scenarios วิธีการหนึ่งที่ได้ผลดีในการอธิบายรายละเอียดของยูสเคสจะได้แก่ การใช้นิยามที่เรียกว่าซีนาริโอ (scenario) เพื่อใช้ในการอธิบายรายละเอียดพฤติกรรมการทำงานในสถานการณ์หนึ่ง ๆ โดยเฉพาะ ซีนาริโอจะถูกนำมาจัดทำในรูปของเอกสารเพื่อใช้สำหรับการนำเสนอลำดับของการติดต่อกันระหว่างแอคเตอร์และยูสเคส โดยเริ่มต้นจากการกระทำและต่อเนื่องไปจนกระทั่งเสร็จสิ้นสมบูรณ์ ซีนาริโอจะนำเสนอการติดต่อกันระหว่างยูสเคสกับแอคเตอร์เป็นสองรูปแบบได้แก่ การทำงานที่เกิดขึ้นเป็นปกติ การทำงานที่เป็นทางเลือกเมื่อมีความผิดพลาดเกิดขึ้น

The Scenario Methodology: 11/14/2018 The Scenario Methodology: ถูกเขียนขึ้นจากมุมมองของ actor โดยมีการกำหนดรายละเอียดเป็นขั้นตอนของระบบจากการวิเคราะห์ โดยใช้การกระทำที่เกิดขึ้นจริง เพื่อให้เป็นไปตาม Use Case Basic และ Alternatives flows จะถูกกำหนดรายละเอียดไว้ตามขั้นตอนที่เกิดขึ้นจริง Use Case และ Scenario จะต้องเป็นไปในแนวทางเดียวกัน และนำเสนอการดำเนินการทั้งทางด้านทฤษฎีและปฏิบัติตามมุมมองของ business requirements.

Alternative Flow ขั้นตอนที่เป็นการกำหนดทางเลือก (Alternative Courses) 11/14/2018 Alternative Flow ขั้นตอนที่เป็นการกำหนดทางเลือก (Alternative Courses)

รายชื่อแอคเตอร์ที่เกี่ยวข้อง 11/14/2018 Use Case Name: ชื่อยูสเคส Actors: รายชื่อแอคเตอร์ที่เกี่ยวข้อง Abstract เป็นการอธิบายรายละเอียดการทำงานของยูสเคสพอสังเขป Use Cases Referenced ยูสเคสที่เกิดขึ้นก่อนและหลังการทำงาน Basic Flow เป็นการดำเนินการปกติของกระบวนการที่ต้องกระทำทีละขั้นจนเสร็จสิ้น โดยไม่มีการระบุรายละเอียดในระดับลึกไปจนถึงวิธีการแต่อย่างใด ในขั้นตอนนี้จะเป็นเพียงการกำหนดว่าอะไรที่จะต้องทำบ้างเท่านั้น Alternate Flow ขั้นตอนการทำงานที่เป็นทางเลือก เมื่อเกิดความผิดพลาดขึ้นในขั้นตอนการดำเนินการปกติ Pre Condition เงื่อนไขก่อนการทำงาน เป็นสิ่งที่ถูกตั้งสมมุติฐานไว้ก่อนเริ่มต้นเข้าสู่การทำงานของยูสเคส Post Condition เงื่อนไขที่เกิดขึ้นหลังการทำงานของยูสเคส เป็นสิ่งที่คาดไว้เมื่อสิ้นสุดการดำเนินการของยูสเคส

ตัวอย่าง Cash Register 11/14/2018 ตัวอย่าง Cash Register Use Case: การซื้อสินค้า (Buy items) Actors: Customer, Cashier Type: Primary Description: เมื่อลูกค้า (Customer) มาที่เคาน์เตอร์พร้อมกับสินค้า (items) ที่ต้องการซื้อ (Purchase) พนักงานเก็บเงิน (Cashier) จะทำการบันทึกรายการสั่งซื้อ (purchase items) และทำหน้าที่เก็บเงิน ( collects payment) ไปพร้อมกัน เมื่อเสร็จสิ้นขั้นตอนดังกล่าวแล้ว ลูกค้า ( Customer) จะออกไปพร้อมกับสินค้า ( items) ที่ต้องการ

A simple use case diagram 11/14/2018 A simple use case diagram Buy Items with Cash Cashier Customer

ตัวอย่างของ Use Case Narrative 1 11/14/2018 ตัวอย่างของ Use Case Narrative 1 Use Case: การซื้อสินค้าด้วยเงินสด (Buy Items with Cash) Actors: Customer (เป็นจุดเริ่มต้น), Cashier Purpose: กำหนดการทำงานของการขายสินค้าด้วยเงินสด Description: เมื่อลูกค้า (Customer) มาที่เคาน์เตอร์พร้อมกับสินค้า (items) ที่ต้องการซื้อ (Purchase) พนักงานเก็บเงิน (Cashier) จะทำการบันทึกรายการสั่งซื้อ (purchase items) และทำหน้าที่เก็บเงิน ( collects payment) ไปพร้อมกัน เมื่อเสร็จสิ้นขั้นตอนดังกล่าวแล้ว ลูกค้า ( Customer) จะออกไปพร้อมกับสินค้า ( items) ที่ต้องการ Basic Flow:

ตัวอย่างของ Use Case Narrative 2 11/14/2018 ตัวอย่างของ Use Case Narrative 2 Basic Flow : พนักงานป้อนรหัสสินค้าที่ลูกค้าเลือกไว้ ระบบแสดงราคาต่อหน่วยของสินค้า พนักงานป้อนจำนวนสินค้าจนครบจำนวน พนักงานบันทึกรายการสั่งซื้อสิ้นค้า และปิดการขาย ระบบคำนวณค่าใช้จ่ายจากรายการสั่งซื้อ ระบบพิมพ์ใบเสร็จให้แก่ลูกค้า Alternative Flow : หากพนักงานป้อนข้อมูลผิดพลาด สามารถแก้ไขได้โดยเลือกรายการแก้ไข PreCondition PostCondition สินค้าที่ชำรุดสามารถคืนได้ภายใน 3 วันพร้อมใบเสร็จ

คำแนะนำในการสร้างยูสเคสไดอาแกรม 11/14/2018 คำแนะนำในการสร้างยูสเคสไดอาแกรม ขั้นตอนที่ 1: กำหนดว่าใครคือผู้ใช้ระบบโดยตรงเพื่อกำหนดเป็นแอคเตอร์ แอคเตอร์จะถูกกำหนดขึ้นตามหน้าที่หรือบทบาทในการทำงานของผู้ใช้ระบบ หรือระบบอื่น ๆ ที่มีความเกี่ยวข้องกัน  ขั้นตอนที่ 2: พิจารณาเลือกแอคเตอร์จากขั้นตอนที่ 1 ในกรณีที่การค้นหาแอคเตอร์จากขั้นตอนแรกมีจำนวนมาก ให้พิจารณากำหนดแอคเตอร์ที่แท้จริงของระบบ การกำหนดแอคเตอร์ในลักษณะนี้ควรพิจารณาว่าแอคเตอร์ใดที่ก่อให้เกิดผลกระทบต่อฟังก์ชันการทำงานที่กำหนดไว้ ในกรณีที่แอคเตอร์ไม่มีผลต่อฟังก์ชันการทำงานของระบบ แอคเตอร์ลักษณะนี้จะถูกตัดออกไปเสมอ

คำแนะนำในการสร้างยูสเคสไดอาแกรม 11/14/2018 คำแนะนำในการสร้างยูสเคสไดอาแกรม ขั้นตอนที่ 3: กำหนดว่าอะไรเป็นสิ่งที่แอคเตอร์ต้องการในการใช้งานของระบบ สิ่งต่าง ๆ ที่แอคเตอร์ต้องการกระทำกับระบบจะกลายมาเป็นยูสเคส  และถูกนำมากำหนดเป็นเป้าหมาย การกำหนดยูสเคสอาจใช้ข้อมูลจากความต้องการของระบบโดยอาศัยมุมมองของแอคเตอร์เป็นหลัก การกำหนดทุก ๆ สิ่งที่ทุก ๆ แอคเตอร์มีการกระทำโดยการติดต่อกับระบบ จะได้ผลลัพธ์ออกมาเป็นการทำงานที่สมบูรณ์ของระบบ  ขั้นตอนที่ 4: สำหรับแต่ละยูสเคสให้ทำการกำหนดว่าการทำงานใดที่เกิดขึ้นเป็นปกติเมื่อแอคเตอร์มีการใช้งานกับระบบ ซึ่งโดยปกติแล้วแต่ละยูสเคสจะประกอบไปด้วยขั้นตอนการทำงานแบบปกติและขั้นตอนการทำงานที่เป็นทางเลือก

คำแนะนำในการสร้างยูสเคสไดอาแกรม 11/14/2018 คำแนะนำในการสร้างยูสเคสไดอาแกรม ขั้นตอนที่ 5: อธิบายการทำงานเฉพาะรายละเอียดการทำงานที่ถูกต้องในแต่ละขั้นตอนตั้งแต่เริ่มต้นจนสิ้นสุดการทำงานภายในยูสเคส ขั้นตอนที่ 6: ขั้นตอนต่อไปจะเป็นการกำหนดรายละเอียดการทำงานที่เป็นทางเลือก ซึ่งเป็นการทำงานที่เกิดขึ้นเมื่อการทำงานแบบปกติมีความผิดพลาดหรือไม่สามารถดำเนินการต่อไปได้ ขั้นตอนที่ 7 : ทบทวนรายละเอียดการทำงานของแต่ละยูสเคส ในกรณีที่มีขั้นตอนการทำงานหรือความซับซ้อนเกิดขึ้นมากเกินไปควรพิจารณาแยกยูสเคสดังกล่าวออกเป็นยูสเคสย่อย ๆ เพื่อให้ง่ายต่อการทำงานในลำดับถัดไป นอกจากนั้นควรพิจารณาถึงความสัมพันธ์ที่เกิดขึ้นในแต่ละยูสเคส เพื่อกำหนดชนิดของความสัมพันธ์ที่ถูกต้องต่อไป ขั้นตอนที่ 8 : พิจารณาทำซ้ำในขั้นตอนที่ 2 - 7 สำหรับแต่ละแอคเตอร์

Step: Evaluate Use-Case Model 11/14/2018 Step: Evaluate Use-Case Model use cases ที่จำเป็นในการทำงานได้ถูกระบุไว้แล้ว ตรวจสอบ use-case model ครอบคลุม functional requirements หรือไม่ use cases ที่ไม่จำเป็นในการทำงานได้ถูกระบุไว้แล้ว Use cases ที่มีการทำงานน้อยเกินไป Use cases ที่ควรจะเป็นส่วนหนึ่งของ use cases ที่ใหญ่กว่า ตรวจสอบการทำงานของแต่ละ use case ควรทำงานได้อย่างถูกต้องตามลำดับ จำนวน use case ที่เหมาะสมไม่ควรเกิน 7 บวกลบ 1

Online Shopping Cart รายละเอียดโดยย่อ 11/14/2018 Online Shopping Cart รายละเอียดโดยย่อ ระบบสั่งซื้อสินค้าผ่านตะกร้าออนไลน์เป็นการสั่งซื้อสินค้าผ่านระบบอินเตอร์เน็ต โดยมีการชำระเงินผ่านบัตรเครดิตเป็นหลัก โดยผู้ใช้ระบบต้องผ่านการลงทะเบียนก่อนจึงสามารถสั่งซื้อสินค้าได้ รูปแบบของการลงทะเบียนจะเป็นการกรอกแบบฟอร์มข้อมูลที่เกี่ยวข้องกับผู้ใช้โดยตรง เมื่อผู้ใช้กรอกข้อมูลครบถ้วนและถูกต้องแล้ว ระบบจะสร้างชื่อผู้ใช้เพื่อนำไปใช้ในการ ลอกอินต่อไป ระบบสั่งซื้อสินค้าผ่านตะกร้าออนไลน์มีการจัดเก็บข้อมูลแยกตามหมวดหมู่ของสินค้า ส่วนการนำเสนอรายละเอียดของสินค้าประกอบไปด้วย รหัสสินค้า ชื่อสินค้า ราคาต่อหน่วย เป็นต้น นอกจากนั้นแล้วผู้ใช้ยังสามารถค้นหาสินค้า ที่ต้องการได้ โดยการระบุคีย์เวิร์ดเพื่อเพิ่มความสะดวกในการเลือกซื้อสินค้าที่ต้องการได้อย่างรวดเร็ว

Online Shopping Cart รายละเอียดโดยย่อ 11/14/2018 Online Shopping Cart รายละเอียดโดยย่อ ผู้ใช้สามารถเลือกสั่งซื้อสินค้าได้จากรายการสินค้าในหมวดที่เลือกไว้ โดยการเลือกที่ตะกร้าสินค้า ระบบจะเลือกสินค้ารายการดังกล่าวเข้าสู่ตะกร้าสั่งซื้อสินค้าที่มีการแสดงรายละเอียดของสินค้า พร้อมทั้งคำนวณค่าใช้จ่ายต่าง ๆ เช่น ราคารวมแต่ละรายการ ราคารวมทั้งสิ้น และภาษี ราคารวม ภาษี เป็นต้น ในขั้นตอนนี้ผู้ใช้สามารถแก้ไขจำนวนสินค้าภายในตะกร้าสินค้าที่ได้มีการสั่งซื้อไปแล้ว หรือลบสินค้าที่ไม่ต้องการออกจากตะกร้าสินค้าได้ โดยระบบจะคำนวณค่าใช้จ่ายต่าง ๆ ทุกครั้งที่มีการเปลี่ยนแปลงเกิดขึ้นภายในตะกร้าสินค้า

Online Shopping Cart รายละเอียดโดยย่อ 11/14/2018 Online Shopping Cart รายละเอียดโดยย่อ เมื่อผู้ใช้เสร็จสิ้นการเลือกสินค้าเข้าสู่ตะกร้าสินค้า ขั้นตอนต่อไปจะเป็นการชำระงินด้วยบัตรเครดิต ซึ่งต้องผ่านการลอกอินก่อนเสมอ ผู้ใช้ต้องกรอกแบบฟอร์มที่เกี่ยวข้องกับข้อมูลบัตรเครดิต ซึ่งได้แก่ ชนิดของบัตรเครดิต หมายเลขบัตร ชื่อเจ้าของบัตร และวันหมดอายุ เพื่อให้ระบบส่งข้อมูล การชำระเงินไปยังหน่วยงานตรวจสอบสถานะบัตรเครดิตภายนอก เมื่อการตรวจสอบสถานะบัตรเครดิตถูกต้อง ขั้นตอนของสั่งซื้อสินค้าถือว่าเสร็จสิ้นลงอย่างสมบูรณ์ นอกจากนั้นแล้วเพื่อความสะดวกในการใช้งานของระบบ ผู้ใช้สามารถตรวจสอบสถานของการสั่งซื้อสินค้าได้โดยผ่านการลอกอิน ระบบจะแสดงข้อมูลการสั่งซื้อทั้งหมดที่ลูกค้าเคยสั่งซื้อไว้โดยผู้ใช้สามารถตรวจสอบรายการสั่งซื้อที่ต้องการได้ โดยระบบจะแสดงรายการสินค้าพร้อมทั้งรายละเอียดต่าง ๆ รวมไปถึงสถานะของการจัดส่ง เป็นต้น

ขั้นตอนแรก การกำหนดแอคเตอร์ 11/14/2018 ขั้นตอนแรก การกำหนดแอคเตอร์ เมื่อพิจารณาถึงความต้องการของระบบแล้วพบว่า ผู้ใช้ระบบมีด้วยกัน 4 ประเภท ผู้ใช้ทั่วไป (User) ที่ต้องการเข้าชมสินค้าภายในระบบ ลูกค้า (Customer) ที่ต้องการสั่งซื้อสินค้าภายในระบบ หน่วยงานตรวจสอบสถานะของบัตรเครดิต (Card Authorization) ระบบ ตรวจสอบสต็อกสินค้า (Check Inventory Status)

ขั้นตอนที่สอง การกำหนดยูสเคส 11/14/2018 ขั้นตอนที่สอง การกำหนดยูสเคส ระบบสั่งซื้อสินค้าผ่านตะกร้าออนไลน์ประกอบไปด้วยยูสเคสดังนี้ เลือกประเภทสินค้า (Browse Product ) เข้าสู่ระบบ (Login) ลงทะเบียน (Register ) เลือกสินค้าเข้าสู่รถเข็น (Add to Shopping Cart) ตรวจสอบยอดรวมและราคาสินค้าที่ปรากฏในรถเข็น (View Shopping Cart) แก้ไขสินค้าในรถเข็น (Update Shopping Cart) จัดการข้อมูลก่อนการจัดส่งสินค้า (Check Out) ตรวจสอบสถานะของสินค้า (View Order Status)

ขั้นตอนที่สอง การกำหนดยูสเคส 11/14/2018 ขั้นตอนที่สอง การกำหนดยูสเคส Browse Product Register Login Add Shopping Cart View Shopping Cart Update Shopping Cart View Order Status Check Out

ขั้นตอนที่ 3 กำหนดความสัมพันธ์ระหว่างยูสเคส 11/14/2018 ขั้นตอนที่ 3 กำหนดความสัมพันธ์ระหว่างยูสเคส ผู้ใช้ระบบสามารถค้นหารายละเอียดของสินค้าได้ซึ่งสามารถแสดงความสัมพันธ์ระหว่างแอคเตอร์และยูสเคสได้ดังนี้ หากต้องการสั่งซื้อ ลูกค้าต้องทำการลอกอินเพื่อเข้าสู่ระบบการสั่งซื้อ ในกรณีที่ยังไม่ได้สมัครเป็นสมาชิกเพื่อใช้สำหรับการล็อกอินเข้าสู่ระบบได้โดยตรง ความสัมพันธ์ของยูสเคสลอกอินและลงทะเบียนเป็นแบบ Extend

ขั้นตอนที่ 3 กำหนดความสัมพันธ์ระหว่างยูสเคส 11/14/2018 ขั้นตอนที่ 3 กำหนดความสัมพันธ์ระหว่างยูสเคส หลังจากที่ลูกค้าล็อกอินเข้าสู่ระบบแล้ว ลูกค้าสามารถเลือกรายการสินค้าที่ต้องการสำหรับการสั่งซื้อได้ ลูกค้าสามารถตรวจสอบความถูกต้องของการสั่งซื้อที่ผ่านไปแล้ว จากยูสเคส View Shopping Cart และสามารถแก้ไขข้อมูลสินค้าที่ปรากฏในรถเข็นได้ ดังนั้นยูสเคส View Shopping Cart และ Update Shopping Cart นี้จึงเป็นความสัมพันธ์แบบ Extend Customer View Shopping Cart Update Shopping Cart <<extend>>

ขั้นตอนที่ 3 กำหนดความสัมพันธ์ระหว่างยูสเคส 11/14/2018 ขั้นตอนที่ 3 กำหนดความสัมพันธ์ระหว่างยูสเคส ทุกครั้งที่มีการเรียกใช้ยูสเคส View Shopping Cart จำเป็นต้องชำระเงิน (Check Out) ก่อนเสมอ ขั้นตอนนี้เป็นการระบุรายละเอียดของบัตรเครดิต รวมไปถึงสถานที่จัดส่งสินค้า เพื่อให้ข้อมูลแก่แอกเตอร์ Check Inverntory Status และ Card Authorization ดำเนินงานต่อไป ความสัมพันธ์ระหว่างยูสเคส View Shopping Cart และ Check Out เป็นความสัมพันธ์ที่มีความเกี่ยวเนื่องกันโดยตรงดังนั้นความสัมพันธ์ในลักษณะนี้จึงกำหนดให้เป็นแบบรวม

ขั้นตอนที่ 3 กำหนดความสัมพันธ์ระหว่างยูสเคส 11/14/2018 ขั้นตอนที่ 3 กำหนดความสัมพันธ์ระหว่างยูสเคส ส่วนความสัมพันธ์ลำดับสุดท้ายจะเป็นความสัมพันธ์ระหว่างแอกเตอร์ลูกค้ากับยูสเคสตรวจสอบสถานะของสินค้า (View Order Status) ซึ่งทำหน้าที่ในการตรวจสอบการสั่งซื้อของลูกค้า เฉพาะในกรณีที่ยังไม่ได้รับสินค้าตามระยะเวลากำหนด

ยูสเคสไดอาแกรม 11/14/2018 Browse Product User Register Login Add to Shopping Cart View Order Status Card Authorization Customer Check Out Check Inventory Status View Shopping Cart Update Shopping Cart <<extend>> <<include>>

รายละเอียดยูสเคส Project Name: ชื่อโปรเจค Use Case Name: ชื่อยูสเคส 11/14/2018 รายละเอียดยูสเคส Project Name: ชื่อโปรเจค Use Case Name: ชื่อยูสเคส Actors: รายชื่อแอคเตอร์ที่เกี่ยวข้อง Use Cases Referenced ยูสเคสที่เกิดขึ้นก่อนและหลังการทำงาน Basic Flow 1 –ยูสเคสเริ่มต้นเมื่อลูกค้าเลือก..... 10 – ยูสเคสสิ้นสุดการทำงาน Alternate Flow ขั้นตอนการทำงานที่เป็นทางเลือก เมื่อเกิดความผิดพลาดขึ้นในขั้นตอนการดำเนินการปกติ Pre Condition เงื่อนไขก่อนการทำงาน เป็นสิ่งที่ถูกตั้งสมมุติฐานไว้ก่อนเริ่มต้นเข้าสู่การทำงานของยูสเคส Post Condition เงื่อนไขที่เกิดขึ้นหลังการทำงานของยูสเคส เป็นสิ่งที่คาดไว้เมื่อสิ้นสุดการดำเนินการของยูสเคส

ยูสเคส : Browse Product 11/14/2018 ยูสเคส : Browse Product เมื่อลูกค้าเลือก Browse Product จากหน้าจอหลัก ระบบจะแสดงประเภท (Category)ของสินค้าทั้งหมด เมื่อผู้ใช้(User) หรือลูกค้า (Customer) เลือกประเภทสินค้าที่ต้องการ รายละเอียดของรายการสินค้าทั้งหมดจะถูกนำเสนอบนหน้าจอ โดยประกอบไปด้วย รหัสสินค้า(productId) ชื่อสิน ค้า(productName) ราคาต่อหน่วย(pricePerUnit) จำนวนที่ต้องสั่งซื้อเป็น อย่างน้อย(minQty) เป็นต้น

1 –ยูสเคสเริ่มต้นเมื่อผู้ใช้เลือกหน้าจอ Browse Product 11/14/2018 Project: Shopping Cart Use Case Name: Browse Product Actors: User Use case Referenced - Basic Flow 1 –ยูสเคสเริ่มต้นเมื่อผู้ใช้เลือกหน้าจอ Browse Product 2 –ระบบรับค่าจากหน้าจอ 3 -ระบบค้นหาข้อมูลประเภทสินค้าจากฐานข้อมูล 4 -ระบบคืนค่าการค้นหา 5 -ระบบแสดงประเภทสินค้าทั้งหมดบนหน้าจอ 6 -ผู้ใช้เลือกสินค้าที่ต้องการดูข้อมูลในหน้าจอหลัก 7 -ระบบรับค่าสินค้าที่ลูกค้าเลือก 8 -ระบบค้นหาข้อมูลสินค้าตามประเภทที่ผู้ใช้เลือก 9 -ระบบคืนค่าการค้นหาข้อมูลรายละเอียดสินค้า 10 -ระบบแสดงข้อมูลรายละเอียดสินค้าทั้งหมด 11 –ยูสเคสสิ้นสุดการทำงาน Alternate Flow Pre Condition(s): Post Condition(s):

11/14/2018 ยูสเคส : Login ในหน้าจอลอกอิน(Login)นี้ ลูกค้า (Customer) กรอกข้อมูลการลอกอิน(Login)ได้แก่ ฟิลด์ชื่อผู้ใช้ (username) และ รหัสผ่าน (password) หลังจากนั้นระบบจะยอมให้ลูกค้าเข้าสู่ระบบการทำงานได้สองฟังก์ชันคือ ชำระเงินของรายการที่สั่งซื้อไว้(CheckOut) ดูข้อมูลที่เคยสั่งซื้อไปทั้งหมดและสถานการสั่งซื้อ(View Order Status) ถ้าผลการตรวจสอบผิดพลาดระบบจะกลับสู่หน้าจอลอกอิน (Login) อีกครั้ง เพื่อให้ผู้ใช้ลอกอินใหม่เสมอ

1 -ยูสเคสเริ่มต้นเมื่อผู้ใช้เข้าสู่หน้าจอลอกอิน 11/14/2018 Project: Shopping Cart Use Case Name: Login Actors: Customer Use case Referenced Check Out Basic Flow 1 -ยูสเคสเริ่มต้นเมื่อผู้ใช้เข้าสู่หน้าจอลอกอิน 2 -ผู้ใช้ระบุชื่อผู้ใช้และรหัสผ่าน 3 -ระบบตรวจสอบความครบถ้วนของข้อมูลจากScript 4 -ระบบรับค่าชื่อผู้ใช้และรหัสผ่าน 5 -ระบบค้นหาชื่อผู้ใช้และรหัสผ่านภายในฐานข้อมูล 6 -ระบบคืนค่าสถานการตรวจสอบจากฐานข้อมูล 7 - ระบบเช็คสถานการคืนค่า 8 –ระบบยอมให้ลูกค้าเข้าสู่ระบบดังนี้ .1 –การชำระเงิน .2 -ดูข้อมูลที่เคยสั่งซื้อไปทั้งหมด 9 –ยูสเคสสิ้นสุดการทำงาน Alternate Flow 3.1 -ในกรณีที่ลูกค้ากรอกข้อมูลไม่ครบระบบจะแสดงข้อความ “กรุณากรอกข้อมูลให้ครบ” 7.1 -ในกรณีที่การตรวจสอบชื่อผู้ใช้และรหัสผ่านไม่ถูกต้องระบบจะแสดงข้อความ“ข้อมูลผิดพลาด กรุณาตรวจสอบอีกครั้ง” และกลับสู่หน้าจอลอกอิน Pre Condition(s): ลูกค้าต้องผ่านการลงทะเบียนก่อนเสมอ Post Condition(s): สามารถเข้าใช้งานของระบบสั่งซื้อสินค้าผ่าน Shopping Cart

ยูสเคส : Add to Shopping Cart 11/14/2018 ยูสเคส : Add to Shopping Cart ภายหลังจากผู้ใช้เลือก Browse Product เพื่อแสดงข้อมูลสินค้าแต่ละรายการจากประเภทของสินค้าที่เลือกไว้ ขั้นตอนต่อไปเป็นการเลือกสั่งซื้อสินค้าผ่าน add Shoppong Cart ซึ่งปรากฏอยู่ในสินค้าแต่ละรายการ เพื่อให้ระบบสามารถเก็บข้อมูลของการสั่งซื้อที่ประกอบไปด้วย รหัสสินค้า(productId) ชื่อสินค้า(productName) ราคาต่อหน่วย(pricePerUnit) จำนวนสั่งซื้อ(qty) นอกจากนั้นระบบยังคำนวณค่าใช้จ่ายต่าง ๆ ได้แก่ ราคารวมแต่ละรายการ(sumPrice) ราคารวมทั้งสิ้น(totalPrice) และภาษี(tax) ในกรณีที่ลูกค้าต้องการเลือกซื้อสินค้าเพิ่มเติมจะสามารถเลือกซื้อสินค้าได้ตามต้องการ

1 - ยูสเคสเริ่มต้นเมื่อลูกค้าเลือก Add Shopping Cart 11/14/2018 Project: Shopping Cart Use Case Name: Add to Shopping Cart Actors: Customer Use case Referenced - Basic Flow 1 - ยูสเคสเริ่มต้นเมื่อลูกค้าเลือก Add Shopping Cart 2 -ระบบรับข้อมูลสินค้าที่ผู้ใช้เลือก 3 –ระบบค้นหารายละเอียดสินค้าในระบบฐานข้อมูล 4 -ระบบคืนค่ารายละเอียดสินค้า 5 –ระบบคำนวณค่าใช้จ่ายราคารวมแต่ละรายการรวมถึงราคารวมทั้งสิ้น 6 -ระบบแสดงข้อมูลการสั่งซื้อตลอดจนค่าใช้จ่ายทั้งหมดที่ลูกค้าเลือก 7 –ยูสเคสสิ้นสุดการทำงาน Alternate Flow 2.1 -ในกรณีที่ลูกค้าต้องการเลือกซื้อสินค้าเพิ่มเติม การทำงานจะต้องทำซ้ำในข้อที่ 2 ถึง 4 พร้อมกับคำนวณราคารวมทั้งสิ้นใหม่ทุกครั้งที่มีการซื้อสินค้าเพิ่มเติมเสมอ Pre Condition(s): ลูกค้าต้องเลือกซื้อสินค้าก่อนเสมอ Post Condition(s): บันทึกข้อมูลสินค้าที่ลูกค้าเลือก