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