Transcript A Use Case Diagram

Use Case Diagram
อ.วิวฒ
ั น์ ชินนาทศิริกลุ
Use Case Model




แบบจำลองควำมต้องกำรของระบบ ที่ นำเสนอ functional
requirement ของระบบโดยรวม จำกมุมมองของผูใ้ ช้ภำยนอก หรือ
ระบบภำยนอก
ระบุพฤติกรรม หรือหน้ำที่กำรทำงำนของระบบ (เน้น “what”) ที่
ระบบต้องมี
ใช้ในกำรทดสอบ และตรวจสอบ โครงสร้ำง และหน้ำที่กำรทำงำนของ
ระบบ
ใน UML ระบุเป็ น Use Case Description (Text) หรือ
Use Case Diagram(Diagram)
Use Case Example

Stock
Exchange
Market
Place Order
Name: กำรส่งรำยกำรซื้ อขำยหลักทรัพย์ (Place Order)
 Main flow of events:
1. Trader ป้อนชื่อ และรหัสของ client
Trader
2. System ตรวจสอบ (Validate) ชื่อ รหัส และ credit ของ client
3. Trader ป้อนรหัสหลักทรัพย์ จำนวนหลักทรัพย์ และรำคำหลักทรัพย์ ที่
Client ต้องกำรซื้ อขำย
4. System ตรวจสอบเงื่อนไขรำคำของหลักทรัพย์
6. System ส่ง order ให้กบ
ั ตลำดหลักทรัพย์
7. System เก็บหมำยเลข order ที่ได้รบ
ั จำกตลำดหลักทรัพย์
8. System แจ้งให้ Trader ทรำบ
Use Case Diagram

ประกอบด้วย




- ควำมสำมำรถ/หน้ำที่ของระบบ
Actor - ผูก้ ระทำ/ผูใ้ ช้งำน Use Case นั้นๆ
Relationship - เส้นแสดงควำมสัมพันธ์ระหว่ำง Use Case กับ Actor
System - ระบบที่กำลังพัฒนำ
Use Case
Use Case Modeling : Core Elements
Construct Description
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.
Syntax
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
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


สถำนกำรณ์ หรือตัวอย่ำงเรื่องรำวกำรใช้งำนระบบ
Scenario จัดเป็ น instance ของ use case
Actors

Actor หมำยถึง someone หรือ something ที่มีกำรปฏิสม
ั พันธ์ โต้ตอบกับ

ระบบ
 สิ่งใดก็ตำมที่มีควำมต้องกำรในกำรแลกเปลี่ยน information กับระบบ หรือ
สิ่งใดก็ตำมที่อยูภ่ ำยนอกระบบ และมีกำรใช้งำน Use Case ของระบบ
 กำหนดบทบำทหน้ำที่ของผูใ้ ช้ระบบ
 กำหนดกำรเชี่อมโยงกับระบบอื่นๆ ภำยนอก
ตัวอย่ำงของ Actors


Customer -- maintain their account
Cashier -- verify withdrawal amount
Customer Cashier
ประเภทของ actors
1.
Primary actor
เป็ น actors ที่มีเป้ำหมำยใช้บริกำรระบบ
เพื่อให้งำนตัวเองสำเร็จตำมบทบำทในกระบวนงำนนั้นๆ
2. Supporting actor
จัดเตรียมบริกำรใดๆ ให้ เช่นระบบ
คอมพิวเตอร์
3. Offstage actor
สนใจในพฤติกรรมของ use case นั้น แต่ไม่ใช่
primary actors และ supporting actor
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 ไม่จำเป็ นต้องอธิบำยรำยละเอียดของ Association เนื่ องจำกไม่มี
กำร Implement ส่วนของ Actor ในระบบ

System


อำจหมำยถึง Software system, business, hardware,..
วัตถุประสงค์ใน use-case modeling เพื่อระบุขอบเขตของระบบที่กำลัง
พัฒนำ (system boundary)
ใช้สญ
ั ลักษณ์
System
Relationships between Use Case

extends : กรณีที่ Use Case หนึ่ งๆ ขยำย (extends) Use Case อื่น
โดยกำรเพิ่มกำรกระทำ (actions) หรือ use case หนึ่ งมีผลกำรทำงำน
ตำมปกติของอีก use case หนึ่ ง เช่น กรณีถอนเงินจำกตู้ ATM ถ้ำบัตรเสียก็จะ
ทำให้กำรถอนเงินล้มเหลว

includes หรือ uses : กรณีที่ Use Case หนึ่ งๆ เรียกใช้ (uses) Use
Case อื่น คล้ำยๆกับกำรเรียกใช้งำนโปรแกรมย่อย โดยโปรแกรมหลัก
ตัวอย่าง include relationship

กำรตรวจสอบ user ที่เข้ำมำในระบบคอมพิวเตอร์ ต้องมีกำรตรวจสอบรหัสผ่ำน
รวมอยูด่ ว้ ย โดย Actor ของระบบนี้ คือ ผูด้ แู ลระบบ
use case ของระบบคือ
- กำรตรวจสอบ user (Validate user)
- กำรตรวจสอบรหัสผ่ำน (Check password)

actor ของระบบคือ

- ผูด้ แู ลระบบ (System Administrator)
Validate Users
System
Administrator
<<include>>
Check Password
User Authorization
ตัวอย่าง extend relationship



ขณะที่รบั โทรศัพท์ปกติ หำกมีสำยเรียกซ้อนเข้ำมำ อำจทำให้ตอ้ งมีกำรรับสำย
เรียกซ้อนก่อน ซึ่งทำให้กำรรับสำยโทรศัพท์ตำมปกติตอ้ งชะงักชัว่ ครำว
use case ของระบบคือ
 กำรรับโทรศัพท์
 กำรรับสำยเรียกซ้อน
actor ของระบบคือ
 ผูร
้ บั โทรศัพท์
<<extends>>
รับโทรศัพท์
รับสำยเรียกซ้อน
ผูร้ บั โทรศัพท์
กำรรับโทรศัพท์
Comparing extends/uses

extend
 ใช้แยกควำมแตกต่ำงของ Use Case
 actors ที่เกี่ยวข้องมักเป็ นคนกระทำ Use case และ Use Case ที่
extend ทั้งหมด
 actor มักเชื่อมต่อกับ “base” Use Case

include/use
 ใช้ extract พฤติกรรมร่วม
 มักไม่มี actor เกี่ยวข้องโดยตรงกับ Use Case ที่มีพฤติกรรมร่วม
ตัวอย่าง Use Case การถอนเงิน
ATM Subsystem: Withdrawal
Enter Password
Check Balance
Card Holder
Withdraw Cash
Get Slip
ตัวอย่าง Use Case Bank Process
deposit
withdraw
customer
transfer
teller
statement
add
interest
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
A Use Case Diagram
Deposit
Transfe
r
Validate
Account
Customer
<<include>>
<<include>>
Withdraw
<<include>>
Balance
Checking
Verify
withdrawa
l
Bank
Teller
ขั้นตอนการสร้าง Use Case Diagram




ค้นหำ Actor ค้นหำได้จำก “กลุ่มผูใ้ ช้ระบบ”
ค้นหำ Use Case ค้นหำได้จำก ควำมรับผิดชอบหรือหน้ำที่ของระบบ
สร้ำงควำมสัมพันธ์ ระหว่ำง Use Case กับ Use Case และ
ระหว่ำง Actor กับ Use Case และระหว่ำง Actor กับ Actor
เขียนคำอธิบำย Use Case (เงือนไขต่ำงๆ)
ตัวอย่างการวิเคราะห์ระบบสั ่งซื้อสินค้าออนไลน์


