Lập mô hình với Java: Một cuốn sách bài tập về UML, Phần 4 Vai trò của tác nhân pdf

Lập mô hình với Java: Một cuốn sách bài tập về UML, Phần 4
Vai trò của tác nhân
Granville Miller, Giám đốc sản phẩm, TogetherSoft
Tóm tắt: Sau một gián đoạn ngắn, Granville Miller mở lại cuốn sách bài tập
UML để thảo luận sâu về một trong những thành phần cơ bản của sơ đồ ca sử
dụng: tác nhân. Tác nhân không chỉ là căn bản trong mô hình hóa UML, nó cũng
có thể đóng vai trò quan trọng trong việc tạo ra các ứng dụng Java và thậm chí có
thể gợi ý các mẫu trong thiết kế ứng dụng J2EE. Tác nhân trở nên đặc biệt quan
trọng khi nói đến việc phát triển các hệ thống phức tạp như các dịch vụ Web, nơi
mà các tương tác bên ngoài đóng vai trò quan trọng trong thiết kế hệ thống. Hãy
theo bước Granville sử dụng các sơ đồ tuần tự và sơ đồ lớp để giải thích vai trò
của tác nhân trong việc lập sơ đồ ca sử dụng và phát triển ứng dụng Java.
Rất ít hệ thống máy tính ngày nay còn tồn tại bên ngoài một mạng nào đó. Ngoài
việc phục vụ một cộng đồng người sử dụng nội bộ, hầu hết các hệ thống còn cung
cấp một kiểu giá trị hoặc dịch vụ nào đó cho các thực thể bên ngoài cho cộng đồng
đó. Đổi lại, hầu hết các hệ thống cũng tận dụng các dịch vụ được cung cấp bởi các
hệ thống khác như các hệ điều hành phía trình khách, các trình duyệt web, cơ sở
dữ liệu bên ngoài, và các nhà cung cấp dịch vụ bên thứ ba. Với sự tiến bước của
các dịch vụ Web, chính chúng ta chẳng bao lâu nữa, có thể phát triển các hệ thống
để cung cấp các dịch vụ cho một phạm vi các ứng dụng ngày càng rộng hơn.
Trong phần này của loạt bài sách bài tập UML, chúng ta sẽ nói về vai trò của tác
nhân trong việc thiết kế các hệ thống phức tạp. Để thảo luận của chúng ta dễ dàng
hơn, tôi sẽ giới thiệu hai mẫu thiết kế thường được dùng vào việc phát triển các hệ
thống như vậy, và sử dụng chúng để chỉ cho bạn, một mô hình hệ thống thay đổi
như thế nào theo tiến triển của quy trình của chúng ta, từ việc thu thập các yêu cầu
đến phân tích và thiết kế. Qua bài viết này, chúng ta sẽ làm việc với ca sử dụng
Đơn xin Vay nợ (Loan Application) mà chúng ta đã phát triển trong các phần
trước của loạt bài sách bài tập UML (xem Tài nguyên).
Mô hình hóa các tương tác bên ngoài
Khi nói đến lập mô hình các tương tác giữa hệ thống của chúng ta và các yếu tố
bên ngoài (chẳng hạn như các hệ thống khác), một thói quen chung là tạo ra các

