Bài giảng Phân tích và thiết kế hướng đối tượng - Bài 3: Biểu đồ USE case phân tích yêu cầu hệ thống - Đào Nam Anh

PHÂN TÍCH VÀ THIẾT KẾ HƯỚNG ĐỐI TƯỢNG 
OBJECT ORIENTED ANALYSIS AND DESIGN 
DR. DAO NAM ANH 
 Bài giảng 3: 
BIỂU ĐỒ USE CASE 
PHÂN TÍCH YÊU CẦU HỆ THỐNG 
1 
RESOURCE - REFERENCE 
1. Ian Sommerville, Software Engineering, Ninth Edition, 2011 
2. Bernd Bruegge & Allen H. Dutoit. Object-Oriented 
Software Engineering: Using UML, Patterns, and Java, 
Third Edition, Prentice Hall, 2010 
3. Russell C. Bjork, ATM Simulation Links, Gordon College 
4. Hans-Erik Eriksson, Magnus Penker, Brian Lyons, David 
Fado, UML 2 Toolkit, John Wiley & Sons Inc, 2003 
5. Dương Kiều Hoa – Tôn Thất Hoà An, Phân tích và thiết kế 
Hệ thống thông tin với UML, 2006 
6. Đào Nam Anh, Giáo Trình Phân Tích Và Thiết Kế Hướng 
Đối Tượng, Đại học Điện lực, 2013 
2 
CONTENT – NỘI DUNG 
Phương pháp hướng đối tượng và quá trình phát 
triển hệ thống phần mềm 
1. Giới thiệu về hệ thống phần mềm 
2. Sự phát triển hệ thống 
3. Các cách tiếp cận trong phát triển phần mềm 
4. Quá trình phát triển phần mềm hợp nhất 
3 
Nội dung 
1. Biểu đồ Use Case phân tích yêu cầu hệ thống 
2. Tập hợp yêu cầu hệ thống 
3. Biểu đồ Use Case 
4. Mô hình hóa với Use Case 
4 
Giới thiệu 
 Yêu cầu là chức năng mà hệ thống phải có hoặc là điều 
kiện mà hệ thống phải đáp ứng theo đề nghị của khách 
hàng. 
 Để xác định các yêu cầu của hệ thống cần làm hai việc: 
tập hợp yêu cầu, mà kết quả là tài liệu đặc tả hệ thống 
viết cho khách hàng hiểu được; và việc phân tích, mà kết 
quả là một mô hình phân tích với các Use Case giải 
thích rõ ràng cho các lập trình viên 
5 
1. Tập hợp yêu cầu hệ thống 
 Tập hợp yêu cầu có nhiều thách thức vì nó cần 
có sự cộng tác của nhiều người tham gia với các 
nền tảng nghiệp vụ khác nhau. 
 Một mặt, khách hàng và người sử dụng là các 
chuyên gia trong phạm vi của họ và họ có ý 
tưởng chung về hệ thống cần làm những gì, 
nhưng họ thường có ít kinh nghiệm trong phát 
triển phần mềm. 
 Mặt khác, các nhà phát triển có kinh nghiệm 
trong việc xây dựng hệ thống, nhưng thường có 
ít kiến thức về môi trường nghiệp vụ của người 
sử dụng. 6 
1. Tập hợp yêu cầu hệ thống 
 Cảnh kịch (scenario) và các Use Case là để lấp khoảng 
trống này. Cảnh kịch mô tả ví dụ sử dụng hệ thống là 
một loạt các tương tác giữa người dùng và hệ thống. 
 Use Case là mô hình trìu tượng của cảnh kịch. Cảnh 
kịch được viết bằng ngôn ngữ tự nhiên, dễ hiểu cho 
người dùng. Nhà phát triển tìm ra những yêu cầu bằng 
cách quan sát và phỏng vấn người sử dụng. Nhà phát 
triển đầu tiên trình bày các quy trình công việc hiện tại 
của người sử dụng trong dạng cảnh kịch, sau đó phát 
triển cảnh kịch thể hiện chức năng của hệ thống tương 
lai trong ngôn ngữ của khách hàng. 
7 
1. Tập hợp yêu cầu hệ thống 
 Use Case là một công cụ xuất sắc để khuyến khích 
