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

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.

Granville Miller, Giám đốc sản phẩm, TogetherSoft

Granville Miller có 14 năm kinh nghiệm trong cộng đồng hướng đối tượng. Ông là đồng tác giả của loạt bài Mô hình hoá ca sử dụng Cấp cao và Hướng dẫn thực hành Lập trình eXtreme (Practical Guide to eXtreme Programming). Ông đã trình bày các bài hướng dẫn tại nhiều hội nghị công nghệ hướng đối tượng trên thế giới. Cách tiếp cận thực hành đến việc phát triển hướng đối tượng của ông là kết quả lao động của ông với các công ty, từ các công ty khởi nghiệp trong giai đoạn đầu đến một số những người khổng lồ phần mềm tiếng tăm nhất



26 09 2009

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ợ
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ợ
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
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ợ
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
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.

Tài nguyên

Bình luận

developerWorks: Đăng nhập

Các trường được đánh dấu hoa thị là bắt buộc (*).


Bạn cần một ID của IBM?
Bạn quên định danh?


Bạn quên mật khẩu?
Đổi mật khẩu

Bằng việc nhấn Gửi, bạn đã đồng ý với các điều khoản sử dụng developerWorks Điều khoản sử dụng.

 


Ở lần bạn đăng nhập đầu tiên vào trang developerWorks, một hồ sơ cá nhân của bạn được tạo ra. Thông tin trong bản hồ sơ này (tên bạn, nước/vùng lãnh thổ, và tên cơ quan) sẽ được trưng ra cho mọi người và sẽ đi cùng các nội dung mà bạn đăng, trừ khi bạn chọn việc ẩn tên cơ quan của bạn. Bạn có thể cập nhật tài khoản trên trang IBM bất cứ khi nào.

Thông tin gửi đi được đảm bảo an toàn.

Chọn tên hiển thị của bạn



Lần đầu tiên bạn đăng nhập vào trang developerWorks, một bản trích ngang được tạo ra cho bạn, bạn cần phải chọn một tên để hiển thị. Tên hiển thị của bạn sẽ đi kèm theo các nội dung mà bạn đăng tải trên developerWorks.

Tên hiển thị cần có từ 3 đến 30 ký tự. Tên xuất hiện của bạn phải là duy nhất trên trang Cộng đồng developerWorks và vì lí do an ninh nó không phải là địa chỉ email của bạn.

Các trường được đánh dấu hoa thị là bắt buộc (*).

(Tên hiển thị cần có từ 3 đến 30 ký tự)

Bằng việc nhấn Gửi, bạn đã đồng ý với các điều khoản sử dụng developerWorks Điều khoản sử dụng.

 


Thông tin gửi đi được đảm bảo an toàn.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=70
Zone=Công nghệ Java, SOA và dịch vụ Web
ArticleID=431448
ArticleTitle=Lập mô hình với Java: Một cuốn sách bài tập về UML, Phần 4
publish-date=09262009