實用軟件架構：從系統環境到軟件部署 ( 簡體 字) |
| 作者：[印]蒂拉克·米特拉（Tilak Mitra）著 | 類別：1. -> 程式設計 -> 綜合 |
| 譯者： |
| 出版社：機械工業出版社 |  3dWoo書號： 46130
詢問書籍請說出此書號！【有庫存】
NT售價： 395 元 |
| 出版日：12/1/2016 |
| 頁數：256 |
| 光碟數：0 |
|
站長推薦：   |
| 印刷：黑白印刷 | 語系： ( 簡體 版 ) |
| |
加入購物車  │加到我的最愛
(請先登入會員) |
| ISBN：9787111550266 |
| 作者序 | 譯者序 | 前言 | 內容簡介 | 目錄 | 序 |
| (簡體書上所述之下載連結耗時費功, 恕不適用在台灣, 若讀者需要請自行嘗試, 恕不保證) |
| 作者序： |
| 譯者序： |
前言：軟件架構這個學科已經有半個世紀的歷史了。此概念于20世紀60年代引入，它的靈感來源于建筑物的架構，其中涉及在開始蓋樓之前擬定的一些藍圖，這些藍圖描述了建筑師對建筑物的結構所制定的設計方案與規格說明。建筑物的藍圖給出了建筑物在功能方面的設計方案，也就是樓層的空間布局示意圖，以及每個建筑工件（例如門、窗、房間、浴室、樓梯等）的尺寸。在使建筑物得以運作的那些方面，藍圖也提供了詳細的設計方案，例如承載建筑結構的地基、電線、水管和輸氣管道的設計，以及下水道系統等，要想使建筑物的功能全面運轉并發揮效用，這些方面都是不可缺少的。
信息技術（information technology，IT）中的軟件架構，其真正靈感來源于建筑架構學中的土木工程（civil engineering）這一學科。據此，我們可以把軟件架構大致分成功能架構（functional architecture）和操作架構（operational architecture）兩大類。軟件架構在 20世紀70年代開始得到大規模實踐，到了20世紀90年代，它已經成為IT界的主流，此時各種架構模式也相繼涌現。這些模式會隨著工作中反復出現的一些用法而演化，所謂反復出現（recurrence），是指這些用法會一直重復地出現在日常應用中。我們之所以能從軟件架構中提煉出架構模式，是因為有一個先決條件已經得到了滿足。這個條件就是軟件架構已經得到了充分的實踐，從而成為業界的主流做法，并且已經作為一門正式的研究與實踐學科，得到了業界的認可。
IT系統的復雜度越來越高，因此各種IT項目都會頻繁而且廣泛地運用軟件架構技術。軟件架構的方式也隨著運用面的擴大而變得豐富起來，并且還涌現出了很多流派，它們采用不同的觀點來看待軟件的架構，并根據其在開發軟件系統時所取得的實際經驗來總結并推廣各自的觀點。軟件架構的流派和觀點變得越來越多，這使很多IT工作者都不知道應該采信哪個流派的觀點。大家不妨回想一下，看看自己有沒有對下面這些問題表示過困惑？
我讀過很多架構方面的書籍，也看過很多期刊和雜志，但是我究竟應該怎樣把這些互不相同的架構流派匯整起來呢？
這些流派中有哪些方面是我比較喜歡的？
這些方面是否可以互補？
如果我是一名架構師，面對著一個時間和預算都受限制的復雜軟件系統，那么應該從哪里開始實現它呢？
我是否能成為一名成功的軟件架構師？
筆者也曾陷入這樣的困惑中。軟件架構師所要面對的一項艱難挑戰，就是尋找一種最佳的方式，來確定系統或應用程序的架構，并對其進行設計。對軟件架構的要義進行把握，既是一種科學，又是一種藝術。我們要用適當的描述語言來定義系統的軟件架構，并對其加以分析和理解，從這個層面來看它是科學。同時，我們還要用清晰、明確并且簡潔的方式把這個架構描繪出來，以便與不同的利益相關者就系統的解決方案架構進行有效的溝通，從這個層面來看它又是藝術。軟件架構師怎樣才能抓住關鍵的架構工件（architecture artifact），從而清晰地描述出整個解決方案呢？這正是難點所在。過度的設計和過多的文檔，會拖慢項目的進度，并給項目的交付帶來風險，而對軟件架構所做的不恰當處理，則會使開發者無法領悟這套架構，這是個很關鍵的問題。如果開發者不能很好地理解軟件的架構，那么他們就無法恰當地遵循技術方面的規范和限制，也無法恰當地使用這套架構來設計并開發系統中的各個部件。在軟件開發的整個生命周期中，這個問題只會越來越嚴重。
2008年，筆者在IBM developerWorks網站上寫了一系列專門談論軟件架構的文章。在連續發布4部分之后，由于某些個人原因，沒有再往下寫。接下來的幾年，筆者看到了一些網友提出的問題，也收到了一些稱贊，然而除此之外，還有另一類信息促使我進行更多的思考。比如，下面這兩個問題：
“先生您好。我正在參考您的系列文章來撰寫碩士論文。請問下一部分的文章什么時候發布？”
“Mitra先生，我們采用您所說的框架做了IT項目，但是項目暫停了，因為您的下一篇文章還沒出來。求助。”
某一天早晨，我忽然感覺讀者確實需要一本架構方面的書籍，它必須寫得簡單、明確、易于理解、便于描述，而且最為重要的是，它必須足夠實用，能夠執行。這本實用的書籍要能夠給IT工作者和軟件工程專業的學生帶來較大的幫助，使他們明白怎樣對軟件系統進行架構。過了一段時間之后，我終于決定開始寫書了。本書代表著軟件架構領域中的集體智慧、經驗、學問和知識，這些內容是筆者根據自己從業18年來的經歷收集而成的。本書面對的讀者有很多，其中包括：
軟件架構師。書中會給出一些實用而且可以反復運用的指導原則，以幫助軟件架構師來研發軟件的架構。
項目經理。本書將會幫助讀者理解并領會系統架構中的關鍵元素，它們是良好的架構所必備的元素，本書還會解釋怎樣才能在進行項目規劃時把架構活動控制得恰到好處。
高校學生。本書將會幫助大家理解怎樣把軟件架構中的理論轉述成實際的問題，并對其加以實現。無論技術如何發展，本書都可以當作長期的參考資料。
教師。通過本書，教師可以幫助學生把軟件架構中的各種理論與實際工作聯系起來，使學生變成能夠應對實際項目的軟件架構師。
首席管理者（C-level executive）或高層管理人員。本書將會幫助他們意識到研發良好的系統架構所必備的要素，對于IT界的任何一種創新活動來說，這種意識都會給公司帶來間接的好處，使他們可以更好地領悟IT架構在整個公司中的基礎地位。
筆者想把這本書寫成一本實用的教程，使讀者可以按照里面所說的方法，通過多個階段的演進來迭代式地構建出軟件的架構。書中會指出各種架構工件的運用方式，使大家可以把這些清晰、簡明、精準而且易懂的工件，恰到好處地運用在實際的應用場景中。在整本書中，筆者會以較為隨意的方式來使用“軟件”（software）“系統”（system）和“解決方案”（solution）這三個詞，由于它們在本書中指的都是架構（architecture），因此這三者之間是可以互換的。筆者之所以要采用這種不拘于字面意思的交替指稱方式，是為了使大家明白：在IT界，這三個詞之間的界限其實是相當模糊的。
從哲學角度來看，東方哲學和西方哲學之間的區別，在于它們對直覺和理性這兩種感知形式的接受程度有所不同，前者更強調直覺，而后者更強調理性。西方世界普遍相信，并且主要依賴于理性的、科學的和演繹式的推理。而東方世界則更加看重憑直覺所獲取的知識，他們認為，更高形式的意識（在這里指的是知識）是通過觀察（也包括反思自己的內心世界）得來的，而不是僅僅通過實驗式的歸納得來的。筆者生長于印度加爾各答一個文化較為多元的孟加拉家庭中，十分認同東方式的信仰和知識觀念，我認為自覺的意識最終需要通過自覺的自由意志來獲得，知識的奧義也要通過直覺和歸納式的推理來領悟。后來，筆者在西方世界生活了將近20年，在這段時間里，我開始看重科學和理性的知識形式。我認為，一個普通人要想在這個殘酷競爭的世界中生存，就必須掌握由理性與科學手段所得到的知識，對于科學、技術和IT領域來說更是如此。等到自己的工作穩定下來之后，可以去深入探索直覺感知力和歸納式推理，這種探索雖然未必會帶來回報，但或許會幫助我們從人生的存在中求得解脫。
在這本書中，筆者試著用一種解說的辦法，通過歸納式的理性推理來幫助讀者掌握實用的軟件架構方式。等到掌握了這種理性的知識之后，讀者可以把注意力放在歸納式的推理上，以探求更為玄妙的直覺知識。如果把解決最困難的架構問題比喻成尋求圣杯（Holy Grail），那么用直覺來感知軟件的架構就相當于層次更高的開悟了，這種境界，我想應該是大家夢寐以求的吧。
等到看完本書并掌握了它的要義之后，希望你能煥然一新，變成一位務實的軟件架構師。軟件架構是個有趣的學科，其中的理性知識，我想讀完這本書之后，大家應該就可以了解到。而憑直覺才能獲得的那一部分知識，則需要以理性知識為基礎，繼續去探索。在這一方面，連筆者也只是剛剛入門而已。
另外再說一句，每章開頭的那些格言，其實都是筆者自己編的。 |
內容簡介：要想構建有效的架構，軟件架構師就必須像動物繪本的畫師那樣，在清晰與模糊之間游走。這雖然很難，但卻必須做到。如果不能在二者之間達成平衡，那么通常就會直接損害系統的設計與實現。由IBM杰出工程師與首席技術官蒂拉克·米特拉先生寫的這本書，是該領域的第一本完備指南，用來全程指導軟件架構師制定出“恰到好處”的解決方案架構。作者會告訴我們應該怎樣確定并捕獲最為重要的架構工件，同時又不陷入過度的設計和過多的文檔之中。作者所講解的方法相當務實，使我們總能夠制定出成功的軟件架構。
本書通過詳盡的解說與務實的指導，告訴大家應該怎樣給實際工作中的IT項目設計架構。這些內容不受制于具體的系統、開發方法或開發環境。作者著重講解了應該怎樣認定那些需要重點關注的架構工件，以及怎樣與利益相關者之間就正在演化的解決方案進行溝通，以填補架構與實現之間的鴻溝。
通過一整套實用的案例研究，全程指引大家迭代式地構建解決方案架構。書中逐步講解了系統環境、架構概述、架構決策、功能模型、操作模型、系統設計的集成模式及基礎設施等方面的重要話題。整本書以清晰明快的筆調準確地告訴大家，怎樣才能在規定的時間和資金范圍之內，自信地打造出成功的軟件架構。
本書涵蓋下列內容
用架構來促進相關人員之間的溝通以及項目的規劃，并為功能型需求和非功能型需求（諸如可擴展性、性能、可維護性及安全性等）提供支持；
專注于當前的架構問題，而不過分依賴理論和一般規律；
對適用于架構工作的分析技術進行介紹；
“恰到好處”地捕獲與系統環境、架構概述、架構決策、功能模型及操作模型有關的信息；
介紹集成模式以及這些模式在架構設計中的用法；
介紹軟件架構所涉及的基礎設施問題；
通過真實的案例研究來展示軟件架構的各個方面。
本書由IBM杰出工程師、首席技術官Tilak Mitra親筆撰寫，Amazon全五星評價。全書通過一整套實用的案例研究，逐步講解了系統環境、架構概述、架構決策、功能模型、操作模型、系統設計的集成模式及基礎設施等方面的內容。
本書共分12章。第1章描述了一個虛構的案例，以演示問題的陳述；第2章給出軟件架構的一些背景知識，以及一些能夠促使我們做好架構工作的成熟價值理念；第3章講解軟件架構中需要關注的一些方面；第4章介紹IT系統的系統環境；第5章介紹3種關鍵視圖：企業視圖、分層視圖和IT系統視圖；第6章討論架構決策的重要性，并指導大家捕獲這些決策；第7章演示怎樣確定系統在功能方面的宏觀設計工件，并告訴大家如何用文檔來記錄這些工件；第8章著重講解系統的操作模型；第9章研究與系統集成有關的基本技術；第10章簡要地講解與主機托管有關的關鍵因素，幫助讀者更有效地利用計算資源和存儲資源；第11章簡單介紹數據分析的價值及各種形式，并從架構的角度演示數據分析藍圖中一些較為關鍵的功能構建塊；第12章分享了一些有用的實際工作經驗。
本書適合軟件架構師、項目經理、高層管理人員、高校計算機及相關專業師生閱讀。 |
目錄：題獻
譯者序
序
前言
致謝
第1章 案例研究 …… 1
1.1 業務問題 …… 1
1.1.1 技術挑戰 …… 2
1.1.2 用例 …… 2
1.1.3 在機器運轉過程中進行實時處理與監控 …… 3
1.1.4 為新機器提供無縫的激活服務 …… 3
1.1.5 生成工作定單 …… 3
1.1.6 盡量減少在為全球客戶提供服務時所產生的延遲 …… 4
1.2 小結 …… 4
第2章 軟件架構是什么？為什么需要做軟件架構 …… 6
2.1 背景知識 …… 6
2.2 軟件架構是什么 …… 7
2.3 為什么需要做軟件架構 …… 9
2.3.1 把架構視為交流工具 …… 9
2.3.2 對項目規劃施加影響力 …… 10
2.3.3 關注非功能方面的能力 …… 11
2.3.4 與設計團隊和實現團隊做出約定 …… 12
2.3.5 為影響力分析提供支持 …… 12
2.4 架構視圖與架構視點 …… 13
2.5 小結 …… 16
2.6 參考資料 …… 16
第3章 恰到好處地把握架構中的重要方面 …… 17
3.1 軟件架構中需要關注的一些方面 …… 17
3.2 小結 …… 19
第4章 系統環境 …… 20
4.1 業務環境與系統環境之間的辨析 …… 20
4.2 捕獲系統環境 …… 22
4.2.1 系統環境圖 …… 23
4.2.2 信息流 …… 25
4.3 案例研究：Elixir的系統環境 …… 27
4.3.1 Elixir的系統環境圖 …… 27
4.3.2 Elixir的信息流 …… 32
4.4 小結 …… 33
4.5 參考資料 …… 33
第5章 架構概述 …… 34
5.1 什么是架構概述 …… 34
5.2 為什么要做架構概述 …… 36
5.3 企業視圖 …… 37
5.3.1 用戶與傳輸渠道 …… 39
5.3.2 核心業務流程 …… 39
5.3.3 數據與信息 …… 40
5.3.4 技術推動力 …… 41
5.4 分層視圖 …… 42
5.4.1 第1層：操作層 …… 45
5.4.2 第2層：服務組件層 …… 45
5.4.3 第3層：服務層 …… 45
5.4.4 第4層：業務流程層 …… 46
5.4.5 第5層：消費者層 …… 46
5.4.6 第6層：集成層 …… 46
5.4.7 第7層：QoS層 …… 46
5.4.8 第8層：信息架構層 …… 47
5.4.9 第9層：治理層 …… 47
5.4.10 進一步研究分層視圖的用法 …… 47
5.5 IT系統視圖 …… 48
5.6 案例研究：Elixir的架構概述 …… 53
5.6.1 Elixir的企業視圖 …… 53
5.6.2 Elixir的業務流程 …… 54
5.6.3 Elixir的數據及信息 …… 54
5.6.4 Elixir的技術推動力 …… 55
5.6.5 Elixir的分層視圖 …… 56
5.6.6 Elixir的IT系統視圖 …… 57
5.7 小結 …… 58
5.8 參考資料 …… 59
第6章 架構決策 …… 60
6.1 為什么需要做架構決策 …… 60
6.2 怎樣開始進行架構決策 …… 61
6.3 創建架構決策 …… 62
6.4 案例研究：Elixir的架構決策 …… 67
6.5 小結 …… 69
第7章 功能模型 …… 71
7.1 為什么需要功能模型 …… 71
7.2 可追溯性 …… 73
7.3 制定功能模型 …… 74
7.3.1 邏輯層面的設計 …… 75
7.3.2 規格層面的設計 …… 79
7.3.3 物理層面的設計 …… 89
7.4 案例研究：Elixir的功能模型 …… 91
7.4.1 邏輯層面 …… 92
7.4.2 規格層面 …… 94
7.4.3 物理層面 …… 97
7.5 小結 …… 98
7.6 參考資料 …… 99
第8章 操作模型 …… 100
8.1 為什么需要操作模型 …… 101
8.2 可追溯性與服務級別協議 …… 102
8.3 制定操作模型 …… 104
8.3.1 概念操作模型 …… 105
8.3.2 規格操作模型 …… 116
8.3.3 物理操作模型 …… 122
8.4 案例研究：Elixir的操作模型 …… 132
8.4.1 COM …… 132
8.4.2 SOM …… 137
8.4.3 POM …… 138
8.5 小結 …… 140
8.6 參考資料 …… 141
第9章 集成：方式與模式 …… 142
9.1 為什么需要進行集成 …… 142
9.2 集成方式 …… 143
9.2.1 用戶界面的集成 …… 144
9.2.2 數據層面的集成 …… 144
9.2.3 消息層面的集成 …… 147
9.2.4 API層面的集成 …… 149
9.2.5 服務層面的集成 …… 150
9.3 集成模式 …… 152
9.3.1 同步的請求??δＪ?…… 152
9.3.2 批次模式 …… 153
9.3.3 同步的批次請求?Υ鵡Ｊ?…… 153
9.3.4 異步的批次請求?Υ鵡Ｊ?…… 153
9.3.5 存儲并轉發模式 …… 154
9.3.6 發布??哪Ｊ?…… 154
9.3.7 聚合模式 …… 154
9.3.8 管道與過濾器模式 …… 155
9.3.9 消息路由器模式 …… 155
9.3.10 消息轉換器模式 …… 156
9.4 案例研究：Elixir的集成視圖 …… 156
9.4.1 標簽1∼5所表示的數據流 …… 157
9.4.2 標簽6∼8所表示的數據流 …… 158
9.4.3 標簽9∼10所表示的數據流 …… 158
9.4.4 標簽11∼12所表示的數據流 …… 158
9.5 小結 …… 159
9.6 參考資料 …… 160
第10章 基礎設施問題 …… 161
10.1 為什么要把基礎設施做好 …… 162
10.2 需要考慮的基礎設施問題 …… 162
10.2.1 網絡 …… 163
10.2.2 托管 …… 165
10.2.3 高可用性與容錯性 …… 169
10.2.4 災難恢復 …… 178
10.2.5 能力規劃 …… 178
10.3 案例研究：Elixir系統的基礎設施問題 …… 181
10.4 小結 …… 183
10.5 我們現在講到什么地方了 …… 184
10.6 參考資料 …… 186
第11章 分析架構入門 …… 187
11.1 為什么要做分析 …… 188
11.2 進行數據分析所采用的維度 …… 189
11.2.1 操作分析 …… 189
11.2.2 描述性的分析 …… 190
11.2.3 預測性的分析 …… 190
11.2.4 指示性的分析 …… 191
11.2.5 認知計算 …… 192
11.3 分析架構的基礎 …… 194
11.3.1 分層視圖中的各層及五大支柱 …… 195
11.3.2 水平層 …… 196
11.3.3 垂直層 …… 199
11.3.4 五大支柱 …… 201
11.4 架構構建塊 …… 205
11.4.1 數據類型層中的ABB …… 206
11.4.2 數據獲取與訪問層中的ABB …… 207
11.4.3 數據存儲庫層中的ABB …… 208
11.4.4 模型層中的ABB …… 209
11.4.5 數據集成與整合層中的ABB …… 210
11.4.6 分析解決方案層中的ABB …… 211
11.4.7 消費者層中的ABB …… 213
11.4.8 元數據層中的ABB …… 213
11.4.9 數據與信息安全層中的ABB …… 214
11.4.10 描述性的分析中的ABB …… 215
11.4.11 預測性的分析中的ABB …… 215
11.4.12 指示性的分析中的ABB …… 217
11.4.13 操作分析中的ABB …… 217
11.4.14 認知計算中的ABB …… 218
11.5 小結 …… 219
11.6 參考資料 …… 220
第12章 架構經驗談 …… 222
12.1 各種敏捷開發觀點應該加以融合 …… 222
12.2 傳統的需求收集技術過時了 …… 224
12.3 MVP范式值得考慮 …… 225
12.4 不要忙于應付各種事務 …… 226
12.5 預測性的分析并不是唯一的分析切入點 …… 227
12.6 領導能力也可以通過培養而獲得 …… 227
12.7 架構不應該由技術來驅動 …… 228
12.8 開源軟件很好，但要謹慎使用 …… 230
12.9 把看似簡單的問題總結起來 …… 230
12.10 根據技術產品的核心優勢來確定架構基線 …… 231
12.11 小結 …… 232
12.12 參考資料 …… 232
附錄A 25個實用小知識 …… 233
附錄B Elixir的功能模型（續） …… 252 |
| 序： |