những người sử dụng tiềm năng nói về hệ thống từ 
hướng nhìn của họ. Đối với người dùng, mô tả những ý 
định trong việc sử dụng hệ thống cũng việc không dễ 
dàng. 
 Người sử dụng thường biết nhiều hơn những gì mà họ 
có thể diễn tả ra: Công cụ Use Case sẽ giúp cho nhóm 
phát triển phá "lớp băng" đó. 
8 
1. Tập hợp yêu cầu hệ thống 
 Ý tưởng chủ đạo là lôi cuốn được người dùng tham gia 
vào những giai đoạn đầu tiên của quá trình phân tích và 
thiết kế hệ thống. 
 Việc này sẽ nâng cao xác suất cho việc hệ thống được 
xây dựng sẽ trở thành một công cụ quen thuộc đối với 
các người dùng – thay vì một tập hợp khó hiểu và rối 
rắm của các khái niệm máy tính mà người dùng trong 
nghiệp vụ của mình có cảm giác không bao giờ hiểu 
được và không thể làm việc cùng. 
9 
1. Tập hợp yêu cầu hệ thống 
Ví dụ ATM: scenarios 
Hệ thống ngân hàng tự động ATM 
 Phần mềm được thiết kế sẽ kiểm soát máy rút tiền tự 
động (ATM) có một đầu đọc thẻ ATM, một giao diện với 
khách hàng gồm có bàn phím và màn hình, một khe trả 
phong bì, một khay tiền tiền mặt (bội số của 20$), một 
máy in biên lai, và một phím để khởi động hoặc dừng 
máy. ATM sẽ giao tiếp với máy tính của ngân hàng 
thông qua một đường truyền thông. 
 ATM sẽ phục vụ một khách hàng tại một thời điểm. Một 
khách hàng sẽ được yêu cầu nạp một thẻ ATM và nhập 
mã số cá nhân (PIN) - cả hai sẽ được gửi đến ngân hàng 
để xác nhận. Các khách hàng sau đó sẽ có thể thực hiện 
một hoặc nhiều giao dịch. 
10 
2. Biểu đồ Use Case 
 Nếu một hệ thống được xem là có chất lượng cao, nó 
phải đáp ứng các yêu cầu của người sử dụng. Vì vậy khi 
phân tích hệ thống phân tích cách tiếp cận theo định 
hướng người sử dụng là thích hợp. 
 Cần xác định người sử dụng của hệ thống và các nhiệm 
vụ mà họ phải thực hiện với hệ thống. Đồng thời tìm 
thông tin về những nhiệm vụ quan trọng nhất của họ, để 
có thể lập nên cảnh kịch sử dụng phù hợp. 
11 
2. Biểu đồ Use Case 
 Có thể coi một biểu đồ Use Case như là tập hợp của một 
loạt các Use Case, mô hình hóa cảnh kịch về việc sử 
dụng hệ thống. 
 Mỗi cảnh kịch mô tả một chuỗi các sự kiện. 
 Mỗi một chuỗi này sẽ được kích hoạt bởi một người nào 
đó, một hệ thống khác hay là một phần trang thiết bị nào 
đó, hoặc là một chuỗi thời gian. 
 Những thực thể kích hoạt nên các chuỗi sự kiện như thế 
được gọi là các Tác Nhân (Actor). 
12 
2. Biểu đồ Use Case 
 'Người sử dụng' và 'nhiệm vụ' trong UML thực tế chính 
là tác nhân (Actor) và Use Case. 
 Tác nhân là mô hình của người sử dụng của hệ thống 
trong một vai trò xác định. Tác nhân cũng có thể là một 
hệ thống bên ngoài có tương tác với hệ thống đang phân 
tích. 
13 
2. Biểu đồ Use Case 
2.1 Thành phần Use Case 
 Những thành phần quan trọng nhất của một mô hình Use 
Case là Use Case, tác nhân và hệ thống. Ranh giới của 
hệ thống được định nghĩa qua chức năng tổng thể mà hệ 
thống sẽ thực thi. 
 Chức năng tổng thể được thể hiện qua một loạt các Use 
