Mô hình Kiến trúc Hướng Dịch vụ với Kiến trúc sư Phần mềm Rational:
Phần 4. Các mô hình tình huống sử dụng
Bertrand Portier, Kiến trúc IT, IBM Software Group Services
Gregory Hodgkinson, Đầu ngành SOA, Prolifics
Tóm tắt: Hướng dẫn thứ tư trong loại bài này trình bày mô hình tình huống sử
dụng. Nó vẫn tiếp tục sử dụng nghiên cứu tình huống cụ thể của một công ty cho
thuê DVD trực tuyến tưởng tượng đã giới thiệu trong ba phần trước và bạn sẽ s
ử
dụng bản Kiến trúc sư Phần mềm Rational® của IBM® để tạo ra mô hình tình
huống sử dụng dựa vào việc nghiên cứu tình huống cụ thể đó.
Trước khi bạn bắt đầu
Hãy tìm hiểu xem hướng dẫn này mang lại những gì và làm thế nào để sử dụng nó
tốt nhất.
Về loạt bài này
Loạt bài này cung cấp một cái nhìn chi tiết về mô hình hóa các kiến trúc hướng
dịch vụ (SOA) bằ
ng cách sử dụng Kiến trúc sư phần mềm Rational® của IBM®.
Mặc dù mục tiêu chủ yếu là nhằm vào các kiến trúc sư phần mềm và các hoạt
động mà họ thực hiện, nhưng hướng dẫn này cũng rất có ích cho những người đảm
nhiệm các vai trò khác trong quá trình phát triển phần mềm, bao gồm cả những
người cung cấp đầu vào cho kiến trúc phần mềm, ví dụ như các nhà phân tích
nghiệp vụ và cả những ng
ười sử dụng kiến trúc phần mềm làm đầu vào để thực
hiện các hoạt động của mình, ví dụ như là các nhà thiết kế và phát triển phần mềm
(hiểu rõ nó, thiết kế, và thực thi). Loạt bài này cũng trình bày nhiều khái niệm
SOA cốt lõi mà nhiều người khác quan tâm.
Bạn sẽ tìm hiểu cách làm thế nào để thực hiện ba điều này, trong các lĩnh vực sau:
• Kiến trúc. Mô tả SOA bao gồm những gì và nó thể hiện ở đâu trong toàn
bộ quá trình phát triển phần mềm.
• Các dịch vụ. Thiết kế kiến trúc dịch vụ cho một giải pháp có sử dụng SOA.
• Các mô hình. Giới thiệu cách công cụ Kiến trúc sư Phần mềm Rational hỗ

trợ một phương pháp tiếp cận phát triển dựa vào-mô hình (MDD) đối với
đặc tả kỹ thuật kiến trúc hướng dịch vụ như thế nào.
Sau khi mô tả kiến trúc phần mềm và xác định vị trí của các dịch vụ trong kiến
trúc phần mềm, loạt bài này giới thiệu Kiến trúc sư Phần mềm Rational và các đặc
tính có liên quan đế
n SOA- và kiến trúc-của nó.
Các hướng dẫn này sử dụng nghiên cứu tình huống cụ thể của một công ty cho
thuê DVD trực tuyến tưởng tượng với ba mục đích chính:
• Mô tả các vật phẩm làm việc được sử dụng như là đầu vào cho các hoạt
động kiến trúc dịch vụ, bao gồm mô hình thành phần nghiệp vụ, mô hình
quy trình nghiệp vụ, mô hình tình huống sử dụng hệ thống, phần hệ thống
bên ngoài của mô hình thiết kế.
• Mô tả từng bước cách thức một mô hình dịch vụ thể hiện kiến trúc hệ thống
sẽ được xác định rõ trong Kiến trúc sư phần mềm Rational như thế nào, bao
gồm những người sử dụng dịch vụ, các đặc tả kỹ thuật của dịch vụ, các
phân vùng của dịch vụ, các nhà cung cấp dịch vụ không phân chia và phức
hợp, các dịch vụ, các hợp tác dịch vụ, các tương tác dịch vụ và các kênh
dịch vụ.
• Giải thích cách thức mô hình dịch vụ được sử dụng sau đó trong các hoạt
động tiếp theo của quá trình phát triển phần mềm như thế nào, với sự quan
tâm đặc biệt đến việc thiết kế và thực thi.

