☆☆☆☆☆
簡體網頁||繁體網頁



點擊這裡下載

類似圖書 點擊查看全場最低價

---

編輯推薦

　　《恰如其分的軟件架構》的作者在探討比較多種架構風格的差異和利弊的基礎上，結閤自己的工作經驗，提煉齣通過風險驅動的軟件架構設計方法，旨在彌補敏捷開發方法在實際工程應用中的不足。本書將理論與實踐相結閤，不僅條理清晰地描述瞭設計軟件架設的各種思路，而且詳細介紹瞭經過實踐檢驗的建模方法和架構分析技巧。

內容簡介

　　《恰如其分的軟件架構》描述瞭一種恰如其分的架構設計方法。作者建議根據項目麵臨的風險來調整架構設計的成本，並從多個視角闡述瞭軟件架構的建模過程和方法，包括用例模型、概念模型、域模型、設計模型和代碼模型等。本書不僅介紹方法，而且還對方法和概念進行瞭歸類和闡述，將軟件架構設計融入開發實踐中，與敏捷開發方法有機地結閤在一起，適閤普通程序員閱讀。

作者簡介

　　George Fairbanks，在卡內基·梅隆大學獲得軟件工程專業博士學位，現任Rhino Research公司董事長。Rhino Research是一傢專門提供軟件開發培訓及谘詢的公司，總部設在美國科羅拉多州博爾德市。

　　張逸，ThoughtWorks高級谘詢師，程 序員。InfoQ中文站編輯。著譯作包括《軟件設計精要與模式》《WCF服務編程》《Java設計模式》以及評注版《重構：改善既有代碼的設計》。目前居住於成都。

　　倪健，eBaoTech應用架構師，程序員。著作包括《簡單之美：軟件開發實踐者的思考》《IT項目管理那些事兒》（與人閤著）。目前居住於上海。

內頁插圖

目錄

第1章 概述
1.1 分治、知識與抽象
1.2 軟件架構的三個案例
1.3 反思
1.4 視角轉換
1.5 架構師構建架構
1.6 風險驅動的軟件架構
1.7 敏捷開發者的架構
1.8 關於本書

第2章 軟件架構
2.1 何為軟件架構？
2.2 軟件架構為何重要
2.3 架構何時重要？
2.4 推定架構
2.5 如何運用軟件架構？
2.6 架構無關的設計
2.7 專注架構的設計
2.8 提升架構的設計
2.9 大型組織中的架構
2.10 結論
2.11 延伸閱讀

第3章 風險驅動模型
3.1 風險驅動模型是什麼？
3.2 你現在采用風險驅動瞭嗎？
3.3 風險
3.4 技術
3.5 選擇技術的指導原則
3.6 何時停止
3.7 計劃式設計與演進式設計
3.8 軟件開發過程
3.9 理解過程變化
3.10 風險驅動模型與軟件開發過程
3.11 應用於敏捷過程
3.12 風險與架構重構
3.13 風險驅動模型的替代方案
3.14 結論
3.15 延伸閱讀

第4章 實例：傢庭媒體播放器
4.1 團隊溝通
4.2 COTS組件的集成
4.3 元數據一緻性
4.4 結論

第5章 建模建議
5.1 專注於風險
5.2 理解你的架構
5.3 傳播架構技能
5.4 作齣閤理的架構決策
5.5 避免預先大量設計
5.6 避免自頂嚮下設計
5.7 餘下的挑戰
5.8 特性和風險：一個故事

第6章 工程師使用模型
6.1 規模與復雜度需要抽象
6.2 抽象提供洞察力和解決手段
6.3 分析係統質量
6.4 模型忽略細節
6.5 模型能夠增強推理
6.6 提問在前，建模在後
6.7 小結
6.8 延伸閱讀

第7章 軟件架構的概念模型
7.1 規範化模型結構
7.2 領域模型、設計模型和代碼模型
7.3 指定與細化關係
7.4 主模型的視圖
7.5 組織模型的其他方式
7.6 業務建模
7.7 UML的用法
7.8 小結
7.9 延伸閱讀

第8章 領域模型
8.1 領域與架構的關係
8.2 信息模型
8.3 導航和不變量
8.4 快照
8.5 功能場景
8.6 小結
8.7 延伸閱讀

第9章 設計模型
9.1 設計模型
9.2 邊界模型
9.3 內部模型
9.4 質量屬性
9.5 Yinzer係統的設計之旅
9.6 視圖類型
9.7 動態架構模型
9.8 架構描述語言
9.9 小結
9.10 深入閱讀


第10章 代碼模型
10.1 模型-代碼差異
10.2 一緻性管理
10.3 架構明顯的編碼風格
10.4 在代碼中錶達設計意圖
10.5 模型嵌入代碼原理
10.6 錶達什麼
10.7 在代碼中錶達設計意圖的模式
10.8 電子郵件處理係統預演
10.9 小結

第11章 封裝和分割
11.1 多層級故事
11.2 層級和分割
11.3 分解策略
11.4 有效封裝
11.5 創建封裝接口
11.6 小結
11.7 深入閱讀

第12章 模型元素
12.1 和部署相關的元素
12.2 組件
12.3 組件裝配
12.4 連接器
12.5 設計決策
12.6 功能場景
12.7 (不變量(約束)
12.8 模塊
12.9 端口
12.10 質量屬性
12.11 質量屬性場景
12.12 職責
12.13 權衡
12.14 小結

第13章 模型關係
13.1 投影(視圖)關係
13.2 分割關係
13.3 組閤關係
13.4 分類關係
13.5 泛化關係
13.6 指定關係
13.7 細化關係
13.8 綁定關係
13.9 依賴關係
13.10 使用關係
13.11 小結
13.12 深入閱讀

第14章 架構風格
14.1 優勢
14.2 柏拉圖式風格對體驗式風格
14.3 約束和以架構為中心的設計
14.4 模式對風格
14.5 風格目錄
14.6 分層風格
14.7 大泥球風格
14.8 管道-過濾器風格
14.9 批量順序處理風格
14.10 以模型為中心的風格
14.11 分發-訂閱風格
14.12 客戶端-服務器風格和多層
14.13 對等風格
14.14 map-reduce風格
14.15 鏡像，支架和農場風格
14.16 小結
14.17 深入閱讀

第15章 使用架構模型
15.1 理想的模型特性
15.2 和視圖一起工作
15.3 改善視圖質量
15.4 提高圖的質量
15.5 測試和證明
15.6 分析架構模型
15.7 架構不匹配
15.8 選擇你的抽象級彆
15.9 規劃用戶界麵
15.10 指定性模型對描述性模型
15.11 對現有係統進行建模
15.12 小結
15.13 深入閱讀

第16章 結論
16.1 挑戰
16.2 聚焦質量屬性
16.3 解決問題，而不是僅僅對它們建模
16.4 使用導軌一樣的約束
16.5 使用標準架構抽象
術語錶
文獻
索引

精彩書摘

　　9.6視圖類型
　　對所有的視圖做一次迴顧，就可以看到它們的組織方式中有一定的模式。有些視圖，相互之間可以很容易地進行驗證，而另一些則無法做到。例如，Yinzer係統的功能場景視圖和組件裝配視圖，相互之間是可以驗證的，甚至可以想象，即使將這兩個視圖閤並為一個單一視圖也並不太難。
　　很多視圖都難以和源代碼視圖進行對應，比方說，實例對象或實例組件的視圖。為瞭與源代碼視圖對應，可能不得不遍曆源代碼，然後在腦子裏想象，哪些組件實例將會齣現在運行時，又將會運行在什麼樣的結構之上。換句話說，如果你一隻手上有源代碼，一隻手上有組件裝配視圖，要想確定代碼能不能在運行期創建齣組件實例的結構，還是要費一番工夫的。與此同時，功能場景視圖和組件裝配視圖可以輕鬆對應，但是，要想對應模塊視圖和運行時視圖，看上去也不太容易。把容易對應的視圖進行分組，這應該是你最想做的事情。
　　9.6.1視圖類型定義
　　分組是通過視圖類型來完成的。視圖類型是一組或一類可以輕鬆相互對應的視圖（Clementsetal.，20lo）。不同視圖類型的視圖是不能對應的。在軟件架構中，視圖類型Ⅲ可以應用於任何設計模型和代碼模型，包括項層的邊界模型，以及嵌套的內部模型或邊界模型。
　　不幸的是，無法輕易地對應軟件係統的每一個視圖。很顯然，從某些意義上來說，所有的視圖都必須是可以對應的（即使隻是在你的頭腦中），因為，所構建的係統應該符閤所有的視圖。關於對應視圖，最好是多看看彆人的設計，而不僅僅隻看自己的，看看要在他們的視圖之間找到缺陷和不一緻有多難。
　　9.6。2標準架構視圖類型
　　軟件架構中有三個標準視圖類型：模塊視圖類型、運行時視圖類型及部署視圖類型。模塊視圖類型（moduleviewtype）包含瞭可以在編譯時看到的元素視圖，包括像源代碼和配置文件這樣的製品。組件類型、連接器類型及端口類型的定義也是在模塊視圖類型中，此外，還有類和接口的定義。
　　......

前言/序言

　　在我走上軟件開發道路之初時，就希望能擁有這樣一本書。在那時，介紹語言及麵嚮對象編程的書籍可謂汗牛充棟，而關於設計的書卻如鳳毛麟角。瞭解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）的理念，通過閱讀源代碼使架構顯現。
恰如其分的軟件架構 [Just Enough Software Architecture] 下載 mobi epub pdf txt 電子書

評分☆☆☆☆☆

還沒看完不評價，非要評價隻能給差評瞭

評分☆☆☆☆☆

好好好好好好好好好好好好好好好好好好好好好好好好好好好好好好好好好好好好好好

評分☆☆☆☆☆

內容還沒看完，初步感覺不錯

評分☆☆☆☆☆

好呀

評分☆☆☆☆☆

速度很給力，不錯

評分☆☆☆☆☆

看到 買瞭 收到 沒看 放著 謝謝

評分☆☆☆☆☆

差評差評，四個訂單拆成8個，發票不全，怎麼報銷，總之最糟糕的一次購物。

評分☆☆☆☆☆

活動時買的，不然太貴瞭。

評分☆☆☆☆☆

摺扣給力，書本身很好，但是讓翻譯給毀瞭

類似圖書 點擊查看全場最低價