Case và mỗi một Use Case đặc tả một chức năng trọn 
vẹn, có nghĩa là Use Case phải thực thi toàn bộ chức 
năng đó, từ sự kiện được kích hoạt đầu tiên bởi một tác 
nhân ngoại cảnh cho tới khi chức năng đòi hỏi được thực 
hiện hoàn tất. 
 Một Use Case luôn phải cung cấp một giá trị nào đó cho 
một tác nhân, giá trị này là những gì mà tác nhân mong 
muốn từ phía hệ thống. Tác nhân là bất kỳ một thực thể 
ngoại cảnh nào mong muốn tương tác với hệ thống. 14 
2. Biểu đồ Use Case 
2.1 Thành phần Use Case 
Một biểu đồ Use Case thể hiện [32]: 
 Hệ thống 
 Tác nhân 
 Use Case. 
Ví dụ biểu đồ Use Case trong UML, trong đó hình chữ 
nhật thể hiện hệ thống, tác nhân được thể hiện qua ký hiệu 
hình người, Use Case được thể hiện qua hình ellipse. 
15 
Check Balance
Card Holder
Withdraw Cash
2. Biểu đồ Use Case 
2.1 Thành phần Use Case 
Hệ thống 
Vì hệ thống là một thành phần của mô hình Use Case nên 
ranh 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àng. 
 Lưu ý một hệ thống không phải bao giờ cũng nhất thiết 
là một hệ thống phần mềm; nó có thể là một chiếc máy, 
hoặc là một nghiệp vụ. 
 Định nghĩa các ranh giới và trách nhiệm của hệ thống 
không phải dễ dàng, bởi không phải bao giờ người ta 
cũng rõ ràng nhìn ra nghiệp vụ nào có khả năng được tự 
động hóa tốt nhất ở hệ thống này và nghiệp vụ nào thì 
tốt nhất nên thực hiện thủ công hoặc dành cho các hệ 
thống khác. 
16 
2. Biểu đồ Use Case 
2.1 Thành phần Use Case 
Tác nhân 
 Một tác nhân là một người hoặc một vật nào đó tương 
tác với hệ thống, sử dụng hệ thống. 
 Trong khái niệm "tương tác với hệ thống", ý muốn nói 
rằng tác nhân sẽ gửi thông điệp đến hệ thống hoặc là 
nhận thông điệp xuất phát từ hệ thống, hoặc là thay đổi 
các thông tin của với hệ thống. Nói một cách ngắn gọn, 
tác nhân thực hiện các Use Case. 
 Một tác nhân có thể là người mà cũng có thể là một hệ 
thống khác (ví dụ đó là một chiếc máy tính khác được 
kết nối với hệ thống của chúng ta hoặc một loại trang 
thiết bị phần cứng nào đó tương tác với hệ thống). 
17 
2. Biểu đồ Use Case 
2.1 Thành phần Use Case 
 Một tác nhân giao tiếp với hệ thống bằng cách gửi hoặc 
là nhận thông điệp, giống như khái niệm chúng ta đã 
quen biết trong lập trình hướng đối tượng. 
 Một Use Case bao giờ cũng được kích hoạt bởi một tác 
nhân gửi thông điệp đến cho nó. 
 Khi một Use Case được thực hiện, Use Case có thể gửi 
thông điệp đến một hay nhiều tác nhân. Những thông 
điệp này cũng có thể đến với các tác nhân khác, hay 
chính tác nhân đã kích hoạt Use Case. 
18 
2. Biểu đồ Use Case 
2.1 Thành phần Use Case 
 Tác nhân cũng có thể được xếp loại. Tác nhân còn có thể 
được định nghĩa theo dạng tác nhân chủ động (active 
actor) hay tác nhân thụ động (passive actor). 
 Một tác nhân chủ động là tác nhân gây ra Use Case, 
trong khi tác nhân thụ động không bao giờ gây ra Use 
Case mà chỉ tham gia vào một hoặc nhiều Use Case. 
19 
2. Biểu đồ Use Case 
2.1 Thành phần Use Case 
Tìm tác nhân 
 Khi nhận diện tác nhân, có nghĩa là chúng ta lọc ra các 
