Bài 2: Mô hình use-case

2.1 Mở đầu
Sự thiếu hiểu biết giữa khách hàng và nhà thiết kế hệ thông tin thường dẫn đến định nghĩa
không chính xác yêu cầu của khách hàng. Sự khác nhau giữa mô hình bài toán và lời giải, cũng
như sự biến đổi giữa chúng thường là nguyên nhân dẫn đến những sai sót trong lúc giải thích vấn
đề. Những sai sót thường gặp đó là: hoàn toàn không hiểu yêu cầu của khách hàng hoặc hiểu
không đến nơi đến chốn các yêu cầu đó. Phương pháp phổ biến để giải quyết vấn đề này đó là
mô hình hóa các trường hợp sử dụng (mô hình use-case), nhờ nó chúng ta có thể xác định được
chức năng của hệ một cách đơn giản, dễ hiểu hơn đối với những người tham gia thiết kế.
Phương pháp này cho phép xây dựng một ngôn ngữ để có thể trao đổi thông tin giữa các bên.
Sự đơn giản của mô hình use-case là nguyên nhân chính dẫn đến việc sử dụng nó không chỉ làm
cơ sở để ký hợp đồng giữa khách hàng và nhóm thiết kế mà còn là cơ sở cho cả quá trình tạo nên
sản phẩm (ví dụ. Rational Unified Process là quá trình được tạo nên từ mô hình use-case).
Các khái niệm cơ bản sử dụng trong mô hình use-case sẽ được giới thiệu ở phần một. Sau đó
chúng ta sẽ nghiên cứu các tác nhân (actor), mối liên hệ giữa các use-case và mối liên hệ giữa
các tác nhân. Cuối cùng bốn bước liên tiếp trong quá trình xây dựng mô hình use-case sẽ được
trình bày.

2.2 Khái niệm cơ bản

Mô hình use-case sử dụng các khái niệm cơ bản trình bày trong Bảng 1

Khái niệm Ý nghĩa Ký hiệu

Tác nhân Người (hoặc vật nào đó) không phải là hệ có (1) Dạng chuẩn:
(actor) ảnh hưởng qua lại với hệ.

Tác nhân đại diện cho người sử dụng hệ như