lớp biểu diễn cách các yếu tố đó tương tác với hệ thống của chúng ta. Mẫu thiết kế
để biểu diễn các thực thể bên ngoài dưới dạng các lớp gọi là mẫu Ảnh gương
(Mirror Image). Về cơ bản, khi chúng ta dẫn ra mẫu Ảnh gương, chúng ta phân
tích hành vi của một thực thể bên ngoài và sau đó tạo ra chân dung của nó
(likeness) trong hệ thống của chính chúng ta. Chân dung này có xu hướng chỉ là
bức vẽ rất hời hợt, do nó chỉ nhằm trừu tượng hóa các dịch vụ mà chúng ta cần
(trong trường hợp sử dụng một lần) hoặc các dịch vụ mà hệ thống cung cấp (trong
trường hợp một lớp thư viện ví dụ như các lớp mạng (Networking) của Java). Dầu
sao, nó không nhằm để triển khai thực hiện các dịch vụ.
Để minh họa, chúng ta hãy xem xét cách mà TCP/IP làm việc trong SDK Java (gói
java.net). TCP/IP là một chức năng cơ sở của hầu hết các hệ điều hành. Là một
dịch vụ, TCP/IP thường trú trong hệ điều hành và cho phép dòng vận chuyển đi
qua một mạng. Nếu chúng ta phải viết một chương trình truyền tệp tin bằng mã
lệnh Java, chúng ta hẳn có thể sử dụng các lớp TCP/IP trong thư viện lớp Java để
truy cập vào các dịch vụ hệ điều hành dành cho giao thức này. Các lớp này sẽ trở
thành một bộ phận của ứng dụng của chúng ta, nhưng cuối cùng chúng cũng
thường trú trong hệ điều hành, không phải trong ứng dụng của chúng ta.
Hình 1 là một sơ đồ UML mô tả các lớp đại diện cho các dịch vụ TCP/IP dành cho
các lớp mạng Java.
Điều quan trọng cần hiểu ở đây là các lớp được minh họa trên đây đại diện cho các
dịch vụ được cung cấp bởi hệ điều hành. Bản thân chúng không phải là các dịch
vụ. Chúng ta đưa thêm những đại diện này vào thiết kế ứng dụng của chúng ta vì
chúng cho phép chúng ta dễ dàng tương tác hơn với hệ điều hành. Chúng ta tương
tác với các đại diện này cứ như là chúng ta đang tương tác với chính các dịch vụ
đó. Các đại diện đảm bảo rằng các tương tác được truyền đạt một cách chính xác
đến hệ thống khác, và rằng bất kỳ kết quả nào của các tương tác này được trả lại
theo một cách thức phù hợp với các mong đợi của chúng ta. Đây là vai trò của các
lớp TCP/IP trong thư viện lớp Java.

Xác định các tương tác bên ngoài
Tương tác với các thực thể bên ngoài được xác định trong giai đoạn thu thập các
yêu cầu để thiết lập mô hình ca sử dụng. Trong các chuyên mục trước, chúng ta đã
thiết lập một mô hình ca sử dụng trong đó các tác nhân đại diện cho các thực thể
bên ngoài tương tác với hệ thống của chúng ta. Trong chuyên mục cuối cùng của
loạt bài sách bài tập UML, chúng ta đã tạo ra ra một hệ thống có thể tương tác với
cả tác nhân con người (người đứng đơn vay tiền) lẫn tác nhân hệ thống bên ngoài
(một phòng tín dụng).
Hình 2 cho thấy mô hình ca sử dụng ban đầu cho hệ thống xử lý vay nợ. Nếu bạn
cần phải phục hồi trí nhớ của bạn về hệ thống này, xin xem các phần trước đây
trong loạt bài sách bài tập UML sẵn có trong phần Tài nguyên Tài nguyên.

Hình 2. Mô hình ca sử dụng xử lý vay nợ

Khi chúng ta hình thành ý niệm một hệ thống vào lúc ban đầu, một điều rất quan
trọng là nhận biết các tác nhân sẽ ảnh hưởng đến hệ thống đó. Việc hiểu biết về
ảnh hưởng qua lại của các yêu cầu và dịch vụ giữa hệ thống của chúng ta và các
tác nhân của nó cho phép chúng ta phân bổ tài nguyên hệ thống một cách phù hợp.
Vai trò của tác nhân trong một hệ thống xác định mức độ mà nó có thể ảnh hưởng
đến hệ thống.


Vai trò của tác nhân
Đừng bỏ lỡ phần còn lại của loạt bài "Một cuốn sách bài tập về UML"
Phần 1: "Giới thiệu về các sơ đồ tuần tự" (05.2001)

Phần 2: "Logic điều kiện trong các sơ đồ tuần tự" (06.2001)

Phần 3: "Logic giao diện người dùng trong việc lập mô hình ca sử dụng"
(06.2001)