thực thể đáng quan tâm theo khía cạnh sử dụng và tương 
tác với hệ thống. 
 Sau đó chúng ta có thể thử đặt mình vào vị trí của tác 
nhân để cố gắng nhận ra các yêu cầu và đòi hỏi của tác 
nhân đối với hệ thống và xác định tác nhân cần những 
Use Case nào. 
20 
2. Biểu đồ Use Case 
2.1 Thành phần Use Case 
Tìm tác nhân 
Có thể nhận diện ra các tác nhân qua các câu hỏi như sau: 
 Ai sẽ sử dụng những chức năng chính của hệ thống? 
 Ai sẽ cần sự hỗ trợ của hệ thống để thực hiện những tác 
vụ hàng ngày của họ? 
 Ai sẽ cần bảo trì, quản trị và đảm bảo cho hệ thống hoạt 
động? 
 Hệ thống sẽ phải xử lý và làm việc với những trang thiết 
bị phần cứng nào? 
 Hệ thống cần phải tương tác với các hệ thống khác nào? 
 Ai hay cái gì quan tâm đến đầu ra của hệ thống? 
21 
2. Biểu đồ Use Case 
2.1 Thành phần Use Case 
Tìm tác nhân 
 Khi đi tìm những người sử dụng hệ thống, đừng quan sát 
những người đang ngồi ở trước màn hình máy tính. Lưu 
ý người sử dụng có thể là bất kỳ người nào hay bất kỳ 
vật nào tương tác hoặc trực tiếp hoặc gián tiếp với hệ 
thống và sử dụng các dịch vụ của hệ thống này để đạt 
đến một kết quả nào đó 
22 
2. Biểu đồ Use Case 
2.1 Thành phần Use Case 
Tìm tác nhân 
 Để có thể nhận dạng được tốt nhiều tác nhân khác nhau, 
hãy tiến hành nghiên cứu những người sử dụng của hệ 
thống hiện thời (một hệ thống thủ công hoặc một hệ 
thống đang tồn tại), hỏi xem họ đóng những vai trò nào 
khi thực thi công việc hàng ngày với hệ thống. 
 Cũng người sử dụng đó có thể thực thi nhiều vai trò 
khác nhau tại nhiều thời điểm khác nhau, tùy thuộc vào 
việc chức năng nào trong hệ thống đang được sử dụng. 
23 
2. Biểu đồ Use Case 
2.1 Thành phần Use Case 
Biểu diễn tác nhân trong ngôn ngữ UML 
Tác nhân trong UML là một lớp với biệt ngữ "Actor" (Tác 
nhân) và tên của lớp này là tên của tác nhân, phản ánh vai 
trò của tác nhân. 
Một lớp tác nhân có thể vừa có thuộc tính (attribute) lẫn 
hành vi (method) cũng như một thuộc tính tài liệu 
(document) mô tả tác nhân đó. Một lớp tác nhân có một 
biểu tượng chuẩn hóa và biểu tượng "hình nhân": 
24 
2. Biểu đồ Use Case 
2.1 Thành phần Use Case 
Quan hệ giữa các tác nhân 
Một tác nhân thường có Liên hệ để sử dụng các trường 
hợp phải được nhị phân. Tác nhân cũng có thể có mối quan 
hệ tổng quát giữa họ, với g ngữ nghĩa điển hình là các con 
có thể làm những gì cha mẹ làm và sau đó làm thêm việc 
khác. 
Khi có nhiều tác nhân nhiều, một số tác nhân có thể là tổng 
quát của tác nhân khác. Khái quát giữa các đối tượng được 
hiển thị như đoạn thẳng với một hình tam giác rỗng đẩu 
chỉ vào tác nhân tổng quát hơn, như thể hiện trong hình 
dưới. 
25 
2. Biểu đồ Use Case 
2.1 Thành phần Use Case 
Quan hệ giữa các tác nhân 
26 
Administrator
Staff
Manager
Registered User
2. Biểu đồ Use Case 
2.1 Thành phần Use Case 
Use Case 
 Một Use Case là đại diện cho một chức năng nguyên 
vẹn mà một tác nhân nhận được. 
 Một Use Case trong ngôn ngữ UML được định nghĩa là 