là một hệ toàn vẹn, hoặc như một hệ thành
phần (hệ con hoặc thậm chí chỉ là một lớp C lie n t
trong hệ). Người sử dụng có thể là thực thể
bất kỳ trong vùng lân cận của hệ mà đang
cần nghiên cứu chức năng. Tác nhân có thể
đưa cho hệ một nhiệm vụ (ví dụ nhận đơn từ,
nộp đơn đặt hàng, gửi thông tin đến đối (2) Với sự sử dụng ký
tượng và/hoặc cùng hoạt động với hệ để thực hiệu phân loại và
hiện nhiệm vụ đó. Từ “hoặc” được dùng đối
hiện nhiệm vụ đó. Từ “hoặc” được dùng đối stereotype ở dạng chữ
với tác nhân bị động, chỉ có nhiệm vụ nhận viết
dữ liệu tạo ra trong lúc thực hiện nhiệm vụ
được đặt ra bởi nhân khác.

Tác nhân phải có tên riêng, không trùng lặp «actor»

với các tên khác.
Client
Các câu hỏi thường gặp:

1.Hệ có thể là tác nhân của chính nó được

không? Vì theo DN, tác nhân chính là thực
(3) Với sự sử dụng ký
thể ở trong vùng lân cận của hệ.
hiệu chuẩn cho sự phân
loại và stereotype ở dạng
Câu hỏi trên thường được đặt ra cho các biểu tượng:
nhiệm vụ được giao bởi các tác nhân có tên
hệ con theo thời gian (time subsystem), có
nghĩa là một đoạn (fragment) của hệ (giả sử
chức năng của cả hệ đang được nghiên cứu).
Nên dùng thêm từ thời gian để chỉ các tác Client
nhân đó – thực thể phi vật chất trong vùng
lân cận của hệ, có ảnh hưởng một đoạn của Các ký hiệu khác:
hệ.

(1) chỉ tác nhân của hệ

2.Tác nhân đó là nhân tố gây nên các use- khác, đang cùng hoạt
case, có nghĩa là, nó là nhân tố dẫn đến sử động với hệ đang xét:
khởi động các use-case, tính cả người gửi
và người nhận dữ liệu đến và đi từ use-
case. Tác nhân đó lả người gây ra sự kiện?
Vậy khách hàng, nếu không được quyền
sử dụng trực tiếp hệ thống có được coi là
tác nhân của hệ thống không?

Insurance
Vậy khách hàng được coi là tác nhân hoặc system
không phải là tác nhân đối với hệ, điều đó
phụ thuộc vào mức độ trừu tượng. Nói chung
khách hang không có quyền sử dụng trực
tiếp các chức năng của hệ được coi là các tác (2) chỉ tác nhân mô hình
nhân thương mại, không phải là tác nhân con theo thời gian:
trong mô hình use-case.
 The 1st day of a
year

Use-case Tác nhân có thể có ảnh hưởng qua lại với hệ

nhiều cách khác nhau. Mỗi cách sử dụng có
Place an
tên riêng của use-case và nó biểu diễn một
chuỗi các hành động được thực hiện bởi hệ order
thống. Nhờ đó tác nhân sẽ nhận được các
kết quả cần thiết. hoặc

• Hành động đó là thao tác atomic (có

nghĩa là hoặc thực hiện toàn bộ hoặc Place an order
không thực hiện) được thực hiện để trả
lời các tín hiệu từ phía tác nhân hoặc từ
các hiện tượng liên quan đến sự trôi
qua của thời gian. Hành động sẽ truyền
tín hiệu đến tác nhân, gây nên hoạt
động đó hoặc đến các tác nhân khác.
• Chuỗi hành động xuất hiện để trả lời
một chuỗi các sự kiện diễn ra giữa tác
nhân và hệ. Chuỗi hành động được
nhóm lại trong các use-case.
• Chuỗi hành động thực hiện bởi hệ
thống – dùng để chỉ giới hạn của hệ và
xác định phạm vi trách nhiệm của nó.
Tất cả những gì thực hiện bởi hệ được
định nghĩa một cách rõ ràng (khác với
hành động của thế giới bên ngoài và nó
được phân biệt một cách rõ ràng).
• Khái niệm kết quả trông thấy định
nghĩa chuỗi hành động kết thúc bằng
một kết quả nào đó có giá trị thiết thực
cho tác nhân. Thực hiện nhiều use-case
chỉ để nhận một kết quả trông thấy là
hành động không được khuyến khích
(ví dụ: sử dụng vài use-case khác nhau
để cùng đưa đến một kết quả: ghi lại
tất cả các đơn đặt hàng). Việc chọn
use-case để đưa đến kểt quả trông thấy
 sẽ giúp chúng ta chọn được trường hợp
thực sự cần thiết và dễ hiểu đối với
người sử dụng.
• Tác nhân cụ thể – giá trị thiết thực (kết
quả trông thấy) được chuyển đến cho
một nhóm người sử dụng xác định; Ý
nghĩa của nó phụ thuộc vào vai trò
chứ không phải người cụ thể nào.

Use-case phải có tên riêng, không được

trùng với các tên khác, và phải xác định rõ
rang mục đich sự tồn tại của nó (kết quả
trông thấy). Cần phải tránh các tên gọi gợi ý
các hành động được thực hiện bởi tác nhân
trong vùng lân cận hệ (không được sự hỗ trợ
của hệ), hoặc những hành động kéo dài theo
thời gian. Theo một số nhà phương pháp học
tên “use-case” cần phải mô tả hành động (ví
dụ „nộp đơn đặt hàng”), đối với một số
người nó phải mô tả các lệnh (ví dụ „hãy nộp
đơn đặt hàng”).

Một tập đầy đủ các use-case định nghĩa chức

năng hoàn hảo của hệ. Mỗi trường hợp cụ
thể biểu diễn một chuỗi sự kiện đặc trưng, nó
xác định một đoạn của hệ.

Tương tác Để đánh dấu tương tác qua lại giữa tác nhân (1)
qua lại giữa và use-case người ta sử dụng đường liền (1).
tác nhân và Để xác định hướng di chuyển sự kiện người
use-case. ta sử dụng đường liền có hướng (2); grot chỉ
thực thể (tác nhân hoặc use-case), gây nên sự
kiện. Tương tác ký hiệu bằng dấu (3), đó là (2)
tương tác tương đương (1), không sử dụng.

(3)
 Khối sử dụng Biểu diễn đoạn hệ thống, được sử dụng bởi
lại vài use-case. Khối sử dụng lại có thể là một
use-case riêng biệt, cho phép
Khái niệm Client
này không Đánh dấu tương tác có thể tác nhân với use-
nằm trong authorization
case. Tương tác của tác nhân với khối sử
chuần UML, dụng lại trong ý nghĩa thông thường (như là
mặc dù nó có chức năng phụ cho các use-case khác và nó
ích cho sự mô không sử dụng được bởi các thực thể ở ngoài
tả chức năng hệ (ký hiệu trên biểu đồ bằng hình chữ nhật,
phụ, đặc biệt không phải hình elip)), bị nghiêm cấm.
quá trình xác
định cấu trúc
của hệ thiết
kế.

Quan hệ gữa Quan hệ «include» và «extend» biểu diễn «include»

các use-case mối liên kết xảy ra giữa các use-case và khối
dùng lại; khái niêm này sẽ được đề cập đến ở «extend»
phần tiếp theo.

Hình 1. Khái niêm mô hình use-case

2.3 Ngữ cảnh của hệ thống

Mô hình hóa các use-case yêu cầu các nhà phân tích phải xác định tất cả các tác nhân sử dụng hệ
đang thiết kế, có nghĩa là xác định nhưng người sử dụng tiềm tàng (nói cách khác: ngữ cảnh của
hệ thống). Thường tác nhân là một người, nhưng đó cũng có thể là một tổ chức (ví dụ: văn phòng
luật) hoặc một hệ thông tin khác. Tác nhân mô hình nhóm người có cùng một nhiệm vụ nào đó,
chứ không phải người cụ thể nào. Ví dụ, theo hình 1, một người cụ thể có thể tương tác với hệ từ
vị trí của nhiều tác nhân: có thể vừa là „người quản lý hệ”, vừa là „một khách hàng”. Và ngược
lại, một tác nhân có thể tương đương với nhiều người cụ thể, ví dụ tác nhân „Người được báo
tin”
 User Actor Use case
can play a role of orders

Jan Kowalski System administrator Reboot system

Adam Malina Employee Enter with authorization

Get general
Concrete guest Informed person
information

Concrete client Client Withdraw money

Hình 1. Biểu diễn sự khác nhau giữa khái niệm tác nhân và người sử dụng hệ.

2.4 Kịch bản use-case

Nguyên tố cơ bản để mô tả use-case đó là xác định dòng sự kiện xảy ra giữa tác nhân và hệ.
Dòng sự kiện cần phải được mô tả bằng ngôn ngữ tự nhiên: dễ hiểu, dùng từ ngữ nằm trong từ
điển khái niệm thuộc miền vấn đề. Ví dụ dòng sự kiện giữa tác nhân và hệ cho use-case „trả tiền”
trong hệ hỗ trợ máy tự động thu trả tiền, có thể mô tả như sau:
1. use-case bắt đầu khi khách hàng cho thẻ vào máy. Hệ đọc thông tin trên thẻ và kiểm tra độ
chính xác của nó.
2. Hệ hỏi mã số (PIN). Khách hàng đưa mã số. Hệ kiểm tra xem mã số có khớp không.
3. Hệ hỏi thao tác nào sẽ được thực hiện. Khách hàng chọn: “Trả tiền”.
4. Hệ hỏi số tiền là bao nhiêu. Khách hàng đưa số tiền.
5. Hệ sẽ nối với ngân hàng để kiểm tra ID của tài khoản và số tiền có khách có thể nhận.
6. Hệ hỏi khách hàng có cần lấy hóa đơn. Bước này chỉ có thể thực hiện được nếu trong máy
có giấy để in.
7. Hệ báo với khách hàng để lấy lại thẻ. Khách hàng lấy thẻ. Tín hiệu báo lấy lại thẻ là cơ chế
giúp cho sự an toàn của khách hàng, không quên thẻ.
8. Hệ trả tiền.
9. Hệ in hóa đơn (nếu khách hàng yêu cầu) và kết thúc use-case.
Có nhiều dòng sự kiện có thể xảy ra, nó phụ thuộc vào:
• Dữ liệu cung cấp bởi tác nhân, ví dụ: tác nhân có thể hủy cuộc giao dịch vào bất cứ lúc
nào hoặc không cần lấy hóa đơn.
• Trạng thái của hệ: ví dụ máy tự động có thể có tiền hoặc cũng có thể hết tiền, có thể hết
giấy in, có thể bộ phận trả tiền bị hỏng, cũng có thể hỏng bộ phận in.
• Quá thời gian cho phép: ví dụ khách hàng không trả lời sau thời gian đã qui định, hệ có
thể hủy bỏ giao dịch.
Không nên coi mỗi một quá trình như một use-case riêng – chúng ta nên gộp tất cả các quá trình
liên quan vào một trường hợp. Một nhóm các quá trình có liên quan gọi là lớp use-case (thay vì
use-case). Lớp use-case xuất hiện khi có nhiều hơn một khả năng xảy ra. Sự xuất hiện của lớp
use-case được gọi là kịch bản use-case. Kịch bản dùng để khai thác từ use-case các chuỗi hành
động có thể xảy ra, nói cách khác: các khả năng của use-case.
Trong các bước đầu phát triển hệ, tốt nhất nên bắt đầu từ một kịch bản cụ thể, sau đó thêm vào
các khả năng khác có thể xảy ra, từ đó tạo nên lớp sử dụng. Hành động dẫn đến kết quả trông
thấy nên gộp lại thành nhóm để có thể cùng quan sát, sửa đổi, kiểm tra (nói chung, coi nó là một
đơn vị trong suốt chu kỳ sống của sản phẩm). Điều đó không tương đương với chức năng chia
nhỏ, mà ta có thể dễ dàng đánh mất cái mốc, đó là kết quả cần phải được đem lại cho khách
hàng.
Xây dựng use-case cần ngiên cứu kỹ tập tương tác giữa người sử dụng và hệ thống, kịch bản mô
tả một hay nhiều use-case. Cơ sở để phân biệt trạng thái trả lời hay trạng thái hỏi. Hệ có cung cấp
các giá trị có tác dụng thiết thực với người sử dụng không? Ví dụ trong trường hợp máy trả tiền
tự động ở ngân hàng, câu hỏi có thể đặt ra như sau: Khách hàng có thấy hài lòng, nếu sau khi
kiểm tra thẻ hệ thông báo là thẻ có giá trị và sau đó trả thẻ, không hỏi gì về lượng tiền phải trả
cũng như không trả tiền?
Xây dựng kịch bản rõ ràng và xác định duy nhất một chuỗi tương tác giữ tác nhân và hệ là một
bài toán khó, đặc biệt là trong trường hợp có nhiều khả năng khác nhau. Nhiệm vụ đó càng trở
nên khó hơn nếu kịch bản phải viết bằng ngôn ngữ thông thường. Một số nhà phân tích đề nghị
sử dụng dạng Bảng 2 để ghi chép kịch bản.

Tên use-case

Tác nhân

Kịch bản chính

Kịch bản phụ số một

Kịch bản phụ số hai

...

Bảng 1. Kịch bản được ghi ở dạng bảng

Sơ đồ trên trông rõ ràng nhưng khó có thể tưởng tượng là nó có thể mô tả các trường hợp khó, ví
dụ các trường hợp với nhiều mạch xen kẽ (alternative thread). Mỗi kịch bản phụ để tránh sự
không rõ ràng, nhiều nghĩa, cần phải định nghĩa đầy đủ cả quá trình, điều đó có thể dẫn đến sự
lặp lại nhiều đoạn kịch bản. Ngoài ra trong cách ghi này, khó có thể tìm ra các luồng chảy con,
cần thiết trong các bước tiếp theo để có thể gộp chúng thành khối sử dụng lại. Tồn tại cách khác
tốt hơn, đó là chia riêng hai phần:
• Luồng sự kiện chính và
• Luồng sự kiện có thể xuất hiện xen kẽ
Trong lúc xác định hai loại mạch này chúng ta có thể đánh dấu các chuỗi tương tác bằng các số
tự nhiên liên tiếp, bằng cách đó có thể phát hiện ra các đoạn kịch bản bị nhắc lại. Các luồng sự
kiện con nên được coi như là các nhóm chức năng trong ngôn ngữ lập trình, có nghĩa là khi trở
về từ luồng sụ kiện con lệnh thực hiện tiếp theo sẽ là lệnh xuất hiện sau lệnh vừa gọi luồng sự
kiện đó.

2.5 Xây dựng cấu trúc use-case

Cấu trúc use-case được xây dựng dựa vảo việc phân tích luồng sự kiện. Nói chung cấu trúc use-
case không thể thiếu trong quá trình thiết kế hệ, nó giúp các hoạt động như: lập kế hoạch, xác
định quyền ưu tiên và phỏng đoán kết quả không gây khó khăn cho quá trình thực hiện đề án.
Cấu trúc use-case thường được xây dựng dựa trên các gói trường hợp (packet) và mối quan hệ
giữ chúng: include, extend và khái quát hóa các chi tiết kỹ thuật. Lỗi cơ bản mà chúng ta thường
mắc phải đó là lạm dụng mối quan hệ include, extend và khái quát hóa. Điều đó có thể dẫn đế
mô hình khó hiểu, khó chăm sóc. Một cách gián tiếp nó làm cho đề án tốn kém hơn.

2.5.1 Gói use-case

Gói use-case gộp các trường hợp vào một công-ten-nơ. Gói use-case đóng vao trò quan trọng
trong các đề tài lớn, chứa nhiều đơn vị chức năng có liên quan lẫn nhau và được tạo nên nhiều
nhà thiết kế. Sử dụng gói giúp cho việc cất giữ, sửa đổi các thành phần của mô hình được dễ
dàng hơn. Sự phân chia ra các gói có ý nghĩa lớn không những trong quá trình tạo nên mô hình
trường hợp mà còn rất có ích trong sản phẩm phần mềm.

2.5.2 Include và extend

Luồng sự kiện có thể biểu diễn ở dạng chuỗi các dòng chảy con: gồm một dòng chính và nhiều
dòng phụ. Cùng một dòng phụ có thể lặp lại trong nhiều use-case khác nhau, vì vậy có thể tách
nó ra như các trường hợp riêng biệt. Trong khi mô tả các chuỗi trường hợp, chúng ta có thê nối
hai trường hợp với nhau sử dụng một trong hai mối quan hệ: include hoặc extend. Nguyên tăc
này cũng có thể sử dụng với các khối sử dụng lại.
Trong cả hai sơ đồ (Hình 1 và Hình 2), P1 được gọi là trường hợp cơ sở, nó phải được thực hiện
đầu tiên. Sơ đồ không xác định, lúc nào trong khi thực hiện trường hợp P1, trường hợp P2 sẽ
được gọi:
• Tiến trình cơ bản (Hình 2): Trường hợp cơ bản P1 luôn gọi P2 - được gọi là trường hợp
chuyển.

«include»
P1 P2

Hình 1. Tiến trình cơ bản

• Tiến trình không bắt buộc (Hình 3): Thỉnh thoảng P1 được mở trộng thêm bởi P2 - gọi là
trường hợp mở rộng. Giới từ „thỉnh thoảng” có nghĩa là điều kiện đặt ra khi gọi P2 phải
được thỏa mãn. Nếu điều kiện gọi P2 không được định nghĩa thì P2 được gọi vô điều
kiện.
 «extend»
P1 P2

Hình 3. Tiến trình không bắt buộc

Sơ đồ trên hình 4 biểu diễn use-case sai mối quan hệ „extend” nối hai trường hợp „Nộp đơn đặt
hàng” và „Thực hiện đơn đặt hàng” , giả sử rằng hai use-case này không thể thực hiện trong
cùng một tiến trình. Giới hạn không cho phép nối các trường hợp không thể xuất hiện trong cùng
một tiến trình liên quan đến cả hai loại quan hệ.

Place an order

«extend»
Client
Supplier

Process an order

Hình 2. Biểu diễn sự xử dụng không đúng mối quan hệ „extend”.

Trên hình 5 chúng ta có ví dụ sơ đồ chứa các điểm mở rộng. Trong sơ đồ này chúng ta có thể
định nghĩa các điều kiện khi sử dụng trường hợp mở rộng.

Car repair

extension points:
Car is out of repair shop
Car needs review
extension point:
«extend» Car needs review

«extend»
extension point:
Car is out of Car review
repair shop
extension points:
Car is dirty
Car towing

«extend»

extension point:
Car wash Car is dirty

Hình 3. Hình vẽ biểu diễn các điểm mở rộng

Tóm lại include và extend được sử dụng với mục đích:
• Đơn giản hóa các tiến trình sự kiện phức tạp.
• Biểu diễn các trường hợp không bắt buộc.
• Sử lý các trường hợp đặc biệt.

2.5.3 Khái quát hóa – chi tiết hóa use-case

Khái quát hóa – chi tiết hóa dựa trên cơ sở tìm ra các yếu tố giống nhau trong các use-case. Nó
dùng để thiết kế tối ưu các luồng sự kiện. Mối quan hệ này là phương tiện để có thể đơn giản hóa
mô hình xương sống và các trường hợp ứng dụng. mối quan hệ khái quát hóa – chi tiết hóa định
nghĩa cho khái niệm tác nhân sẽ được trình bày cụ thể ở chương sau.

2.6 Ví dụ các sơ đồ use-case

Trên hình 6 và 7 chúng ta có sơ đồ ví dụ của 2 hệ thống phục vụ máy tự động bán thuốc lá và
máy thực hiện các lệnh của ngân hàng.

ud Cigarettes selling machine

Refill
comodity

Sell Execute money

cigarettes transaction
Client Operator

Create report

Controler

Hình 4. Sơ đồ use-case của máy bán thuốc lá tự động.

Chúng ta để ý rằng sơ đồ use-case của máy bán thực hiện các lệnh của ngân hàng không thỏa
mãn yêu cầu về độ rõ ràng bởi vì trong sơ đồ này, các đường chỉ mối tương tác giữa tác nhân và
hệ cắt nhau. Không nên coi thường sự rõ ràng của sơ đồ, bởi vì nó là nhân vật trung gian giúp
cho sự truyền đạt thông tin giữa các thành viên trong nhóm thiết kế cũng như giữa nhóm thiết kế
và khách hàng đơn giản hơn.

ud Bank operations machine

Database Client’s account

management service
«include»
subsystem

«include»
Account’s balance Client’s card
information and code
verification
Client

Client’s card «include»

initialization

System
administrator

Hình 7. Sơ đồ use-case cho máy thực hiện các lệnh của ngân hàng.

2.7 Phát triển mô hình use-case

Chúng ta hãy nghiên cứu sơ đồ use-case trong hình vẽ 8

Deposit money
?

Client Withdraw money

Hình 8. Sơ đồ ví dụ use-case.

Trường hợp khách hàng tự rút tiền đã được giải quyết. Tuy vậy trường hợp khách hàng tự trả
tiền vẫn còn là vấn đề mở. Giả sử rằng khách hàng không có quyền sử dụng chức năng liên quan
đến việc trả tiền. Cần phải định nghĩa một tác nhân mới, ví dụ thủ quỹ. Trên sơ đồ ở hình 9, tác
nhân thủ quỹ được ghi thêm như là một nguyên tố phát triển mô hình.
 Deposit money

Cashier

Client Withdraw money

Hình 5. Mô hình được mở rộng thêm một tác nhân mới.

ud Bank system

Deposit
money

Withdraw Cashier
money

Bank Check account

client balance

Management
Take a loan

Hình 6. Mô hình được phát triển thêm các tác nhân mới, các use-case kế tiếp, sơ đồ đóng khung
cùng tên gọi của nó.

Sơ đồ có thề tiếp tục mở rộng bằng cách cho thêm các tác nhân mới, các use-case mới, khối sử
dụng lại hoặc các mối quan hệ giữa các use-case cũng như giữa use-case và khối sử dụng lại
(Hình 10 và 11). Ngoài ra có thể có thể đóng khung sơ đồ và đặt tên cho hệ.
 ud Bank system

Deposit
money Cashier

«include»

Withdraw
money
«extend»
«include»
Update account
balance

Bank
client Check account
balance

Take a loan
Management

Hình 7. Mô hình được mở rộng thêm khối sử dụng lại và mối quan hệ giữa các use-case.

2.8 Độ chi tiết của mô hình use-case

Mô hình use-case đó là mô hình hệ thống, được nhìn từ góc độ trừu tượng – góc độ của tác nhân
sử dụng hệ. Tác dụng cơ bản của mô hình này (mặc dù nó không phải là duy nhất), đó là nói
chuyện với khách hàng tương lai, mục đích là xác định chính xác yêu cầu của khách hàng. Mô
hình không được chi tiết quá cũng không được cụ thể quá: quá chi tiết sẽ khó nghiên cứu, quá
tổng quát sẽ không phát hiện được các khối sử dụng lại. Theo kinh nghiệm thực tế, sơ đồ use-
case nói chung không xác định một cách chính xác và là mô hình chủ quan, vì vậy nội dung lẫn
độ chi tiết của nó phụ thuộc vào kinh nghiệm của nhà phân tích. Nói chung các nhà phân tích
khác nhau tạo nên các mô hình khác nhau (xem Hình 12 và 13). Cần nhớ rằng nhận định trên có
ý nghĩa tổng quan không cho mọi loại mô hình chứ không chỉ mô hình use-case.
 Edit
program Compile
program

«include»

«include»

Execute
program
Programmer User

Print file

Hình 8 Sơ đồ ví dụ use-case.

«extend»

Edit
program Compile
program

«extend»

Execute
program
Programmer User

Print file

Hình 9. Dạng khác của sơ đồ 12.

2.9 Xây dựng mô hình use-case

Mô hình use-case được biểu diễn bằng tập các use-case và tập các tác nhân có tương tác với hệ
qua các use-case đó. Mô hình giúp chúng ta mô tả chức năng của hệ. Điều đó có nghĩa là trong
bước xây dựng mô hình use-case chúng ta phải tập trung vào các yêu cầu chức năng, còn các yêu
cầu không chức năng (vd. Sự sử dụng song song nguồn dữ liệu chung trong lúc tương tác giữa
các trường hợp) có thể bỏ qua. Nhiệm vụ chính của mô hình là mô tả đúng chức năng của hệ cần
thiết kế, còn các nhiệm vụ khác không chức năng chỉ là các điều kiện bổ sung. Các chức năng
này được chú ý tới trong lúc thiết kế hệ. Để bảo đảm các ký hiệu được thống nhất trong quá
trình tạo mô hình, chúng ta phải lập ra một từ điển các khái niệm liên quan đến miền vấn đề hoặc
mô hình đối tượng đơn giản của miền vấn đề. Mô hình use-case được xây dựng dựa trên bốn
bước (Hình 14) và trong quá trình xây dựng mô hình sự hợp tác với khách hàng được yêu cầu
mật thiết. Điều đó suy ra từ nghuyên tắc: „Không nên mô tả các trường hợp khó hiểu đối với
người sử dụng”.

Following steps are documented in

1 Establish glossary
Notion glossary

2 Determine actors

Actors definition document

3 Determine use cases

Create description for each use

case and: Use case diagram with
4
split use case into named parts detailed description for

search for common parts in each use case
different use cases

Hình 10. Các bước kế tiếp trong xây dựng mô hình truường hợp.

2.9.1 Bước 1: Lập từ điển khái niệm

Từ điển khái niệm liên quan đến miền vấn đề. Lập từ điển cần bắt đầu từ bước xây dựng mô hình
use-case cho hệ thống cần thiết kế. Trong lúc lập từ điển cần chú ý tới các điểm sau:
• Xây dưng từ điển đó là chắt lọc từ yêu cầu của người sử dụng những khái niệm, có liên
quan đế tác nhân, use-case, đối tượng, các phép toán, sự kiện,...
• Các khái niệm trong từ điển cần được định nghĩa một cách chính xác và duy nhất.
• Sử dụng các khái niệm trong từ điển phải trở thành nguyên tắc khi mô tả các vần đề tiếp
theo và xây dưng mỗi mô hình tiếp theo.
Dưới đây chúng tôi cho ví dụ từ trong từ điển khái niệm:
„Tài khoản – sử dụng để ghi lại lượng tiền và kết quả dao dịch được thực hiện bởi khách hàng là
chủ của tài khoản. Tài khoản có thể có nhiều loại: ví dụ tài khoản riêng, tài khoản chung của vợ
chồng, của hãng. Một khách hàng có thể có nhiều tài khoản.”
Khi chọn khái niệm vào từ điển cần chú ý:
• Danh từ: có thể chỉ tác nhân hoặc thực thể từ miền vấn đề;
• Các từ chỉ hàm số, hành động, cách cư sử - chúng có thể là cơ sở để phân biệt các use-
case.
 Bước 2: Xác định tác nhân
Để xác định tác nhân điều quan trọng là trả lời các câu hỏi sau đây:

Nhóm khách hàng nào cần sự dụng sự giúp đỡ của hệ (ví dụ: người gửi thư, người nộp đơn đặt
hàng,...)?

Những đối tượng nào sẽ cần thiết cho hệ trong lúc hoạt động và thực hiện các nhiệm vụ của
mình (ví dụ người điều hành mạng)

Hệ phải sử dụng các yếu tố bên ngoài nào (ví dụ các hệ khác, phần tử nhạy, mạng,...) để có thể
thực hiện nhiệm vụ của mình?

Xác định tác nhân phải đi cùng với xác định với phạm vi trách nhiệm của hệ, có nghĩa là nhất
thiết phải xác định danh giới của hệ, tức là loại bỏ các miền vấn đề con, mà hệ không phục vụ.
Các tác nhân tiềm tàng cần được biểu diễn bằng hình ảnh sử dụng sơ đồ như trên hình 15.

Database
management
subsystem
«system»
System
Bank operations
administrator
machine

Client

Hình 11. Sơ đồ ngữ cảnh của máy thực hiện các lệnh của ngân hàng.
Sau đó trong bước kế tiếp cần xác định:
• Tên của từng tác nhân;
• Phạm vi ý nghĩa của từng tác nhân và mối quan hệ giữa các tác nhân, ví dụ: thư kí và nhân
viên quản lí, nhân viên quản lí và một nhân viên bất kỳ, nhân viên và một người bất kỳ.
Để cố thể làm đơn giản cấu trúc của sơ đồ và tăng sự mạch lạc (bằng cach giảm số lương
tương tác của tác nhân và use-case, từ đó dẫn đến giảm bớt số đường cắt trên sơ đồ), cần
phải xác định cấp bậc thừa kế của tác nhân đối với việc sử dụng hệ, tức là xây dựng cấu
trúc khái quát hóa- chi tiết hóa cho tác nhân. Ví dụ, trên Hình 16 tác nhân nhân viên quản
lí được thừa hưởng quyền dùng các use-case định nghĩa cho tác nhân nhân viên và có thể
sử dụng mọi use-case của chính bản thân mình. Trong hình 17 cấu trúc thừa hưởng của các
tác nhân được sử dụng với mục đích làm giảm số đường nối chỉ tương tác giữa các tác
nhân trong hệ.
 Person
inheritance
symbol

Employee Guest

Accountant Administrative
worker

Hình 12. Ví dụ cấu trúc thừa hưởng của các tác nhân

ud Bank operations machine

Database
management Client’s account
subsystem service
«include»

«include»
Account’s balance Client’s card
information and code
verification
Client
Client’s card «include»
initialization

System
administrator

Hình 13. Sơ đồ máy thực hiện các lệnh ở ngân hàng, sử dụng cấu trúc thừa hưởng của các tác
nhân

Bước 3: Xác định các use-case

Để tìm kiếm use-case các nhà phân tích cần chú ý:

• Đối với mỗi tác nhân cần xác định nhiệm vụ, cần phải thực hiện với mục đích bổ trợ hoạt
động trong miền vấn đề cũng như hoạt động của hệ.
 • Trong bước đầu tiên càn xác định “nhiệm vụ chính”, tức là các nhiệm vụ có ý nghĩa
chính cho việc hợp tác với hệ (đó là các sử dụng chuẩn). Bỏ qua các hành động đặc biệt,
bổ sung hoặc không bắt buộc

• Nhóm các nhiệm vụ có mục đích giống nhau thành một use-case, Bằng cách đó có thể
trách chia một use-case ra thành nhiều trường hợp con (nhất là trong các bước đầu tiên
xây dựng mô hình)

• Sắp xếp theo thứ tự tác nhân và use-case ở dạng sơ đồ.

• Phân tích lại các use-case đã đặt ra (một số trường hợp có thể là trường hợp con của các
use-case khác), cũng như mối lien hệ giữ tác nhân và use-case. Xác đinh cái gggì có thể
thừa, cái gì có thể khái quát hóa.

• Xác định mối quan hệ qua lại giữa các use-case. Đối với mỗi loại quan hệ, xác định đó là
quan heeệ loại gì: cơ bản hay không bắt buộc?

• Bổ sung thêm các trường hợp phụ, đặc biệt, các trường hợp bổ sung, hoặc không bắt
buộc.

• Diễn tả use-case bằng ngôn ngữ tự nhiên, sử dụng cac thuật ngữ được định nghĩa ở trong
từ điển khái niệm. Cơ sở cho nhận định: mô hình đã đủ chi tiết chưa chính là câu trả lời
cho câu hỏi: tất cả nhóm thiết kế có hiểu nội dung của use-case không? Tài liệu mô tả nó
đã đủ cụ thể cho nhà thiết kế và người kiểm tra chương trình chưa?

• Chia mỗi use-case ra thành các khối, sao cho mỗi khối không quá tổng quát cũng không
quá cụ thể.

• Nghiên cứu các trường hợp đã đựoc định nghĩa dưới khía cạnh tách riêng các khối sử
dụng lại. Phân tích sự giống nhau về tên gọi của use-case cũng như sự giống nhau về tên
gọi và cách xử sự của các khối xuất hiện trong định nghĩa của nó. Sự tách khối sử dụng
lại có thể gắn liền với việc xác định các nhiệm vụ chính hoặc cho thêm các tính chất mới
cho các nhiệm vụ đã tồn tại.

Tên cho các use-case cần phải ngắn gọn, nhưng đồng thời phải xác định được đặc
điểm của bài toán. Các tên này phải thể hiện các hoạt động từ khía cạnh tác nhân, ví dụ:
”trả tiền” chứ không phải “nhận tiền từ khách hàng”.

Bước 4: Tài liệu mô tả use-case

Tài liệu mô tả use-case phải chứa đựng:
• Sơ đồ use-case: tác nhân, use-case và và quan hệ giữa các use-case.
 • Mô tả ngắn gọn và tổng hợp mỗi use-case:
 Khi nào và bằng cách nào use-case bắt đầu và kết thúc;
 Mô tả các tương tác giữ use-case và tác nhân: khi nào xảy ra tương tácvà thông tin gì
sẽ được gửi đi;
 Khi nào use-case cần đến các dữ liệu cất giữ trong hệ và với mục đích gì, và khi nào
nó sẽ ghi lại giữ liệu vào trong hệ và ghi như thế nào;
 Những ngoại lệ có thể xuất hiện trong lúc thực hiện use-case
 Các yêu cầu đặc biệt, vd. Thời gian cho phép cho một câu trả lời, năng suất;
 Khi nào các khái niệm trong miền vấn đề được sử dụng và nó được sử dụng như thế
nào.
• Mô tả cụ thể mỗi use-case:
 Kịch bản
 Sơ đồ hoạt động: Sơ đồ hoạt động sẽ được giới thiệu cụ thể trong một bài giảng riêng
liên quan đến vấn đề này.

Bảng 2 chứa bản mẫu để thiết lập tài liệu cho use-case. Bảng 4 mô tả use-case „Hãy cho mượn
đĩa” được đingh nghĩa cho hệ thống phục vụ cửa hàng mượn đĩa DVD (văn bản các yêu cầu
được ghi ở mục 2.12).

Tên Tên use-case

Số id Số thứ tự của use-case

Tác giả Thông tin về tác giả

Quyền ưu tiên Vd. Cao, thấp, trung bình

Dạng Vd. Tổng quát, cụ thể

Tác nhân Danh sách các tác nhân có liên quan đến use-case

Mô tả Ngắn gọn các tính chất đặc trưng của use-case

Điều kiện bắt đầu Thông tin: cái gì cần phải thực hiện trước đó để hệ có thể thực hiện
use-case đang xét.

Điều kiện kết thúc Các điều kiện sau khi thực hiện use-case

Luồng sự kiện chính Kịch bản chính

Luồng sự kiện không Kịch bản phụ có thể xảy ra

bắt buộc
bắt buộc

Các đòi hỏi không Vd. Thời gian cho phép cho một câu hỏi, tôc độ giao dịch, itd.
chức năng

Các chú ý thêm Giới hạn, thông tin thương mại

Bảng 2 Tài liệu ví dụ cho một use-case

Tên Hãy mượn đĩa

Số id 7

Tác giả Jan Kowalski – nhà phân tích

Quyền ưu tiên Cao

Dạng Cụ thể

Tác nhân Nhân viên cửa hang

Mô tả Use-case liên quan đến việc ghi chép các giao dịch mượn đĩa; nếu
đĩa dành cho người lớn thì chỉ người trên 18 tuổi co quyền được
mượn; một người có thể mượn nhiều nhất 5 đĩa; không được cho
mượn, nếu người đó đang ở trong thời gian „treo tài khoản”.

Điều kiện bắt đầu Người mượn phải có đăng ký là khách hàng của cửa hàng.

Điều kiện kết thúc Nếu các điều kiện mượn đĩa được thỏa mãn, thì các thông tin về
giao dịch phải được ghi lại: ai mượn, mượn gì và mượn khi nào.

Luồng sự kiện chính 1.Nhân viên cửa hàng khởi động use-case hãy cho mượn đĩa
2.Hệ yêu cầu đưa tên, họ người cho mượn đĩa. Nhân viên đưa các
thông tin cần thiết.
3.Hệ hỏi tên phim. Nhân viên đưa tên.
4.Hệ ghi lại thông tin về giao dịch mượn đĩa phim (ai mượn, đĩa
gì, ngày tháng mượn).
Luồng sự kiện không 2a Nếu người cho mượn không có quyên cho mượn (không có
bắt buộc đăng ký trong hệ) hệ sẽ thong báo với tác nhân và kết thúc use-
case.

2b. Nếu có nhiều hơn một người có quyền cho mượn đĩa, hệ sẽ
 đưa ra danh sách. Nhân viên sẽ chọn một người từ danh sách đó.

3a Nếu không có phim yêu cầu ở trong cửa hàng hoặc tất cả các
phim đó đã được mượn, hệ sẽ tang báo với tác nhân và kết thúc
use-case.

3b Nếu phim dành cho người lớn, người mượn nhỏ hơn 18 tuổi,
hệ thông báo điều đó với tác nhân và kết thúc use-case.

3c Nếu khách hàng đã mượn nhiều hơn 5 đĩa, hệ thông báo với tác
nhân và kết thúc use-case.

3d Nếu khách hàng đang ở trong thời kỳ treo tài khoản, hệ thông
báo với tác nhân và kết thúc use-case.

Các đòi hỏi không Không có

chức năng

Các chú ý thêm Không có

Bảng 3 Tài liệu mô tả use-case Hãy cho mượn đĩa của hệ phục vụ của hàng cho mượn đĩa DVD.

2.10 Ví dụ văn phòng luật sư

Trên hình 18 chúng ta có sơ đồ use-case được xây dựng dựa vào các yêu cầu cho hệ thống phục
vụ văn phòng luật.

Văn phòng luật sư:

Một văn phòng luật sư quyết định sử dụng hệ thống thông tin để tăng năng suất và chất lượng
hoạt động của văn phòng. Dựa vào các yêu cầu của các nhân viên văn phòng chúng ta sẽ tìm
cách thiết kế mô hình khái niệm:

1) Cần phải ghi lại thông tin về khách hàng và luật sư: tên (không vượt quá hai tên), họ, tên
thời con gái, địa chỉ và số điện thoại.