Chúng ta đã thảo luận các vai trò có sẵn khác nhau dành cho một tác nhân trong
bài viết đầu tiên trong loạt bài sách bài tập UML. Có lẽ bạn nhớ lại rằng có bốn
vai trò tiềm năng mà một tác nhân có thể đóng trong một ca sử dụng: tác nhân
khởi tạo, máy chủ, tác nhân tiếp nhận, và tác nhân xúc tiến. Một tác nhân là tác
nhân khởi tạo khi vai trò của nó là đưa ca sử dụng vào hành động. Tác nhân hành
động như một máy chủ khi nó cung cấp một hoặc nhiều dịch vụ cần thiết để đạt
được mục tiêu của ca sử dụng. Một tác nhân được gọi là tác nhân tiếp nhận khi vai
trò của nó là nhận thông tin từ hệ thống một kho dữ liệu là một thí dụ về một tác
nhân tiếp nhận trong hệ thống. Và, cuối cùng, một tác nhân được gọi là tác nhân
xúc tiến khi nó thực hiện một hành động thay mặt một tác nhân khác trong một hệ
thống.
Các tác nhân có thể đóng nhiều vai trò đồng thời. Tác nhân có thể là người hoặc
máy, và nhân dạng của nó có thể là ẩn danh hoặc có danh. Nếu một tác nhân là ẩn
danh, nhân dạng của nó không ảnh hưởng gì đến hệ thống. Một người sử dụng
cuối có thể đóng nhiều vai trò trong một hệ thống mà không cần phải có nhân
dạng; cũng như vậy, bất kể người sử dụng cuối nào đóng vai trò đó Tom, Mike
hay Judy người ấy sẽ trải qua chính xác đúng bấy nhiêu chức năng. Máy móc
cũng có thể đóng vai trò như tác nhân ẩn danh, đặc biệt trong lĩnh vực dịch vụ
Web.
Ngược lại, một hệ thống có thể yêu cầu xác định thông tin để xử lý các vấn đề như
bảo đảm an ninh hoặc chất lượng dịch vụ. Trong những trường hợp như thế, tác
nhân phải được nhận biết. Vào bất cứ lúc nào mà một hệ thống đòi hỏi thông tin
về tác nhân dù thông tin đó là một sự nhận dạng chính xác hay chỉ là một thông
tin riêng nào đó tác nhân đó được coi là một thực thể đã biết.


Từ các yêu cầu đến triển khai thực hiện
Khi chúng ta chuyển từ các sơ đồ ca sử dụng sang sơ đồ tuần tự và sơ đồ lớp,
chúng ta sẽ thông báo ngay ảnh hưởng của các tác nhân đã biết. Các sơ đồ tuần tự
ban đầu của chúng ta (được phát triển trong các phần trước của cuốn sách bài tập

UML) bao gồm các tác nhân được nhận biết. Ở mức phân tích này chúng ta mô tả
tương tác giữa hệ thống của chúng ta và các tác nhân của nó như là một loạt các
thông điệp. Như vậy, chúng ta không làm việc với cá nhân con người hay hệ thống
riêng lẻ; mà đúng hơn là chúng ta đã bao kín các chi tiết của những con người hay
sự vật tương tác với hệ thống trong một thực thể trừu tượng mà chúng ta gọi là tác
nhân. Hình 3 mô tả một phần của sơ đồ tuần tự cho ca sử dụng Đơn xin Vay nợ.
Để xem sơ đồ đầy đủ, xin xem các phần trước của cuốn sách bài tập UML

Hình 3. Một phần sơ đồ tuần tự cho ca sử dụng Đơn xin Vay nợ

Khi chúng ta chuyển từ sơ đồ tuần tự đến sơ đồ lớp, việc phân tích hệ thống của
chúng ta trở nên tinh hơn về chi tiết. Chúng ta không còn làm việc với các tác
nhân nữa, do ở mức này các tác nhân đã gắn kết với các yêu cầu và hành vi. Thay
vào đó, ý tưởng trừu tượng đằng sau tác nhân đó có thể được làm rõ thêm lên. Hầu
hết các "tác nhân" xuất hiện ở mức này sẽ được xác định bởi ít nhất một thuộc
tính; nếu không, chúng sẽ không đáng quan tâm đối với hệ thống trong giai đoạn
phân tích. Bất kỳ mức độ nhận dạng nào thậm chí chỉ một thuộc tính đều làm
cho một tác nhân trở thành tác nhân được nhận biết. Hơn nữa, trong sơ đồ lớp tác
nhân đã nhận biết không còn là một tác nhân nữa; nó trở thành một lớp.
Sự dịch chuyển này có thể đơn giản là việc tạo ra một lớp riêng lẻ để biểu diễn tác
nhân của chúng ta, như trong Hình 4. Một cách khác đi, hệ thống có thể "thấy" tác
nhân của chúng ta là một yếu tố phức tạp hơn. Trong trường hợp này, có thể cần
tiến hành một vài phép trừu tượng. Chính trong hoàn cảnh này, mẫu Ảnh gương
phát huy tác dụng. Mẫu Ảnh gương lấy thực thể bên ngoài của chúng ta và biến nó
thành một phần của hệ thống.
Trong ví dụ đơn xin vay nợ của chúng ta, hai lớp là kết quả của việc chuyển dịch
các tác nhân đã biết thành các lớp. Cả người đứng đơn và phòng tín dụng phải có
các đặc điểm nhận dạng. (Nếu hệ thống của chúng ta không đòi hỏi phải xác định
các đặc điểm nhận dạng của cả hai thực thể này thì nó sẽ bị bỏ ngỏ cho khả năng
gian lận.)

