Mô hình hóa Use Case

MÔ HÌNH HÓA USE CASEHoang Huu Hanh (PhD), Hue Universityhanh-at-hueuni.edu.vn

Use Case Modeling 2

Nội dungUse Case là gì?Lợi ích của Use CaseUse Case vs. Tài liệu yêu cầuMô hình hóa Use Case

◦Hệ thống - System◦Tác nhân - Actor◦Use Case◦Quan hệ giữa các Use Case

Ví dụ: TVRS Use CaseBased on tutorials and presentations of Rational’s UML website

Use Case Modeling 3

Use Case là gì?Được đề xuất bởi Ivar Jacobson (1994)“Là một khối chức năng được thực hiện

bởi hệ thống để mang lại một kết quả có giá trị đối với một actor nào đó”

Trả lời câu hỏi “Hệ thống sẽ làm gì” theo cách nhìn của người sử dụng

Là tập các kịch bản được đưa ra dựa vào các yêu cầu chung của người sử dụng

Mô hình hóa Use Case không phải là một kỹ thuật mô hình hóa hướng đối tượng

Use Case Modeling 4

Lợi ích Use CaseNắm bắt các yêu cầu về chức

năng từ khía cạnh người dùng Mô tả rõ ràng và phù hợp những

gì hệ thống cần làm Là cơ sở để kiểm định hệ thốngGiúp cho việc đưa các yêu cầu hệ

thống thành các lớp và các hàm chức năng vào hệ thống

Use Case Modeling 5

Lợi ích Use CaseĐóng vài trò như là một đơn vị cơ

bản dùng để đánh giá Là đơn vị được phân tách nhỏ

nhất ◦Each increment that is planned and

delivered is described in terms of the Use Case that will be delivered in that increment

Use Case Modeling 6

Use Case và các yêu cầuMột tài liệu yêu cầu cho biết những gì hệ thống

sẽ thực hiện. Use Case mô tả những hoạt động mà người sử dụng thực hiện và những đáp trả tương ứng của hệ thống

Đôi khi Use Case được xem như là một suy luận từ những yêu cầu

Các yêu cầu sẽ được lập tài liệu hiệu quả bằng các Use Case◦ Tăng khả năng tìm vết ◦ Giúp cho việc xác thực yêu cầu người dùng và chức

năng của hệ thống dễ dàng hơn◦ Giúp cho việc phân loại người sử dụng thủ công◦ Công cụ để tìm các lớp

Use Case Modeling 7

Use Case và các yêu cầuUse Case không phù hợp cho việc

xác định các yêu cầu phi chức năng của hệ thống

Use case được xem như là một phần của việc đặc tả các yêu cầu hệ thống

Use Case Modeling 8

Biểu đồ Use CaseMô hình Use Case được mô tả trong

UML bởi một hay nhiều biểu đồ Use Case (UCD)

Một biểu đồ Use Case bao gồm 4 thành phần chính: ◦Mô tả hệ thống◦Các tác nhân mà hệ thống tương tác◦Các UC, hoặc dịch vụ mà hệ thống thực

hiện◦Mối quan hệ giữa các thành phần trên

Use Case Modeling 9

Hệ thốngLà một phần của mô hình Use CaseRanh giới của hệ thống mà ta muốn phát triển cần

phải được định nghĩa rõ ràngHệ thống không cần thiết là một hệ thống

phần mềmĐịnh nghĩa các vùng biên quan trọng của hệ

thống◦ Những tác vụ nào được thực hiện tự động hoặc

thủ công?◦ Những tác vụ nào được thực hiện bởi các hệ

thống khác? Tất cả các giải pháp được đưa ra phải nằm trong vùng

biên của hệ thống

Use Case Modeling 10

Hệ thốngMột hệ thống trong biểu đồ Use

Case được mô tả như một hộp hình khối

Tên của hệ thống được hiển thị bên trong hoặc trên hộp hình khối

Traffic Violations Report System


Tác nhânLà cái gì hoặc ai tương tác với hệ thống (trao

đổi thông tin với hệ thống)Tác nhân mô tả và đại diện cho một vai trò, chứ