2) Đối với nhân viên, cần phải ghi lại thông tin về số năm công tác trong nghề.

3) Đối với các sự việc mà văn phòng giải quyết cần ghi lại thông tin như: ngày bắt đầu và
ngày kết thúc, sự việc liên quan đến vấn đề gì, sự việc có kết thúc tốt đẹp không, thông
tin về khách hàng và các luật sư tham gia giải quyết sự việc.
4) Cần phải ghi lại tất cả các ngày tháng và các phiên tòa liên quan đến sự việc. Trong sự
kiện mỗi phiên tòa phải có số riêng, không được trùng lặp.

5) Luật sư có thể bị thải việc trong lúc giải quyết vụ việc, cần phải ghi lại từ khi nào đến khi
nào luật sư tham gia giải quyết sự việc.

6) Trong một thời điểm luật sư chỉ có thể được chia một sự việc.

7) Cần phải chú ý rằng, luật sư cũng có thể là khách hàng của văn phòng, nhưng lúc đó
không được tham gia giải quyết sự việc mà người đó yêu cầu.

8) Sự việc có thể bị hủy bất cứ thời điểm nào; thông tin về các sự việc bị hủy không cần ghi
lại.

9) Thông tin về các sự việc phải lưu trữ trong hệ 10 năm sau khi sự việc kết thúc.