Hình 4. Một sơ đồ lớp sử dụng mẫu Ảnh gương

Trong mô hình đơn giản của chúng ta, có một ánh xạ một-một giữa các tác nhân
và các bổ sung lớp. Tuy nhiên, các tác nhân thường đại diện cho các tương tác
"sâu hơn" có thể dẫn đến nhiều lớp và tương tác phức tạp hơn. Một tác nhân đơn
lẻ có thể dẫn đến việc thêm vào nhiều lớp, không lớp nào trong số đó mang tên
của tác nhân ban đầu.
Ngoài việc biểu diễn các tác nhân đã biết, sơ đồ lớp sẽ thường biểu diễn các vai trò
máy chủ và tác nhân tiếp nhận. Các vai trò này có thể được nhận biết hoặc không,
nhưng để cho hệ thống sử dụng các dịch vụ được cung cấp bởi các vai trò đó, một
hoặc nhiều lớp phải đại diện cho các dịch vụ được cung cấp. Chúng ta đã thấy điều
này bằng thí dụ TCP/IP.


Các tác nhân ẩn danh
Một tác nhân ẩn danh ví dụ như tác nhân khởi tạo hay tác nhân xúc tiến cũng có
thể dẫn đến việc thêm vào các lớp. Tuy nhiên việc bổ sung này sẽ liên quan đến
giai đoạn thiết kế hơn là phân tích. Chúng ta bơm vào các lớp này vì lý do liên
quan đến việc thực hiện hệ thống thực tế của chúng ta, chứ không phải như một sự
phản ánh các ràng buộc nghiệp vụ. Ví dụ chúng ta có thể thêm vào lôgic giao diện
người sử dụng mà chúng ta muốn tách riêng khỏi mô hình của chúng ta, hoặc
chúng ta có thể thêm vào một số lớp vì lý do hiệu năng.
Trong phát triển EJB, mẫu Mặt tiền phiên làm việc (Session Facade) thường được
dùng để giảm thiểu lưu lượng trên mạng và đảm bảo tính nhất quán của giao dịch.
Mẫu này cũng đóng vai trò lớn lao trong việc phát triển các dịch vụ Web, và là
một hình mẫu chính về việc sử dụng các tác nhân ẩn danh trong thiết kế hệ thống.
Mẫu Mặt tiền phiên làm việc thay thế nhiều cuộc gọi đến một bean thực thể bằng
một lời gọi đơn lẻ đến một bean phiên. Các bean phiên mới gọi đến các bean thực
thể trên máy chủ thay mặt trình khách.

Để minh họa cho mẫu Mặt tiền phiên làm việc, chúng ta hãy xem xét một ca sử
dụng, ở đây người sử dụng xuất chi tài khoản séc của mình để thực hiện trả nợ
vay. Nếu chúng ta sử dụng các bean thực thể để triển khai thực hiện ca sử dụng
Trả tiền (Make Payment), một giao dịch đơn lẻ này có thể đòi hỏi bốn lời gọi
xuyên qua mạng, như trong Hình 5. Bạn có lẽ nhớ lại, vào lúc này, mũi tên
nghiêng trong sơ đồ tuần tự biểu thị một thông điệp với thời gian đáp ứng chậm
hơn (kết quả của việc gửi một thông điệp qua một mạng thay vì gửi nó trực tiếp
đến một đối tượng). Hơn nữa, có dịp để cho một trong các giao dịch có lẽ không
bao giờ thực sự hoàn tất.
Hình 5 minh hoạ minh hoạ cách thức một bean thực thể sẽ quản lý ca sử dụng Trả
tiền.

Hình 5. Cách tiếp cận dùng bean thực thể trong việc trả nợ

Một mình bean thực thể rõ ràng không phải là cách triển khai thực hiện tốt đối với
ca sử dụng của chúng ta. Hiệu năng là một vấn đề, và thất bại khi hoàn tất bước
cuối cùng (thực hiện trả nợ) sẽ là một vấn đề thậm chí còn lớn hơn. Mẫu Mặt tiền
phiên làm việc giải quyết các vấn đề này bằng cách thêm một bean phiên vào kịch
bản. Bean phiên có vai trò như đại diện cục bộ của tác nhân của chúng ta.


