1. PHƯƠNG PHÁP TÌM KIẾM USE CASE
Trình bày: Nguyễn Văn Sang
Email : nvsang@gimasys.com
2. Use Case
1. Vai trò của use case trong Project
2. Actor
3. Event List and Event Table
4. Proposed format of an event table
5. Getting to use cases
6. Shadow use cases
3.
4. 1. Actor
1. Actors are key to obtaining several artifacts in the
project.
Actors are usually thought of as human beings, but they
also may be other systems, timers and clocks, or
hardware devices.
2. To find the actors, ask the following questions.
Who/what will be interested in the system?
Who/what will want to change the data in the system?
Who/what will want to interface with the system?
Who/what will want information from the system?
6. 2.Event List and Event Table
Actor Definition
Customer Place orders for products
Supplier Supplies products to the company for
resale
Accounting system Gets accounting information from the
system
Shipping Clerk Coordinates the routing of fulfilled
product orders
7. 3.Proposed format of an event table
• Xác định Actor thông qua cấu trúc sau:
Subject+Verb +Object
Subject is an Actor defined earlier in the process.
Verb shows the action.
Object is the focus of the action defined in the
verb.
• Ví dụ:
CSGT lập biên bản vi phạm hành chính đối với
người vi phạm
8. 3.Proposed format of an event table
Subject verd object Frequency Arrival
pattern
response
Customer places order 1000/day Episodic Order is
edited and
save in the
system.
CSGT Lập Biên bản vi
phạm
Nhiều
lần/ngay
Biên bản
được lưu
vào hệ
thống
9. • Response là một trong những thành phần
quan trọng của “Event table”, nó ảnh hưởng
đến thiết kế và là trình sau này của hệt thống
• when readdressing the event table, we make
sure the table is grouped in actor order.
• We take these natural groupings and write a
short (one or two words) descriptive phrase
for each, asking these questions.
What do these events have in common?
Do these events have the same ultimate goal? If
so,what is it?
11. 4.Getting to use cases
• Finding the Pathways through the Use Case
• We need to find the various pathways through
each use case.
• Primary
• Alternate
• Exception
12. Use case Template
User case name Two or three words
User case
description
A short description
User case Authors The authors of the use case
Actors The actors involved in this use case
Locations The locations that will perform this use case;
Typically base on a geographical location but may be departments or divisions
Status The stage that the use case is in: initial path-ways defined and completed
Priority With 1 being the highest
Assumptions What is assumed to be true, or false, about this use case
Preconditions Facts that must be true before this use case and its internal pathways can be initiated:
sometimes called the required system state for execution
Postconditions Facts the must be true when use case ends; sometimes called the required system state upon
completion
Primary pathways The name of the primary pathway
Alternate pathway Alternate pathways through the use case
Exception
pathway
Exception pathways or error conditions
13. Finding the Happy path
User case Happy path
Maintain orders A customer calls in to inquire
about an order’s status.
14. Finding the Alternate Pathways
• An alternate pathway is a pathway that is still
considered a good citizen pathway.
15. Finding the Alternate Pathways
Use case Alternate pathway
Maintain orders
- A customer calls in to change a product quantity
for one order item on the order
- A customer calls to cancel on order
- A customer calls to add a new item to an order
- A customer calls to delete an item from an order
- A customer to change the shipping terms of an
order
- A customer buys an extended warranty on an
item.
- A customer calls to change the billing method.
16. Finding the Exception pathways
• An exception pathway is intended to capture
an “unhappy” pathway.
17. Finding the Exception pathways
User case Happy path
Maintain orders
- A customer calls in to cancel an order that isn’t
found in the system
- A customer calls to add a warranty that is no
longer valid for the time that the product has
been owned
- A customer calls to change order , and the
product to be added is not found in the system.
18. 5. Shadow use cases
• Use cases are viewed form the eyes of the
business, that is the use.
• I call these shadow use cases because they are
never given their due respect in most
applications.
19. 5. Shadow use cases
The most common shadow use cases found
across all application domains:
1. Security
2. Audit
3. Archiving
4. Architecture infrastructure