今天絕大多數計算機系統都處在某種網絡之中。大多數系統除了為內部的用戶群體服務，還要為該群體以外的實體提供某種價值或服務。作為回報，大多數系統也用了其它系統（例如，客戶機端操作系統、Web 浏覽器、外部數據庫和第三方服務提供者）提供的服務。隨著 Web 服務的到來，我們很快就會發現，我們開發的系統要為越來越廣泛的應用程序提供服務。
在 UML 工作簿系列的這一部分中，我們將來談談參與者在復雜系統的設計中的角色。為了便於討論，我將介紹開發復雜系統時經常使用的兩種設計模式，通過它們向您展示系統模型在從需求收集推進到分析和設計這個過程中的變化。這一部分通篇都將使用我們在 UML 工作簿系列的前幾部分中開發的貸款申請用例。
為外部交互建模
談到為我們的系統和外部元素（如其它系統）之間的交互建模，通常的做法是，創建一些類，它們表示這些元素和我們的系統之間的交互方式。把外部實體表示為類，這樣一種設計模式稱為 鏡像映象（Mirror Image）模式。當我們援用鏡像映象模式時，我們基本上是先分析某一外部實體的的行為特征，然後在我們自己的系統中創建它的相似體。這個相似體通常很簡單，因為它只是想抽象出我們需要的服務（對於單次使用這一情況）或系統提供的服務（對於諸如 Java 聯網類類庫這一情況）。它並不試圖以任何方式實現這些服務。
我們通過研究 TCP/IP 在 Java SDK（包 java.net ）中的工作原理加以說明。TCP/IP 是大多數操作系統的基本功能。TCP/IP 是一個服務，它駐留在操作系統上，使流量得以跨網絡流動。假如我們打算用 Java 代碼寫一個文件傳輸程序，我們可能要用到 Java 類庫中的 TCP/IP 類，用它們來訪問針對這個協議的操作系統服務。這些類將成為我們應用程序的一部分，但它們最終將駐留在操作系統中，而不是在應用程序中。
圖 1是一張 UML 圖，顯示了一些表示 TCP/IP 服務的類，這些服務是針對 Java 聯網類的。
這裡重要的是要理解上圖所示的類 表示了操作系統所提供的服務。它們並不是服務本身。我們之所以將這些表示納入到我們的應用程序設計中，是因為它們使我們可以更容易地與操作系統交互。我們與這些表示交互，就 好像是在與服務本身交互一樣。這些表示確保了交互被正確地傳送至另一個系統，而且交互的任何結果都將按我們期望的方式返回。這就是 TCP/IP 類在 Java 類庫中的角色。
識別外部交互
識別與外部實體的交互在構建用例模型的需求收集階段進行。在前面的專欄文章中，我們構建了一個用例模型， 參與者在其中表示與系統交互的外部實體。在 UML 工作簿系列的前一個專欄中，我們設計了一個既能與參與人（貸款申請人）又能與外部系統參與者（征信所）交互的系統。
圖 2 顯示了貸款處理系統最初的用例模型。
圖 2. 貸款處理用例模型
在我們最初概念化一個系統的時候，識別將影響系統的參與者是很重要的。理解了需求和服務在系統與其參與者之間的相互作用，我們就可以相應地分配系統資源。參與者在系統中的 角色決定了它對系統有多大程度的影響。
參與者的角色
我們在 UML 工作簿系列的 第一篇文章中討論了參與者可以扮演的各種角色。您或許能回想起來，參與者在用例中可能扮演四種角色：啟動器（initiator）、服務器（server）、接收器（receiver）以及代理（facilitator）。如果某個參與者的作用是啟動用例，則它的角色就是 啟動器。如果參與者提供實現用例目標所需的一個或多個服務，那它充當的就是 服務器。當某個參與者的作用是接收來自系統的信息時，我們就稱它為 接收器，數據倉庫就是系統接收器的一個例子。最後，當某個參與者代表系統中的另一個參與者執行操作時，我們就稱它為 代理。
參與者可以同時扮演多個角色。參與者可能是人或機器，其身份可以是匿名的，或者是已知的。如果參與者是匿名的，則它的身份對系統沒有任何影響。最終用戶在未曾標識的情況下可能會扮演多種角色；同樣，不管是哪位最終用戶扮演了某種角色 ― Tom、Mike 或是 Judy ― 他或她將經歷完全相同的功能。機器也可能扮演匿名參與者，尤其是在 Web 服務領域中。
相比而言，為了處理諸如安全或服務質量之類的事情，系統就需要標識信息了。在這樣的情況下，參與者必須是已知的。任何時候當系統要求關於某個參與者的信息時 ― 不管這個信息是確切的標識還是只鱗片爪的個別信息 ― 這個參與者就被認為是一個已知的實體。
從需求到實現
當我們從用例圖轉入到序列圖和類圖時，馬上就會注意到已知的參與者的影響。我們最初的序列圖（在 UML 工作簿以前的部分中開發的）包含了已知的參與者。在這個層次的分析上，我們把系統與它的參與者之間的交互描述為一系列消息。因此，我們不是在處理個別的人或系統；相反地，我們把那些與系統交互的人或系統的細節封裝到抽象的實體中，我們稱它為參與者。圖 3 圖示了貸款申請用例的序列圖的一部分。想查看完整的序列圖，請參閱 UML 工作簿以前的部分。
圖 3. 貸款申請用例的序列圖的一部分
當我們從序列圖轉到類圖時，我們的系統分析就更精細了。因為在這個層次上，參與者是與需求和行為聯系在一起，所以我們不再處理參與者的問題。相反，參與者背後的抽象概念可能將被提出來。在這個層次上出現的大多數“參與者”都將至少由一個屬性標識；否則它們就是系統在分析階段時所不感興趣的參與者。任何級別的標識 ― 哪怕只是一個屬性 ― 就能把一個參與者變成已知的參與者。而且，已知的參與者在類圖中已不再是一個參與者；它成為了一個類。
這個轉變可能就像創建一個類來表示參與者那樣簡單，如圖 4 所示。系統還可以將我們的參與者“看作”是更復雜的元素。在這個例子中，將會得到幾種抽象。鏡像映象模式的用武之地是後一種情況。鏡像映象模式取得外部實體，然後將它轉變成系統的一部分。
在我們的貸款申請示例中，通過將已知的參與者轉換成類而得到的類有兩個。申請人和征信所都必須有標識性的特征。（如果我們的系統不要求這兩個實體的標識性特征，那將為詐騙行為大開方便之門。）
圖 4. 一個利用了鏡像映象模式的類圖
在我們簡單的模型中，存在一個參與者與所添加的類之間的一一映射。然而，參與者通常表示“更深層的”交互，可能產生多個類和更復雜的交互。一個參與者可能需要添加許多類，而其中沒有一個類使用了原始參與者的名稱。
類圖除表示已知的參與者之外，還常常表示服務器角色和接收器角色。這些角色可以是已知的或未知的，但為了系統能夠使用由它們提供的服務，必須有一個或多個類來表示所提供的服務。通過 TCP/IP 示例，我們看到了這一點。
匿名參與者
諸如啟動器或代理這樣的匿名參與者也會使一些類被添加進來。但這種添加與設計而不是分析有關。我們注入這些類是由於與實際的系統實現有關的一些原因，而不是要反映業務約束。例如，我們可能會添加想與模型分離開來的用戶接口邏輯，或者我們可能會出於性能方面的原因而添加某些類。
在 EJB 開發中， 會話虛包（Session Facade）模式常被用來使網絡流量最小化和確保事務一致性。在 Web 服務的開發中，這一模式也有極重要的作用，該模式還是匿名參與者在系統設計中的用法的典型示例。會話虛包模式用對會話 bean 的單個調用來代替對實體 bean 的多個調用。新的會話 bean 代表客戶機對服務器上的實體 bean 進行調用。
為了說明會話虛包模式，我們來考慮這樣一個用例，用戶能將貸款支付的帳目記入她的支票帳戶的借方。如果我們用實體 bean 來實現這個付款用例，則一個簡單的事務需要跨網絡進行四個調用，如圖 5 所示。此時您可能會回想起來，在序列圖中，斜向箭頭表明消息有較漫長的響應時間（這是跨網絡發送消息而不是直接將消息發送到對象的結果）。此外，有可能其中某個事務永遠也不會實際完成。
圖 5 說明了實體 bean 將如何管理付款用例。
圖 5. 用實體 bean 的辦法來實現償還貸款
對於我們的用例，單單實體 bean 顯然不會是一種好的實現。性能就很成問題，而無法完成最後一個步驟（完成支付）可能會是一個更大的問題。通過在這個方案中加入一個會話 bean，會話虛包解決了這些問題。會話 bean 充當參與者的本地代理。
用會話 bean 進行建模
從邏輯上說，會話 bean 封裝了它所代表的參與者所希望的操作。這樣，會話 bean 就為我們與實體 bean 的交互提供了一個 虛包。會話 bean 讓我們不用在網絡間拖動數據幾次，而是通過服務器上的一個事務就可以實現我們的目標。而且，注入會話 bean，就確保了用戶事務的原子性，從而付款將被安全記入貸方。例如，會話 bean 會回滾無法完成的支付的任何借項。這就保證了我們用戶的錢不會憑空消失。
會話 bean 還能代表參與者進行多種操作。會話 bean 的行為與參與者在用例模型內匯集起來的行為一致。因此，如果一個申請人參與者發起了一個申請貸款用例和一個接受貸款用例，則這兩個用例的工作流將被收集到申請人會話 bean 中。申請人會話 bean 可以申請一項貸款，然後在另一個事務中接受它。
圖 6 說明了引入會話 bean 給我們的付款用例帶來的變化。
圖 6. 用會話虛包的辦法實現付款
正如我們已經看到的，會話 bean 被指定給某個參與者，利用它對該參與者的特有了解，會話 bean 既方便了參與者的事務又增強了系統性能。會話虛包模式可用於已知的和未知的參與者。這種模式不太用於服務器角色和接收器角色的參與者。它更多是為了啟動器或代理角色的參與者而被實現。顯然，付款用例中的客戶是啟動器角色。
結束語
對於將用例圖中的參與者轉換成類圖中有效的抽象，鏡像映象模式和會話虛包模式是很有用的，這樣最終將能夠更清楚地轉換成代碼。已知的參與者通常在系統的邏輯中能有某種形式的體現；匿名參與者也一樣。
從圖到代碼的轉換，其更重要的含義是 可跟蹤性。通過使用諸如鏡像映象和會話虛包之類的模式，我們就可以跟蹤類的創建過程，以反映出外部實體的標識或它所提供的服務。我們可以通過其逆過程理解使這些類得以產生的元素。這些轉換的目標是使抽象更好，代碼更易於理解和維護。
