<del id="qes8q"></del>
 書單推薦 新書推薦 |
系統(tǒng)架構(gòu)：復雜系統(tǒng)的產(chǎn)品設計與開發(fā) 
定 價：119 元 叢書名：架構(gòu)師書庫
9 7 5 8 5 7 1 1 4 1 3 1 0 
本書首先講解了什么是系統(tǒng)，什么是系統(tǒng)架構(gòu)，并從形式和功能兩個方面講解了如何分析系統(tǒng)。之后開始講解如何創(chuàng)建良好的系統(tǒng)架構(gòu)。在將概念演化為架構(gòu)的過程中，架構(gòu)師需要對系統(tǒng)進行分解，以看清這些組件的結(jié)構(gòu)以及它們之間的交互情況，因此需要根據(jù)一些衡量指標來構(gòu)建權(quán)衡空間，以便使用優(yōu)化算法找出優(yōu)勢較大的架構(gòu)。
前言
我們寫這本書，是為了闡述一種強大的思想。越來越多的人已經(jīng)開始有了這種思想，這就是“系統(tǒng)的架構(gòu)”（architecture of a system）。從電網(wǎng)的架構(gòu)到移動支付系統(tǒng)的架構(gòu)，很多領域都出現(xiàn)了系統(tǒng)架構(gòu)的思維。架構(gòu)就是系統(tǒng)的DNA，也是形成競爭優(yōu)勢的基礎所在。擁有系統(tǒng)架構(gòu)師這一頭銜的專業(yè)人士，現(xiàn)在已經(jīng)超過10萬人，此外還有更多的人以其他身份參與架構(gòu)工作。
對于強大的思想，其邊界一般都比較模糊。我們發(fā)現(xiàn)許多同事、客戶和同學都能夠意識到系統(tǒng)架構(gòu)問題，但他們對這個詞的用法有所區(qū)別。這個詞一般用來區(qū)分兩個已有的系統(tǒng)，例如“這兩種山地自行車的架構(gòu)不同”。
系統(tǒng)的架構(gòu)到底是由什么組成的？這個話題通常會引發(fā)巨大的爭論。在某些領域中，架構(gòu)用來指代一項能夠在抽象層面上區(qū)分兩類系統(tǒng)的決策，例如“封包交換的架構(gòu)”（packet-switched architecture）與“電路交換的架構(gòu)”（circuit-switched architecture）。而在另外一些領域中，這個詞則用來在忽略某些小細節(jié)的情況下描述整體的實現(xiàn)，例如“我們的軟件是用來充當服務架構(gòu)的”。
我們的目標是闡述架構(gòu)思維的強大之處，并且使其邊界變得更加明晰。架構(gòu)思維的強大，源自它能夠使我們在項目的早期階段權(quán)衡各種架構(gòu)、展望后續(xù)的發(fā)展情況，并發(fā)現(xiàn)各種約束以及對提升項目價值較為重要的機遇。如果架構(gòu)把全部細節(jié)都包括進去，那么我們就無法在各種粗略的想法之間輕易跳躍，但如果架構(gòu)中缺少了重要的價值驅(qū)動力，那它又顯得沒有意義。
我們寫本書時所持有的理念與Eberhardt Rechtin相同，都認為架構(gòu)師應該是專才，而非通才。我們想在書中描述系統(tǒng)架構(gòu)的分析與構(gòu)建過程，也想展示系統(tǒng)架構(gòu)的“科學性”。與產(chǎn)品設計規(guī)范相比，本書的措辭在某種程度上較為寬松一些，因為我們要處理的系統(tǒng)更加復雜。產(chǎn)品研發(fā)人員所重視的是設計問題，而我們要強調(diào)的則是系統(tǒng)中的各個部件如何才能凝聚成一個連貫的整體，我們重視的是這個奇妙的涌現(xiàn)過程。
我們把過去的經(jīng)驗融入了本書中。我們有幸參與了許多復雜系統(tǒng)的早期研發(fā)工作，這些系統(tǒng)遍布通信、運輸、移動廣告、財經(jīng)、機器人、醫(yī)療設備等各個領域，其復雜程度也各有不同，從農(nóng)具到國際空間站，我們都接觸過。
此外，書中的案例研究還涉及混合動力車（hybrid car）及商用飛機（commercial aircraft）等其他領域的系統(tǒng)架構(gòu)師所總結(jié)出的一些經(jīng)驗。我們認為，本書必須要能夠應對當前系統(tǒng)架構(gòu)師所面臨的各項挑戰(zhàn)，因為只有這樣，才能推進系統(tǒng)架構(gòu)的發(fā)展。
本書的核心受眾有兩類人，一類是專業(yè)的架構(gòu)師，另一類是工程學的學生。系統(tǒng)架構(gòu)這一理念，是相關行業(yè)的從業(yè)者從實踐和嘗試中得來的，這些從業(yè)者運用自身的智慧，試著總結(jié)出一些經(jīng)驗，以應對研發(fā)新系統(tǒng)時所面臨的挑戰(zhàn)。本書的一部分目標讀者是進行架構(gòu)決策的資深專業(yè)人士。這些專業(yè)人士包括高級技術人員，也包括軟件、電子、工業(yè)用品、航空、汽車及消費用品等科技產(chǎn)業(yè)中的管理人員。
本書的另一部分目標讀者是工程學的學生。本書是根據(jù)過去15年間我們在麻省理工學院講授研究生課程時的教學經(jīng)驗而寫成的，其中有很多學生后來成了私人企業(yè)和政府部門中的佼佼者，對此我們深感榮幸。架構(gòu)思維不僅可以幫助我們理解系統(tǒng)當前的運作方式，而且對于科技組織的管理來說，這也應該是一項必備的能力。
致謝我們要感謝使本書得以面世的諸位人士。首先，感謝Bill Simmons、Vic Tang、Steve Imrich、Carlos Gorbea和Peter Davison，他們在本書的相關章節(jié)中提供了自己的專業(yè)意見，并對本書的初稿做了點評。Norman R. Augustine為本書撰寫了推薦序，并幫助我們成形系統(tǒng)架構(gòu)方面的想法，為此我們深表感激。
感謝評審者Chris Magee、Warren Seering、Eun Suk Suh、Carlos Morales、Michael Yukish及Ernst Fricke給我們提供了明確的意見，并幫我們指出了未能傳達出關鍵思想的那些段落。還要感謝很多匿名評審者，他們給出的反饋意見使我們能夠?qū)Ρ緯右愿倪M。感謝OPM（Object Process Methodology，對象過程方法）的研發(fā)者Dov Dori，他是我們的優(yōu)秀合作伙伴。
感謝Pat Hale為我們在MIT的教學活動提供支持并對本書初稿給出反饋。感謝MIT系統(tǒng)設計與管理2011班（MIT System Design and Management Class of 2011）的63位同學詳細閱讀本書的每一章，并給出大量建議。尤其要感謝Erik Garcia、Marwan Hussein、Allen Donnelly、Greg Wilmer、Matt Strother、David Petrucci、Suzanne Livingstone、Michael Livingstone及Kevin Somerville。感謝MIT圖書館的Ellen Finnie Duranceau幫我們明智地選擇了出版社。
本書的編寫得益于歷屆的研究生，他們所貢獻的內(nèi)容以各種形式出現(xiàn)在本書中。除了上面提到的那些人之外，還要感謝Morgan Dwyer、Marc Sanchez、Jonathan Battat、Ben Koo、Andreas Hein及Ryan Boas。
感謝Pearson團隊的Holly Stark、Rose Kernan、Erin Ault、Scott Disanno及Bram van Kempen為本書的出版所付出的辛勤勞動。
最后，感謝Crawley的妻子Ana、Cameron的妻子Tess，以及Selva的妻子Karen，感謝你們在周末和假期對我們著書工作的理解，使我們不至于把它拖成一本“永遠都寫不完的書”。
—Edward Crawley Bruce Cameron Daniel Selva馬薩諸塞州劍橋市
推 薦 序Norman R. Augustine在醫(yī)療健康領域中，有一種趨勢特別有前途，這就是生物醫(yī)學研究與工程實踐的結(jié)合。我有一位朋友是工程師，他最近告訴我，美國一家知名大學曾經(jīng)開了這樣一個會，工程系與心臟病學科系的教研人員，在會上探討了這兩種學科的結(jié)合方式。會議的重點是構(gòu)建一顆可供人類使用的機械心臟，心臟病學科系的主管剛開始描述人類心臟的各項特征，就有工程師打斷他，并問道：“機械心臟必須放在胸腔中嗎？有沒有可能放在其他更容易夠到的地方？例如大腿中？”開會的人以前從來沒考慮過這種可能。主管接著描述心臟的特征，但是過了一會兒，又有另一個工程師打斷他，并提問：“能不能不要只放一個心臟，而是把三顆或四顆心臟組合成分布式系統(tǒng)？”這個問題，也是大家從未考慮過的。
本書由系統(tǒng)架構(gòu)領域內(nèi)三位備受崇敬的領軍人物撰寫，他們的觀點很有見地。書中討論的就是如何提出并回答上面那樣的問題。我在工作中曾經(jīng)碰到工程、商務、政府等方面的各種系統(tǒng)架構(gòu)問題，當運用系統(tǒng)架構(gòu)領域中的一些經(jīng)驗來解決這些問題時，我發(fā)現(xiàn)結(jié)果會好很多。
然而，單單運用這些經(jīng)驗是不夠的。剛開始工作時，我記得自己總是問同事各種問題。當時我們正在“合作”完成一個導彈項目，我問他們?yōu)槭裁匆捎媚撤N特定的方式來設計產(chǎn)品的某個部件。有人給出的原因是“這種設計方式重量最輕”，有人說他設計的那一部分雷達橫截面（radar cross-section）最小，還有人說自己設計的那個部件成本低、體積小，等等。
這些理由都不錯，可是其中缺了一樣東西。那就是系統(tǒng)架構(gòu)師（system architect）。
系統(tǒng)架構(gòu)師的缺位很常見，但表現(xiàn)方式一般比較微妙。幾年前，我曾經(jīng)參與了近音速運輸機（Near-Sonic Transport aircraft）的早期研發(fā)工作。一份市場調(diào)查表明，乘客想要更快地到達目的地。近音速運輸?shù)睦砟�，就是想使速度盡量接近音速（也就是接近1馬赫，1馬赫≈1225km/h），但又不超過它，以避免超過音速之后所引發(fā)的各種問題。然而空氣動力學者（我早前的研究領域就是空氣動力學）發(fā)現(xiàn)：這樣做使得飛機在阻力曲線上會進入一個耗油量陡增的區(qū)域。
從系統(tǒng)架構(gòu)的觀點來看，我們要解決的問題并不是怎樣飛得更快，而是如何縮短乘客從家中到機場、辦理登機手續(xù)、過安檢、上飛機、飛行、落地后取行李并駛往最終目標所需的總時間。把這個問題放在剛才那個情境中考慮，我們就會發(fā)現(xiàn)，更基本的問題其實應該是：節(jié)省這5分鐘或10分鐘的飛行時間，究竟能給乘客帶來多大的好處？答案是：帶不來多大好處。因此，這項近音速運輸機計劃就提前終止了。如果我們想使乘客更快地到達目的地，那么顯然還有其他更好的方案可供探索。這個項目之所以失敗，是因為大家沒有意識到自己正在處理的是系統(tǒng)架構(gòu)問題，而不單單是空氣動力學或飛機設計方面的問題。
這些年來，我一直在不斷地完善自己對“系統(tǒng)”這個詞所下的定義。系統(tǒng)是“可以交互的兩個或多個元素”，而本書作者又明智地補充了一點，那就是系統(tǒng)的功效必須大于各自元素的功效之和。盡管在概念層面很簡單，但是現(xiàn)實世界中的系統(tǒng)相當復雜。實際上，對于由若干元素所構(gòu)成的（而且這些元素之間都以最簡單的方式來交互）系統(tǒng)來說，描述其可能具備的狀態(tài)數(shù)量所用的那個公式非常嚇人，有“怪獸公式”之稱。此外，很多系統(tǒng)里面還有人的因素在內(nèi)，如果系統(tǒng)里面還包括人，那么系統(tǒng)架構(gòu)所面臨的困難就會更大，因為人的因素會帶來不確定性。我們在現(xiàn)實中遇到的就是這種系統(tǒng)，本書作者要分析和解決的架構(gòu)問題，也針對的是這種系統(tǒng)。
我曾經(jīng)分析過這樣一個給美國南極站進行補給的系統(tǒng)。與其他系統(tǒng)一樣，我需要非常謹慎地設定具體的評估目標。是要縮減在可以預期的狀況下所產(chǎn)生的消耗，還是要減少在無法預期的最差狀況（例如糟糕的天氣）下所產(chǎn)生的消耗？又或者是要盡量避免在補給品根本無法送達時所發(fā)生的那些“令人遺憾的”狀況？可以考慮的目標還有很多。
在這個系統(tǒng)中，有很多個必須互相配合的元素，例如運輸船、破冰船、各種飛機、用于卸貨的冰碼頭、存儲設施、交通工具、通信等。而且在做各種決策時，還要考慮架構(gòu)中一直可能會發(fā)生的一種危險，那就是單點故障。
我還在商務領域中遇到了一個比剛才更復雜的問題，那就是能不能把7家公司的所有部門或主要部門，合并為洛克希德·馬丁公司，如果能，應該如何去做。這個系統(tǒng)中的每個“元素”都有其優(yōu)缺點，每個都涉及很多人，都有自己的目標、能力和局限性。這項決策的關鍵在于，合并之后的新公司，其效能是否遠遠高于原有那些部分各自的效能總和。如果做不到這一點，那就沒有理由耗費資金去進行合并與收購了。
對于這一類復雜問題來說，并沒有簡單的數(shù)學公式能夠給出“正確”答案。然而，系統(tǒng)思維（systems thinking）的訓練是一項極為有用的工具，可以幫助我們?nèi)ピu估系統(tǒng)的觀感、系統(tǒng)中潛藏的機遇以及系統(tǒng)對參數(shù)的敏感程度等。在剛才那個企業(yè)合并的案例中，大多數(shù)人都認為合并是“對的”，順便說一下，在相似的案例中，有80%的情況也是如此。
我與本書的一位作者及其他同事，曾經(jīng)向美國總統(tǒng)提出一項載人航天計劃，這項計劃是為將來的幾十年而制定的。在這個案例中，最困難的地方是怎樣合理地定義任務（mission），雖說確定適當?shù)挠布渲靡彩莻�不小的工作，但與前者比起來，難度還是要低一些。所幸這種問題都可以通過系統(tǒng)思維來解決。
正如作者在書中所說的那樣，系統(tǒng)架構(gòu)的建立過程，既是科學，又是藝術。盡管這聽起來很美好，但現(xiàn)實相當殘酷。與達爾文式的物種進化現(xiàn)象一樣，用過去的錯誤架構(gòu)所搭建出來的系統(tǒng)是無法生存的；反之，用良好的架構(gòu)所搭建的系統(tǒng)不僅可以生存，而且會越來越好。
所謂復雜系統(tǒng)的架構(gòu)，也就是這么一回事。
目錄
系統(tǒng)架構(gòu)原則
譯者序
推薦序
前言
致謝
作者介紹
第一部分系統(tǒng)思維
第1章 系統(tǒng)架構(gòu)簡介 2
1.1 復雜系統(tǒng)的架構(gòu) 2
1.2 良好架構(gòu)的優(yōu)勢 2
1.3 學習目標 5
1.4 本書結(jié)構(gòu) 6
1.5 參考資料 7
第2章 系統(tǒng)思維 8
2.1 簡介 8
2.2 系統(tǒng)與涌現(xiàn) 8
2.2.1 系統(tǒng) 8
2.2.2 涌現(xiàn) 10
2.3 任務一：確定系統(tǒng)及其形式與功能 13
2.3.1 形式與功能 13
2.3.2 工具-過程-操作數(shù)：這是人類的標準思維模式嗎 16
2.4 任務二：確定系統(tǒng)中的實體及其形式與功能 16
2.4.1 具備形式與功能的實體 17
2.4.2 確定如何將系統(tǒng)初步分解為恰當?shù)膶嶓w 18
2.4.3 用整體思維找出系統(tǒng)中的潛在實體 19
2.4.4 集中注意力，找出系統(tǒng)中的重要實體 21
2.4.5 為實體創(chuàng)建抽象或從實體中發(fā)現(xiàn)抽象 22
2.4.6 定義系統(tǒng)的邊界，并將其與外圍環(huán)境隔開 24
2.5 任務三：確定實體之間的關系 25
2.5.1 關系的形式與功能 25
2.5.2 外部接口 28
2.6 任務四：涌現(xiàn) 28
2.6.1 涌現(xiàn)的重要性 28
2.6.2 系統(tǒng)故障 29
2.6.3 預測涌現(xiàn)物 30
2.6.4 涌現(xiàn)物依賴于實體及其關系 31
2.7 小結(jié) 32
2.8 參考資料 33
第3章 思考復雜的系統(tǒng) 34
3.1 簡介 34
3.2 系統(tǒng)中的復雜度 34
3.2.1 復雜度 34
3.2.2 引入Team XT這一范例系統(tǒng) 35
3.3 系統(tǒng)的分解 38
3.3.1 分解 38
3.3.2 體系 39
3.3.3 層級分解 39
3.3.4 簡單的系統(tǒng)、復雜度適中的系統(tǒng)以及復雜的系統(tǒng) 41
3.3.5 原子部件 42
3.4 特殊的邏輯關系 43
3.4.1 類/實例關系 43
3.4.2 特化關系 43
3.4.3 遞歸 44
3.5 對復雜系統(tǒng)進行思索 44
3.5.1 自頂向下及自底向上式的思考 44
3.5.2 交替思考 45
3.6 架構(gòu)展示工具：SysML與OPM 45
3.6.1 視圖與投射 45
3.6.2 SysML 46
3.6.3 OPM 46
3.7 小結(jié) 49
3.8 參考資料 50
第二部分 系統(tǒng)架構(gòu)的分析
第4章 形式 53
4.1 簡介 53
4.2 架構(gòu)中的形式 53
4.2.1 形式 53
4.2.2 用解析表示法來表現(xiàn)形式：對象 56
4.2.3 形式的分解 57
4.3 對架構(gòu)中的形式進行分析 58
4.3.1 定義系統(tǒng) 58
4.3.2 確定形式實體 59
4.3.3 把泵作為復雜度適中的系統(tǒng)來分析 61
4.4 對架構(gòu)中的形式關系進行分析 63
4.4.1 形式關系 63
4.4.2 空間/拓撲形式關系 65
4.4.3 用圖和圖表來展現(xiàn)形式關系：OPM 67
4.4.4 用表格及類似矩陣的視圖來展現(xiàn)形式關系：DSM 70
4.4.5 連接性的形式關系 71
4.4.6 其他的形式關系 74
4.5 形式環(huán)境 75
4.5.1 伴生系統(tǒng)、整個產(chǎn)品系統(tǒng)及系統(tǒng)邊界 75
4.5.2 使用情境 77
4.6 軟件系統(tǒng)中的形式 77
4.6.1 軟件系統(tǒng)：信息形式及其二元性 77
4.6.2 軟件中的形式實體與形式關系 79
4.6.3 軟件系統(tǒng)所在的整個產(chǎn)品系統(tǒng)、軟件系統(tǒng)的邊界及使用情境 81
4.7 小結(jié) 82
4.8 參考資料 82
第5章 功能 83
5.1 簡介 83
5.2 架構(gòu)中的功能 84
5.2.1 功能 84
5.2.2 把功能視為過程加操作數(shù) 84
5.2.3 用解析表示法來展現(xiàn)功能 85
5.3 分析對外展現(xiàn)的功能和價值 89
5.3.1 對外界展現(xiàn)的主要功能 89
5.3.2 與價值有關的操作數(shù) 90
5.4 對內(nèi)部功能進行分析 93
5.4.1 內(nèi)部功能 93
5.4.2 確定內(nèi)部功能 94
5.5 分析功能交互及功能架構(gòu) 97
5.5.1 功能交互與功能架構(gòu) 97
5.5.2 確定功能交互 98
5.5.3 價值通路 100
5.5.4 涌現(xiàn)與細分 101
5.5.5 軟件系統(tǒng)中的功能架構(gòu) 102
5.6 與價值相關的次要外部功能及內(nèi)部功能 105
5.7 小結(jié) 106
5.8 參考資料 107
第6章 系統(tǒng)架構(gòu) 108
6.1 簡介 108
6.2 系統(tǒng)架構(gòu)：形式與功能 109
6.2.1 形式與功能之間的映射 109
6.2.2 確定形式與過程之間的映射 114
6.2.3 形式結(jié)構(gòu)承載并展現(xiàn)功能交互 116
6.2.4 確定形式結(jié)構(gòu)是如何承載功能和性能的 118
6.3 系統(tǒng)架構(gòu)中的非理想因素、支持層及接口 119
6.3.1 系統(tǒng)架構(gòu)中的非理想因素 119
6.3.2 系統(tǒng)架構(gòu)中的支持功能及支持層 120
6.3.3 形式與功能中的系統(tǒng)接口 121
6.4 操作行為 123
6.4.1 操作者 124
6.4.2 行為 124
6.4.3 操作成本 126
6.5 用各種表示法來推究系統(tǒng)架構(gòu) 127
6.5.1 能夠?qū)ο到y(tǒng)架構(gòu)進行簡化的幾種方式 127
6.5.2 用投射法來表示系統(tǒng)的架構(gòu) 128
6.5.3 把過程投射到對象 129
6.5.4 把過程和操作數(shù)投射到形式 130
6.6 小結(jié) 133
6.7 參考資料 134
第7章 與特定解決方案無關的功能和概念 135
7.1 簡介 135
7.1.1 正向工程與更加復雜的系統(tǒng) 135
7.1.2 對與特定解決方案無關的功能和概念所做的介紹 136
7.2 確定與特定解決方案無關的功能 138
7.3 概念 140
7.3.1 作為一種觀念的概念 140
7.3.2 對概念構(gòu)想有所幫助的框架 142
7.3.3 構(gòu)想概念時所應依循的步驟 144
7.3.4 為概念命名
你還可能感興趣
我要評論
|
