恰如其分的軟件架構
| 恰如其分的軟件架構 |
4657879809987.jpg)
本書描述了一種恰如其分的架構設計方法。作者建議根據項目面臨的風險來調整架構設計的成本，並從多個視角闡述了軟件架構的建模過程和方法，包括用例模型、概念模型、域模型、設計模型和代碼模型等。本書不僅介紹方法，而且還對方法和概念進行了歸類和闡述，將軟件架構設計融入開發實踐中，與敏捷開發方法有機地結合在一起，適合普通程序員閱讀。
目錄
基本內容
書名：恰如其分的軟件架構:風險驅動的設計方法
作者：George Fairbanks
類型：計算機與互聯網
出版日期：2013年9月5日
語種：簡體中文
ISBN：9787560990750
外文名：Just Enough Software Architecture
譯者：張逸
出版社：華中科技大學出版社
頁數：359頁
開本：16
定價：88.00
內容簡介
《恰如其分的軟件架構》的作者在探討比較多種架構風格的差異和利弊的基礎上，結合自己的工作經驗，提煉出通過風險驅動的軟件架構設計方法，旨在彌補敏捷開發方法在實際工程應用中的不足。本書將理論與實踐相結合，不僅條理清晰地描述了設計軟件架設的各種思路，而且詳細介紹了經過實踐檢驗的建模方法和架構分析技巧。
作者簡介
George Fairbanks在卡內基•梅隆大學獲得軟件工程專業博士學位，現任Rhino Research公司董事長。Rhino Research是一家專門提供軟件開發培訓及諮詢的公司，總部設在美國科羅拉多州博爾德市。
張逸是ThoughtWorks高級諮詢師，程 序員。InfoQ中文站編輯。著譯作包括《軟件設計精要與模式》《WCF服務編程》《Java設計模式》以及評註版《重構：改善既有代碼的設計》。目前居住於成都。
倪健是eBaoTech應用架構師，程序員。著作包括《簡單之美：軟件開發實踐者的思考》《IT項目管理那些事兒》（與人合著）。目前居住於上海。
媒體推薦
《恰如其分的軟件架構》一本超值的書，案例豐富有趣，言簡意賅，閱讀輕鬆。當年如果讀到這樣的書，我可以少犯許多錯誤！渴望成為更為優秀軟件設計師的讀者，這本書絕對值得在你的書架上占有一席之地。 ——Timothy J. Halloran博士，SureLogic Inc.工程總監
George Fairbanks的《恰如其分的軟件架構》一書中的風險驅動建模方法已經被NASA Johnson Space Center（JSC）成功地應用於eXtensible Information Modeler (XIM) 項目。項目的所有成員，從項目管理人員到開發人員，都必須遵循。實際上，這本書應該是每一位開發人員的必備工具。僅僅是講述(代碼模型和反模式)的部分，就值回書價了。
——Christopher Dean，
美國國家航空航天局約翰遜空間中心工程科學團隊XIM首席架構師
本書完全滿足了那些軟件開發實踐者的關鍵需求，即如何有效地創建更加實際的系統。George常常運用自己的經驗，並與學術理論相結合，為我們提供一個又一個概念模型、領域（或更廣範圍）內的最佳實踐，以及在軟件架構方面（如何更有用更現實）非常實用的指導。他在書中提出了基於風險的架構方法，並幫助我們認識到怎樣才是「恰如其分」的。本書的問世為軟件架構領域又增添了一份重要的文獻。
——Desmond D』Souza, 《MAp and Catalysis》一書的作者，Kinetium, Inc.
名人推薦
這是一本超值的書，案例豐富有趣，言簡意賅，閱讀輕鬆。當年如果讀到這樣的書，我可以少犯許多錯誤！渴望成為更為優秀軟件設計師的讀者，這本書絕對值得在你的書架上占有一席之地。
——Timothy J.Halloran博士，SureLogic Inc.工程總監
本書提出的獨特視角讓軟件架構設計變得不再難以捉摸。恰如其分的軟件架構概念及風險驅動的設計理念讓人耳目一新。作者將架構設計原則與現實問題有機地結合起來，值得所有從事軟件開發工作的人士閱讀。
——Marcus Fontoura博士，Yahoo！Research首席科學家兼架構師
圖書目錄
第1章概述1
1.1分治、知識與抽象2
1.2軟件架構的三個案例3
1.3反思5
1.4視角轉換6
1.5架構師構建架構7
1.6風險驅動的軟件架構8
1.7敏捷開發者的架構9
1.8關於本書10
第2章軟件架構15
2.1何為軟件架構？16
2.2軟件架構為何重要18
2.3架構何時重要？22
2.4推定架構23
2.5如何運用軟件架構？24
2.6架構無關的設計25
2.7專注架構的設計26
2.8提升架構的設計27
2.9大型組織中的架構30
2.10結論31
2.11延伸閱讀32
第3章風險驅動模型35
3.1風險驅動模型是什麼？37
3.2你現在採用風險驅動了嗎？38
3.3風險39
3.4技術42
3.5選擇技術的指導原則44
3.6何時停止47
3.7計劃式設計與演進式設計48
3.8軟件開發過程51
3.9理解過程變化53
3.10風險驅動模型與軟件開發過程55
3.11應用于敏捷過程56
3.12風險與架構重構58
3.13風險驅動模型的替代方案58
3.14結論60
3.15延伸閱讀61
第4章實例：家庭媒體播放器65
4.1團隊溝通67
4.2COTS組件的集成75
4.3元數據一致性81
4.4結論86
第5章建模建議89
5.1專注於風險89
5.2理解你的架構90
5.3傳播架構技能91
5.4作出合理的架構決策92
5.5避免預先大量設計93
5.6避免自頂向下設計95
5.7餘下的挑戰95
5.8特性和風險：一個故事97
第6章工程師使用模型103
6.1規模與複雜度需要抽象104
6.2抽象提供洞察力和解決手段105
6.3分析系統質量105
6.4模型忽略細節106
6.5模型能夠增強推理107
6.6提問在前，建模在後108
6.7小結108
6.8延伸閱讀109
第7章軟件架構的概念模型111
7.1規範化模型結構114
7.2領域模型、設計模型和代碼模型115
7.3指定與細化關係116
7.4主模型的視圖118
7.5組織模型的其他方式121
7.6業務建模121
7.7UML的用法122
7.8小結123
7.9延伸閱讀123
第8章領域模型127
8.1領域與架構的關係128
8.2信息模型131
8.3導航和不變量133
8.4快照134
8.5功能場景135
8.6小結136
8.7延伸閱讀137
第9章設計模型139
9.1設計模型140
9.2邊界模型141
9.3內部模型141
9.4質量屬性142
9.5Yinzer系統的設計之旅143
9.6視圖類型157
9.7動態架構模型161
9.8架構描述語言162
9.9小結163
9.10深入閱讀164
第10章代碼模型167
10.1模型—代碼差異167
10.2一致性管理171
10.3架構明顯的編碼風格174
10.4在代碼中表達設計意圖175
10.5模型嵌入代碼原理177
10.6表達什麼178
10.7在代碼中表達設計意圖的模式180
10.8電子郵件處理系統預演187
10.9小結193
第11章封裝和分割195
11.1多層級故事195
11.2層級和分割197
11.3分解策略199
11.4有效封裝203
11.5創建封裝接口206
11.6小結210
11.7深入閱讀210
第12章模型元素213
12.1和部署相關的元素214
12.2組件215
12.3組件裝配219
12.4連接器223
12.5設計決策233
12.6功能場景234
12.7（不變量（約束）239
12.8模塊239
12.9端口241
12.10質量屬性246
12.11質量屬性場景249
12.12職責251
12.13權衡252
12.14小結253
第13章模型關係255
13.1投影（視圖）關係256
13.2分割關係261
13.3組合關係261
13.4分類關係261
13.5泛化關係262
13.6指定關係263
13.7細化關係264
13.8綁定關係268
13.9依賴關係269
13.10使用關係269
13.11小結270
13.12深入閱讀271
第14章架構風格273
14.1優勢274
14.2柏拉圖式風格對體驗式風格275
14.3約束和以架構為中心的設計276
14.4模式對風格277
14.5風格目錄277
14.6分層風格277
14.7大泥球風格280
14.8管道—過濾器風格281
14.9批量順序處理風格283
14.10以模型為中心的風格285
14.11分發—訂閱風格286
14.12客戶端—服務器風格和多層288
14.13對等風格290
14.14map—reduce風格291
14.15鏡像，支架和農場風格293
14.16小結294
14.17深入閱讀295
第15章使用架構模型297
15.1理想的模型特性297
15.2和視圖一起工作303
15.3改善視圖質量306
15.4提高圖的質量310
15.5測試和證明312
15.6分析架構模型312
15.7架構不匹配318
15.8選擇你的抽象級別319
15.9規劃用戶界面320
15.10指定性模型對描述性模型320
15.11對現有系統進行建模320
15.12小結322
15.13深入閱讀323
第16章結論325
16.1挑戰326
16.2聚焦質量屬性330
16.3解決問題，而不是僅僅對它們建模331
16.4使用導軌一樣的約束332
16.5使用標準架構抽象333
術語表335
文獻347
索引355
序言
在我走上軟件開發道路之初時，就希望能擁有這樣一本書。在那時，介紹語言及面向對象編程的書籍可謂汗牛充棟，而關於設計的書卻如鳳毛麟角。了解C++語言的特性並不意味着你能設計出一個好的面向對象系統，熟知統一建模語言（UML），也未必能設計出一個好的系統架構。
本書不同於其他介紹軟件架構的書籍，區別在於：
風險驅動的架構設計 當風險很小時，設計無須謹小慎微，但當風險威脅到項目的成功時，就沒有任何藉口進行草率的設計了。許多資歷豐富的敏捷軟件支持者都認為進行適度的預先設計是有裨益的，而本書則描述了一種恰如其分的架構設計方法。它避免了以「一招鮮，吃遍天」的方式來解決「焦油坑」問題，建議根據面臨的風險來調整架構與設計的成本，摒棄倉促草率的做法，通過更為嚴謹的方式來調整大多數技術的精確度。
促進架構設計的民主化 你所在的團隊可能擁有軟件架構師——事實上，你可能正是其中一位。我認識的每一位架構師都希望所有開發者能夠理解架構。他們抱怨開發者無法理解約束存在的原因，無法認識到表面看來細小的變化怎麼會影響系統的屬性。本書力求將架構與所有軟件開發者聯繫起來。
積累陳述性知識 能夠擊中網球與知道為何能擊中網球明顯不同，心理學家將其分別稱為過程性知識（procedural knowledge）與陳述性知識（declarative knowledge）。如果你已經善於設計和構建系統，你會用到本書提供的許多技術，但是，本書更要讓你認識到你能做到的事情，並為這些概念命名。這些陳述性知識可以提高你指導其他開發者的能力。
強調工程實踐 軟件系統的設計者與構建者要做的事情很多，包括安排日程計劃、協調資源的承諾及滿足利益相關人的需求。諸多軟件架構書籍業已涵蓋了軟件開發過程與組織結構。相對而言，本書將重心放在軟件開發的技術部分，處理開發者要做的事情，以確保系統可以工作，即工程學的範疇。它為你展現了如何構建模型，如何分析架構，並在原則的指導下進行設計權衡。它還描述了軟件設計者用來分析從中等到大型規模問題的技術，指出了在哪裡才能學到專業技術的更多細節。因此，通觀全書，軟件工程師指的就是開發者，並沒有將架構師從程序員中區分出來。
提供實踐指導 本書提供了架構的實踐方法。軟件架構是一種軟件設計，設計決策會影響到架構，反之亦然。最優秀的開發者所要做的事情就是深入那些障礙的細節，理解它們，再提煉出這些障礙的本質，從整體上將它們與架構相關聯。書中採用的方式是，從架構到數據結構設計，描述具有不同抽象層級的模型，並遵循了這種向下深挖，繼而向上提升的行為。
我的職業生涯源於我對如何構建軟件系統的渴求。這種渴求引導我遊走於學術研討與行業軟件開發之間。我擁有完整的計算機科學學位：學士、碩士及博士（獲得卡耐基•梅隆大學軟件工程學的博士學位）。我的論文專注於軟件框架領域，因為它是許多開發者都要面臨的問題。我開發了一種新的規格，稱為設計片段（design fragment），它可以用來描述如何使用框架。同時，我還構建了一個基於Eclipse的工具，用於驗證它們的使用是否正確。我非常榮幸能夠得到David Garlan與Bill Scherlis的指導，並邀請到Jonathan Aldrich與Ralph Johnson成為論文的評審委員。
我受益於學術的精確與嚴密，但我的根還是在工程界。我作為軟件開發者，參與了多個項目，包括：Nortel DMS-100中央辦公電話交換機、駕駛模擬器的統計分析、時代華納通信公司的IT應用系統、Eclipse IDE插件，還有我自己創建的網絡初創公司開發的每一行代碼。我作為一名業餘的系統管理員搗鼓着自己的Linux機器，擁有一間閃爍着燈光、用電力供暖的小房間。
我在敏捷技術的早期就成為它的擁躉，1996年，我成功地鼓動我的部門將開發周期從6個月切換為2周，並在1998年開始測試先行的開發。
本書的主要讀者是那些實踐中的軟件開發者。讀者應該對基本的軟件開發思想，包括面向對象軟件開發、UML、用例與設計模式等有所了解。若能擁有實際的軟件開發過程的經驗，對閱讀本書會更有幫助，因為本書的許多基本主張都基於這些常見的經驗。若你看到開發者編寫了太多的文檔，又或者未經深思熟慮就急於編寫代碼，一定會認識到這種軟件開發方式的謬誤，需要尋找像本書提供的那些治病良方。本書同樣可以作為大學高年級學生或研究生的教材。
對於不同的讀者，這裡提出了一些期望：
新手開發者或學生 如果你已經了解軟件開發的基本機制，例如，編程語言和數據結構設計，理想情況下，已經學過通用的軟件工程學課程，本書會為你介紹軟件的特定模型，幫助你形成軟件架構的概念模型。無須繪製大量圖形、編寫大量文檔，這一模型就能幫助你從大型系統的混亂中走出來，理清思路。它還為你提供了諸如質量屬性和架構風格等理念的初次體驗。你可以學會如何從對小程序的理解，上升到對整個行業規模與質量的理解。它能加速你的成長，使你成為一位高效的、富有經驗的開發者。
經驗豐富的開發者 倘若你善於開發軟件系統，可能會被頻繁要求去指導別人。然而，你可能發現你所掌握的架構知識多少有些異於尋常，或許還使用了獨一無二的圖形標記或術語。本書將提高你指導他人的能力，理解為何你能夠在別人苦苦掙扎的領域取得成功，並教給你標準的模型、標記與名稱。
軟件架構師 在你所在的軟件組織中，一旦其他成員無法理解身為架構師的你究竟做了什麼，以及為何要這樣做，這個角色就會變得處境艱難。本書不僅教會你構建系統的技術，還提供了一些辦法幫助你向團隊解釋你的工作內容與工作方式。或者，你甚至可以將本書分享給同事，使他們成為真正的團隊夥伴，以便能夠更好地完成工作。
學術研究人員 本書為軟件架構領域做出了多個貢獻。它引入了軟件架構的風險驅動模型，這是一種決定為項目作出多少架構和設計工作的方法。它描述了三種架構方法：架構無關的設計、專注架構的設計與提升架構的設計。它還整合了軟件架構的兩種視角：功能視角與質量屬性視角，從而形成一種單獨的概念模型。本書還引入了架構明顯的編程風格（architecturally-evident coding style）的理念，通過閱讀源代碼使架構顯現。[1]