một tập hợp của các chuỗi hành động mà một hệ thống 
thực hiện để tạo ra một kết quả có thể quan sát được, tức 
là một giá trị đến với một tác nhân cụ thể. 
 Những hành động này có thể bao gồm việc giao tiếp với 
nhiều tác nhân cũng như thực hiện tính toán và công 
việc nội bộ bên trong hệ thống. 
27 
2. Biểu đồ Use Case 
2.1 Thành phần Use Case 
Use Case 
Các tính chất tiêu biểu của một Use Case là: 
 Một Use Case bao giờ cũng được gây ra bởi một tác 
nhân, được thực hiện nhân danh một tác nhân nào đó. 
Tác nhân phải ra lệnh cho hệ thống để thực hiện Use 
Case đó, dù là trực tiếp hay gián tiếp. 
 Một Use Case phải cung cấp một giá trị cho một tác 
nhân. Giá trị đó không phải bao giờ cũng cần thiết phải 
thể hiện ra ngoài. 
 Một Use Case là phải hoàn tất. Một trong những lỗi 
thường gặp là phân rã một Use Case thành các Use Case 
nhỏ hơn, và các Use Case này thực thi lẫn nhau giống 
như việc gọi hàm cho một ngôn ngữ lập trình. 
28 
2. Biểu đồ Use Case 
2.1 Thành phần Use Case 
Use Case 
 Một Use Case là một lớp, chứ không phải một thực thể. 
Nó mô tả trọn vẹn một chức năng, kể cả các giải pháp bổ 
sung và thay thế có thể có, các lỗi có thể xảy ra cũng 
như những ngoại lệ có thể xảy ra trong quá trình thực 
thi. 
 Một kết quả của sự thực thể hóa một Use Case được gọi 
là một cảnh kịch (scenario) và nó đại diện cho một sự sử 
dụng cụ thể của hệ thống (một cách thực thi riêng biệt 
qua hệ thống). 
 Ví dụ một cảnh kịch của Use Case "Ký hợp đồng bảo 
hiểm" có thể là "John liên hệ với hệ thống qua điện thoại 
rồi sau đó ký hợp đồng bảo hiểm ô tô cho chiếc xe 
Toyota Carolla mà anh ta vừa mua." 29 
2. Biểu đồ Use Case 
2.1 Thành phần Use Case 
Tìm Use Case 
Quá trình tìm các Use Case bắt đầu với các tác nhân đã 
được xác định ở phần trước. Đối với mỗi tác nhân, hãy hỏi 
các câu hỏi sau: 
 Tác nhân này cần những chức năng nào từ hệ thống? 
Hành động chính của tác nhân là gì ? 
 Tác nhân có cần phải đọc, phải tạo, phải hủy bỏ, phải 
sửa chữa, hay là lưu trữ một loại thông tin nào đó trong 
hệ thống? 
 Tác nhân có cần phải báo cho hệ thống biết về những sự 
kiện nào đó? Những sự kiện như thế sẽ đại diện cho 
những chức năng nào? 
30 
2. Biểu đồ Use Case 
2.2. Quan hệ giữa các Use Case 
Có ba loại quan hệ Use Case: 
 Quan hệ mở rộng, 
 Quan hệ sử dụng và 
 Quan hệ tạo nhóm. 
Quan hệ mở rộng và quan hệ sử dụng là hai dạng khác 
nhau của tính thừa kế. Quan hệ tạo nhóm là một phương 
cách để đặt nhiều Use Case chung với nhau vào trong một 
gói. 
31 
2. Biểu đồ Use Case 
2.2. Quan hệ giữa các Use Case 
Quan hệ mở rộng 
Ta thấy một số Use Case đã tồn tại cung cấp một phần 
những chức năng cần thiết cho một Use Case mới. Trong 
một trường hợp như vậy, có thể định nghĩa một Use Case 
mới là Use Case cũ cộng thêm một phần mới. Một Use 
Case như vậy được gọi là một Use Case mở rộng 
(extended use case). 
Trong quan hệ mở rộng, Use Case gốc được dùng để mở 
rộng phải là một Use Case hoàn thiện. Use Case mở rộng 
không nhất thiết phải sử dụng toàn bộ hành vi của Use 
Case gốc. 
Quan hệ mở rộng giữa các Use Case được biểu thị bằng 
đoạn thẳng ngắt quãng, trỏ về phía Use Case được dùng để 
mở rộng, đi kèm với stereotype >. 
32 
2. Biểu đồ Use Case 
2.2. Quan hệ giữa các Use Case 
Quan hệ sử dụng 
 Khi một nhóm các Use Case cùng chung một hành vi 