Mô hình hoá với bean phiên
Về mặt lôgic, bean phiên gói ghém các hành động dự tính của tác nhân mà nó đại
diện. Như vậy, bean phiên cung cấp mặt tiền cho các tương tác của chúng ta với
các bean thực thể. Thay cho kéo lê dữ liệu trên toàn mạng vài lần, bean phiên cho
phép chúng ta đạt được các mục tiêu của mình bằng một giao dịch đơn lẻ trên máy
chủ. Ngoài ra, việc thêm bean phiên vào cũng bảo đảm rằng giao dịch của người
sử dụng là không thể phân chia được và các khoản thanh toán sẽ được ghi có một
cách an toàn. Ví dụ, bean phiên có thể cuộn ngược lại bất kỳ một khoản ghi nợ nào
trong việc thanh toán mà không được thực hiện. Việc này sẽ bảo vệ người sử dụng

của chúng ta chống lại mất cắp tiền.
Bean phiên cũng có thể thực hiện nhiều hoạt động thay mặt một tác nhân. Hành vi
của bean phiên phỏng theo hành vi thu thập được của tác nhân trên mô hình ca sử
dụng. Do đó, nếu một tác nhân Người đứng đơn (Applicant) khởi xướng một ca sử
dụng Thỉnh cầu Vay nợ (Apply for Loan) và Chấp nhận cho vay (Accept Loan),
luồng công việc cho các ca sử dụng này sẽ được thu thập lại trong bean phiên
Người đứng đơn. Bean phiên Người đứng đơn có thể thỉnh cầu vay nợ và sau đó
chấp nhận nó trong giao dịch khác.
Hình 6 minh họa việc đưa vào một bean phiên thay đổi ca sử dụng Trả tiền của
chúng ta như thế nào.

Hình 6. Cách tiếp cận dùng Mặt tiền phiên làm việc để thực hiện trả tiền

Như chúng ta đã thấy, bean phiên sử dụng các kiến thức đặc thù của tác nhân mà
nó được gắn kết vào để vừa làm dễ dàng hơn cho các giao dịch của tác nhân đó và
vừa cải thiện hiệu năng của hệ thống. Mẫu Mặt tiền phiên làm việc có thể được sử
dụng cho cả tác nhân được nhận biết và không được nhận biết. Ít khi mẫu này phải
được áp dụng cho các tác nhân trong vai trò máy chủ và tác nhân tiếp nhận.
Thường gặp nhất là mẫu này được thực hiện cho các tác nhân trong vai trò tác
nhân khởi tạo hoặc tác nhân xúc tiến. Rõ ràng là khách hàng trong ca sử dụng Trả
tiền là một tác nhân khởi tạo.


Kết luận
Các mẫu Ảnh gương và Mặt tiền phiên làm việc rất hữu ích để đổi các tác nhân
trong các sơ đồ ca sử dụng thành các trừu tượng hóa hợp lệ trong các sơ đồ lớp,
mà cuối cùng dẫn đến việc dịch thành mã lệnh sạch sẽ hơn. Các tác nhân được
nhận biết thường tìm thấy đường đi của mình, dưới một hình thức nào đó, vào
logic của hệ thống; tác nhân ẩn danh cũng có thể làm được như vậy.
Hệ quả lớn hơn của việc dịch từ sơ đồ sang mã lệnh là khả năng dò theo vết

(traceability). Bằng cách sử dụng các mẫu như Ảnh gương và Mặt tiền phiên làm
làm việc, chúng ta có thể lần theo việc tạo ra các lớp để phản ánh lại nhân dạng
của một thực thể bên ngoài, hoặc các dịch vụ được cung cấp bởi một thực thể bên
ngoài. Đảo lại quy trình, chúng ta có thể hiểu được các yếu tố làm hình thành nên
các lớp này. Mục tiêu của việc dịch này là trừu tượng hóa và nhận được mã lệnh
tốt hơn, dễ hiểu và dễ bảo trì hơn.

Mục lục

 Mô hình hóa các tương tác bên ngoài
 Xác định các tương tác bên ngoài
 Vai trò của tác nhân
 Từ các yêu cầu đến triển khai thực hiện
 Các tác nhân ẩn danh
 Mô hình hoá với bean phiên
 Kết luận