ระบบสัง่ ซื้ อสินค้ำออนไลน์ เป็ นกำรสัง่ ซื้ อสินค้ำผ่ำนระบบอินเทอร์เน็ ต โดยมีกำรชำระเงินผ่ำนบัตร
เครดิตเป็ นหลัก โดยปกติแล้วผูใ้ ช้ระบบต้องผ่ำนกำรลงทะเบียนก่อนจึงสำมำรสัง่ ซื้ อสินค้ำได้รปู แบบ
กำรลงทะเบียนจะเป็ นกำรกรอกแบบฟอร์มข้อมูลที่เกี่ยวข้องกับผูใ้ ช้ ได้แก่ ชื่อ นำมสกุล เพศ อีเมล์
วันเดือนปี เกิด อำชีพ ที่อยู่ เบอร์โทรศัพท์ติดต่อ ชื่อผูใ้ ช้งำนและ รหัสผ่ำน เป็ นต้น เมื่อผูใ้ ช้กรอก
ข้อมูลครบถ้วนและถูกต้องแล้ว โดยชื่อผูใ้ ช้งำนจะต้องไม่ซ้ำกับในระบบเพื่อใช้ลอกอินเข้ำระบบต่อไป
ระบบสัง่ ซื้ อสินค้ำออนไลน์มีกำรจัดเก็บข้อมูลแยกตำมหมวดหมู่ของสินค้ำ ส่วนกำรนำเสนอ
รำยละเอียดของสินค้ำประกอบด้วย รหัสสินค้ำ ชื่อสินค้ำ รำคำต่อหน่ วย เป็ นต้น นอกจำกนั้นแล้วผูใ้ ช้
ยังสำมำรถค้นหำสินค้ำที่ตอ้ งกำรได้โดยกำรระบุคียเ์ วิรด์ เพื่อเพิ่มควำมสะดวกในกำรเลือกซื้ อสินค้ำที่
ต้องกำรได้อย่ำงรวดเร็ว
ผูใ้ ช้สำมำรถเลือกสัง่ ซื้ อสินค้ำได้จำกรำยกำรสินค้ำในหมวดที่เลือกไว้โดยกำรคลิกที่ ตระกร้ำ สินค้ำ
ระบบจะเลือกสินค้ำรำยกำรดังกล่ำวเข้ำสู่ตระกร้ำสัง่ ซื้ อสินค้ำที่มีกำรแสดงรำยละเอียดของสินค้ำ
พร้อมทั้งคำนวณค่ำใช้จำ่ ยต่ำงๆ เช่น รำคำรวมแต่ละรำยกำร รำคำรวมทั้งสิ้ น ภำษี และรำคำรวม
ภำษี เป็ นต้น ในขั้นตอนนี้ ผูใ้ ช้สำมำรถแก้ไขจำนวนสินค้ำภำยในตระกร้ำสินค้ำที่ได้มีกำรสัง่ ซื้ อไปแล้ว
หรือ ลบสินค้ำที่ไม่ตอ้ งกำรออกจำกตระกร้ำสินค้ำได้ โดยระบบจะคำนวณค่ำใช้จำ่ ยต่ำง ๆ ทุกครั้งเมื่อ
มีกำรเปลี่ยนแปลงเกิดขึ้ นภำยในตระกร้ำสินค้ำ

เมื่อผูใ้ ช้เสร็จสิ้ นกำรเลือกซื้ อสินค้ำแล้ว ขั้นตอนต่อไปจะเป็ นกำรชำระเงินด้วยบัตรเครดิต ซึ่งต้องผ่ำน
กำรลอกอินเสมอ ผูใ้ ช้ตอ้ งกรอกแบบฟอร์มที่เกี่ยวข้องกับข้อมูลบัตรเครดิต ได้แก่ ชนิ ดของบัตรเครดิต
หมำยเลขบัตร ชื่อเจ้ำของบัตร และวันที่หมดอำยุ เพื่อให้ระบบส่งข้อมูลกำรชำระเงินไปยังหน่ วยงำน
ตรวจสอบสถำนะบัตรเครดิตภำยนอกเมื่อมีกำรตรวจสอบสถำนะบัตรเครดิตถูกต้อง ขั้นตอนของกำร
สัง่ ซื้ อสินค้ำถือว่ำเสร็จสิ้ น นอกจำกนั้นแล้วเพื่อควำมสะดวกในกำรใช้งำนของระบบผูใ้ ช้สำมำรถ
ตรวจสอบสถำนะของกำรสัง่ ซื้ อสินค้ำได้โดยผ่ำนกำรลอกอิน ระบบจะแสดงข้อมูลกำรสัง่ ซื้ อสินค้ำ
ทั้งหมดที่ผใู้ ช้เคยสัง่ ซื้ อไว้โดยผูใ้ ช้สำมำรถตรวจสอบรำยกำรสัง่ ซื้ อสินค้ำที่ ตอ้ งกำรได้ โดยระบบจะ
แสดงรำยกำรสินค้ำพร้อมทั้งรำยละเอียดต่ำงๆรวมไปถึงสถำนะของกำรจัดส่งเป็ นต้น
ขั้นตอนที่ 1 หา Actor ในระบบ
ขั้นตอนที่ 1 หา Actor ในระบบ
 เมื่อพิจำรณำจำกควำมต้องกำรแล้ว พบว่ำ ผูใ้ ช้ระบบมี 2 ประเภทคือ ผูใ้ ช้ทวั ่ ไป
(User)
ที่ตอ้ งกำรเข้ำชมสินค้ำภำยในระบบ และลูกค้ำ (Customer) ที่ตอ้ งกำร
สัง่ ซื้ อสินค้ำภำยในระบบ นอกจำกนั้นแล้วในระบบนี้ ยังเกี่ยวข้องโดยตรงกับหน่ วยงำน
ตรวจสอบสถำนะของบัตรเครดิต (Card Authorization) เพื่อทำหน้ำที่ตรวจสอบ
สถำนะทำงกำรเงินของลูกค้ำ ส่วนกำรตรวจสอบจำนวนสินค้ำในคลังเพื่อใช้ประกอบ
สัง่ ซื้ อสินค้ำนั้น เป็ นหน้ำที่ของระบบตรวจสอบสต๊อกสินค้ำ (Check Inventory
System)
 ดังนั้น Actor ของระบบได้แก่ ผูใ้ ช้ ลูกค้ำ ระบบตรวจสอบสถำนะของบัตรเครดิต
และ ระบบตรวจสอบสต๊อกสินค้ำ
ขั้นตอนที่สอง – กาหนด use case


