1 責(zé)任模式
這一章關(guān)注的重點(diǎn)是關(guān)系,以及怎樣為錯(cuò)綜復(fù)雜的關(guān)系建立模型,另外,所有的插圖都來自原書(《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)上的一致性,如下圖所見,我們從中抽象出Party,作為Person和Organization的抽象父類。

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

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

通過增加新的關(guān)聯(lián)關(guān)系,可以靈活實(shí)現(xiàn)組織(Organization)之間的各種關(guān)系以及可能的變化。在上圖中,{hierarchy}是一個(gè)約束(constraint)來限定關(guān)系。
1.3 組織關(guān)系抽象
第三步,在一般的情況下,以上的模式已經(jīng)足夠解決問題,但當(dāng)這樣的層次和組織關(guān)系很多而且復(fù)雜時(shí)(超過兩種),例如現(xiàn)在流行的矩陣管理,就可以將關(guān)系本身抽取出來獨(dú)立處理,如下圖所示,作者此時(shí)考慮到組織結(jié)構(gòu)的有效時(shí)段,所以加入了一個(gè)時(shí)間段屬性來記錄組織結(jié)構(gòu)的存在時(shí)間。

請注意,在這個(gè)模式中,Organization Structure才是模式的核心,在系統(tǒng)中,由兩個(gè)Organization的實(shí)例(分別充當(dāng)parent和subsidiary),以及一個(gè)Type實(shí)例來說明該結(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ù)雜,要解決這樣的問題,就可以引入知識(shí)層和操作層的分離。
由下圖可見,用虛線隔離開的,就是知識(shí)層(Knowledge level)和操作層(Operational level),在這個(gè)模型中,知識(shí)層(Knowledge level)由三個(gè)類協(xié)作完成,它們分別是Accountablity Type、Connection Rule、Party Type,在Connection Rule中定義合法的Party關(guān)系規(guī)則,并通過Accountablity Type對(duì)Accountablity進(jìn)行創(chuàng)建時(shí)的合法性檢驗(yàn)。它的另一個(gè)好處就是,可以將知識(shí)層的實(shí)例化獨(dú)立出來,作為操作層(Operational level)運(yùn)行時(shí)的配置;換句話說,當(dāng)知識(shí)層的規(guī)則改變時(shí),系統(tǒng)的行為將被改變,而不需要任何其他代碼的改動(dòng),這當(dāng)然是一種比較理想化的情況。
由此想到,構(gòu)建專家系統(tǒng)的設(shè)計(jì)思路也可以從這個(gè)模式得到一些啟發(fā),這是筆者一時(shí)的感觸。
在原書中,如何實(shí)現(xiàn)這樣的模型提得比較模糊,但是筆者認(rèn)為,可以將它們作為正常的模型來實(shí)現(xiàn),兩個(gè)層次的區(qū)分只是表明它們各自擔(dān)負(fù)的任務(wù)和地位不同。知識(shí)層傾向于描述系統(tǒng)可能存在的各種形式,并設(shè)定判斷系統(tǒng)是否有效的各種規(guī)則;操作層則描述在這樣的配置下系統(tǒng)實(shí)際的行為。通過改變內(nèi)在的配置來改變外在的行為,就是這個(gè)模式的目的。
由于這個(gè)模式的特點(diǎn),改變系統(tǒng)行為時(shí)不必更改操作層的代碼,但是,并不意味著改變系統(tǒng)行為連測試也不必要做。同樣,也需要調(diào)試、配置管理。
作者也提到,這樣的模式用起來并不輕松,甚至在一般的系統(tǒng)中也不必要,但當(dāng)你發(fā)現(xiàn)有必要用它的時(shí)候,別猶豫(感覺象用降落傘一樣)!
1.6 小結(jié)
從簡單到復(fù)雜,前面分五步介紹了適用于解決Party及其關(guān)系的各種模式,每種推薦的模式都有其表現(xiàn)的機(jī)會(huì),希望我這篇文章可以起到一些拋磚引玉的作用,并歡迎大家對(duì)其中的錯(cuò)誤進(jìn)行指正,歡迎發(fā)表意見,進(jìn)行交流。
原文參照《Analysis Patterns:Reusable Object Models》,Chapter 2,Martin Fowler
原文:
http://blog.csdn.net/nzh_csdn/archive/2004/12/19/221484.aspx