không phải là một người sử dụng thật sự và cụ thể của hệ thống

Ví dụ:◦ Nhân viên (Clerk)– Nhập dữ liệu◦ Người giám sát (Supervisor)– Cho phép hiệu

chỉnh/xóa dữ liệu ◦ Người quản lý (Manager) – Cho phép xem các phân

tíchMột người sử dụng đơn lẻ có thể có nhiều hơn

một vai trò


Tác nhânTác nhân có mục đích:

◦Add a Traffic Violation◦Lookup a Traffic Violation

Tác nhân không nhất thiết là con người◦Có thể là một hệ thống bên ngoài tương tác

với hệ thống chínhMỗi tác nhân đều có tên, phản ánh vai

trò của tác nhânMột use case luôn được kích hoạt bởi

một tác nhân nào đó


Ký hiệu tác nhân

Clerk

<< Actor >>Clerk


Mối quan hệ giữa các tác nhân Khi các tác nhân với từng vai trò cả mình, nhằm thực

hiện một vai trò khái quát hơn thì vai trò đó được mô tả như một sự khái quát chung của từng vai trò riêng biệt

Những hành vi chung của các tác nhân sẽ được mô tả ở lớp cha

Các tác nhân kế thừa các hành vi của lớp tác nhân cha và mở rộng những chức năng mà lớp cha không có

Các tác nhân không nhất thiết lúc nào cũng có quan hệ với nhau

ClerkSupervisorManager


Xác định tác nhânAi sử dụng chức năng chính của hệ

thống?Ai sẽ duy trì, quản lý và giữ cho hệ

thống làm việc?Những phần mềm/hệ thống khác mà hệ

thống cần tương tác?◦Những hệ thống máy tính khác◦Những ứng dụng khác chạy trên cùng một

máy tính (i.e. X client/server)◦Chú ý: tránh nhầm lẫn giữa sự tương tác

(interaction) với đầu vào (input)


Xác định tác nhânLà ai

◦ Sử dụng hệ thống?◦ Cài đặt hệ thống?◦ Khởi động hệ thống?◦ Duy trì hệ thống?◦ Thoát hệ thống?◦ Thu thập thông tin từ hệ thống?◦ Cung cấp thông tin cho hệ thống?

Chuyện gì xảy ra tại một thời điểm định trước?


Thời gian?Xem thời gian như là một tác

nhânTác nhân thời gian có thể kích

hoạt một Use Case


Use CaseMô tả một chức năng hoàn chỉnh theo

quan điểm của một tác nhân◦Một UC thỏa mãn một mục đích nào đó

của tác nhânLuôn được kích hoạt bởi một tác nhânMột UC cung cấp một giá trị cho một

tác nhân Một UC phải hoàn chỉnh

◦Tránh phân rã UC thành các UC nhỏ hơn bổ sung cho nhau (phân rã chức năng)


Use Case (cont.)Các kịch bản của UC thường được mô tả

dưới dạng văn bản◦Đặc tả đơn giản và nhất quán cách thức mà

