係統架構：復雜係統的産品設計與開發 下載 mobi epub pdf 電子書 2024

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



點擊這裡下載

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

---

內容簡介

　　本書首先講解瞭什麼是係統，什麼是係統架構，並從形式和功能兩個方麵講解瞭如何分析係統。之後開始講解如何創建良好的係統架構。在將概念演化為架構的過程中，架構師需要對係統進行分解，以看清這些組件的結構以及它們之間的交互情況，因此需要根據一些衡量指標來構建權衡空間，以便使用優化算法找齣優勢較大的架構。

目錄

係統架構原則
譯者序
推薦序
前言
緻謝
作者介紹
第一部分係統思維
第1章　係統架構簡介 2
1.1　復雜係統的架構 2
1.2　良好架構的優勢 2
1.3　學習目標 5
1.4　本書結構 6
1.5　參考資料 7
第2章　係統思維 8
2.1　簡介 8
2.2　係統與湧現 8
2.2.1　係統 8
2.2.2　湧現 10
2.3　任務一：確定係統及其形式與功能 13
2.3.1　形式與功能 13
2.3.2　工具-過程-操作數：這是人類的標準思維模式嗎 16
2.4　任務二：確定係統中的實體及其形式與功能 16
2.4.1　具備形式與功能的實體 17
2.4.2　確定如何將係統初步分解為恰當的實體 18
2.4.3　用整體思維找齣係統中的潛在實體 19
2.4.4　集中注意力，找齣係統中的重要實體 21
2.4.5　為實體創建抽象或從實體中發現抽象 22
2.4.6　定義係統的邊界，並將其與外圍環境隔開 24
2.5　任務三：確定實體之間的關係 25
2.5.1　關係的形式與功能 25
2.5.2　外部接口 28
2.6　任務四：湧現 28
2.6.1　湧現的重要性 28
2.6.2　係統故障 29
2.6.3　預測湧現物 30
2.6.4　湧現物依賴於實體及其關係 31
2.7　小結 32
2.8　參考資料 33
第3章　思考復雜的係統 34
3.1　簡介 34
3.2　係統中的復雜度 34
3.2.1　復雜度 34
3.2.2　引入Team XT這一範例係統 35
3.3　係統的分解 38
3.3.1　分解 38
3.3.2　體係 39
3.3.3　層級分解 39
3.3.4　簡單的係統、復雜度適中的係統以及復雜的係統 41
3.3.5　原子部件 42
3.4　特殊的邏輯關係 43
3.4.1　類/實例關係 43
3.4.2　特化關係 43
3.4.3　遞歸 44
3.5　對復雜係統進行思索 44
3.5.1　自頂嚮下及自底嚮上式的思考 44
3.5.2　交替思考 45
3.6　架構展示工具：SysML與OPM 45
3.6.1　視圖與投射 45
3.6.2　SysML 46
3.6.3　OPM 46
3.7　小結 49
3.8　參考資料 50
第二部分　係統架構的分析
第4章　形式 53
4.1　簡介 53
4.2　架構中的形式 53
4.2.1　形式 53
4.2.2　用解析錶示法來錶現形式：對象 56
4.2.3　形式的分解 57
4.3　對架構中的形式進行分析 58
4.3.1　定義係統 58
4.3.2　確定形式實體 59
4.3.3　把泵作為復雜度適中的係統來分析 61
4.4　對架構中的形式關係進行分析 63
4.4.1　形式關係 63
4.4.2　空間/拓撲形式關係 65
4.4.3　用圖和圖錶來展現形式關係：OPM 67
4.4.4　用錶格及類似矩陣的視圖來展現形式關係：DSM 70
4.4.5　連接性的形式關係 71
4.4.6　其他的形式關係 74
4.5　形式環境 75
4.5.1　伴生係統、整個産品係統及係統邊界 75
4.5.2　使用情境 77
4.6　軟件係統中的形式 77
4.6.1　軟件係統：信息形式及其二元性 77
4.6.2　軟件中的形式實體與形式關係 79
4.6.3　軟件係統所在的整個産品係統、軟件係統的邊界及使用情境 81
4.7　小結 82
4.8　參考資料 82
第5章　功能 83
5.1　簡介 83
5.2　架構中的功能 84
5.2.1　功能 84
5.2.2　把功能視為過程加操作數 84
5.2.3　用解析錶示法來展現功能 85
5.3　分析對外展現的功能和價值 89
5.3.1　對外界展現的主要功能 89
5.3.2　與價值有關的操作數 90
5.4　對內部功能進行分析 93
5.4.1　內部功能 93
5.4.2　確定內部功能 94
5.5　分析功能交互及功能架構 97
5.5.1　功能交互與功能架構 97
5.5.2　確定功能交互 98
5.5.3　價值通路 100
5.5.4　湧現與細分 101
5.5.5　軟件係統中的功能架構 102
5.6　與價值相關的次要外部功能及內部功能 105
5.7　小結 106
5.8　參考資料 107
第6章　係統架構 108
6.1　簡介 108
6.2　係統架構：形式與功能 109
6.2.1　形式與功能之間的映射 109
6.2.2　確定形式與過程之間的映射 114
6.2.3　形式結構承載並展現功能交互 116
6.2.4　確定形式結構是如何承載功能和性能的 118
6.3　係統架構中的非理想因素、支持層及接口 119
6.3.1　係統架構中的非理想因素 119
6.3.2　係統架構中的支持功能及支持層 120
6.3.3　形式與功能中的係統接口 121
6.4　操作行為 123
6.4.1　操作者 124
6.4.2　行為 124
6.4.3　操作成本 126
6.5　用各種錶示法來推究係統架構 127
6.5.1　能夠對係統架構進行簡化的幾種方式 127
6.5.2　用投射法來錶示係統的架構 128
6.5.3　把過程投射到對象 129
6.5.4　把過程和操作數投射到形式 130
6.6　小結 133
6.7　參考資料 134
第7章　與特定解決方案無關的功能和概念 135
7.1　簡介 135
7.1.1　正嚮工程與更加復雜的係統 135
7.1.2　對與特定解決方案無關的功能和概念所做的介紹 136
7.2　確定與特定解決方案無關的功能 138
7.3　概念 140
7.3.1　作為一種觀念的概念 140
7.3.2　對概念構想有所幫助的框架 142
7.3.3　構想概念時所應依循的步驟 144
7.3.4　為概念命名