10) Hệ thông sẽ giúp văn phòng trong các công việc sau đây:

• Ghi lại các sự việc

• Phân chia luật sư cho các sự việc

• Ghi lại các phiên tòa

• Ghi lại kết thúc của sự việc

• Xác định danh sách các sự việc đã kết thúc thắng lợi trong thời gian đã cho.
 ud Law office

Register trial

Lawyer Register case «extend»

Assign lawyer to the case

«include»
Check if the lawyer is
Law office currently available
manager
Dismiss lawyer from the case

List cases met with success

Cancel case

10 years after
closing the case
Delete case

Hình 14 Sơ đồ use-case của hệ thống phục vụ văn phòng luật sư

2.11 Tóm lại

Mục đích chính của việc xây dựng mô hình use-case đó là để giúp các nhà phân tích xác định
chính xác yêu cầu chức năng của hệ thống cần xây dựng. Ngoải ra mô hình use-case cho phép:

• Hiểu rõ hơn các khả năng sử dụng hệ, điều đó giúp cho người sử dụng, cũng như nhà
phân tích và các nhà thiết kế thể hiểu rõ hơn mục đích và chức năng của hệ thống;

• Sự thong tin giữa các thành viên liên quan đến hệ thống (đại diện khách hàng, người sử
dụng hệ, thiết kế viên ) được rõ ràng, mạch lạc hơn;

