簡介： 用戶模型是對一組人員和這些人員如何使用某個 IT 解決方案的描述。這種類型的建模基於主要的可用性理論與實踐，並允許解決方案架構師指定 IT 解決方案的外部條件，以便該解決方案對所有類型的用戶都有用並可用。在本文中，瞭解如何爲支持安全 Web 資源訪問的簡單組件構建用戶模型。瞭解用戶模型如何確定需求定義方面的可能差距。
<!-- -->
平均分 (1個評分)在本系列的第 1 部分中，您瞭解了什麼是用戶模型，以及爲什麼它可以幫助改進您構建的系統的可用性。用戶模型從人員的角色、目標、技能、要求他們執行的任務和他們將在 IT 解決方案中處理的對象等方面，描述他們將如何使用 IT 解決方案。用戶模型包含以下概念：
| 用戶角色 | 一組職責，刻畫使用系統的人羣的特徵 |
|---|---|
| 用戶目標 | 用戶角色必須使用該解決方案的目的和動機 |
| 技能集 | 用戶角色可能具備的相關技能的集合 |
| 用戶任務 | 用戶角色採取來幫助實現用戶目標的操作 |
| 用戶對象 | 用戶角色理解並在用戶任務期間使用的概念或虛擬對象 |
| 用戶數據類型 | 用戶對象的複雜屬性類型 |
| 用戶對象篩選器 | 用戶對象屬性的有限子集 |
| 用戶構件 | 用戶角色在用戶任務期間必須使用的物理對象或文件 |
| 用戶域 | 用戶任務的邏輯分組 |
| 規程 | 技能集的邏輯分組 |
| 用戶團隊 | 用戶角色的邏輯分組 |
用戶模型是一種統一建模語言（Unified Modeling Language，UML）類模型。該模型中的每個元素表示爲一個應用了適當構造型的 UML 類。構造型化的 UML 特性和關聯描述元素的屬性和屬性之間的關係。
在本文中，瞭解如何爲一個簡單場景構建用戶模型。（UML 屏幕截圖來自 IBM Rational® Software Architect, Version 7.0。）
該場景涉及一個簡單的安全組件，此組件支持 Web 登錄和受控制的在線資源訪問。每個資源的所有者可以定義誰能夠訪問該資源。從業務的角度看，此組件具有三個主要功能：
- 設置誰可以訪問每個資源
- 登錄和訪問所需資源
- 記錄哪些用戶在訪問每個資源，用於審覈目的
構建用戶模型的第一步是確定誰將使用該解決方案。用戶的特徵在用戶模型中通過用戶角色 來刻畫。用戶角色描述一羣具有相似需要和職責的用戶。用戶角色可以表示用戶組織中將大量使用該解決方案的特定工作。或者，用戶角色可以具有更細的粒度，僅包括執行不同類型的工作但需要以相似方式使用該解決方案的人員的一個共同工作方面。
用戶模型 包含許多用戶角色。必須特別小心地確定所有類型的用戶，因爲忽略某個人員羣體會在解決方案中導致脆弱性。用戶角色應該基於用戶羣體的實際情況，而不是精心設計以匹配解決方案本身的設計。
在我們的安全組件場景中，存在擁有資源的人員和使用資源的人員。其中每個羣體分別稱爲“資源所有者”和“業務用戶”。
用戶角色涵蓋用戶工作的一個方面，而不是代表某項完整的工作。用戶角色不是互斥的。有些人可以是一個資源的資源所有者和另一個資源的業務用戶。資源所有者甚至可以是他或她自己的資源的業務用戶。只要某個個人一次僅扮演單個用戶角色，就足以對這些用戶角色進行區分了。
另一個用戶角色是“審覈員”，負責檢查審覈記錄以確定誰正在訪問每個資源。
最後，您需要考慮：
- 誰將設置該解決方案？
- 誰將確保該解決方案保持運行？
- 誰將調查該解決方案的問題？
- 誰將擴展該解決方案？
該安全組件具有以下用戶角色：
- 資源所有者
- 負責確保正確的用戶獲得對他們擁有的資源的訪問權限
- 業務用戶
- 負責使用適當的資源來執行業務
- 審覈員
- 負責安全策略的定義（和對這些策略的遵從性）
- IT 管理員
- 負責 IT 系統（包括該安全組件）的可用性
- 部署人員
- 負責經過測試的軟件版本的初始部署
- 開發人員
- 負責向該組件添加新功能並修復代碼中的缺陷
- 測試工程師
- 負責驗證該組件的編碼是正確的
- 解決方案架構師
- 負責選擇應該使用該組件的場合
每個用戶角色在該用戶模型中使用一個將構造型設置爲 <<user_role>> 的 UML 類來表示。該構造型顯示在 UML 類的頂部，並帶有一個 
圖標。還爲該 UML 類指定了一個構造型爲 <<definition>> 的屬性。此屬性的名稱是對該用戶角色的簡短描述，並標記有
圖標。圖 1 顯示了一個使用 UML 類來定義的用戶角色的示例。
圖 1. 使用 UML 類定義的用戶角色
在 Rational Software Architect 中，還爲每個屬性顯示了 
圖標，意味着該屬性是私有的，並且在用戶模型中不重要。
每個用戶角色應該至少定義一個用戶目標。用戶目標 定義用戶角色嘗試達到的最終狀態或目的。圖 2 顯示了“資源所有者”(Resource Owner) 用戶角色的用戶目標示例。
圖 2. 資源所有者的用戶目標
該用戶目標的名稱是“資源所有者”希望達到的狀態。存在一個提供簡短描述的 <<definition>> 屬性、一個或多個 <<measure>> 屬性 (
) ，並可選地存在一個或多個 <<target>> 屬性 (
)。
<<measure>> 屬性描述用戶角色將如何測量該用戶目標是否成功實現。在適當的情況下，還可以對錶示成功的測量成果級別進行建模。這是在 <<target>> 屬性中提供的。
通常，您定義的初始用戶目標與您認爲用戶可能執行的任務緊密相關。例如，您最初可能定義了一個名爲“定義所有有效用戶”的用戶目標。這實際上是一組操作，可將其作爲一個用戶任務進行建模（將在稍後描述）。
用戶目標應該以聲明方式定義用戶角色希望實現的事務狀態。用戶目標不描述該最終狀態是如何實現的。這樣存在兩個優點：
- 您可以客觀地檢查指定的解決方案是否真正滿足用戶的目標。
- 使您不會在這個早期階段就侷限於特定的實現模型。
因此，讓我們將該用戶目標修改爲“資源訪問受到正確控制”。此目標捕獲了爲什麼 資源所有者要使用該 IT 解決方案，但是沒有描述如何使用。
定義了用戶目標以後，就可以使用與 <<primary_goal>> 構造型的聚合關係來將該目標與適當的用戶角色聯繫起來。將其稱爲主要目標是爲了強調我們僅在對驅使用戶角色使用該解決方案的原因進行建模。
圖 3 顯示了該用戶角色與該用戶目標之間的聚合關聯。
圖 3. 用戶角色的主要用戶目標
資源所有者的 Project Explorer 視圖顯示了資源所有者與該用戶目標的 <<definition>> 和 <<primary_goal>> 關聯，如圖 4 所示。
圖 4. Project Explorer 中用於關聯的構造型
通過選擇角色名稱（在此例中爲“資源訪問受到正確控制”）將構造型應用於關聯，以在相應的窗格中顯示該角色的屬性。Apply Stereotypes 按鈕在 Stereotypes 選項卡下，如圖 5 所示。
圖 5. 應用構造型
屬性和關聯按字母順序出現在 Project Explorer 中。它們在圖上的出現順序是在 Resource Owner 屬性視圖中的 Attributes 選項卡下定義的。
本部分討論每個用戶角色預期應該具備的技能。技能是在技能集中定義的。技能集 是與某個主題相關的技能的集合。每項技能通常僅在單個技能集中出現。技能集使用具有 <<skill_set>> 構造型的 UML 類進行定義。技能集具有一個提供簡短描述的 <<definition>> 屬性，以及對構成該技能集的關鍵技能做顯式文檔記錄的一個或多個 <<skill>> 屬性。圖 6 顯示了一個示例。
圖 6. 技能集
用戶角色通過與 <<assumed_skill>> 構造型的聚合（空心菱形）關係與技能集聯繫起來。可以在用戶角色之間共享技能集。一個用戶角色可以具有多個技能集。
在圖 7 所示的示例中，存在一個資源所有者預期將具備的針對資源安全技能的技能集。此定義規定擁有某個資源的個人需要具備這些技能。
圖 7. 與某個技能集相關聯的用戶角色
當添加了從 Resource Owner 用戶角色到 Resource Security Policies 技能集的關聯時，該關聯將出現在 Resource Owner 的 Project Explorer 視圖中。可以看到 <<assumed_skill>> 構造型已應用於該關聯。
圖 8. <<assumed_skill>> 構造型
對技能集建模涉及到指明哪些技能是某個用戶角色特有的，以及哪些技能是某些或所有用戶角色共有的。爲此，您還要指明技能集之間的關係（使用聚合）。通常，表示高級技能的技能集具有與更基本的必備技能之間的聚合關係。
在圖 9 所示的示例中，存在三個聯繫在一起的技能集：基本計算機技能 (Basic Computer Skills)、個人用戶安全性 (Personal User Security) 和資源安全策略 (Resource Security Policies)。“資源安全策略”具有與“個人用戶安全性”之間的聚合關係。Project Explorer 視圖表明該聚合已應用了 <<nested_skill_set>> 構造型，意味着瞭解“資源安全策略”的任何用戶角色還了解“個人用戶安全性”。“個人用戶安全性”和“基本計算機技能”之間的關係也類似如此。
圖 9. 聯繫在一起的技能集
在對技能集建模以後，將不同用戶角色所需要的技能做一下對比是非常有趣的。例如，圖 10 表明“資源所有者”與“業務用戶”具有圍繞資源安全性的相同基本技能。因此，資源所有者具有操作業務用戶的資源安全性用戶界面的技能。
圖 10. 用戶角色和技能集之間的關係
在建模過程中的此部分，您將定義用戶的預期技能級別。如果預期履行這些用戶角色的人員不具備您指定的技能，則項目需要爲這些用戶包括培訓資料，或者您可能需要嘗試某種不同的方法。此分析在設計信息組織方式時也是非常有用的，因爲它有助於揭示人員在何處可以履行多個用戶角色。
在爲用戶角色定義用戶目標和技能集時，您會發現在名稱和 <<definition>> 屬性中使用的單詞選擇方面，您在開始爲用戶角色定義一個詞彙表。
用戶模型以用戶對象和用戶構件的形式，包含了該詞彙表的正式定義。用戶對象表示出現在用戶界面上的虛擬概念。用戶構件是物理的事物，例如文件和文檔。
將要經歷幾次迭代才能完成該詞彙表。在完成用戶角色、用戶目標和技能集的基本定義以後，就是在用戶模型中構建該用戶對象和用戶構件詞彙表的恰當時機了。
請考慮如圖 11 所示的技能集。
圖 11. 技能集
該技能集暗示存在以下類型的用戶對象：
- Resource
- Access Level
- Access Control List
- User Group
- User Account
以及以下用戶構件：
- Audit Log
對於其中每個用戶對象和用戶構件，創建一個帶有 <<user object>> 或 <<user_artifact>> 構造型的 UML 類，並添加一個 <<definition>> 屬性以提供簡短描述。
圖 12. 創建 UML 類
如果不確定要使用 <<user object>> 還是 <<user artifact>> 構造型，只需做出您的最佳猜測。當以後有了更多信息時，可以容易地更改構造型。
每個用戶對象和用戶構件可以定義用戶屬性，以表明用戶角色瞭解有關這些用戶對象和用戶構件的什麼信息。在圖 13 所示的示例中，Resource 具有六個屬性：Name、Type、Owner、Creation Time、Last Update Time 和 Description。
圖 13. 定義了屬性的 Resource 用戶對象
每個用戶屬性具有類型，此類型可以是以下類型之一：
- 基本 UML 基元類型（String、Integer、Boolean 或 UnlimitedNatural）。
- 導入的模型庫中的某種類型。在此示例中，DateTime 和 Text 來自於一個導入的模型庫。
- UML 枚舉（如果可以將用戶屬性設置爲某個固定的值集）。
- 某種用戶數據類型。
- 與另一個用戶對象、用戶構件或用戶數據類型的關聯。
用戶數據類型是一種自定義數據類型，表示用戶屬性的相關集合。用戶類型被建模爲應用了 <<user_datatype>> 構造型的類。該數據類型應該對用戶有意義。
用戶屬性始終應用了 <<user_attribute>> 構造型，即使其類型是與另一個用戶對象、用戶構件或用戶數據類型的關聯。<<user_attribute>> 構造型的圖標爲
。
用戶屬性還可以具有 <<identifier>> 構造型，其圖標爲 
，指示該用戶屬性在確定、定位或選擇用戶對象或用戶構件的實例時非常有用。最後，還存在 <<dynamic_enum>> 構造型 (
)，指示該用戶屬性的有效值被定義爲服務器上的一個列表（而不是通過 UML 枚舉在模型中定義爲固定列表）。
圖 14 顯示了 Resource 用戶對象的樹形視圖，並具有如下用戶屬性列表：Access Control List、Creation Time、Description、Last Update Time、Name、Owner 和 Type。Name 和 Type 還具有 <<identifier>> 構造型，並且 Type 也具有 <<dynamic_enum>>。
圖 14. Resource 用戶對象在 Project Explorer 中的樹形視圖
在使用該樹形視圖時，務必記住：
- 該列表顯示了所有的用戶屬性，包括其類型爲與另一個用戶對象、用戶構件或用戶類型的關聯的用戶屬性。Access Control List 就是這樣一個關聯，如圖 15 所示。下一部分將對這些關聯進行更詳細的描述。
圖 15. 關聯
- 當某個用戶屬性應用了多個構造型時，您將使用最先應用於該用戶屬性的構造型的圖標。例如，Name 同時應用了 <<user_attribute>> 和 <<identifier>>，但是由於最先應用 <<identifier>>，因此使用了其鑰匙形圖標。類似地，Type 應用了 <<user_attribute>>、<<identifier>> 和 <<dynamic_enum>>，但是使用了 <<dynamic_enum>> 圖標，因爲該構造型是最先應用的。
通過從屬性中刪除所有的構造型，然後以所需的順序重新應用這些構造型，從而可以更改構造型的順序以更改所使用的圖標。
- 可以通過屬性窗格將用戶屬性標記爲只讀。
用戶對象之間的關係使用 UML 關聯進行定義。使用了所有四種類型：雙向、定向（單向）、聚合和組合。
在圖 6 所示的示例中，用戶構件 Audit Log 和用戶對象 Audit Log Entry 之間存在一個組合（黑色菱形）。
圖 16. 審覈日誌與其審覈日誌條目之間的組合關聯
組合 意味着一個用戶對象是另一個用戶對象的一部分。在該示例中，Audit Log Entry 是 Audit Log 的一部分。基數設置爲 *，這意味着每個 Audit Log 中有零到多個 Audit Log Entry。該關係的另一端的基數爲 1，這意味着每個 Audit Log Entry 僅出現在一個 Audit Log 中。
在圖 17 所示的示例中，存在兩個來自於 User Group 的聚合關聯。聚合暗示兩個用戶對象之間的臨時關係。來自 User Group 的第一個聚合關係環回到自身。這表示一個 User Group 可以列出其他 User Group。兩端的基數均爲 *，因此一個 User Group 中可以包括零到多個其他 User Group，並且一個 User Group 可以包括在零到多個其他 User Group 中。
第二個聚合關聯指向 User Account，表示一個 User Group 可以具有零個或多個與之關聯的 User Account。此外，一個 User Account 可以包括在零個或多個 User Group 中。
圖 17. 聚合關聯
這是用於描述用戶對象樹的常見建模模式。您可以將 User Group 看作是樹中的中間節點，將 User Account 看作是樹葉。
圖 18 顯示瞭如何對 Access Control List 建模。該關係具有一個來自於 Resource 的關聯，表示 Access Control List 是 Resource 的一部分。 每個 Resource 有一個 Access Control List，並且一個 Access Control List 只能屬於一個 Resource。
圖 18. Access Control List 是 Resource 的一部分
Access Control List 由多個條目構成，因此我們創建了一個名爲 Access Control List Entry 的新用戶對象，如圖 19 所示。
圖 19. 具有多個條目的 Access Control List
起初，Access Level 被定義爲一個用戶對象。經過深思熟慮之後，可以明顯看出它實際上是 Access Control List Entry 的一個用戶屬性。它可以具有的值是一個固定的值列表。如果希望在模型中硬編碼這些值，可以使用一個 UML 枚舉來對其進行建模，如下所示。
使用一個 <<dynamic_enum>> 構造型，從而可以在以後定義訪問值，並且這些值可以隨 Resource 的每種類型而不同。
當使用動態枚舉時，Access Level 被指定給某個 User Group 或 User Object。可以使用繼承來對此選擇進行建模。定義一個名爲 Access List 的新用戶對象，並通過其屬性視圖將其設置爲抽象的。
圖 20. 屬性
由於 Access List 是抽象的，其名稱以斜體顯示。
圖 21. 斜體顯示的抽象用戶對象
User Group 和 User Account 都繼承 Access List，這意味着它們都是某種 Access List。
圖 22. 兩種使用繼承的 Access List 類型
Access Control List Entry 通過另一個聚合關聯與 Access List 聯繫在一起。由於 Access List 是抽象的，Access Control List Entry 只可能指向某個繼承 Access List 的具體（非抽象）用戶對象——在此例中爲 User Group 或 User Account。圖 23 顯示了一個示例。
圖 23. 繼承
與詞彙表相關的最後一個概念是用戶對象篩選器，當您開始對用戶任務建模時，此概念將變得更加重要。用戶對象篩選器是應用了 <<user_object_filter>> 構造型的類。可以使用用戶對象篩選器來對用戶對象的有限視圖建模，並且其中包含該用戶對象的屬性一個子集。用戶對象篩選器具有與它所篩選的用戶對象的定向關聯。此定向關聯上的構造型爲 <<filtered_object>>。
圖 24 顯示了 Resource 用戶對象的兩個篩選器的定義，這兩個篩選器分別名爲 Resource Selection Filter 和 Resource ACL Filter。
圖 24. 爲 Resource 定義用戶對象篩選器
Resource Selection Filter 定義了在從列表中選擇一個或多個 Resource 時非常有用的 Resource 屬性。例如，當某個資源所有者希望選擇要使用的資源時，該篩選器包含 Name、Type、Creation Time 和 Last Update Time 用戶屬性。當使用此用戶對象篩選器來代替用戶對象時，用戶將不會看到 Owner、Description 和 Access Control List 用戶屬性。
Resource ACL Filter 僅包括 Name 和 Access Control List。諸如 Access Control List Entry 等 Access Control List 中的所有用戶屬性都將可見。
此時，您應該考慮如何完成每個用戶目標。用戶目標是通過執行用戶任務來完成的。每個用戶任務描述一個操作，用戶執行該操作以實現全部或部分用戶目標。用戶任務的範圍從粗粒度到細粒度不等。有些用戶任務可以通過其他用戶任務組合而成。然而，用戶任務始終以對用戶有意義的術語來表示。
用戶任務使用具有 <<user task>> 構造型的 UML 類進行定義。與其他用戶建模元素一樣，用戶任務具有一個 <<definition>> 屬性以提供簡短描述。圖 25 顯示了一個名爲 Maintain Access to Resource 的用戶任務。
圖 25. 用戶任務 Maintain Access to Resource 的定義
用戶目標通過一個單向關聯與相應的用戶任務聯繫起來。該關聯應用了 <<supporting_task>> 構造型。一個用戶目標通常與多個用戶任務聯繫在一起。例如，資源所有者確保“資源訪問受到正確控制”的目標是通過多次執行以下用戶任務來實現的：
- 查看資源
- 維護資源訪問
- 將資源移交給新的所有者
圖 26 中的類關係圖顯示了從該用戶目標到這些用戶任務的三個關係。
圖 26. 爲實現用戶目標而需要執行的任務
該 Project Explorer 視圖顯示了這些帶有 <<supporting_task>> 構造型的關係。
圖 27. <<supporting_task>> 構造型
此模型僅表明該用戶目標與這些用戶任務之間存在一個關係。它沒有描述何時執行這些用戶任務。我們依賴用戶的技能和理解來確定何時執行這些任務才適當。例如，資源所有者將使用他們的判斷（或其他來源的信息）來了解應該爲哪些用戶提供訪問權限，以及何時需要刪除訪問權限。
如果您覺得可以描述一個明確的過程，該過程闡述某個用戶目標如何轉換爲用戶任務，那麼該用戶目標很可能是一個複雜的用戶任務。在這樣的情況下，您應該將其構造型更改爲 <<user_task>>，併爲該用戶角色創建一個新的用戶目標。
用戶任務的行爲是使用從該用戶任務到某個用戶對象、用戶對象篩選器或用戶構件的定向關聯來進行建模的，如下所示。該關聯上的構造型爲 <<action_target>>。
圖 28. 用戶任務和用戶對象（用戶對象篩選器）之間的關係
每個 action_target 關聯定義該用戶任務中的一個步驟。關係上的 <<select>>、<<view>>、<<create>>、<<update>> 或 <<delete>> 關鍵字表示在該步驟中執行什麼類型的操作。各個關聯在屬性窗格的特性選項卡中的出現順序就是預期要執行那些步驟的順序。
需要驗證用戶任務與用戶角色的技能匹配。在定義用戶任務以後，我們將這些用戶任務與執行它們所需要的技能集關聯起來。要使用的關係是從用戶任務到技能集的定向關聯，如圖 29 所示。該關聯上的構造型爲 <<required_skill>>。
圖 29. 定向關聯
如果截止目前已定義的所有技能集似乎都不適合，則定義一個新的技能集並將其與用戶任務關聯起來。
在將每個技能集與用戶任務相關聯時，檢查預期要執行該任務的用戶角色具備相關的技能集。這需要追溯到用戶目標。例如，對於圖 30 中的“Maintain Access to Resource”，存在一個將用戶角色、用戶目標、用戶任務和技能集聯繫在一起的關係環。
圖 30. 一致的關係環——用戶角色具備執行某個用戶任務的技能
下一階段是定義哪些用戶對象（和用戶構件）與每個技能集相關聯。此階段可以定義需要包括在教育課程、幫助信息和手冊中的信息類型。完成此任務的最簡單方法是將與該技能集相關聯的用戶任務所操作的每個用戶對象或構件聯繫在一起。
在該場景中，用戶任務處理 Access Control List 和相關的用戶對象。兩個用戶任務都與 Resource Security Policies 技能集相關聯，因此 Resource Security Policies 技能集也具有這些用戶對象。圖 31 顯示了這些關係。
圖 31. 技能集與用戶對象或構件之間的關係
技能集與用戶對象或構件之間的關聯是雙向的，並在技能集端具有 <<glossary>> 構造型，在用戶對象或構件端具有 <<taught_by>> 構造型。
最後，可以定義用戶域以將相關用戶任務分組在一起。在圖 32 所示的示例中，用戶域是一個應用了 <<user_domain>> 構造型的 UML 類。用戶域可以連同用戶任務一起嵌套在另一個用戶域中。在較大的用戶模型中，當您希望將用戶任務組織到邏輯組中時，嵌套用戶域是非常有用的。
圖 32. 對相關用戶任務進行分組
本文說明了學習用於構建用戶模型的符號和過程是多麼簡單。您只需基本瞭解 UML 類關係圖和了解用於在用戶角色之間進行區分的 UML 構造型。
有些開發團隊曾經遇到過回答用戶建模所引發的問題的困難。但是，這不是因爲用戶建模非常困難；而是由於對解決方案的用戶瞭解得不夠全面。用戶建模的最大價值在於確定需求定義方面的差距，如果忽略這些差距，可能會導致非常糟糕的可用性（以及蒙受的所有成本和失敗風險）。
用戶建模可以揭示出何時需要通過聯繫參與者和用戶以獲取所需信息，從而執行更多的分析。一旦解決了不確定性，用戶模型即可按照將對開發團隊有用的形式捕獲丟失的細節。其結果是獲得該解決方案所支持的用戶類型、那些用戶需要的技能以及用戶在使用該解決方案時所做的工作的有條理的定義。這實際上是構建解決方案用例的堅實基礎。
請繼續關注本系列的第 3 部分，其中將討論可用於擴展用戶模型的 UML 的構造型和關係。