กำรกำหนดยูสเคสของระบบสัง่ ซื้ อสินค้ำออนไลน์ ผูใ้ ช้ (User) สำมำรถค้นหำรำยละเอียด
ของสินค้ำ(Browse Product) ได้ดว้ ยตนเอง ในกรณีของกำรพิจำรณำพบว่ำแอคเตอร์คือ
ลูกค้ำ (Customer) จะต้องมีกำรลงทะเบียน (Register) เพื่อบันทึกข้อมูลที่จำเป็ นในกำร
ลงทะเบียน รวมทั้งชื่อผูใ้ ช้งำนและรหัสผ่ำนสำหรับเข้ำสู่ระบบ(login) โดยลูกค้ำสำมำรถ
เลือกสินค้ำที่ตอ้ งกำรเข้ำสู่กำรสัง่ ซื้ อ (Add Shopping Cart) และเมื่อสัง่ ซื้ อสินค้ำแล้วจะ
สำมำรถตรวจสอบยอดรวมและรำคำสินค้ำที่ปรำกฎในรถเข็นได้ (View Shopping Cart)
นอกจำกนี้ หำกพบข้อผิดพลำดจำกกำรสัง่ ซื้ อ ลูกค้ำสำมำรถแก้ไขสินค้ำในรถเข็น (Update
Shopping Cart) ที่ได้สงั ่ ซื้ อไปแล้ว
นอกจำกนั้นระบบจะคำนวณค่ำใช้จำ่ ยต่ำง ๆ ได้แก่ รำคำรวมในแต่ละรำยกำร รำคำรวมทั้ง
สิ้ น และ ภำษีซึ่งลูกค้ำจะต้องกรอกรำยละเอียดกำรจ่ำยเงิน และกรอกสถำนที่จดั ส่งสินค้ำ
เพื่อทำกำรส่งสินค้ำให้แก่ลกู ค้ำต่อไป(Check out) ในกรณีที่ยงั ไม่ได้รบั สินค้ำตำม
ระยะเวลำที่กำหนดลูกค้ำจะต้องสำมำรถตรวจสอบสถำนะของสินค้ำ(View Order Status)
ที่ตอ้ งจัดส่งให้แก่ลกู ค้ำได้
ตัวอย่างการเขียน Use case narrative ของ ยูสเคส: Login
Use case:
Actors:
Purpose:
Overview:
Login
Customer
เพื่อให้ลกู ค้ำเข้ำใช้งำนระบบได้
ลูกค้ำลอกอินเข้ำระบบ โดยจะระบุชื่อผูใ้ ช้งำนและรหัสผ่ำน
ระบบจะตรวจสอบข้อมูลของลูกค้ำ ถ้ำถูกต้องระบบจะแสดง
หน้ำจอหลักของลูกค้ำให้เพื่อใช้งำนในส่วนต่ำงๆต่อไป
ลูกค้ำต้องผ่ำนกำรลงทะเบียนก่อนเสมอ
สำมำรถเข้ำใช้งำนระบบส่งซื้ อสินค้ำออนไลน์ได้
Preconditions:
Postconditions:
Special Requirements: -
Flow of Events
Actor Action
System Response
1.ยูสเคสเริ่มต้นเมื่อลูกค้ำเลือกฟั งก์ชนั ล็อกอิน
2.ลูกค้ำระบุชื่อผูใ้ ช้งำนและรหัสผ่ำน
3.ระบบตรวจสอบควำมครบถ้วนของข้อมูลจำก Java Script
4.ระบบรับค่ำชื่อผูใ้ ช้งำนและรหัสผ่ำน
5.ระบบค้นหำชื่อผูใ้ ช้งำนและรหัสผ่ำนภำยในฐำนข้อมูล
6.ระบบคืนค่ำสถำนะกำรตรวจสอบจำกฐำนข้อมูล
7.ระบบตรวจสอบสถำนะกำรคืนค่ำ
8.ระบบยอมให้ลกู ค้ำเข้ำสู่ระบบดังนี้
8.1 กำรชำระเงิน
8.2 ดูขอ้ มูลที่เคยสัง่ ซื้ อไปทั้งหมด
9.ลูกค้ำเห็นหน้ำจอสำหรับใช้งำน
Alternative Flow of Events
ขั้นตอนที่ 3 – ในกรณีที่ลกู ค้ำกรอกข้อมูลไม่ครบระบบจะแสดงข้อควำม “กรุณำกรอก
ข้อมูลให้ครบ” และทำขั้นตอนที่ 2 ซ้ำ
ขั้นตอนที่ 7-ในกรณีที่กำรตรวจสอบชื่อผูใ้ ช้งำนและรหัสผ่ำนไม่ถกู ต้อง ระบบจะแสดง
ข้อควำม “ข้อมูลไม่ถกู ต้อง กรุณำตรวจสอบอีกครั้ง” และกลับสู่หน้ำจอลอกอิน
แบบฝึ กหัด
1. ให้นักศึกษำวิเครำะห์ควำมต้องกำรของระบบและวำดยูสเคสไดอำแกรมของระบบเช่ำ
รถ และเขียน Use case narrative เป็ นตัวอย่ำง 1use case จำกข้อมูลที่
กำหนดด้ำนล่ำง
 ระบบเช่ำรถ เป็ นระบบเช่ำรถของบริษัทหนึ่ งที่ให้บริกำรผ่ำนระบบอินเทอร์เน็ ต โดยมีกำร
