1          責任模式

這一章關注的重點是關系，以及怎樣為錯綜復雜的關系建立模型，另外，所有的插圖都來自原書（《Analysis Patterns：Reusable Object Models》），并遵循UML標準。

1.1    Party模式

在這一章中，首先我們接觸到是是Party模式，在進行系統分析和概念模型設計的時候，經常發現人和各種各樣的組織有著同樣的行為，例如，固定電話的計費可能是針對個人，也可能是一個單位；需要各種服務的時候，你可能求助于一個服務公司，或者服務公司一個特定的業務員。總之，因為人（Person）和組織（Organization）表現上的一致性，如下圖所見，我們從中抽象出Party，作為Person和Organization的抽象父類。

1.2    組織（Organization）的內部結構

第二步，如果我們把注意力轉移到組織（Organization）的內部結構，就會發現一些有趣的問題，通常最常見的一種結構是金字塔結構，因此建模時可能按照這樣的結構建立線性的模型，例如：

這樣的模型并沒有錯誤，但是有缺陷，首先不能滿足比較復雜的組織關系，更嚴重的是，一旦需要更多的層次關系，例如存在部門直接上下級關系以及區域附屬管理方式，必將引起整個模型的更改，對系統的影響可想而知，在這種情況下，最通常的改進措施是引入層次關系，如下圖所示：

通過增加新的關聯關系，可以靈活實現組織（Organization）之間的各種關系以及可能的變化。在上圖中，{hierarchy}是一個約束（constraint）來限定關系。

1.3        組織關系抽象

第三步，在一般的情況下，以上的模式已經足夠解決問題，但當這樣的層次和組織關系很多而且復雜時（超過兩種），例如現在流行的矩陣管理，就可以將關系本身抽取出來獨立處理，如下圖所示，作者此時考慮到組織結構的有效時段，所以加入了一個時間段屬性來記錄組織結構的存在時間。

請注意，在這個模式中，Organization Structure才是模式的核心，在系統中，由兩個Organization的實例（分別充當parent和subsidiary），以及一個Type實例來說明該結構的類型。在這樣的結構中，可能存在許多的規則（Rule），這些規則可以根據情況分別處理：如果Type很多，而且規則主要跟Type有關，就分配給與Type相關聯；如果Type并不多，但主要根據Organization的子類型變化，就可以分布到Organization的子類型中。

1.4    責任（Accountability）模式

第四步，從第一步看到，Party是Person和Organization的抽象父類，因此把Party代入上面的模式（有點象我們小時侯代數里常用的代入），正式形成責任（Accountability）模式。

1.5    知識層（Knowledge level）和操作層（Operational level）分離

出現這樣一種想法是考慮到以下情況：當Accountablity Type的數量比Accountability的數量多很多的時候，處理Accountablity Type的規則也變得更為復雜，要解決這樣的問題，就可以引入知識層和操作層的分離。

由下圖可見，用虛線隔離開的，就是知識層（Knowledge level）和操作層（Operational level），在這個模型中，知識層（Knowledge level）由三個類協作完成，它們分別是Accountablity Type、Connection Rule、Party Type，在Connection Rule中定義合法的Party關系規則，并通過Accountablity Type對Accountablity進行創建時的合法性檢驗。它的另一個好處就是，可以將知識層的實例化獨立出來，作為操作層（Operational level）運行時的配置；換句話說，當知識層的規則改變時，系統的行為將被改變，而不需要任何其他代碼的改動，這當然是一種比較理想化的情況。

由此想到，構建專家系統的設計思路也可以從這個模式得到一些啟發，這是筆者一時的感觸。

在原書中，如何實現這樣的模型提得比較模糊，但是筆者認為，可以將它們作為正常的模型來實現，兩個層次的區分只是表明它們各自擔負的任務和地位不同。知識層傾向于描述系統可能存在的各種形式，并設定判斷系統是否有效的各種規則；操作層則描述在這樣的配置下系統實際的行為。通過改變內在的配置來改變外在的行為，就是這個模式的目的。

由于這個模式的特點，改變系統行為時不必更改操作層的代碼，但是，并不意味著改變系統行為連測試也不必要做。同樣，也需要調試、配置管理。

作者也提到，這樣的模式用起來并不輕松，甚至在一般的系統中也不必要，但當你發現有必要用它的時候，別猶豫（感覺象用降落傘一樣）！

1.6        小結

從簡單到復雜，前面分五步介紹了適用于解決Party及其關系的各種模式，每種推薦的模式都有其表現的機會，希望我這篇文章可以起到一些拋磚引玉的作用，并歡迎大家對其中的錯誤進行指正，歡迎發表意見，進行交流。

原文參照《Analysis Patterns：Reusable Object Models》，Chapter 2，Martin Fowler