nào đó thì hành vi này có thể được tách riêng ra thành 
một Use Case riêng biệt và nó có thể được sử dụng bởi 
các Use Case kia, một mối quan hệ như vậy được gọi là 
quan hệ sử dụng. 
 Trong quan hệ sử dụng, phải sử dụng toàn bộ Use Case 
khái quát hóa, nói một cách khác, ta có một Use Case 
này sử dụng toàn bộ một Use Case khác. 
 Quan hệ sử dụng giữa các Use Case được biểu thị bằng 
đoạn thẳng với hình tam giác rỗng trỏ về phía Use Case 
được sử dụng, đi kèm với stereotype >. 
33 
2. Biểu đồ Use Case 
2.2. Quan hệ giữa các Use Case 
Quan hệ chung nhóm 
 Khi một số các Use Case cùng xử lý các chức năng 
tương tự hoặc có thể liên quan đến nhau theo một 
phương thức nào đó, người ta thường nhóm chúng lại 
với nhau. 
 Nhóm các Use Case được thực hiện bằng khái niệm 
"Gói" (Package) của UML. Gói không cung cấp giá trị 
gia tăng cho thiết kế. 
 Ví dụ: Tất cả các Use Case có liên quan đến sinh viên sẽ 
được nhóm thành "Student related" 
34 
Student related Staff related General
2. Biểu đồ Use Case 
2.3. Miêu tả Use Case 
 Miêu tả Use Case 
 Miêu tả một Use Case thường được thực hiện trong văn 
bản. Đây là lời đặc tả đơn giản và nhất quán về việc các 
tác nhân và các Use Case tương tác với nhau ra sao. 
 Nó tập trung vào ứng xử đối ngoại của hệ thống và 
không đề cập tới việc thực hiện nội bộ bên trong hệ 
thống. Ngôn ngữ và các thuật ngữ được sử dụng trong 
lời miêu tả chính là ngôn ngữ và các thuật ngữ được sử 
dụng bởi khách hàng/người dùng. 
35 
2. Biểu đồ Use Case 
2.3. Miêu tả Use Case 
Văn bản miêu tả cần phải bao gồm những điểm sau: 
 Mục đích của Use Case: Mục đích chung cuộc của Use 
Case là gì? Cái gì cần phải được đạt tới? 
 Use Case được khởi chạy như thế nào: Tác nhân nào 
gây ra sự thực hiện Use Case này? Trong hoàn cảnh 
nào? 
 Các thông điệp giữa tác nhân và Use Case: Use Case và 
các tác nhân trao đổi thông điệp hay sự kiện nào để 
thông báo lẫn cho nhau, cập nhật hoặc nhận thông tin và 
giúp đỡ nhau quyết định? 
36 
2. Biểu đồ Use Case 
2.3. Miêu tả Use Case 
Văn bản miêu tả cần phải bao gồm những điểm sau: 
 Dòng chảy thay thế trong một Use Case: Một Use Case 
có thể có những dòng thực thi thay thế tùy thuộc vào 
điều kiện. Hãy nhắc đến các yếu tố này, nhưng chú ý 
đừng miêu tả chúng quá chi tiết đến mức độ chúng có 
thể “che khuất“ dòng chảy chính của các hoạt động 
trong trường hợp căn bản. Những động tác xử lý lỗi đặc 
biệt sẽ được miêu tả thành các Use Case khác. 
 Use Case sẽ kết thúc với một giá trị đối với tác nhân như 
thế nào: Miêu tả khi nào Use Case được coi là đã kết 
thúc, và loại giá trị mà nó cung cấp đến tác nhân. 
37 
2. Biểu đồ Use Case 
2.4. Kiểm tra Use Case 
 Sau khi các Use Case đã được miêu tả, cần phải thực 