tác nhân và hệ thống tương tác với nhau◦Mẫu mô tả UC (Use Case Description

TempateMô tả theo mức ý định của người sử

dụng và sự trả lời của hệ thống◦Không sử dụng các yếu tố công nghệ, tránh

chí tiết hoá các cơ chế, đặc biệt là liên quan đến các giao diện


Mẫu mô tả UC◦Tên (Name)

Tên của UC, có nghĩa gần với mục đích người sử dụng

◦Các tác nhân (Actors)◦Mục đích (Goals)◦Các yêu cầu (Requirements) (tùy chọn)

Cung cấp khả năng lần vết◦Điều kiện tiên quyết (Pre-Conditions)

Các điều kiện cần thiết cần phải có trước khi thực hiện mộ UC

Có thể là một UC khác (không giống với quan hệ <<include>>)


Biểu mẫu mô tả UC Mô tả (Description)

◦ Mô tả các tiến trình cơ bản hoặc bình thường của hệ thống nếu hệ thống hoạt động như dự định (mọi thứ điều đúng)

Điều kiện sau (Post-conditions)◦ Trạng thái của hệ thống sau khi UC được thực thi◦ Các giá trị đưa ra cho các tác nhân◦ Phân biệt giữa biến thể và các ngoại lệ

Các biến thể (Variations)◦ Các điều kiện dẫn tới việc phân nhánh◦ Mô tả các tiến trình thay thế hoặc là tên mở rộng của UC

Các ngoại lệ (Exceptions)◦ Những điều kiện không mong đợi dẫn tới việc phân nhánh

(xung đột với điều kiện sau)◦ Mô tả các tiến trình thay thế


Use-Cases TipsPhần lớn bắt đầu và kết thúc bởi

tác nhân Kịch bản (mô tả) được viết theo

cách nhìn của tác nhân (vì vậy các bước nên chỉ rõ cho tác nhân thấy)

Sử dụng các câu khai báo


Tìm kiếm Use CaseVới mỗi tác nhân, ta xác định:

◦Những dịch vụ nào tác nhân yêu cầu từ hệ thống?

◦Hệ thống có lưu trữ thông tin không? Đọc, tạo, hủy, hiệu chỉnh, lưu trữ thông tin

◦Liệu tác nhân cần được thông báo về các sự kiện trong hệ thống, hay tác nhân cần thông báo cho hệ thống về việc gì đó không?

◦Công việc thường ngày của tác nhân có đơn giản không? Không nên chỉ tập trung vào hệ thống hiện tại


Use Case (cont.)Ký hiệu Use Case

◦ Là một hình elip chứa tên của Use Case◦ Được đặt bên trong biên mô hình của hệ

thống◦ Kết nối với ít nhất một tác nhân

Add Traffic Violation

Traffic Violations Report system

Clerk

Ngoại lệ cho các UC đặc biệt và mở rộng


Mối quan hệ giữa các Use CaseMối quan hệ “Include” (“uses” đối với các

phiên bản trước)◦ Khi một số UC có chung hành vi, thì hành vi đó sẽ

được mô hình hóa thành một UC riêng được sử dụng bởi các UC khác

◦ X << includes >> Y có nghĩa là muốn thực hiện hành động X thì phải thực hiện Y ít nhất một lần

◦ Thận trọng đối với việc phân rã chức năng ◦ UC “include” phải hoàn chỉnh ◦ X phải thỏa mãn những điều kiện đầu của Y trước

khi “include” Y

<< include >>X Y


Mối quan hệ giữa các Use CaseQuan hệ khái quát hóa

◦ Sử dụng khi một số Use Case có chung một vài tác vụ, nhưng khác nhau ở một vài tác vụ khác để có thể tách ra thành các Use Case riêng biệt

◦ Các Use Case tổng quát và chuyên biệt phải có cùng chung mục đích

◦ Một Use Case chuyên biệt nắm bắt một kịch bản nào đó của Use Case tổng quát

◦ Use Case tổng quát phải hoàn thiện Specialized Generalized


Mối quan hệ giữa các Use CaseQuan hệ khái quát hóa

◦Use Case chuyên biệt có thể tương tác với các tác nhân mới

◦Loại Use Case này cũng có thể thêm vào các điều kiện đầu và post-conditions

Specialized Generalized


Recommended Workflow1. Xác định các tác nhân (quan hệ giữa chúng nếu

cần thiết)2. Với mỗi tác nhân đã xác định, tìm UC cho đến

khi không tìm thấy UC mới a. Xác định tất cả mục đích của tác nhân b. Quyết định tiến trình nào sẽ giúp đạt được đối với

mỗi mục đích c. Tạo Use Case đối với mỗi mục đích tìm được

Tác nhân/mục đích mới có thể được tìm thấy trong bước này d. Xác thực/kiểm tra tính đúng các Use Case tìm được

3. Vẽ biểu đồ Use Case◦ Đơn giả hóa mô hình bằng cách lặp lại các quy trình

trong trường hợp biểu đồ quá phức tạp


TVRS Use CaseExample


Example – TVRS Use CaseName: Remove Traffic ViolationActors: Supervisor, OffendersDB.Goal: Remove an existing Traffic ViolationReferences to requirements: 1.2.3, 1.3.2.4, …Pre-conditions:

◦ Normal Course of “Lookup Traffic Violation” UC is completed, and the details of an existing Traffic Violation are displayed

Description:1. Supervisor calls for deletion of the chosen

Traffic Violation2. TVRS prompts Supervisor for confirmation

External System


Example – TVRS Use Case3. Supervisor confirms4. TVRS requests OffendersDB to delete the Traffic

Violation from the offender’s record5. OffendersDB approves that the Traffic Violation has

been deleted6. TVRS allows Supervisor to look up a new Traffic

Violation as described in the “Lookup Traffic Violation” UC

Post-conditions: ◦ Removed Traffic Violation is no longer stored in the

TVRS.◦ Traffic Violation is removed from the offender’s

record in the OffendersDB◦ "Lookup Traffic Violation" form is displayed


Example – TVRS Use CaseExceptions:

◦ 3a: Supervisor cancels: 3a1: TVRS Continues to item 6 without

removing the Traffic Violation◦ 5a: Traffic Violation is not removed from

the OffendersDB 5a1: TVRS displays an error message

describing the failure5a2: TVRS continues to item 6 without clearing chosen Traffic Violation details, and without deleting the Traffic Violation


Example – TVRS Use CaseName: Add Traffic ViolationActors: Clerk, PolicemenDB, OffendersDBGoal: Add a new Traffic Violation to the TVRSReferences to requirements: …Pre-conditions:

◦ The Traffic Violation Management window is displayed

Description:1. Clerk calls for addition of a new Traffic Violation2. TVRS displays an empty Traffic Violation Details

form3. Clerk enters violation details and calls for saving

the new Traffic Violation


Example – TVRS Use Case4. TVRS prompts Clerk for confirmation.5. Clerk confirms6. TVRS asks the PolicemenDB whether or

not the policeman is known7. PolicemenDB replies that the policeman

is known8. TVRS asks the OffendersDB whether or

not the offender is known9. [Extension point] OffendersDB replies

that the offender is known…


Example – TVRS Use CasePost-conditions:

◦ New Traffic Violation is stored in the TVRS◦ TVRS displays an empty Traffic Violation Details form

Variations:◦ 5a: Clerk cancels

5a1: TVRS continues to item 2 without clearing the traffic violation details entered by clerk

◦ 9a: OffendersDB replies that the offender is not known. Described in Use Case “New Offender”

◦ 7a: Policeman is not stored in the policemenDB 7a1: TVRS displays an error message 7a2: TVRS continues to item 2 without clearing Traffic

Violation details entered by clerk◦ ...


Example – TVRS Use CaseExceptions:

◦ 3a: Clerk cancels addition of the new Traffic Violation 3a1: TVRS displays the "Traffic Violation

Management" form◦ …


Example – TVRS Use CaseName: New Offender [extends “Add

Traffic Violaton” ]Actors:Goal: References to requirements: …Pre-conditions:

◦ Offender is not stored in the OffendersDB

UC attributes are “inherited”


Example – TVRS Use Case Description:

◦ 9a: OffendersDB replies that the offender is not known. [Add Traffic Violation]

◦ 9b: TVRS displays an empty “Offender Details form”◦ 9c: Clerk enters offender details and calls for saving the

new details◦ 9d: TVRS prompts Clerk for confirmation◦ 9e: Clerk confirms◦ 9f: TVRS requests OffendersDB to store the new offender◦ 9g: OffendersDB replies that offender was stored

successfully Post-conditions:

◦ New Offender is stored in the offenders DB ...


Example – TVRS Use Case

Remove T.V

Lookup T.V

Replace Offender

New Offender

Edit T.V.(8)

Add T.V.(9)

Clerk

Supervisor

Traffic Violations Report System

<<extend>>

<<extend>>

<<include>> OffendersDB

PolicemenDB


Levels of Use-CasesSea-Level

◦Discrete interactions between primary actor and system

Kite-Level◦Show how sea-level use-cases fit into

wider business interactions


Use-CasesProvide the boundaries and

scope of a project


Prioritize Use CaseBased on riskTimeMoney


Thank You!… feel tired?YES!!!!

Documents

Mô hình hóa Use Case