Về đầu trang
Về hướng dẫn này
Trong Phần 1, chúng ta đã giới thiệu một nghiên cứu tình huống cụ thể của một
công ty cho thuê video được dùng làm ví dụ trong suốt loạt bài hướng dẫn này.
Sau đó chúng ta đã đặt kiến trúc dịch vụ trong khung công tác của Rational
Unified Process và đã giới thiệu chồng giải pháp SOA (SOA Solution Stack) của
IBM để tham khảo. Chúng ta đã lưu ý các vật phẩm làm việc khác nhau được dùng
làm đầu vào cho một kiế

n trúc dịch vụ và sau đó sử dụng nghiên cứu tình huống
cụ thể để đưa ra các ví dụ về hai mô hình: mô hình kiến trúc nghiệp vụ (đã mô tả
trong Phần 1 dưới dạng một mô hình thành phần nghiệp vụ) và mô hình quy trình
nghiệp vụ.
Trong Phần 2, chúng ta đã xem xét chi tiết mô hình miền là gì và làm thế nào để
biểu diễn nó trong Kiến trúc sư Phần mềm Rational. Bạn đã bắt đầu có được kinh
nghiệm thực hành với công c
ụ và tạo ra mô hình miền được sử dụng trong loạt bài
này.
Trong Phần 3, chúng ta đã giải thích làm thế nào để tạo mô hình các hệ thống bên
ngoài nằm trong bối cảnh của kiến trúc hướng dịch vụ. Chúng ta đã bàn về việc
phân tích từ dưới lên và việc mô hình hóa các giao diện và các thành phần.
Trong phần này, chúng ta trình bày mô hình tình huống sử dụng. Chúng ta bắt đầu
bằng cách xác định vị trí và mô tả mô hình tình huống sử dụng bằng các đầu vào
của nó và mô tả cách nó đóng góp vào mô hình hóa SOA của bạn như thế nào. Sau
đó, chúng ta mô tả cách làm thế nào để tạo mô hình trong Kiến trúc sư phần mềm
Rational và cách trình bày chi tiết nó như thế nào khi sử dụng các phần tử của mô
hình tình huống sử dụng.

Về đầu trang
Mục tiêu
Sau khi hoàn thành phần này của loạt bài hướng dẫn, bạn sẽ có khả năng:
• Mô tả giá trị của một mô hình tình huống sử dụng.
• Tạo một mô hình tình huống sử dụng để chỉ rõ các tác nhân, các tình huống
sử dụng và các luồng trong tình huống sử dụng.

Về đầu trang
Các điều kiện cần có trước
Để thu được kết quả tốt nhất từ hướng dẫn này, bạn nên (nhưng không nhất thiết)
làm quen trước với:

• Kiến trúc hướng-dịch vụ (SOA-Service-oriented architecture).
• Kiến trúc sư Phần mềm Rational của IBM.
• Ngôn ngữ mô hình hóa thống nhất (UML-Unified Modeling Language).
• Quy trình thống nhất Rational của IBM (IBM Rational Unified Process®-
RUP®)
Chú ý quan trọng:
Chúng tôi rất khuyến cáo bạn nên đọc ba phần đầu tiên của loạt bài hướng dẫn này
trước khi đọc phần này (nhấn vào đường liên kết "Nhiều hơn nữa về các loại bài
này", ở góc trên bên trái).

Về đầu trang
Các yêu cầu hệ thống
Bản Kiến trúc sư Phần mềm Rational V7 (với bản sửa 005 hoặc mới hơn).
Tạo mô hình tình huống sử dụng
Có một mô hình cuối cùng mà chúng ta sẽ xem lại trước khi bắt đầu thực hiện mô
hình Dịch vụ, đó là mô hình Tình huống sử dụng. Nó sẽ là một đầu vào quan trọng
sau này, khi tạo mô hình các tương tác và các hợp tác dịch vụ trong mô hình dịch
vụ.
Giới thiệu về mô hình Tình huống sử dụng
Các mô hình như là Mô hình Thành phần Nghiệp vụ™ của IBM®, mô hình quy
trình nghiệp vụ và mô hình miền là các mô hình mức nghiệp vụ
. Tuy nhiên, mô
hình Tình huống sử dụng của hệ thống (thường được gọi tắt là mô hình Tình
huống sử dụng) là mô hình ở mức CNTT chứ không phải ở mức nghiệp vụ. Mặc
dù nghiệp vụ vẫn còn là trọng tâm xem xét của chúng ta, bây giờ chúng ta sẽ mô
hình hóa nhiều hơn những thứ chỉ có trong nghiệp vụ. Cụ thể, chúng ta đang mở
rộng tầm nhìn của chúng ta để xem xét các vấn đề CNTT (cụ thể
hơn là các hệ
thống phần mềm).
Mô hình tình huống sử dụng là mô hình mức CNTT trừu tượng cao nhất của

chúng ta. Nó xem xét giải pháp từ quan điểm của các yêu cầu, do đó chúng ta có
thể đặt câu hỏi: Giải pháp này cần hỗ trợ hành vi nào? Nó thường dùng để xác
định rõ hộp đen hành vi của giải pháp bằng cách mô tả các yêu cầu như là một tập
hợp các tương tác giữa các tác nhân bên ngoài với hệ thống. Trong khi mô hình
Quy trình nghiệp v
ụ cung cấp một khung nhìn tuần tự trực tiếp (end-to-end) về các
bước nghiệp vụ, mà các bước này trong một số trường hợp có thể bao gồm các
tương tác với hệ thống, thì mô hình Tình huống sử dụng chỉ tập trung vào các
tương tác này và do đó cung cấp một khung nhìn dựa trên-tương tác về các yêu
cầu hệ thống.
Một mô hình tình huống sử dụng định nghĩa hai điều, chủ yếu là:
• Định nghĩa về các tác nhân bên ngoài, là người tương tác với hệ thống.
• Một danh sách các tình huống sử dụng mà chúng có tương tác với chúng.
Hơn nữa mỗi đặc tả tình huống sử dụng sẽ bao gồm thông tin về các sự kiện châm
ngòi thao tác nghiệp vụ, các điều kiện cần có trước và các điều kiện cần có sau.
Tuy nhiên điều quan trọng nhất là sự mô tả từng bước, có chi tiết, về hành vi được
diễn tả bởi tình huống sử dụng sẽ
được chứa trong luồng các sự kiện cơ sở, cùng
với một tập hợp các luồng thay thế có khả năng (thay thế cho luồng các sự kiện cơ
sở).
Việc tạo mô hình tình huống sử dụng là rất có ích khi bạn muốn tạo ra một khung
nhìn có cấu trúc về phạm vi của hệ thống. Mỗi tình huống sử dụng tạo thành một
gói các đặc tả yêu cầu rồi các đặc t
ả này sẽ được tiếp tục đưa vào luồng công việc
của dự án (ví dụ, thiết kế và thực thi). Do đó, bằng cách thêm một tình huống sử
dụng vào mô hình, bạn bổ sung thêm công việc thiết kế và thực thi.
Việc phân tích các tương tác tác nhân-hệ thống giúp đỡ rất nhiều khi một ứng
dụng phần lớn là dựa vào một giao diện người dùng (UI, màn hình). Ví dụ, trong
nghiên cứu tình huống cụ thể của công ty DVD2U c
ủa chúng ta, chúng ta sẽ mô

hình tình huống sử dụng Thông báo Trả lại, ở đây các thành viên của DV2DU sử
dụng một giao diện Web để thông báo cho công ty DVD2U rằng họ đã gửi trả lại
đĩa DVD qua đường bưu điện. Các chi tiết của tình huống sử dụng Thông báo trả
lại (thông tin do người sử dụng cung cấp) sau đó sẽ được sử dụng để thiết kế trang
Web Thông báo Trả lại.
Tuy nhiên, các mô hình Tình huống s
ử dụng không chỉ gồm các tương tác dựa vào
UI. Trong trường hợp khi có một tương tác hệ thống bên ngoài với hệ thống mà
bạn đang xác định phạm vi hoạt động, tác nhân sẽ là một tác nhân hệ thống, chứ
không phải là một tác nhân con người và phần còn lại của các ý tưởng cơ bản dùng
để đặc tả hành vi ở mức các yêu cầu cũng sẽ giống như trong các tương tác dựa
vào-UI.
Đối với mỗi một trong hai kiểu tương tác khác nhau ấy, bạn có thể có một tập hợp
khác nhau của các vật phẩm làm việc của đặc tả bổ sung thêm, thích hợp với kiểu
tương tác cụ thể đó. Ví dụ, tình huống sử dụng hướng đến tác nhân con người luôn
có thể lợi dụ
ng các mô hình màn hình đơn giản bổ sung thêm, các đặc tả luồng dẫn
hướng và các đặc tả các trường. Theo cùng một cách đó, bạn có thể bổ sung thêm
cho các tình huống sử dụng hướng đến tác nhân hệ thống với một ánh xạ đến đặc
tả kỹ thuật của hệ thống bên ngoài mà Phần 3 của loạt bài này đã mô tả (xem
đường liên kết "Nhiều hơn nữa về các loại bài này" ở góc trên bên trái của màn
hình).
Các đầu vào để mô hình hóa tình huống sử dụng
Việc tạo mô hình tình huống sử dụng là một phần của lĩnh vực Các yêu cầu và nó
sử dụng các vật phẩm làm việc do các hoạt động dự án trước đó sinh ra. Nói chung,
chúng ta chia chúng thành các đầu vào từ trên xuống và từ dưới lên:
• Các ví dụ về các vật phẩm làm việc từ trên xuống mà chúng ta đã đề cập
trong loạt bài này cho đến nay là mô hình thành phần nghiệp vụ (xem Phần
1), mô hình Quy trình Nghiệp vụ (vẫn ở Phần 1) và mô hình Miền (xem
Phần 2).

• Chúng ta đã xem xét một vật phẩm làm việc từ dưới lên: mô hình Hệ thống
Bên ngoài (xem Phần 3).
Có một luồng nữa của các vật phẩm làm việc từ trên xuống nằm ngoài phạm vi
của loạt bài này, nhưng vẫn rất có ích để ghi lại đối với nhận biết tình huống sử
dụng. Luồng này bao gồm các nhu cầu kinh doanh, các đặc tính hệ thống và các
đặc tả kỹ thuật bổ sung thêm. Các vật phẩm làm việc này, cùng với những vật
phẩm đã đề cập ở trên, được tóm tắt dưới đây trong Hình 1.

Hình 1. Đầu vào cho mô hình tình huống sử dụng

Sau đây là mô tả ngắn gọn về bản chất của các đầu vào này:
• Mô hình Quy trình Nghiệp vụ. Nó được sử dụng để nhận biết các tác
nhiệm nghiệp vụ cần phải được mô tả với các tình huống sử dụng (các tình
huống sử dụng đó bao gồm tương tác tác nhân-hệ thống).
• Mô hình Thành phần Nghiệp vụ. Các lĩnh vực chức năng nghiệp vụ được
định nghĩa trong mô hình Thành phần Nghiệp vụ và có thể được sử dụng để
làm nên các đường ranh giới của các gói tình huống sử dụng, có nghĩa là
các đường ranh giới của các hệ thống sở hữu từng tình huống sử dụng.
• Mô hình Miền. Khi đặt tên và mô tả các tình huống sử dụng, chúng ta sử
dụng bảng từ vựng của các nghiệp vụ được định nghĩa trong mô hình miền.
• Các đặc tính. Nếu một danh sách các đặc tính được sử dụng như là một cơ
chế gọn nhẹ để xác định phạm vi của các yêu cầu của hệ thống, thì đây là
một khung nhìn yêu cầu có ích dùng để nhận biết các tình huống sử dụng.
Mỗi đặc tính cần theo vết đến ít nhất một tình huống sử dụng hoặc ít nhất
đến một đặc tả bổ sung.
• Mô hình Hệ thống bên ngoài. Hệ thống bên ngoài đã định nghĩa trong mô
hình này sẽ trở thành các tác nhân hệ thống trong mô hình Tình huống sử
dụng.
Mô hình tình huống sử dụng được dùng như thế nào trong hoạt động tạo mô
hình SOA

Như đã nói trước đây, mô hình tình huống sử dụng là một khung nhìn cấu trúc rất
có ích về phạm vi của một dự án. Bạn có thể sử dụng chúng như các gói của các
yêu cầu thông tin và sắ
p xếp các thiết kế màn hình dựa theo chúng, bởi vì chúng
cung cấp một gói các tương tác con người-UI có liên quan.
Cũng giống như thế, khi SOA là phong cách kiến trúc thì các tình huống sử dụng
cung cấp các gói yêu cầu về các tương tác sau đó sẽ được thực hiện với các dịch
vụ. Chúng ta sử dụng một kỹ thuật mà, với mỗi tình huống sử dụng trong mô hình
Tình huống sử dụng, chúng ta chỉ rõ một sự hợp tác dịch vụ
trong mô hình Dịch
vụ. Sau đó, với mỗi luồng trong mô hình Tình huống sử dụng (luồng cơ sở và mỗi
luồng thay thế), chúng ta chỉ rõ một sự tương tác dịch vụ (một tương tác UML)
trong hợp tác dịch vụ. Bằng cách này, chúng ta sử dụng các nội dung của mô hình
tình huống sử dụng để đóng gói các đặc tả động trong mô hình dịch vụ.
Tạo mô hình tình huống sử dụng UML trong Kiến trúc sư Phầ
n mềm Rational
Mẹo:
Điểm khởi đầu cho phần này là dự án hướng dẫn SOA, là kết quả của Phần 3 của
loạt bài này.
1. Tải về tệp tin DVD_Rental-Part3-ProjectInterchange.zip (xem Tải về) và
sau đó làm theo các hướng dẫn này để nhập khẩu dự án vào trong vùng làm
việc của bạn.
Lưu ý:
Nếu bạn vẫn còn có sẵn vùng làm việc từ Phần 3, hãy bỏ qua các bước này và
chuyển sang Bước 8.
2. Khở
i động Kiến trúc sư phần mềm Rational. Sử dụng vùng làm việc mặc
định hoặc tạo một vùng làm việc mới.
3. Sau khi nó đã chạy, đóng màn hình Chào đón nếu bạn đang ở trong một
vùng làm việc mới.

4. Chọn File > Import.
5. Trong trình thủ thuật Import, gõ project vào trong trường có nhãn là Select
an import source filter và sau đó chọn Project Interchange và nhấn Next
(Hình 2).

Hình 2. Nhập khẩu trao đổi dự án (Import the Project Interchange)

6. Nhấn Browse và trỏ đến vị trí ở đó bạn đã lưu tệp tin DVD_Rental-Part3-
ProjectInterchange.zip.
7. Chọn SOA Tutorial và nhấn Finish (Hình 3).

Hình 3. Nhập khẩu dự án hướng dẫn SOA

8. Chọn Window > Open Perspective > Modeling để chuyển sang phối cảnh
mô hình hóa (nếu bạn chưa ở trong nó).
Nếu bạn mở rộng dự án hướng dẫn SOA, bạn sẽ thấy giống như Hình 4 trong
khung nhìn Project Explorer.

Hình 4. Khung nhìn của Project Explorer đầu tiên

9. Chọn dự án SOA Tutorial, nhấn chuột phải và chọn New > UML Model.
10. Trong trình thủ thuật New UML Model, nhấn Next để sử dụng các khuôn
mẫu tiêu chuẩn.
11. Trong màn hình kế tiếp, chỉ rõ tên tệp tin là Use Case Model. Ngoài ra, hãy
chắc chắn rằng Create a default diagram in the model được chọn, và sau
đó chọn Use Case Diagram cho kiểu sơ đồ mặc định.
12. Nhấn Finish.
Lưu ý:
Trong hướng dẫn này, mô hình tình huống sử dụ
ng đơn giản đến mức mà chúng ta

không cần phải sử dụng khuôn mẫu mô hình tình huống sử dụng đã được cung cấp.
Chúng ta chỉ đơn giản sử dụng một khuôn mẫu mô hình rỗng (Blank Model).
Dự án Hướng dẫn SOA của bạn bây giờ trông giống như Hình 5.

Hình 5. Mô hình tình huống sử dụng đầu tiên

Chỉ rõ các phần tử của mô hình Tình huống sử dụng
Bây giờ, chỉ rõ các phần tử sau đây của mô hình Tình huống sử dụng: các tác nhân,
danh sách các tình huống sử dụng, các phân loại tình huống sử dụng và các luồng
trong tình huống sử dụng.
Các tác nhân
Trong mô hình Quy trình nghiệp vụ, chúng ta đã xác định một vai trò có tên là
Member (thành viên của DVD2U) và một vai trò khác có tên là Receiving Clerk
(nhân viên làm việc tại kho hàng DVD2U). Ngoài ra, trong mô hình Thiết kế
(phần các hệ thống bên ngoài), chúng ta đã xác định một hệ thố
ng đang tồn tại để
Quản lý Quan hệ Khách hàng (Customer Relationship Management). Tất cả đều
là các ứng cử viên trở thành các tác nhân trong mô hình tình huống sử dụng này, vì
vậy bây giờ bạn sẽ tạo ra các tác nhân của tình huống sử dụng để đại diện cho các
vai trò mà họ sẽ đóng trong các tình huống sử dụng ấy (một tác nhân của tình
huống sử dụng định nghĩa một vai trò có thể được đóng khi tương tác với h
ệ
thống).
1. Trong sơ đồ Main, chọn Actor trong palette và nhấn vào một nơi nào đó
trong sơ đồ. Thao tác này sẽ tạo ra một tác nhân mới. Đặt tên nó là Member.
2. Lặp lại các bước trên cho Receiving Clerk and Customer Relationship
Management.
Sơ đồ của bạn bây giờ trông giống như Hình 6.

Hình 6. Các tác nhân của tình huống sử dụng


Bạn biết rằng Member và Receiving Clerk là các tác nhân con người, trong khi
Quản lý Quan hệ Khách hàng là một hệ thống. Bây giờ bạn sẽ sử dụng các từ khóa
để phân biệt giữa các tác nhân con người và tác nhân hệ thống.
3. Chọn tác nhân Member và trong khung nhìn Properties, nhấn vào phiếu
Stereotypes.
4. Gõ human vào trong trường Keywords (Hình 7).

Hình 7. Từ khóa: human

5. Lặp lại hai bước trên đây cho hai tác nhân còn lại (chỉ rõ là system cho tác
nhân Customer Relationship Management).
Mô hình tình huống sử dụng của bạn trong Project Explorer sẽ giống như Hình 8.

Hình 8. Các tác nhân của mô hình Tình huống sử dụng

Xác định các tình huống sử dụng
Trong mô hình Quy trình Nghiệp vụ, chúng ta đã xác định một tác nhiệm nghiệp
vụ có tên là Thông báo trả lại (Notify of return) do Thành viên (Member) thực
hiện và được phân loại là tương tác Con người-Hệ thống (Hình 9). Tiếp theo, bạn
sẽ tạo ra một tình huống sử dụng cho việc này.
Như một quy tắc chung, hãy coi phạm vi của một tình huống sử dụng hệ thống là
ở mức một giao dịch hệ thống nguyên tử (không phân chia) như tác nhân đã trải
qua. Điều này có nghĩa là, thay vì trở thành các tình huống sử dụng mới, hai tác
nhiệm tiếp theo chỉ có hệ thống thực hiện (vị thế của thành viên lấy ra và gửi đi
băng Video kế tiếp) được coi là một phần trong phạm vi của cùng một tình huống
sử dụng hệ thống.

Hình 9. Mô hình Quy trình Nghiệp vụ Trả lại băng Video (1/2)


Ngoài ra, chúng ta đã xác định một tác nhiệm nghiệp vụ khác có tên là Record
receipt (Ghi biên nhận) được Receiving Clerk (nhân viên tiếp nhận) thực hiện và
được phân loại là tương tác con người-hệ thống (Hình 10). Bạn sẽ tạo ra một tình
huống sử dụng nữa cho tác nhiệm này. Theo quy tắc chung đã nói ở trên, việc trả
lại bản sao cho kho cấp hàng được coi là một phần của cùng một tình huống sử
dụng.

Hình 10. Mô hình Quy trình Nghiệp vụ Trả lại băngVideo (2/2)

Lưu ý rằng các nhà phân tích nghiệp vụ đã làm một việc rất tốt khi phân loại các
tác nhiệm nghiệp vụ trong mô hình Quy trình Nghiệp vụ (mã màu da cam dành
cho tác nhiệm chỉ con người làm, màu xám dành cho chỉ hệ thống làm và màu
xanh dương dành cho con người và hệ thống). Như bạn có thể thấy, hai tác nhiệm
nghiệp vụ mà chúng ta đã dùng để xác định các tình huống sử dụng, được hiển thị
màu xanh dương để nói lên rằng chúng là tác nhiệm do con người và hệ th
ống
cùng làm. Vậy thì đó là các ứng cử viên hoàn hảo cho các tình huống sử dụng. Tuy
nhiên, một số tình huống sử dụng sẽ chỉ dựa vào các tác nhiệm chỉ do hệ thống
làm. Trường hợp này, hoặc sẽ có một tác nhân hệ thống hoặc Thời gian sẽ là một
tác nhân nếu chúng được bắt đầu bởi kiểu xử lý theo bó (batch). Cũng lưu ý rằng
các tác nhiệm chỉ con người làm không có bất kỳ tình huống s
ử dụng hệ thống
tương ứng nào, bởi vì chúng hoàn toàn thực hiện bằng tay (mặc dù chúng có thể
đem lại các kết quả mà các tác nhiệm hướng xuống chỉ con người làm hoặc chỉ hệ
thống làm sẽ sử dụng).
Đối với hướng dẫn này, bạn không cần phải xem chi tiết về các đầu nối (số bội và
vai trò) trên các sơ đồ UML của tình huống sử dụng. Hãy thay đổi các lựa chọn
Ưa thích (Preferences) của bạn ngay bây giờ để Kiến trúc sư Phần mềm Rational
không hiển th
ị chúng theo mặc định:

6. Chọn Window > Preferences.
7. Trong Preferences, gõ connector vào trường Filter.
8. Nhấn Modeling > Diagrams > Appearance và chọn Connectors (see
Figure 11).
9. Bỏ chọn cả hai Show multiplicity và Show roles (Hình 11) và sau đó nhấn
vào Apply và OK.

Hình 11. Lựa chọn ưa thích đối với connectors

10. Trong sơ đồ Main, chọn Use Case trong palette, và nhấn vào một vùng
trống của sơ đồ tình huống sử dụng. Điều này sẽ tạo ra một tình huống sử
dụng mới. Hãy đặt tên nó là Notify of Return.
11. Lặp lại các bước trên cho tình huống sử dụng Record Receipt.
12. Member là một vai trò đối với Notify of Return. Hãy đặt con trỏ chuột của
bạn lên trên Member. Khi đầu nối (connector) đi ra xuất hi
ện (Hình 12),
nhấn chuột và kéo nó lên trên Notify of Return.

Hình 12. Đầu nối đi ra của một vai trò

1. Lặp lại các bước trên để kết nối Customer Relationship Management đến
Notify of Return và để kết nối Receiving Clerk đến Record Receipt.
Sơ đồ của bạn bây giờ trông giống như Hình 13.

Hình 13. Các tình huống sử dụng và các tác nhân

Tổ chức các tình huống sử dụng
Với các mô hình tình huống sử dụng lớn hơn (ví dụ, những mô hình có chứa một
tá các tình huống sử dụng), thì phân loại các tình huống sử dụng là một cách làm
tốt. Có nhiều cách tiếp cận phân loại khác nhau mà bạn có thể làm theo. Một cách

là phân loại các tình huống sử dụng theo các lĩnh vực chức năng nghiệp vụ mà các
tình huống sử dụng nằm trong đó. Bạn sẽ
làm điều đó với ví dụ mô hình Tình
huống sử dụng này, mặc dù nó chứa chỉ có hai tình huống sử dụng. Trong trường
hợp này, các lĩnh vực chức năng nghiệp vụ là các thành phần nghiệp vụ của Mô
hình Thành phần Nghiệp vụ (Hình 14).

Hình 14. Bản đồ Mô hình Thành phần Nghiệp vụ cho DVD2U

Trong nghiên cứu tình huống cụ thể DVD2U này, có hai thành phần nghiệp vụ
thích hợp: Online Rentals (đối với Notify of Return và các tác nhân của nó) và
Tracking (đối với Record Receipt và các tác nhân của nó). Bây giờ bạn sẽ phân
loại hai tình huống sử dụng cho phù hợp.
1. Từ Project Explorer, chọn Use Case Model, nhấn chuột phải vào và chọn
Add UML > Package.Đặt tên gói là Online Rentals.
2. Từ Project Explorer, kéo các phần tử Notify of Return, Customer
Relationship Management và Member lên trên gói Online Rentals.
3. Mở sơ đồ đã được tự động tạo ra trong gói Online Rentals và kéo ba phần
tử mô hình lên trên nó. Đổi tên sơ đồ thành Online Rentals Use Cases.
4. Lặp lại ba bước trên để di chuyển Record Receipt và Receiving Clerk vào
một gói Tracking. Dùng Tracking Use Cases làm tên sơ đồ.
5. Lưu mô hình củ
a bạn (CTRL + S).
Mô hình tình huống sử dụng của bạn trong Project Explorer bây giờ trông giống
như Hình 15.

Hình 15. Các mô hình tình huống sử dụng trong Project Explorer

Lưu ý:
Trong hoạt động tạo mô hình tình huống sử dụng điển hình, kiến trúc sư sẽ duyệt

tính hợp lệ các tình huống sử dụng để loại bỏ bất kỳ mục nào không quan trọng về
mặt kiến trúc và để đảm bảo rằng chúng được phân chia một cách thích hợp.
Trong ví dụ DVD2U đơn giản này, chúng ta tiếp tục sử dụng hai tình huống sử
dụng và chúng ta sẽ đảm bảo chắc chắn rằng thiết kế của chúng ta đáp ứng các yêu
cầu mà chúng mô tả.
Luồng của tình huống sử dụng
Xác định tập hợp các tình huống sử dụng để mô tả phạm vi của dự
án luôn được
thực hiện bằng cách sử dụng một mô hình tình huống sử dụng, nhưng điều này chỉ
là một phần nhỏ của toàn bộ đặc tả của tình huống sử dụng. Nhiều sự nỗ lực đã
dành cho việc mô tả chi tiết từng đặc tả của tình huống sử dụng. Đây là nơi các
yêu cầu chính xác được chỉ rõ. Đây là nơi phân tích các yêu cầu
được thực hiện,
do một nhà phân tích hệ thống tiến hành. Nhiều vật phẩm làm việc khác sẽ được
sử dụng làm đầu vào có ích, như được mô tả ở trên.
Đối với mỗi tình huống sử dụng, các thông tin sau đây cần được nắm bắt (ngoài
lĩnh vực chức năng và các tác nhân của nó):
• Tổng quan. Một mô tả mức cao về mục tiêu của tình huống sử dụng trong
một hoặc hai câu.
• Sự kiện nghiệp vụ. Điều gì châm ngòi tình huống sử dụng.
• Các điều kiện cần có trước. Các điều kiện phải được thỏa mãn để cho tình
huống sử dụng xảy ra.
• Các điều kiện cần có sau. Những gì đã được thay đổi như là kết quả thực
hiện tình huống sử dụng.
Tình huống sử dụng Notify of Return có thể trông giống như ví dụ này: