1          責(zé)任模式

這一章關(guān)注的重點(diǎn)是關(guān)系，以及怎樣為錯(cuò)綜復(fù)雜的關(guān)系建立模型，另外，所有的插圖都來(lái)自原書(shū)（《Analysis Patterns：Reusable Object Models》），并遵循UML標(biāo)準(zhǔn)。

1.1    Party模式

在這一章中，首先我們接觸到是是Party模式，在進(jìn)行系統(tǒng)分析和概念模型設(shè)計(jì)的時(shí)候，經(jīng)常發(fā)現(xiàn)人和各種各樣的組織有著同樣的行為，例如，固定電話的計(jì)費(fèi)可能是針對(duì)個(gè)人，也可能是一個(gè)單位；需要各種服務(wù)的時(shí)候，你可能求助于一個(gè)服務(wù)公司，或者服務(wù)公司一個(gè)特定的業(yè)務(wù)員。總之，因?yàn)槿耍?strong>Person）和組織（Organization）表現(xiàn)上的一致性，如下圖所見(jiàn)，我們從中抽象出Party，作為Person和Organization的抽象父類。

1.2    組織（Organization）的內(nèi)部結(jié)構(gòu)

第二步，如果我們把注意力轉(zhuǎn)移到組織（Organization）的內(nèi)部結(jié)構(gòu)，就會(huì)發(fā)現(xiàn)一些有趣的問(wèn)題，通常最常見(jiàn)的一種結(jié)構(gòu)是金字塔結(jié)構(gòu)，因此建模時(shí)可能按照這樣的結(jié)構(gòu)建立線性的模型，例如：

這樣的模型并沒(méi)有錯(cuò)誤，但是有缺陷，首先不能滿足比較復(fù)雜的組織關(guān)系，更嚴(yán)重的是，一旦需要更多的層次關(guān)系，例如存在部門(mén)直接上下級(jí)關(guān)系以及區(qū)域附屬管理方式，必將引起整個(gè)模型的更改，對(duì)系統(tǒng)的影響可想而知，在這種情況下，最通常的改進(jìn)措施是引入層次關(guān)系，如下圖所示：

通過(guò)增加新的關(guān)聯(lián)關(guān)系，可以靈活實(shí)現(xiàn)組織（Organization）之間的各種關(guān)系以及可能的變化。在上圖中，{hierarchy}是一個(gè)約束（constraint）來(lái)限定關(guān)系。

1.3        組織關(guān)系抽象

第三步，在一般的情況下，以上的模式已經(jīng)足夠解決問(wèn)題，但當(dāng)這樣的層次和組織關(guān)系很多而且復(fù)雜時(shí)（超過(guò)兩種），例如現(xiàn)在流行的矩陣管理，就可以將關(guān)系本身抽取出來(lái)獨(dú)立處理，如下圖所示，作者此時(shí)考慮到組織結(jié)構(gòu)的有效時(shí)段，所以加入了一個(gè)時(shí)間段屬性來(lái)記錄組織結(jié)構(gòu)的存在時(shí)間。

請(qǐng)注意，在這個(gè)模式中，Organization Structure才是模式的核心，在系統(tǒng)中，由兩個(gè)Organization的實(shí)例（分別充當(dāng)parent和subsidiary），以及一個(gè)Type實(shí)例來(lái)說(shuō)明該結(jié)構(gòu)的類型。在這樣的結(jié)構(gòu)中，可能存在許多的規(guī)則（Rule），這些規(guī)則可以根據(jù)情況分別處理：如果Type很多，而且規(guī)則主要跟Type有關(guān)，就分配給與Type相關(guān)聯(lián)；如果Type并不多，但主要根據(jù)Organization的子類型變化，就可以分布到Organization的子類型中。

1.4    責(zé)任（Accountability）模式

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

1.5    知識(shí)層（Knowledge level）和操作層（Operational level）分離

出現(xiàn)這樣一種想法是考慮到以下情況：當(dāng)Accountablity Type的數(shù)量比Accountability的數(shù)量多很多的時(shí)候，處理Accountablity Type的規(guī)則也變得更為復(fù)雜，要解決這樣的問(wèn)題，就可以引入知識(shí)層和操作層的分離。

由下圖可見(jiàn)，用虛線隔離開(kāi)的，就是知識(shí)層（Knowledge level）和操作層（Operational level），在這個(gè)模型中，知識(shí)層（Knowledge level）由三個(gè)類協(xié)作完成，它們分別是Accountablity Type、Connection Rule、Party Type，在Connection Rule中定義合法的Party關(guān)系規(guī)則，并通過(guò)Accountablity Type對(duì)Accountablity進(jìn)行創(chuàng)建時(shí)的合法性檢驗(yàn)。它的另一個(gè)好處就是，可以將知識(shí)層的實(shí)例化獨(dú)立出來(lái)，作為操作層（Operational level）運(yùn)行時(shí)的配置；換句話說(shuō)，當(dāng)知識(shí)層的規(guī)則改變時(shí)，系統(tǒng)的行為將被改變，而不需要任何其他代碼的改動(dòng)，這當(dāng)然是一種比較理想化的情況。

由此想到，構(gòu)建專家系統(tǒng)的設(shè)計(jì)思路也可以從這個(gè)模式得到一些啟發(fā)，這是筆者一時(shí)的感觸。

在原書(shū)中，如何實(shí)現(xiàn)這樣的模型提得比較模糊，但是筆者認(rèn)為，可以將它們作為正常的模型來(lái)實(shí)現(xiàn)，兩個(gè)層次的區(qū)分只是表明它們各自擔(dān)負(fù)的任務(wù)和地位不同。知識(shí)層傾向于描述系統(tǒng)可能存在的各種形式，并設(shè)定判斷系統(tǒng)是否有效的各種規(guī)則；操作層則描述在這樣的配置下系統(tǒng)實(shí)際的行為。通過(guò)改變內(nèi)在的配置來(lái)改變外在的行為，就是這個(gè)模式的目的。

由于這個(gè)模式的特點(diǎn)，改變系統(tǒng)行為時(shí)不必更改操作層的代碼，但是，并不意味著改變系統(tǒng)行為連測(cè)試也不必要做。同樣，也需要調(diào)試、配置管理。

作者也提到，這樣的模式用起來(lái)并不輕松，甚至在一般的系統(tǒng)中也不必要，但當(dāng)你發(fā)現(xiàn)有必要用它的時(shí)候，別猶豫（感覺(jué)象用降落傘一樣）！

1.6        小結(jié)

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

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