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