hiện thẩm tra xem các mối quan hệ có được nhận diện 
không. Trước khi tất cả các Use Case được miêu tả, nhà 
phát triển chưa thể có được những kiến thức hoàn tất và 
tổng thể để xác định các mối quan hệ thích hợp, kiểm 
thử làm theo phương thức đó có thể sẽ dẫn đến một tình 
huống nguy hiểm. 
38 
2. Biểu đồ Use Case 
2.4. Kiểm tra Use Case 
Trong thời gian thực hiện công việc này, hãy trả lời các câu 
hỏi sau: 
 Tất cả các tác nhân liên quan đến một Use Case có mối 
liên kết giao tiếp với Use Case đó không? 
 Có tồn tại những sự tương tự giữa một loạt các tác nhân 
minh họa một vai trò chung và nhóm này có thể được miêu 
tả là một lớp tác nhân căn bản? 
 Có tồn tại những sự tương tự giữa một loạt các Use Case, 
minh họa một dòng chảy hành động chung? Nếu có, điều 
này có thể được miêu tả là một mối quan hệ sử dụng đến 
với một Use Case khác? 
 Có tồn tại những trường hợp đặc biệt của một Use Case có 
thể được miêu tả là một mối quan hệ mở rộng? 
39 
2. Biểu đồ Use Case 
2.5 Use Case kiểm thử 
 Một trong các mục đích chính của Use Case là kiểm thử 
(testing). Có hai loại kiểm thử khác nhau được thực hiện 
ở đây: kiểm tra (verification) và phê duyệt xác nhận 
(validation). 
 Kiểm tra đảm bảo là hệ thống đã được phát triển đúng 
đắn và phù hợp với các đặc tả đã được tạo ra. 
 Phê duyệt xác nhận đảm bảo rằng hệ thống sẽ được phát 
triển chính là thứ mà khách hàng hoặc người sử dụng 
cuối thật sự cần đến. 
40 
2. Biểu đồ Use Case 
2.5 Use Case kiểm thử 
 Use Case đóng một phần không thể thiếu trong việc giúp 
đội kiểm thử lập tổ chức việc kiểm thử. 
 Các Test Case được tạo ra từ các Use Case. Giá trị đầu 
vào khác nhau sẽ được kiểm thử điều kiện biên. Dòng 
chảy trong Use Case cũng sẽ có ích cho các Test Case. 
41 
2. Biểu đồ Use Case 
2.6 Thực hiện các Use Case 
 Use Case là những lời miêu tả độc lập với sự thực thi 
các chức năng của hệ thống. 
 Điều đó có nghĩa là Use Case sẽ được thực hiện (thực 
thể hóa) trong hệ thống, vậy trách nhiệm để thực thi các 
hành động được miêu tả trong tài liệu Use Case được 
phân bổ cho các đối tượng cộng tác thực thi chức năng 
đó. 
42 
2. Biểu đồ Use Case 
2.6 Thực hiện các Use Case 
 Jacobson sử dụng phương pháp định nghĩa ba loại đối 
tượng căn bản (có nghĩa là ba loại lớp): 
 các đối tượng biên (boundary objects) , 
 đối tượng chỉ huy (control objects) và 
 đối tượng thực thể (entity objects). 
Đối với mỗi Use Case, các loại đối tượng này được sử 
dụng để miêu tả một sự cộng tác thực thi Use Case. 
43 
2. Biểu đồ Use Case 
2.6 Thực hiện các Use Case 
 Đối tượng biên: loại đối tượng này nằm gần đường ranh 
giới của hệ thống mặc dù vẫn nằm bên trong hệ thống. 
Chúng tương tác với các tác nhân nằm bên ngoài hệ 
thống và nhận thông điệp cũng như gửi thông điệp đến 
các loại đối tượng khác nằm bên trong hệ thống. 
44 
2. Biểu đồ Use Case 
2.6 Thực hiện các Use Case 
 Đối tượng chỉ huy: loại đối tượng này chỉ huy sự tương 