前言/序言

　　前言　　我們寫這本書，是為瞭闡述一種強大的思想。越來越多的人已經開始有瞭這種思想，這就是“係統的架構”（architecture of a system）。從電網的架構到移動支付係統的架構，很多領域都齣現瞭係統架構的思維。架構就是係統的DNA，也是形成競爭優勢的基礎所在。擁有係統架構師這一頭銜的專業人士，現在已經超過10萬人，此外還有更多的人以其他身份參與架構工作。 　　對於強大的思想，其邊界一般都比較模糊。我們發現許多同事、客戶和同學都能夠意識到係統架構問題，但他們對這個詞的用法有所區彆。這個詞一般用來區分兩個已有的係統，例如“這兩種山地自行車的架構不同”。 　　係統的架構到底是由什麼組成的？這個話題通常會引發巨大的爭論。在某些領域中，架構用來指代一項能夠在抽象層麵上區分兩類係統的決策，例如“封包交換的架構”（packet-switched architecture）與“電路交換的架構”（circuit-switched architecture）。而在另外一些領域中，這個詞則用來在忽略某些小細節的情況下描述整體的實現，例如“我們的軟件是用來充當服務架構的”。 　　我們的目標是闡述架構思維的強大之處，並且使其邊界變得更加明晰。架構思維的強大，源自它能夠使我們在項目的早期階段權衡各種架構、展望後續的發展情況，並發現各種約束以及對提升項目價值較為重要的機遇。如果架構把全部細節都包括進去，那麼我們就無法在各種粗略的想法之間輕易跳躍，但如果架構中缺少瞭重要的價值驅動力，那它又顯得沒有意義。 　　我們寫本書時所持有的理念與Eberhardt Rechtin相同，都認為架構師應該是專纔，而非通纔。我們想在書中描述係統架構的分析與構建過程，也想展示係統架構的“科學性”。與産品設計規範相比，本書的措辭在某種程度上較為寬鬆一些，因為我們要處理的係統更加復雜。産品研發人員所重視的是設計問題，而我們要強調的則是係統中的各個部件如何纔能凝聚成一個連貫的整體，我們重視的是這個奇妙的湧現過程。 　　我們把過去的經驗融入瞭本書中。我們有幸參與瞭許多復雜係統的早期研發工作，這些係統遍布通信、運輸、移動廣告、財經、機器人、醫療設備等各個領域，其復雜程度也各有不同，從農具到國際空間站，我們都接觸過。 　　此外，書中的案例研究還涉及混閤動力車（hybrid car）及商用飛機（commercial aircraft）等其他領域的係統架構師所總結齣的一些經驗。我們認為，本書必須要能夠應對當前係統架構師所麵臨的各項挑戰，因為隻有這樣，纔能推進係統架構的發展。 　　本書的核心受眾有兩類人，一類是專業的架構師，另一類是工程學的學生。係統架構這一理念，是相關行業的從業者從實踐和嘗試中得來的，這些從業者運用自身的智慧，試著總結齣一些經驗，以應對研發新係統時所麵臨的挑戰。本書的一部分目標讀者是進行架構決策的資深專業人士。這些專業人士包括高級技術人員，也包括軟件、電子、工業用品、航空、汽車及消費用品等科技産業中的管理人員。 　　本書的另一部分目標讀者是工程學的學生。本書是根據過去15年間我們在麻省理工學院講授研究生課程時的教學經驗而寫成的，其中有很多學生後來成瞭私人企業和政府部門中的佼佼者，對此我們深感榮幸。架構思維不僅可以幫助我們理解係統當前的運作方式，而且對於科技組織的管理來說，這也應該是一項必備的能力。 　　緻謝我們要感謝使本書得以麵世的諸位人士。首先，感謝Bill Simmons、Vic Tang、Steve Imrich、Carlos Gorbea和Peter Davison，他們在本書的相關章節中提供瞭自己的專業意見，並對本書的初稿做瞭點評。Norman R. Augustine為本書撰寫瞭推薦序，並幫助我們成形係統架構方麵的想法，為此我們深錶感激。 　　感謝評審者Chris Magee、Warren Seering、Eun Suk Suh、Carlos Morales、Michael Yukish及Ernst Fricke給我們提供瞭明確的意見，並幫我們指齣瞭未能傳達齣關鍵思想的那些段落。還要感謝很多匿名評審者，他們給齣的反饋意見使我們能夠對本書加以改進。感謝OPM（Object Process Methodology，對象過程方法）的研發者Dov Dori，他是我們的優秀閤作夥伴。 　　感謝Pat Hale為我們在MIT的教學活動提供支持並對本書初稿給齣反饋。感謝MIT係統設計與管理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幫我們明智地選擇瞭齣版社。 　　本書的編寫得益於曆屆的研究生，他們所貢獻的內容以各種形式齣現在本書中。除瞭上麵提到的那些人之外，還要感謝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在醫療健康領域中，有一種趨勢特彆有前途，這就是生物醫學研究與工程實踐的結閤。我有一位朋友是工程師，他最近告訴我，美國一傢知名大學曾經開瞭這樣一個會，工程係與心髒病學科係的教研人員，在會上探討瞭這兩種學科的結閤方式。會議的重點是構建一顆可供人類使用的機械心髒，心髒病學科係的主管剛開始描述人類心髒的各項特徵，就有工程師打斷他，並問道：“機械心髒必須放在胸腔中嗎？有沒有可能放在其他更容易夠到的地方？例如大腿中？”開會的人以前從來沒考慮過這種可能。主管接著描述心髒的特徵，但是過瞭一會兒，又有另一個工程師打斷他，並提問：“能不能不要隻放一個心髒，而是把三顆或四顆心髒組閤成分布式係統？”這個問題，也是大傢從未考慮過的。 　　本書由係統架構領域內三位備受崇敬的領軍人物撰寫，他們的觀點很有見地。書中討論的就是如何提齣並迴答上麵那樣的問題。我在工作中曾經碰到工程、商務、政府等方麵的各種係統架構問題，當運用係統架構領域中的一些經驗來解決這些問題時，我發現結果會好很多。 　　然而，單單運用這些經驗是不夠的。剛開始工作時，我記得自己總是問同事各種問題。當時我們正在“閤作”完成一個導彈項目，我問他們為什麼要采用某種特定的方式來設計産品的某個部件。有人給齣的原因是“這種設計方式重量最輕”，有人說他設計的那一部分雷達橫截麵（radar cross-section）最小，還有人說自己設計的那個部件成本低、體積小，等等。 　　這些理由都不錯，可是其中缺瞭一樣東西。那就是係統架構師（system architect）。 　　係統架構師的缺位很常見，但錶現方式一般比較微妙。幾年前，我曾經參與瞭近音速運輸機（Near-Sonic Transport aircraft）的早期研發工作。一份市場調查錶明，乘客想要更快地到達目的地。近音速運輸的理念，就是想使速度盡量接近音速（也就是接近1馬赫，1馬赫≈1225km/h），但又不超過它，以避免超過音速之後所引發的各種問題。然而空氣動力學者（我早前的研究領域就是空氣動力學）發現：這樣做使得飛機在阻力麯綫上會進入一個耗油量陡增的區域。 　　從係統架構的觀點來看，我們要解決的問題並不是怎樣飛得更快，而是如何縮短乘客從傢中到機場、辦理登機手續、過安檢、上飛機、飛行、落地後取行李並駛往最終目標所需的總時間。把這個問題放在剛纔那個情境中考慮，我們就會發現，更基本的問題其實應該是：節省這5分鍾或10分鍾的飛行時間，究竟能給乘客帶來多大的好處？答案是：帶不來多大好處。因此，這項近音速運輸機計劃就提前終止瞭。如果我們想使乘客更快地到達目的地，那麼顯然還有其他更好的方案可供探索。這個項目之所以失敗，是因為大傢沒有意識到自己正在處理的是係統架構問題，而不單單是空氣動力學或飛機設計方麵的問題。 　　這些年來，我一直在不斷地完善自己對“係統”這個詞所下的定義。係統是“可以交互的兩個或多個元素”，而本書作者又明智地補充瞭一點，那就是係統的功效必須大於各自元素的功效之和。盡管在概念層麵很簡單，但是現實世界中的係統相當復雜。實際上，對於由若乾元素所構成的（而且這些元素之間都以最簡單的方式來交互）係統來說，描述其可能具備的狀態數量所用的那個公式非常嚇人，有“怪獸公式”之稱。此外，很多係統裏麵還有人的因素在內，如果係統裏麵還包括人，那麼係統架構所麵臨的睏難就會更大，因為人的因素會帶來不確定性。我們在現實中遇到的就是這種係統，本書作者要分析和解決的架構問題，也針對的是這種係統。 　　我曾經分析過這樣一個給美國南極站進行補給的係統。與其他係統一樣，我需要非常謹慎地設定具體的評估目標。是要縮減在可以預期的狀況下所産生的消耗，還是要減少在無法預期的最差狀況（例如糟糕的天氣）下所産生的消耗？又或者是要盡量避免在補給品根本無法送達時所發生的那些“令人遺憾的”狀況？可以考慮的目標還有很多。 　　在這個係統中，有很多個必須互相配閤的元素，例如運輸船、破冰船、各種飛機、用於卸貨的冰碼頭、存儲設施、交通工具、通信等。而且在做各種決策時，還要考慮架構中一直可能會發生的一種危險，那就是單點故障。 　　我還在商務領域中遇到瞭一個比剛纔更復雜的問題，那就是能不能把7傢公司的所有部門或主要部門，閤並為洛剋希德·馬丁公司，如果能，應該如何去做。這個係統中的每個“元素”都有其優缺點，每個都涉及很多人，都有自己的目標、能力和局限性。這項決策的關鍵在於，閤並之後的新公司，其效能是否遠遠高於原有那些部分各自的效能總和。如果做不到這一點，那就沒有理由耗費資金去進行閤並與收購瞭。 　　對於這一類復雜問題來說，並沒有簡單的數學公式能夠給齣“正確”答案。然而，係統思維（systems thinking）的訓練是一項極為有用的工具，可以幫助我們去評估係統的觀感、係統中潛藏的機遇以及係統對參數的敏感程度等。在剛纔那個企業閤並的案例中，大多數人都認為閤並是“對的”，順便說一下，在相似的案例中，有80%的情況也是如此。 　　我與本書的一位作者及其他同事，曾經嚮美國總統提齣一項載人航天計劃，這項計劃是為將來的幾十年而製定的。在這個案例中，最睏難的地方是怎樣閤理地定義任務（mission），雖說確定適當的硬件配置也是個不小的工作，但與前者比起來，難度還是要低一些。所幸這種問題都可以通過係統思維來解決。 　　正如作者在書中所說的那樣，係統架構的建立過程，既是科學，又是藝術。盡管這聽起來很美好，但現實相當殘酷。與達爾文式的物種進化現象一樣，用過去的錯誤架構所搭建齣來的係統是無法生存的；反之，用良好的架構所搭建的係統不僅可以生存，而且會越來越好。 　　所謂復雜係統的架構，也就是這麼一迴事。
係統架構：復雜係統的産品設計與開發 下載 mobi epub pdf txt 電子書 格式

評分☆☆☆☆☆

很不錯的書籍 非常的便宜

評分☆☆☆☆☆

還可以，就是看不懂

評分☆☆☆☆☆

此用戶未及時填寫評價內容，係統默認好評！

評分☆☆☆☆☆

這個商品不錯這個商品不錯這個商品不錯這個商品不錯這個商品不錯這個商品不錯這個商品不錯這個商品不錯這個商品不錯

評分☆☆☆☆☆

神作哦，寫的太好瞭。

評分☆☆☆☆☆

做活動時候買的，很優惠啊，相信京東

評分☆☆☆☆☆

書不錯，很值得購買。

評分☆☆☆☆☆

6666666

評分☆☆☆☆☆

打怪升級到一定級彆靠的不是速度，而是需要強大理論知識支撐

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