• Xác định quyền sử dụng các dữ liệu của hệ (dựa trên tương tác giữa tác nhân và use-
case);

• Làm cơ sở để thiết kế giao diện với người sử dụng;

• Xác định một cách sơ lược cấu trúc của hệ, nhờ đó có thể xác định thành phần của hệ, từ
đó kế hoạch xây dựng hệ;
 • Cơ sở để đánh giá thời gian và phí tổn để thực hiện đề tài;

• Cơ sở để lên kế hoạch phát triển phần mềm;

• Cơ sở để lên kế hoạch kiểm tra hệ;

• Kiểm tra sự chính xác của các kết quả (trung gian) được tạo nên trong quá trình xây
dựng hệ;

Hình 15 cho thấy sự ảnh hường của mô hình use-case đến mô hình phân tích cũng như mô hình
miền vấn đề và ngược lại, có nghĩa là sự ảnh hường của mô hình miền vấn đề đến mô hình ứng
dụng và mô hình phân tích. Mô hình phân tích nói chung thường vượt ra ngoài phạm vi nhiệm
vụ của hệ thống, nó bao gồm cả các hoạt động chung với hệ bên ngoài.

Experts
Domain
experience Domain
model

Analytical
Use cases model of
system

Users

strong influence
weak influence

Hình 15 Biểu diễn mối quan hệ qua lại giữ các nhân tố cốt yếu của quá trình xây dựng hệ thông
tin.