tác giữa các nhóm đối tượng. Một đối tượng như thế có 
thể đóng vai trò "bộ phận điều khiển” cho toàn bộ một 
Use Case hoàn tất, hay nó có thể thực thi một chuỗi 
hành động chung của nhiều Use Case. Thường thì một 
đối tượng như vậy chỉ tồn tại trong quá trình thực thi 
Use Case. 
45 
2. Biểu đồ Use Case 
2.6 Thực hiện các Use Case 
 Đối tượng thực thể: loại đối tượng này đại diện cho các 
thực thể của bài toán nằm trong phạm vi mà hệ thống xử 
lý. Thường chúng mang tính thụ động, theo khái niệm là 
chúng không tự gây nên các tương tác đối với chúng. 
Trong một hệ thống thông tin, các đối tượng thực thể 
thường mang tính trường tồn (persistent) và được lưu trữ 
trong một hệ ngân hàng dữ liệu. Các đối tượng thực thể 
thường tham gia vào nhiều Use Case khác nhau. 
46 
2. Biểu đồ Use Case 
2.6 Thực hiện các Use Case 
47 
3. Mô hình hóa với Use Case 
 Trong kỹ thuật mô hình hóa Use Case, hệ thống sẽ có 
hình dạng của một "hộp đen" và cung cấp các Use Case. 
 Hệ thống làm điều đó như thế nào, các Use Case được 
thực thi ra sao, đó là những khía cạnh chưa được đề cập 
tới trong giai đoạn này. 
 Trong thực tế, nếu mô hình hóa Use Case được thực 
hiện trong những giai đoạn đầu của dự án thì thường nhà 
phát triển sẽ không biết Use Case sau này sẽ được thực 
thi (tức là biến thành những dòng code thật sự) như thế 
nào. 
48 
3. Mô hình hóa với Use Case 
Mục tiêu chính yếu đối với các Use Case là để: 
 Mô tả các yêu cầu chức năng của hệ thống, đây là kết 
quả rút ra từ sự thỏa thuận giữa khách hàng, người sử 
dụng cuối) và nhóm phát triển phần mềm. 
 Tạo nên một mô tả rõ ràng và nhất quán về việc hệ 
thống cần phải làm gì, làm sao để mô hình có thể được 
sử dụng nhất quán suốt toàn bộ quá trình phát triển, 
được sử dụng làm công cụ giao tiếp cho tất cả những 
người tham gia và để tạo nên một nền tảng cho các mô 
hình thiết kế các chức năng. 
 Tạo nên một nền tảng cho việc kiểm thử hệ thống, đảm 
bảo hệ thống thỏa mãn đúng những yêu cầu do người sử 
dụng đưa ra. 
49 
3. Mô hình hóa với Use Case 
Mục tiêu chính yếu đối với các Use Case là để: 
 Cung cấp khả năng theo dõi các yêu cầu về mặt chức 
năng được chuyển thành các lớp cụ thể cũng như các thủ 
tục cụ thể trong hệ thống. 
 Đơn giản hóa việc thay đổi và mở rộng hệ thống qua 
việc thay đổi và mở rộng mô hình Use Case, sau đó chỉ 
theo dõi riêng những Use Case đã bị thay đổi cùng 
những hiệu ứng của chúng trong thiết kế hệ thống và 
xây dựng hệ thống. 
50 
3. Mô hình hóa với Use Case 
Những công việc cụ thể cần thiết để tạo nên một mô hình 
Use Case bao gồm: 
1. Định nghĩa hệ thống (xác định phạm vi hệ thống) 
2. Tìm ra các tác nhân cũng như các Use Case 
3. Mô tả Use Case 
4. Định nghĩa mối quan hệ giữa các Use Case 
5. Kiểm tra và phê chuẩn mô hình. 
51 
4 Tạo lập biểu đồ Use Case 
trong Rational Rose 
52 
Tóm tắt 
1. Biểu đồ Use Case phân tích yêu cầu hệ thống 
2. Tập hợp yêu cầu hệ thống 
3. Biểu đồ Use Case 
4. Mô hình hóa với Use Case 
53 
DISCUSSION – CÂU HỎI 
https://sites.google.com/site/daonamanhedu/teac
hing/objectorientedanalysisanddesign 
54