內容簡介
分析模式可復用的對象模型
《分析模式可復用的對象模型》的作者Martin Fowler是國際著名的OO專家，敏捷開發方法的創始人之一，現為thoughtworks公司的首席科學家，《分析模式可復用的對象模型》是作者的代表作之一，深受業界專業人士和廣大讀者的好評，經久不衰。
《分析模式可復用的對象模型》講述各種分析模式（即來自概念性業務模型的模式）和支持模式（即講述如何使用分析模式的輔助性模式），把論述重點放在介紹面向對象分析和設計的最終結果—即模型本身。作者透過平實樸素的語言，將自己豐富的對象建模經驗與讀者分享，使讀者可以馬上採納這些經驗性模式。
《分析模式可復用的對象模型》適合的讀者範圍非常廣：面向對象的計算機分析人員和設計人員（尤其是那些參與系統分析的人員）、數據建模人員、編程人員以及專業的軟體工程師都可以從《分析模式可復用的對象模型》中獲得寶貴的知識和經驗。
作者簡介
作者：（英國）福勒（Martin Fowler） 譯者：樊東平 張路 等
福勒（Martin Fowler），在面向對象分析設計、UML、模式、軟體開發方法學、XP、重構等方面，都是世界頂級的專家，現為Thought Works公司的首席科學家。Thougtlt Works是一家從事企業套用開發和集成的公司。早在20世紀80年代，Fowler就是使用對象技術構建多層企業套用的倡導者，他著有幾本經典書籍：《分析模式》、《UML精粹》和《重構》等。
編輯推薦
《分析模式可復用的對象模型》：Martin Fowler認識到面向對象研究團體需要一本超越傳統方法學著作所包含的工具和技術的書，因此撰寫了《分析模式可復用的對象模型》，重點介紹面向對象分析和設計的最終結果——模型本身。他將自己豐富的對象建模專業經驗與讀者分享，著眼於找出重複問題並把這些問題轉換為可復用的模型。《分析模式可復用的對象模型》提供一個模式目錄，涉及交易.測量、財務和組織內部關係等廣泛領域。
鑒於概念模式不能孤立存在，Martin Fowler還提出一系列“支持模式”，這些支持模式討論如何將概念模式轉變為適合大型信息系統構架的軟體。在介紹每種模式時，都講述設計背後的緣由以及使用這種模式的規則。書中的示例包含有用模型的使用細節並進一步探討了將會改進分析、建模和實現的復用技巧。
媒體推薦
“本書是對不斷發展的模式文獻的一個重要貢獻。它捕捉來自不同領域的深奧的對象建模專業知識，形成一個模式目錄。這些領域模式將有助於你解決不同領域中具有挑戰性的建模問題。”
——Erich Gamma
“Martin Fowler為我們給出答案，而不僅僅是一個可以找到這些答案的過程。在本書中，透過作者平實樸素的語言，你將找到自己下一個業務對象模型的重要內容。”
“就像‘四人幫’在他們的經典著作《設計模式》中總結出了通用的設計模式，Martin Fowler在這本讓人期待已久的書中為我們總結出套用領域的諸多模式。本書是從事面向對象業務建模和業務過程重組工作的所有分析人員和設計人員的必備之書。”
——Donald G. Firesmith
序言
不久前，還沒有任何有關面向對象分析和設計的書籍。而現在，卻有如此之多的書籍，以致於任何一個專業人員都無法全部涉獵。其中大部分書籍都專注於：傳授一種圖符表示法，提出一個簡單的建模過程，並用幾個簡單的示例來加以說明。本書是一本與它們完全不同的書。它並不把重點放在過程——即如何建模，而是把重點放在過程的結果——即模型本身。
我是一個信息系統對象建模方面的顧問。客戶常常聘請我訓練他們的員工如何建模和為他們的項目提供指導。我的大部分技能來自對建模技術以及如何運用這些技術的了解。然而，更重要的是我的實際經驗，這些經驗是在建造許多模型和經常分析重複出現問題的過程中積累起來的。我經常發現項目在很多方面會遇到以前我曾面對的同樣問題。這些經驗使得我可以重用以前所建造的模型，我只需要對這些模型加以改進，使之適應新的需求。
在過去的幾年裡，越來越多的人已經意識到這一現象，並且認識到那些通常介紹方法論的書籍雖然很有價值，但都只提出了學習過程的第一步，而這個學習過程還必須捕獲要被建模的實際事物本身。這種認識逐漸發展成為“模式”運動，在這一運動中匯集了各種各樣的人，他們有著不同的興趣和觀點，卻抱著共同的目標，即傳播有用的軟體系統模式。
由於這個模式群體構成的多樣性，我們很難給“模式”一個準確的定義。我們中的所有人都相信，一旦我們看到一個模式，就能辨別出它；我們認為我們在大多數情況下是一致的，但我們無法給出一個簡單的定義。我對模式的定義是：模式是一種問題解決思路，它已經適用於一個實踐環境，並且也可能適用於其它環境。
我喜歡給出一個寬鬆的定義，因為我希望能儘可能地接近模式研究的初衷，而不需要增加太多限制性的內容。模式可以有多種形式，而每一種形式增加了對於該模式有用的特性（1.2節討論有關模式研究的現狀以及本書所處的地位）。
本書討論的是分析方面的模式，這些模式反映的是業務過程的概念架構，而不是實際的軟體實現。絕大部分章節討論不同業務領域的模式。這些模式很難按照傳統的行業（如製造、金融、醫療保健等）進行分類，因為它們通常可用在多個領域。這些模式非常重要，因為它們可以幫助我們了解人們對世界的認識。基於這樣的認識去設計計算機系統並確實去改變這種認識是非常有價值的，而認識中需要改變的地方正是需要進行業務過程重組（BPR）的地方。
然而，概念模式不可能孤立存在。對於軟體工程師來講，只有在他們明白如何實現概念模型時，這些概念模型才有用。本書介紹了一些可用於將概念模型轉化成軟體實現的模式，並且討論了在一個大型信息系統中這些軟體實現是如何適應系統構架的，另外還討論了使用這些模式的具體實現技巧。
我寫本書是因為它也正是我在開始時想要閱讀的書。建模人員會從本書中找到可以幫助他們如何在新領域中大展拳腳的基本思路。這些模式包括：有用的模型、設計背後的論證以及適用範圍。擁有這些信息，建模人員就可以為特定的問題改造現有的模型。
圖書目錄
Ralph Johnson序
Ward Cunningham序
前言
第1章 緒論 1
1.1 概念模型 1
1.2 模式世界 4
1.2.1 Christopher Alexander 5
1.2.2 描述格式 5
1.2.3 關於模式的抽象程度 6
1.3 本書中的模式 7
1.3.1 建模實例 8
1.3.2 模式的來源 8
1.3.3 跨領域的模式 9
1.4 概念模型與業務過程重組 9
1.5 模式與框架 10
1.6 本書的使用 11
第一部分 分析模式
第2章 責任模式 17
2.1 團體 18
2.2 組織層次 19
2.3 組織結構 21
2.4 責任 22
2.5 責任知識級 24
2.6 團體類型泛化 26
2.7 層次型責任 27
2.8 操作範圍 29
2.9 職位 31
第3章 觀察和測量模式 33
3.1 數量 34
3.2 轉換率 36
3.3 複合單位 37
3.4 測量 38
3.5 觀察 40
3.6 觀察概念的子類型化 43
3.7 觀察方案 44
3.8 雙時間記錄 44
3.9 被否決的觀察 45
3.10 臨床觀察、假設與推理 45
3.11 關聯觀察 46
3.12 觀察過程 48
第4章 針對公司財務的觀察模式 52
4.1 企業片斷 53
4.1.1 定義維度 57
4.1.2 維度的屬性以及企業片斷 59
4.2 測量方案 60
4.2.1 保持計算的有效性 61
4.2.2 比較和因果測量方案 62
4.2.3 狀態類型：定義計畫的和實際的狀態 63
4.2.4 構造測量 66
4.2.5 維度合併 66
4.3 範圍 69
4.4 帶範圍的現象 70
4.4.1 帶範圍屬性的現象 71
4.4.2 範圍函式 73
4.5 使用最終框架 75
第5章 引用對象 77
5.1 名稱 77
5.2 標識方案 79
5.3 對象合併 81
5.3.1 複製並替換 82
5.3.2 替代 82
5.3.3 本質/表象 83
5.4 對象等價 83
第6章 庫存與賬務 85
6.1 賬目 87
6.2 事務 88
6.3 匯總賬目 90
6.4 備註賬目 92
6.5 記入規則 93
6.5.1 可逆性 94
6.5.2 不使用事務 94
6.6 個體實例方法 95
6.6.1 使用singleton類實現 95
6.6.2 使用策略模式實現 96
6.6.3 使用內部case語句實現 97
6.6.4 使用參數化方法實現 98
6.6.5 使用解釋器實現 98
6.6.6 實現方式的選擇 99
6.7 記入規則的執行 99
6.7.1 急切觸發 99
6.7.2 基於賬目的觸發 101
6.7.3 基於記入規則的觸發 102
6.7.4 向後鏈式觸發 102
6.7.5 觸發手段的比較 102
6.8 多個賬目的記入規則 103
6.9 選擇條目 106
6.10 賬務實踐 107
6.11 條目來源 109
6.12 結算單和所得計算書 110
6.13 對應賬目 111
6.14 專門化的賬目模型 112
6.15 登記條目到多個賬目 113
6.15.1 使用備註賬目 116
6.15.2 派生賬目 116
進一步閱讀 118
第7章 使用財務模型 119
7.1 結構模型 120
7.2 結構的實現 122
7.3 設定新的電話服務 124
7.4 建立通話 126
7.5 實現基於賬目的觸發 127
7.6 把電話分成白天和夜晚兩類 128
7.7 按時間收費 130
7.8 計算稅款 133
7.9 結論 134
7.9.1 記入規則的結構 134
7.9.2 什麼時候不能使用框架 136
7.9.3 賬務實踐圖 137
第8章 計畫 139
8.1 提議和執行的動作 140
8.2 完成和放棄的動作 141
8.3 掛起 142
8.4 計畫 143
8.5 方案 146
8.6 資源分配 149
8.7 輸出和啟動函式 153
第9章 交易 156
9.1 契約 156
9.2 契約夾 160
9.3 報價 165
9.4 場景 168
第10章 派生契約 176
10.1 期貨契約 177
10.2 期權 179
10.2.1 多頭、空頭、看漲和看跌：體現一種謀略的辭彙 181
10.2.2 子類型化或者非子類型化 182
10.3 產品 184
10.4 子類型狀態機 188
10.4.1 確保狀態圖的一致 190
10.4.2 一致性的使用問題 192
10.5 並行的套用和領域層次結構 194
10.5.1 套用外觀的類型檢查 195
10.5.2 給超類型一個包裝性接口 196
10.5.3 使用一個運行時屬性 196
10.5.4 使套用外觀對領域模型可見 198
10.5.5 使用異常處理 199
第11章 交易包 201
11.1 對一個包的多重訪問級別 201
11.2 相互可見性 205
11.3 包的子類型化 208
11.4 結論 209
第二部分 支持模式
第12章 信息系統的分層構架 213
12.1 兩層構架 214
12.2 三層構架 215
12.3 表示層和套用邏輯層 218
12.3.1 表示層/套用邏輯層分離的優點 222
12.3.2 在客戶/伺服器環境中伸展外觀 222
12.4 資料庫互動 224
12.4.1 把領域層連線到數據源 224
12.4.2 資料庫接口層 225
12.5 結論 227
第13章 套用外觀 229
13.1 一個醫療保健示例 229
13.2 外觀的內容 231
13.2.1 方法的類型 232
13.2.2 樣本方法 233
13.3 公共方法 234
13.4 操作 235
13.5 類型轉換 236
13.6 多重外觀 237
第14章 類型模型的模式—設計模板 240
14.1 實現關聯 242
14.1.1 雙向關聯和單向關聯 243
14.1.2 關聯的接口 243
14.1.3 基礎類型 245
14.1.4 實現一個單向關聯 246
14.1.5 在兩個方向上都使用指針的雙向實現 246
14.1.6 在一個方向上使用指針的雙向實現 247
14.1.7 使用關聯對象的雙向實現 248
14.1.8 雙向實現的比較 248
14.1.9 派生映射 249
14.1.10 非集合映射 249
14.2 實現泛化 249
14.2.1 用繼承實現 249
14.2.2 用多重繼承組合類實現 250
14.2.3 用標誌實現 250
14.2.4 用委託給一個隱藏類來實現 251
14.2.5 通過創建一個替換來實現 253
14.2.6 泛化的接口 254
14.2.7 實現hasType操作 255
14.3 對象創建 255
14.3.1 創建的接口 256
14.3.2 創建的實現 256
14.4 對象析構 256
14.4.1 析構的接口 257
14.4.2 析構的實現 257
14.5 入口點 258
14.5.1 查找對象的接口 259
14.5.2 查找操作的實現 260
14.5.3 使用類或者登記表對象 260
14.6 實現約束 260
14.7 其它技術的設計模板 261
第15章 關聯模式 263
15.1關聯類型 264
15.2 帶鍵值的映射 266
15.3 歷史映射 268
第16章 後記 273
第三部分 附 錄
附錄A 技術和符號 277
附錄B 模式列表 293
索引 301
文摘
人工智慧教程文摘
如果一個模型有多個隸屬層次關係，我們可以用一種類型化的關係（如圖2.6 所示）來表示。我們把層次關聯關係轉化成一種類型，通過使用組織結構類型的不同實例來區分不同的層次關係。這樣就能用組織結構的兩個實例（銷售組織和服務組織）來處理上一節的場景（雙層次關係）。新產生的層次關係可以通過簡單地增加新的組織結構類型的方式加以處理。顯然，這種抽象方式使我們能夠在複雜性適度增加的情況下的增加更多的系統柔性。對於雙層次關係，這樣去做並不值得，但對於多層次關係，就很有必要。另外請注意，組織結構有時間周期；這使我們可以有效地記錄組織結構的周期性變化。進而要注意的是，我並沒有把組織結構類型看成是一種屬性——類型屬性是一個很重要的概念，我們將在後面具體談到。
例：為波士頓的2176大容量卡布奇諾咖啡機而設立的服務小組向波士頓的銷售辦事處負責。我們可以將其刻畫成這樣一個組織結構模型：父節點是波士頓的銷售辦事處，子節點是波士頓的2176服務小組，組織結構類型叫做產品線管理。
例：為波士頓的2176大容量卡布奇諾咖啡機而設立的服務小組向產品支持結構中的2170產品系列服務中心負責。我們可以把它看成是一個單獨的組織結構，它的父節點是2170產品系列服務中心，而子節點是波士頓的2176服務小組。組織結構類型叫做產品支持。
要簡化對象結構，應把重點放在約束規則上。這些規則的具體形式可以是：“對於一個組織結構，如果其類型是銷售組織並且其子節點是一個部門的話，那么其父節點必須是一個區域子公司”。請注意，約束規則被表示成指向組織結構的屬性，其暗含著約束規則針對該組織結構。然而，這也意味著當通過增加新的組織結構類型的方式來擴展系統時，會改變該組織結構中的約束規則。而且，隨著組織結構類型數量的增加，這些規則將變得難以處理。
可以把約束規則放到組織結構類型中（如圖2-7所示）。針對特定的組織結構類型的所有規則被集中到一個地方，這樣便於增加新的組織結構類型。
然而，如果我們很少改變組織結構類型而是經常增加新的組織子類型，圖2-7就難以處理了。在這種情況下，組織子類型的每次增加都會導致約束規則的改變。更好的方法是讓約束規則跟隨組織子類型。概括起來，我們的目標是儘量減小模型的變化。我們應該按照這種方式，在不影響模型的其它部分的前提下，把約束規則放在最容易發生變化的地方。