2.12 Câu hỏi và các vấn đề tập giải quyết

1. Thực hiện các bài tập sau đây sử dụng tài liệu mô tả các yêu cầu của hệ phục vụ cửa hàng
cho mượn đĩa DVD:

• Lập từ điển khái niệm;

• Xác định tác nhân của hệ;

• Với mỗi tác nhân hãy tìm use-case (không đi vào các chi tiết cụ thể của mỗi
use-case);
 • Hãy xây dựng sơ đồ use-case dựa vào các tác nhân và các use-case được định
nghĩa;

• Hãy xây dựng cấu trúc các use-case dựa trên quan hệ giữa chúng: include và
extend;

• Hãy xây dựng cấu trúc đẳng cấp của các tác nhân;

• Hãy thay đổi sơ đồ dựa trên quan hệ giữa các tác nhân của hệ;

• Lập văn bản mô tả các use-case;

• Thay đổi cho phù hợp với hiện thực từ điển khái niệm;

2. Hãy thực hiện các bài tập sau đây cho một vài use-case (vd. use-case liên quan đến giao
dịch trả đĩa):
• Xây dựng kịch bản;
• Xác định khối sử dụng lại;
• Xây dựng sơ đồ use-case, đối với mỗi use-case cần chú ý các kết luận suy ra từ phân tích
kịch bản và các khối sử dụng lại;
• Hãy thay đổi văn bản mô tả use-case;
• Thay đổi cho phù hợp với hiện thực từ điển khái niệm.

