UML 建模實戰第四彈：參與者角色、鏡像映象與會話外觀模式

現代系統無不處於網絡中，既為內部用戶服務，也依賴外部系統（瀏覽器、數據庫、第三方服務）。隨 Web Services 普及，系統將面向更廣泛的消費者。本文探討參與者在複雜系統設計中的角色轉換，介紹「鏡像映象」與「會話外觀」兩大設計模式，展示從需求到設計的模型演進。貫穿「貸款申請」用例。

一、 外部交互建模：鏡像映象模式

將外部實體建模為本系統內的類，稱為「鏡像映象」。核心思想：分析外部行為特徵，在本系統創建其「替身」，僅抽象所需服務，**不實現服務**。

例：Java java.net 封裝 OS 層 TCP/IP 協議棧。應用調用 Socket/URL 等類，實際委託 OS 內核完成網絡傳輸。UML 中這些類標記為「外部服務表達」，而非服務本身。

二、 參與者識別與角色分類

需求階段（用例圖）識別參與者。貸款系統涉及「申請人」（人）與「徵信所」（外部系統）。

參與者四大角色：

• 啟動器：發起用例（如申請人提交申請）。
• 服務器：提供實現目標所需服務（如徵信所提供信用報告）。
• 接收器：接收系統輸出（如數據倉庫存檔）。
• 代理：代表其他參與者行動。

參與者可兼任多角色，可匿名（身份不影響行為，如匿名網銀用戶），亦可已知（需身份標識以支持安全/服務質量）。

三、 從需求到實現：參與者如何變為類

序列圖（分析階段）以消息流描述參與者交互，封裝細節於抽象實體。類圖（設計階段）則將「已知參與者」提煉為帶標識屬性的類——**任何標識屬性都使參與者成為已知實體，從而在類圖中轉化為類**。

鏡像映象模式適用於「深層交互」的外部系統：一個參與者可能衍生多個類，名稱不再沿用原參與者名。貸款例中，「申請人」與「徵信所」均需標識，故映射為兩個核心領域類。

類圖亦常表達服務器/接收器角色（如 TCP/IP 類庫），無論參與者是否已知，系統使用其服務均需對應類。

四、 匿名參與者與會話外觀模式

匿名參與者（啟動器/代理）引入的類源於**設計考量**（如分離 UI、性能優化），而非業務約束。EJB/Web Services 中的「會話外觀」是典型例證。

問題：客戶直接調用多個實體 Bean（借記、貸記、查詢餘額、確認）需 4 次網絡往返，性能差且事務一致性難保證（圖 5）。

解決：引入會話 Bean 作為客戶端本地代理（外觀）。單次調用封裝完整業務事務，本地執行多實體操作，保證原子性（失敗回滾），大幅減少網絡開銷（圖 6）。

會話 Bean 歸屬特定參與者（如「申請人會話 Bean」聚合「申請貸款」「接受貸款」兩用例流程），利用對參與者行為的內聚理解，同時優化性能與一致性。適用於已知/未知參與者，主要服務啟動器/代理角色。

總結

「鏡像映象」處理外部系統深度集成，「會話外觀」優化分布式調用顆粒度。兩模式實現從用例參與者到設計類的**可追溯轉換**，使抽象更清晰、代碼更易維護。