Mô hình hóa Use Case
description
Transcript of 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
Use Case Modeling 11
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ò
Use Case Modeling 12
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 đó
Use Case Modeling 13
Ký hiệu tác nhân
Clerk
<< Actor >>Clerk
Use Case Modeling 14
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
Use Case Modeling 15
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)
Use Case Modeling 16
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?
Use Case Modeling 17
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 Case Modeling 18
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 Modeling 19
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
Use Case Modeling 20
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>>)
Use Case Modeling 21
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 Case Modeling 22
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
Use Case Modeling 23
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 Modeling 24
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
Use Case Modeling 25
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
Use Case Modeling 26
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
Use Case Modeling 27
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
Use Case Modeling 28
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
Use Case Modeling 29
TVRS Use CaseExample
Use Case Modeling 30
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
Use Case Modeling 31
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
Use Case Modeling 32
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
Use Case Modeling 33
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
Use Case Modeling 34
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…
Use Case Modeling 35
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◦ ...
Use Case Modeling 36
Example – TVRS Use CaseExceptions:
◦ 3a: Clerk cancels addition of the new Traffic Violation 3a1: TVRS displays the "Traffic Violation
Management" form◦ …
Use Case Modeling 37
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”
Use Case Modeling 38
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 ...
Use Case Modeling 39
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
Use Case Modeling 40
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 Case Modeling 41
Use-CasesProvide the boundaries and
scope of a project
Use Case Modeling 42
Prioritize Use CaseBased on riskTimeMoney
Use Case Modeling 43
Thank You!… feel tired?YES!!!!