Cửa hàng cho mượn đĩa

1. Hệ thống có nhiệm vụ lưu trữ các thông tin về khách hàng (tên, tuổi, địa chỉ, sổ điện thoại).
Khách hàng chỉ có thể là những người đẫ kết thúc 16 tuổi.
2. Hệ thống có nhiệm vụ lưu trữ các thông tin về nhân viên (tên, tuổi, ngày tháng năm sinh,
nơi sinh, địa chỉ, sổ điẹn thoại, ngày nhận việc, mức lương). Không được nhận nhân viên
chưa thành niên. Nhân viên cửa hàng có thể đồng thời là khách hàng, lúc đó mọi nguyên tắc
sử dụng cho nhân viên đó cũng giống như một khách hàng bình thường.
3. Hệ thống có nhiệm vụ lưu trữ các thông tin về phim và đĩa DVD của cửa hàng.
4. Thông tin về phim bao gồm: tên phim, ngày sản xuất, phim dài bao nhiêu phút, các diễn viên
chính và số tiền phải trả khi mượn phim. Phim dành cho người lớn chỉ có thể cho người đã
kết thúc 18 tuổi mượn.
5. Cùng một phim có thể có nhiều đĩa. Trên một đĩa chỉ có thể có một phim. Hủy một phim có
nghĩa là hủy tất cả các đĩa có chứa phim đó.
6. Thông tin về giao dịch mượn đĩa bao gồm: ngày mượn, ngày trả và tiền số phải trả khi mượn
phim. Khách hàng phải trả tiền ngay khi mượn phim. Khách hàng có thể quyết định ngày trả
đĩa, các đĩa khác nhau có thể có ngày trả khác nhau.
7. Mỗi lần mượn có thể mượn vài đĩa nhưng không được vượt quá 3 đĩa.
8. Khách hàng có thể giữ nhiều nhất 5 đĩa trong một thời điểm.
9. Trong trường hợp giữ đĩa quá lâu, số tiền phải trả cho một ngày giữ đĩa sẽ tăng theo một
phần trăm nào đó so với giá tiêu chuẩn. Phần trăm đó sẽ tăng dần theo số ngày quá hạn,
nhưng không được vượt quá 100% số tiền qui định.
10. Người mượn bị 3 lần quá hạn sẽ mất quyền mượn đĩa; thời gian „mất quyền sử dụng” kéo dài
một năm.
11. Hàng ngày phải viết tường trình về các sự kiện xảy ra ở cửa hàng: số lượng đĩa được mượn,
số lượng đĩa được trả, số lượng đĩa hiện đang được mượn và số tiền thu được.
12. Thỉnh thoảng viết tường trình kết về hoạt động của cửa hàng trong một thời gian nào đó (các
khoảng thời gian có thể giao nhau), chứa các thông tin về các đĩa thường hay được mượn và
các diễn viên nổi tiếng.
13. Với mỗi bản tường trình, cần ghi lại ngày ghi chép.
14. Các bản tường trình phải được sắp xếp theo thời gian.