ชำระเงินและกำรจองทั้งหมดโดยใช้บตั รเครดิต ลูกค้ำส่งคำร้องกำรจองซึ่งประกอบด้วยข้อมูล
ต่ำงๆ ดังนี้
1. ข้อมูลกำรจอง ประกอบด้วย ชนิ ดรถ วันรับรถ และวันคืนรถ
2. ข้อมูลลูกค้ำ ประกอบด้วย ชื่อ ที่อยู่ และเบอร์โทรศัพท์
3. ข้อมูลบัตรเครดิต ประกอบด้วย หมำยเลขบัตรเครดิต เดือนหมดอำยุ และปี หมดอำยุ
เพื่อให้
ระบบส่งข้อมูลส่งหมำยเลขบัตรเครดิต เดือนหมดอำยุ ปี หมดอำยุ จำนวนเงิน และ
หมำยเลขร้ำนค้ำไปยังระบบอนุ มตั ิบตั รเครดิตเมื่อระบบได้รบั รหัสอนุ มตั ิบตั รเครดิต ลูกค้ำจะ
ได้รบั รหัสกำรจอง ขั้นตอนกำรจองรถถือว่ำสิ้ นสุด


เมื่อมีกำรจองรถเรียบร้อยแล้ว ลูกค้ำจึงจะสำมำรถเช่ำรถได้ จำกนั้นส่งคำร้องกำรเช่ำรถ
โดยลูกค้ำระบุรหัสกำรจองและเวลำสิ้ นสุด หลังจำกนั้นระบบร้องขอเลขไมล์ออก ลูกจ้ำง
จะระบุขอ้ มูลเลขไมล์ออก เพื่อออกสัญญำกำรเช่ำ ขณะเดียวกันลูกค้ำระบุขอ้ มูลผูข้ บั ขี่ใน
สัญญำเช่ำ ได้แก่ ชื่อ วันเกิด หมำยเลขใบขับขี่ และหน่ วยงำนออกใบอนุ ญำตของผูข้ บั ขี่
หลังจำกนั้นลูกค้ำระบุเลขบัญชีของผูช้ ำระเงิน ระบบจะใช้เลขบัญชีในกำรออกสัญญำเช่ำ
สุดท้ำยลูกค้ำระบุค่ำใช้จำ่ ยที่จะต้องชำระเพิ่มเติม (กำรสละสิทธิ์ควำมเสียหำยจำกกำรชน
, ประกันหนี้ , ประกันอุบตั ิเหตุส่วนบุคคล) ระบบเพิ่มข้อมูลและสร้ำงสัญญำเช่ำให้แก่
ลูกค้ำ (ข้อกำหนด: ลูกค้ำต้องได้รบั กำรตอบสนองจำกระบบภำยใน 15 วินำที)
เมื่อลูกค้ำต้องกำรคืนรถ ลูกค้ำระบุหมำยเลขใบขับขี่ และเวลำคืน จึงถือว่ำสิ้ นสุดกำรคืน
รถ จำกนั้นลูกจ้ำงบันทึกข้อมูลกำรตรวจสอบรถ ได้แก่ เลขไมล์เข้ำ ระดับน้ ำมัน และควำม
เสียหำย จำกนั้นออกใบแจ้งหนี้ แก่ลกู ค้ำ ลูกค้ำชำระค่ำเช่ำโดยบัตรเครดิต โดยระบุขอ้ มูล
กำรชำระเงิน ได้แก่ หมำยเลขใบขับขี่ จำนวนเงินที่ชำระ หมำยเลขบัตรเครดิต เดือน
หมดอำยุและปี หมดอำยุ เมื่อระบบได้รบั กำรอนุ มตั ิจำกระบบอนุ มตั ิบตั รเครดิต ระบบ
ออกใบเสร็จรับเงินให้ลกู ค้ำ (หำกไม่ได้รบั กำรอนุ มตั ิ ระบบแจ้งให้ลกู ค้ำทรำบและลูกค้ำ
ต้องทำกำรระบุขอ้ มูลกำรชำระเงินอีกครั้ง)
เอกสารอ้างอิง

UML

http://angsila.cs.buu.ac.th
วิเครำะห์และออกแบบเชิงวัตถุ โดย กิตติ ภักดีวฒ
ั นะกุล และกิตติพงษ์ กลม
กล่อม สำนักพิมพ์เคพีที