世界著名計算機教材精選：軟件架構與模式 pdf epub mobi txt 电子书 下载 2025

☆☆☆☆☆

Joachim Goll 著，賈山 等 譯

出版社： 清华大学出版社

ISBN：9787302450993

版次：1

商品编码：12040515

包装：平装

开本：16开

出版时间：2017-01-01

用纸：胶版纸

页数：312

字数：505000

正文语种：中文

編輯推薦

　　1. 介紹麵嚮對象設計方法中的架構和設計模式。 　　2. 有助於提高軟件的編寫質量，加深對軟件理論知識的理解，擴展專業視野，瞭解大型軟件開發中的架構模式。 　　3. 介紹的設計模式和架構模式都配有Java語言的程序實例，模式中類和類之間的靜態關係或對象間的動態關係都用UML語言描述。各章末均提供瞭相應的練習。 　　4. 本書在網絡上提供各章練習答案和書中實例的Java代碼。 　　5. 可以作為高校計算機相關專業的教材，也可供係統開發人員和大型係統的係統架構設計人員閱讀參考。

內容簡介

　　《世界著名計算機教材精選：軟件架構與模式》可供計算機專業學生、工科學者、係統開發人員和大型係統的係統架構設計人員閱讀。本書的目標是讓讀者掌握係統架構和模式的基本原理與實際應用。

內頁插圖

目錄

第1章 麵嚮對象設計的原理 1
1.1 程序的可讀性、正確性和
可擴展性 2
1.1.1 可讀性 2
1.1.2 正確性 2
1.1.3 可擴展性 3
1.2 封裝、抽象和信息隱藏 3
1.3 關注點分離和單一職責
原則 4
1.4 接口隔離原則 6
1.5 鬆耦閤 6
1.6 裏氏代換原則 7
1.7 契約式設計 9
1.7.1 斷言 9
1.7.2 覆寫要遵守契約 11
1.8 開閉原則 13
1.9 依賴倒置原則和控製反轉 18
1.9.1 依賴倒置原則 18
1.9.2 控製反轉 19
1.10 對象生成過程中減少
?依賴性 21
?1.10.1 依賴查找 22
?1.10.2 依賴注入 26
1.11 總結 28
1.12 練習 29
第2章 軟件架構 30
2.1 軟件架構概念 31
2.2 軟件架構的質量 32
2.3 參考架構、架構模式和設計
模式 33
2.4 軟件架構概念的任務和前景 34
2.4.1 係統中的分析任務 34
2.4.2 係統中的結構設計
任務 35
2.4.3 觀察軟件架構的
角度 37
2.4.4 軟件架構的原型 37
2.5 軟件架構師對一個項目的
意義 37
2.5.1 軟件架構師的技術
能力 38
2.5.2 軟件架構師的溝通
能力 38
2.5.3 構造軟件架構過程中
的決定 39
2.6 總結 40
2.7 練習 41
第3章 軟件設計的模式 42
3.1 模式的使用 43
3.2 模式的屬性和它的設計 44
3.3 架構模式、設計模式和慣用
法的界限 44
3.4 描述設計模式和架構模式的
模闆 46
3.5 總結 47
3.6 練習 47
第4章 麵嚮對象設計模式 48
4.1 設計模式的分類 48
4.2 設計模式的概述 49
4.2.1 結構模式 49
4.2.2 行為模式 50
4.2.3 創建型模式 51
4.2.4 設計模式指南 51
4.3 結構模式中的適配器模式 51
4.3.1 名稱/其他可用的
名稱 51
4.3.2 問題 51
4.3.3 解決方法 52
4.3.4 評價 57
4.3.5 使用範圍 58
4.3.6 類似的模式 58
4.4 結構模式中的橋梁模式 58
4.4.1 名稱/其他可用的
名稱 58
4.4.2 問題 58
4.4.3 解決方法 59
4.4.4 評價 66
4.4.5 使用範圍 67
4.4.6 類似的模式 67
4.5 結構模式中的裝飾模式 67
4.5.1 名稱/其他可用的
名稱 67
4.5.2 問題 67
4.5.3 解決方法 68
4.5.4 評價 76
4.5.5 使用範圍 77
4.5.6 類似的模式 80
4.6 結構模式中的外觀模式 81
4.6.1 名稱/其他可用的
名稱 81
4.6.2 問題 81
4.6.3 解決方法 81
4.6.4 評價 86
4.6.5 使用範圍 86
4.6.6 類似的模式 86
4.7 結構模式中的組閤模式 87
4.7.1 名稱/其他可用的
名稱 87
4.7.2 問題 87
4.7.3 解決方法 87
4.7.4 評價 95
4.7.5 使用範圍 95
4.7.6 類似的模型 97
4.8 結構模式中的代理模式 97
4.8.1 名稱/其他可用的
名稱 97
4.8.2 問題 98
4.8.3 解決方法 98
4.8.4 評價 102
4.8.5 使用範圍 102
4.8.6 類似的模式 103
4.9 行為模式中的模闆方法
模式 104
4.9.1 名稱/其他可用的
名稱 104
4.9.2 問題 104
4.9.3 解決方法 104
4.9.4 使用範圍 108
4.9.5 評價 109
4.9.6 類似的模式 109
4.10 行為模式中的命令模式 109
4.10.1 名稱/其他可用的
?名稱 109
4.10.2 問題 109
4.10.3 解決方法 110
4.10.4 評價 115
4.10.5 使用範圍 116
4.10.6 類似的模式 116
4.11 行為模式中的觀察者模式 117
4.11.1 名稱/其他可用的
?名稱 117
4.11.2 問題 117
4.11.3 解決方法 117
4.11.4 評價 124
4.11.5 使用範圍 124
4.11.6 類似的模式 125
4.12 行為模式中的策略模式 125
4.12.1 名稱/其他可用的
??名稱 125
4.12.2 問題 125
4.12.3 解決方法 125
4.12.4 使用範圍 129
4.12.5 評價 129
4.12.6 類似的模式 130
4.13 行為模式中的中間者
?模式 130
4.13.1 名稱/其他可用的
??名稱 130
4.13.2 問題 131
4.13.3 解決方法 131
4.13.4 評價 138
4.13.5 使用範圍 138
4.13.6 類似的模式 138
4.14 行為模式中的狀態模式 139
4.14.1 名稱/其他可用的
??名稱 139
4.14.2 問題 139
4.14.3 解決方法 139
4.14.4 使用範圍 146
4.14.5 評價 146
4.14.6 類似的模式 146
4.15 行為模式中的角色模式 147
4.15.1 名稱/其他可用的
??名稱 147
4.15.2 問題 147
4.15.3 解決方法 148
4.15.4 評價 155
4.15.5 使用範圍 155
4.15.6 類似的模式 156
4.16 行為模式中的拜訪者模式 156
4.16.1 名稱/其他可用的
??名稱 156
4.16.2 問題 156
4.16.3 解決方法 156
4.16.4 評價 169
4.16.5 使用範圍 170
4.16.6 類似的模式 171
4.17 行為模式中的迭代器模式 171
4.17.1 名稱/其他可用的
??名稱 171
4.17.2 問題 171
4.17.3 解決方法 171
4.17.4 評價 178
4.17.5 使用範圍 178
4.17.6 類似的模式 180
4.18 創建型模式中的工廠
??方法 180
4.18.1 名稱/其他可用的
??名稱 180
4.18.2 問題 180
4.18.3 解決方法 181
4.18.4 評價 185
4.18.5 使用範圍 185
4.18.6 類似的模式 186
4.19 創建型模式中的抽象工廠
??模式 186
4.19.1 名稱/其他可用的
??名稱 186
4.19.2 問題 186
4.19.3 解決方法 186
4.19.4 評價 195
4.19.5 使用範圍 195
4.19.6 類似的模式 196
4.20 創建型模式中的單例模式 196
4.20.1 名稱/其他可用的
??名稱 196
4.20.2 問題 196
4.20.3 解決方法 196
4.20.4 評價 204
4.20.5 使用範圍 204
4.20.6 類似的模式 204
4.21 創建型模式中的對象池
??模式 204
4.21.1 名稱/其他可用的
??名稱 204
4.21.2 問題 205
4.21.3 解決方法 205
4.21.4 評價 210
4.21.5 使用範圍 211
4.21.6 類似的模式 211
4.22 總結 211
4.23 練習 213
第5章 架構模式 216
5.1 分層架構模式 217
5.1.1 名稱/其他可用的
名稱 217
5.1.2 問題 217
5.1.3 解決方法 217
5.1.4 評價 219
5.1.5 使用範圍 220
5.1.6 類似的模式 226
5.2 管道和過濾器架構模式 226
5.2.1 名稱/其他可用的
名稱 226
5.2.2 問題 226
5.2.3 解決方法 227
5.2.4 評價 232
5.2.5 使用範圍 232
5.2.6 類似的模式 234
5.3 插件架構模式 235
5.4 中介模式 245
5.5 麵嚮服務的架構模式 267
5.6 模型-視圖-控製器架構模式 291
5.7 總結 307
5.8 練習 308
參考文獻 310
　　
　　

精彩書摘

　　第3章 軟件設計的模式

　　軟件開發過程中的每一步都有對應的模式：用於係統分析的模式、係統設計模式、編程模式和測試模式。對於特殊的任務也有模式，比如對設計圖形界麵或者與數據庫的數據交換。

　　本書專注於軟件設計中的模式。這裏要注意它們的區彆：

　　* 架構模式（architectural patterns）。

　　* 設計模式（design patterns）。

　　確定架構模式和設計模式的界限參見3.3節。

　　用於設計的模式是已經經過證實的可用於解決一些特定問題的參考答案。在設計係統時要考慮使用模式，因為它們都是已經在多個係統中被證明過的。

　　設計階段的模式起源於架構師Christopher Alexander1。他在20世紀70年代整理總結瞭一套城市建設的模式。Christopher Alexander認識到，建築或者整條街道雖然可能包括相同的元素，但是完全可以按照不同的模式建造。換句話說，他通過元素和它們之間典型的關係可以辨彆模式。

　　“……除瞭元素之外，每個建築都是由元素之間的關係組成的一定模式定義的……” [Ale77]

　　在城市建築學中，模式是一個具有開創性意義的理念。但是它在建築學中的流行和認可的程度遠遠不如在軟件開發領域。

　　模式對係統設計起到瞭重要的貢獻，它促使軟件開發在走嚮成熟的工程技術的道路上邁齣瞭重要的一步。模式基本上是不依靠任何平颱，不被限製於一種固定的編程語言。被命名的模式擴展瞭專業技術語言，受過訓練的開發人員可以在一個更高的抽象層次中理解一個問題和答案。

　　模式經常要和抽象結閤，它是一個抽象類或者接口的符號。真實的類是派生類，模式並不知道派生類，它們是由使用模式的用戶定義的。它們或者在編譯時齣現在以具體類為基礎的模式中，或者是在運行時在麵嚮對象模式中替代模式中的抽象 部分。

　　為瞭使模式可以供其他開發者使用，必須做好文檔工作。模式不是發明齣來的，而是在實際應用中因為可以解決典型的問題而被發現齣來的方法，它們可以在很多實際應用中使用。

　　3.1節研究在軟件設計中模式的使用。3.2節描述在軟件設計中模式的屬性和它的設計。3.3節確定架構模式、設計模式和慣用法相互的界限。在3.4節中介紹模闆，本書中利用這個模闆介紹如何給模式做文檔。

　　3.1 模式的使用

　　軟件設計中模式的主要目標是通過再次使用已經獲得的經驗提高架構的靈 活性。

　　大部分係統設計中包含很多模式，僅僅通過這個特徵還不能判斷這是一個好的設計。

　　這裏Christopher Alexander使用瞭適當的語言：“建築可能是通過鬆散排列的模式建造的。這樣的建築隻能體現齣模式的聚集，並不具有內部的一緻性，它沒有真正的核心。還有一種模式結閤的方式就是在同一空間的多模式疊加。這樣的建築具有內部的一緻性，它把很多的含義包含在一個小的空間裏。通過這種內部的凝聚力使它具有核心力。”一個好的設計的形成，需要多個模式相互間完美地組閤，形成疊加效應。

　　隻有在真正有意義的時候纔可以使用模式。在使用模式之前，一定要仔細考慮要使用的模式是否適閤解決這個問題，使用之後會産生什麼樣的結果。

　　從開發者的角度認為模式具有一定的安全性。這種安全性是建立在事實的基礎上的，是前人經過應用已經得到證實的結果。然而這容易形成誤導，認為在任何情況下使用模式都是正確的選擇。單純使用模式並不能保證對於設計中齣現的具體問題是有意義的。

　　在以對象為基礎的模式中委托原則經常起到重要的作用。委托一個用於接收信息的對象，消息可以繼續傳遞給

　　* 接收信息的對象所聚集的部分對象；

　　* 或者是在運行時實現一個抽象（接口或抽象類）的對象（這個抽象是由接收信息的對象實現的）。

　　使用任何形式的委托或者抽象，其代價都是降低係統的性能。額外增加的層次總是和降低係統的性能相聯係的。

　　如果要求係統具有擴展性，那麼模式的使用具有優勢。但是如果首先是對係統性能的要求，係統的可修改性沒有重要作用時，使用模式就要仔細考慮。

　　盡管使用模式可以提高架構的可擴展性，但是同時也增加瞭架構的復雜度。

　　為瞭保證可擴展性，可能會生成新的類和操作，或者是新的類和類之間的關係。這種復雜度會降低係統的性能，在這種情況下，復雜度所帶來的優點並不能抵消性能降低的不足。

　　如果係統需要靈活性是推測的，即目前還不清楚係統將來是否需要，那麼就應該“隻保持必要的靈活性，越少越好”。

　　本書關於模式的介紹，其核心是解釋如何解決問題。然而，這個問題的實質是什麼時候適閤使用模式。這個問題往往被忽視瞭。也許沒有已知的模式可以達到預期的目標。

　　尋找解決具體設計問題的方法是艱難的，人們必須仔細研究待解決的問題，比較有關模式的性能。

　　3.2 模式的屬性和它的設計

　　模式的目標就是提高架構的屬性。例如屬性包括下麵兩點：

　　* 可理解性；

　　* 可擴展性。

　　可理解性可以通過簡易性達到，即通過為每個模式提供簡易的結構化的全麵文檔。可擴展性可以通過以下兩點實現：

　　* 靜態繼承。

　　* 使用聚閤接口2或者是抽象類。

　　麵嚮對象模式滿足以下設計原則：

　　* 鬆耦閤性係統（詳見1.5節），組件的鬆耦閤性。

　　* 抽象（詳見1.2節），通過泛化、接口或者抽象類。

　　* 信息隱藏（詳見1.2節），通過隱藏程序實現的部分。

　　* 明確的職責（詳見1.3節），通過角色安排。

　　* 依賴倒置原則，高層的類不依賴於低層的類。

　　這裏需要強調的是有時候需要為非麵嚮對象係統製定模式。這樣的模式不需要繼承和多態[Bus98，24頁]。模式不一定都是麵嚮對象的。本書中所介紹的設計模式都是以麵嚮對象為基礎的。

　　人們想到麵嚮對象時，總會認為是通過泛化達到盡可能高的抽象，換句話說，就是找到它的基類，通過細分得到不同的變化。

　　因此一些模式就設計成以抽象類為基類，還有一些模式使用接口。人們更偏愛於使用接口，有兩個原因：

　　（1）在一些編程語言中，例如Java，接口允許多重繼承，抽象基類則不允許。

　　（2）抽象基類可以包含抽象操作，也可以包含已經完成的操作。接口則隻能包含抽象操作，這樣更讓人一目瞭然。

　　接口優於抽象類，但這並不總是成立的。如果人們在每個實現類中都必須實現一個聚集或者默認實現，這種情況就應該使用抽象類。

　　3.3 架構模式、設計模式和慣用法的界限。

　　……

前言/序言

　　譯 者 序

　　隨著中德兩國交往的不斷加深，各行各業都在不斷地拓展多方位的閤作。但是中德兩國在軟件行業的閤作卻並不多見，來自德國的計算機類翻譯著作也非常少。

　　德國企業齣於嚴謹的風格和安全性的考慮，基本很少有軟件外包，對於應用軟件的開發和使用一般也都局限在德國本土範圍內（除瞭一些大型公司，如SAP），所以我們對德國計算機行業的發展瞭解得並不多。

　　本書的作者Goll教授不僅有多年的計算機軟件工作經驗，同時還在德國Esslingen應用技術大學創建瞭軟件專業，1994年他還建立瞭Steinbeis-Transferzentrum Systemtechnik軟件公司。因為該公司所在地是奔馳公司和博世公司的總部，所以主要從事汽車和自動化方嚮的軟件開發。我在上學期間曾得到Goll教授的耐心指導。Goll教授無論是在專業技術還是在教學業務上都是令人敬重和贊佩的。

　　希望這本書的引進能夠使廣大讀者對德國的軟件技術有初步的認識。本書共分為5章。前3章主要是介紹一些軟件技術的理論。第4章介紹瞭常用的軟件模式，具有一定的軟件基礎知識的讀者通過學習本章的內容可以提高編寫軟件的質量，同時加深對軟件理論知識的理解。第5章介紹瞭軟件架構模式，讀者在熟練掌握軟件模式後，通過本章可以擴展視野，逐步瞭解大型軟件開發所使用的架構模式。對於軟件開發人員來說，通過學習本章的內容可以加快在專業方麵的成長。

　　賈山翻譯瞭本書的第1章、第3章和第4章，天津理工大學的李欣老師翻譯瞭第2章和第5章。在本書翻譯過程中，譯者得到瞭清華大學齣版社的大力支持和幫助，在此緻以衷心的感謝。讀者如果在閱讀中有任何疑問，可以直接發送電子郵件到zd_jiashan@126.com。

　　賈山

　　2016年10月

　　前 言

　　本書的內容

　　軟件係統的架構應該是易於擴展和標準化的，這樣便於開發者對係統架構進行修改。在麵嚮對象設計方法中，已經有很多有意義的架構和設計模式。這些模式都是建立在麵嚮對象理論基礎上的，例如依賴倒置原則。所以，本書首先介紹的是一些基本的原則，接下來講解如何把這些麵嚮對象的原則運用到係統架構和設計模式中。所有這些講解都配有Java語言的程序實例。

　　在講解設計原則之後，本書將重點探討係統架構和設計模式，通過附帶的實例，讀者可以從中選擇適閤自己係統的模式。書中的一些實例隻截取瞭部分代碼，完整的實例可以從相應的網站上查看。

　　本書可供計算機專業學生、工科學者、係統開發人員和大型係統的係統架構設計人員閱讀。本書的目標是讓讀者掌握係統架構和模式的基本原理與實際應用。

　　書中的實例都是以Java語言為基礎的。在講解模式中類和類之間的靜態關係或者是對象之間的動態關係時，均是藉助於UML語言進行描述的。所以讀者應該具備Java語言和UML語言的基礎知識。

　　書中的圖標錶示對相應的內容做簡短的總結。圖標提醒讀者，這是在實際開發過程中經常容易導緻錯誤的地方。

　　每章附帶簡單的練習，書中沒有提供答案，讀者可以在相應的網站上查看。

　　本書的緣起

　　本書作者在此前的另一本書《軟件技術的方法和架構》[Gol11]1中的第2章曾經簡短地介紹瞭設計和架構模式。在本書中，主要介紹這部分內容，不僅對這部分內容做認真的整理，而且還增加瞭麵嚮對象設計的基本原理，因為這是設計模式的基礎和加深理解模式所必需的。在吸收瞭模式後麵隱藏的設計原理並重新修訂以後，就形成瞭此書。

　　各章概要

　　下麵簡單地介紹各章的主要內容。

　　第1章討論麵嚮對象設計的基本原則，包括對於一個類的設計和多個類間閤作的設計原則。一個類的設計原則有封裝、抽象、信息隱藏、關注點分離、單一職責原則和接口隔離原則。多個類的閤作涉及鬆耦閤原則、裏氏代換原則、契約式設計原則、開閉原則和依賴倒置原則。隨後分析瞭控製反轉和在對象創建過程中減少相互依賴性，這兩個是還沒有形成“原則”的技術。

　　第2章關注軟件架構概念的定義和軟件架構關於非功能性的質量。軟件設計中的參考架構和模式的相互比較。在分析和討論構建一個係統的主要任務、軟件架構的不同層次和結構模型以後，再研究軟件架構師對一個項目的意義。

　　第3章研究架構模式、設計模式和慣用法的每一個特性，最後介紹描述設計模式和架構模式的模闆。

　　第4章研究麵嚮對象設計模式。麵嚮對象設計模式多用於在軟件開發中解決子係統中的特定問題。設計模式由類組成，通過類之間的互相協作解決特定的問題。每一個模式適用於一類問題的解決。本章將介紹結構模式、行為模式和創建型模式。在結構模式中講解適配器模式、橋梁模式、裝飾模式、外觀模式、組閤模式和代理模式。在行為模式中研究模闆方法模式、命令模式、觀察者模式、策略模式、中間者模式、狀態模式、角色模式、拜訪者模式和迭代器模式。創建型模式包括工廠方法模式、抽象工廠模式、單例模式和對象池模式。

　　第5章介紹架構模式。架構模式可以把係統劃分為係統組件。一個架構模式可以含有多個設計模式，也可以不含有設計模式，例如分層架構模式就不包含設計模式。本章介紹分層架構模式、管道和過濾器架構模式、插件架構模式、中介模式、麵嚮服務的設計模式和模型-視圖-控製器（MVC）模式。

　　書寫格式

　　本書中重要的概念加粗顯示。

　　相應網址的重要提示

　　本書相應的網址為http://pan.baidu.com/s/1o6MEsqu，包含各章練習答案和書中的實例。

　　感謝

　　作者在編寫本書的過程中，從實例到文字得到瞭很多人的幫助。他們是Benjamin Adolphi先生、Sebastian Bickel先生、Manuel Gotin先生、Konstantin Holl先生、Dominic Kadynski先生、MichaKoller先生、Paul Krohmer先生和Philipp Stehle先生。Steffen Wahl先生、Christian Tolk先生、Fabian Wirsum先生和Jennifer Rauscher女士對文字處理和資源配置做瞭長期大量的細緻工作。作者在此錶示衷心的感謝。

　　J. Goll/M. Dausmann

　　1 本書正文中提及的參考文獻均以5字符或6字符代號錶示，詳見書末的“參考文獻”。——譯注

　　書中涉及的概念

　　派生類

　　一個派生類是從一個基類派生齣來的。派生類繼承瞭基類的結構（屬性的名稱和類型）和方法。

　　依賴性

　　依賴性是指兩個模型元素間的特殊關係。它錶明，一個獨立元素的變化會影響到相關的元素。

　　抽象窗口工具包（AWT）

　　AWT類庫是Swing類庫的前身。AWT-GUI組件與操作係統密切相關。Swing-GUI組件則藉助於Java 2D的類庫，通過Java的模擬機顯示在屏幕上，所以看起來操作係統沒有依賴性。

　　抽象類

　　抽象類不能構造實例。從技術上講，一個抽象類包含一個或多個方法的定義，但是在抽象類裏並沒有實現這些方法。沒有實現的方法隻能在其派生類中實現。

　　抽象類也可以是不包含抽象方法的。這種抽象類隻是為錶達自身，不能被實例化。例如，一個“電器”或“飲料”不能被實例化。

　　抽象

　　抽象就是去掉每一個不重要的細節，而隻專注於重點內容。

　　聚集

　　聚集是一種特殊的組閤，它錶達的是部分與整體的關係，說明部分與整體的生存期沒有關聯。這一點與組閤（composition）正好相反。

　　參與者

　　參與者是指一個陌生的係統或者一個設備在係統環境中的角色。參與者與係統之間是相互作用的。

　　用例圖（use case）

　　用例圖是描述係統可以提供的服務，包括實現這些功能的步驟。用例圖的功能通常由協作圖（對象之間的交互）實現。

　　架構

　　架構可以理解為：

　　* 把係統分解為模塊。

　　* 描述如何通過模塊間的閤作實現目標功能。

　　* 描述結構的策略，即分解（靜態的）和功能（動態的）。

　　軟件架構設計的目標就是讓係統對外能實現所期望的功能。

　　關聯

　　關聯描述瞭連接的規則，用於連接兩個或多個對象（對象是同級彆的）。關聯從原則上說是一個類間的對稱結構關係。人們可以把關聯限製成單嚮的。

　　屬性

　　屬性的概念存在於類、對象、關聯和數據庫中。麵嚮對象中的屬性概念來自麵嚮數據範例。這意味著：

　　* 屬性屬於類或對象。

　　* 一個關聯類描述瞭一個關聯的特性。

　　* 數據庫中關係（錶）的一列也稱為屬性。屬性與列的取值並不相關，而隻是列的標題。屬性值是列裏麵具體的一個取值。

　　基類

　　基類處在繼承的層次結構中，在被關注類的上方。

　　關係

　　兩個或多個元素之間的關係是指這些元素之間存在的聯係。關係有動態的和靜態的。

　　分類器

　　分類器是來自UML元模型的一個概念。一般認為，如果UML的模型元素能夠生成一個實例，它就是分類器。一個分類器正常情況下有一個結構和一個功能，例如抽象類是一個分類器。接口可以特殊地當作是分類器，因為接口沒有屬性，也就是說沒有結構。

　　委托

　　委托是一種結構，一個對象收到一條信息後，並不是自己實現全部方法，而是把消息繼續傳遞下去。

　　依賴倒置

　　一個對象依賴於另一個對象，使用依賴倒置後，依賴的方嚮會倒轉，即依賴和被依賴的實體關係被倒轉。

　　依賴倒置原則

　　依賴倒置原則是為瞭避免或者減少不同等級中模塊間的依賴關係。這就要求一個高一級的類不能依賴於一個低一級的類。高一級的類應該聚集瞭一個接口或者是一個抽象類。這個抽象類或接口應該由高一級的類決定，低一級的類應該依賴於這個抽象類或接口。

　　圖錶

　　圖錶是觀察係統的特定視角。

　　在UML中的圖錶大部分包含許多用綫連接起來的節點。此外，還有時間圖，用於模擬電子的脈衝圖錶。

　　實體

　　實體在所要處理的問題框架內，具有一定的意義。它可以錶示物品、生物或者草案。

　　實體對象

　　實體對象就是現實世界中物品、生物或者草案的抽象化錶示。

　　設計模式（design pattern）

　　在針對一個問題的最佳解決方案中，類或對象通過相互閤作所實現的功能，可以成為這類問題的解決方案。

　　事件

　　事件是控製流或者控製流的組閤。係統應對事件做齣反應。

　　框架

　　框架可以為正在開發的係統提供類，其派生類可以繼承它的功能。框架可以決定應用的結構，即粗略的結構。框架定義類和對象的劃分、各自的中心職責、類和對象的閤作以及它們的控製流[Gam95]。

　　保密原則

　　保密原則確保類的對象中的內部和私有結構對外是不可以使用的，隻有在類的內部纔可以識彆內部結構和方法的具體實現部分。接口和它的實現部分是分離的。對象中的數據隻能通過接口中定義的方法來使用。

　　泛化

　　泛化與細分的方嚮相反。在泛化時，要在繼承的層次結構的上端整理綜閤的屬性，然後嚮下細分，泛化的屬性也會被繼承。在繼承的層次結構中，嚮上是泛化，嚮下是細分。

　　業務流程

　　業務流程是專業技術方麵的工作進程。它體現瞭為達到一個業務目標所采用的各個相關措施的結閤。

　　分組

　　分組是多個元素的組閤。在UML中存在包的模型元素。包並不是係統的組成部分，而是概念上的示意圖，把元素清楚地按組進行組閤。

　　標識

　　即使不同的對象擁有相同的屬性值時也可以區分開它們，因為每個對象都有自己的 標識。

　　慣用法

　　慣用法是在特定的程序語言中的模型，是在深層次的抽象水平上作為設計模式或架構模式，即可以用一種編程語言來實現設計模式，用來解決不適用於設計模式的特定技術 問題。

　　實例

　　實例是UML模型元素的具體錶現形式。

　　實例化

　　生成類型的實例。

　　交互

　　交互是通過兩個對象間傳送消息或者是多個對象相互作用而體現齣的動態關係。

　　進程間通信

　　進程間通信（IPC）是把進程間的通信看做聯動機製。進程間通信的概念包括操作係統進程對操作係統進程的通信、綫程對綫程的通信。在一颱計算機上要進行進程間通信，需要藉助於這颱計算機的操作係統進行信息交換。如果並行的進程分布在不同的計算機，則計算機之間必須可以使用計算機對計算機的通信。

　　控製反轉

　　在控製流反轉時，原先掌握控製流的程序要把控製權轉交給其他的模塊（大部分情況是可復用的模塊），這樣可以從輪詢轉換到事件驅動。一個可復用的模塊（例如框架）常常調用專有模塊（例如應用程序）。

　　通道

　　通道錶示點到點的連接，用直綫來錶示。通道遵守先進先齣原則，即先進入通道的先離開。

　　封裝

　　封裝是麵嚮對象程序設計中的重要概念之一。一般認為把數據和所屬的功能放在一個盒子裏（類）是十分有意義的，這樣數據和所屬功能沒有被分開。

　　基數

　　基數的概念在數據庫和UML中都存在：

　　* 在數據庫領域，基數在係統分析階段確定實體與實體之間數量的對應關係，或者在係統設計階段確定錶與錶的數據記錄數量的對應關係。基數可以依照關係類型標明 1對1、1對n或者n對m。

　　* 在UML中基數錶明所關注的UML元素的個數。藉助於基數可以錶示齣多倍的關係（例如，1..m）。

　　類

　　類在麵嚮對象中體現的是一種數據類型，它可以生成對象。類含有結構和功能。結構包括屬性。類裏麵的方法決定瞭其對象的功能。類的每一個對象都有自己的標識。

　　類圖

　　類圖展示的是類與類之間的靜態關係（關聯、泛化、實現或依賴）。

　　協作

　　協作由一係列對象組成，它們通過閤作實現在應用場景下的功能。對象的協作可以實現一個功能。

　　通信圖

　　通信圖是在二維空間裏展示所關注的對象、對象間的連接和沿連接實現的信息在對象間的交換。通過把對象分組和對象間的閤作，盡管對象的連接是從動態角度齣發的，也可以清晰地看齣對象的結構組織。

　　模塊

　　模塊的概念體現在係統劃分和模塊技術中：

　　* 模塊1是係統的組成部分，也就是劃分的産物。

　　* 模塊在模塊技術中錶示它是係統模塊化的一部分。模塊功能的具體實現隱藏在模塊對外的接口內。與類相對比，調用模塊的所有方法都必須通過接口。模塊可以穩定地安裝在計算機上。模塊在實際使用中往往包含一個或多個類、接口或小的模塊。

　　模塊模型

　　模塊模型在軟件技術中描述的是由模塊組成的係統運行時的框架。模塊模型定義瞭箱體，單模塊係統在箱體裏運行（運行環境），同時還定義瞭模塊對箱體的接口和對其他模塊的接口。對此已經定義瞭很多模塊的結構，比如模型的持久性、安全性和版本管理。

　　組閤

　　組閤是關聯的一個特例，它描述的是整體與其局部的關係。局部的存在和整體的存在相關聯，一個局部隻屬於一個唯一的整體。

　　具體類

　　具體類可以實例化，即具體類可以生成對象。

　　構造函數

　　構造函數是一個特殊的方法。構造函數與類名相同，在生成對象時被調用，為實例化服務。構造函數沒有返迴值類型，而且不能被繼承。

　　控製對象

　　控製對象並不是現實世界的實體。控製對象相當於一個流程控製。

　　生命綫

　　生命綫存在於UML的時序圖和通信圖中。對象在通信圖中作為對話者可以在UML中被描述為生命綫。在UML的時序圖和通信圖中的生命綫之間可以實現信息交流。

　　方法

　　一個方法實現一個操作。

　　中間件

　　中間件是程序的一個層次，它可以擴展延伸到多颱計算機，服務於分布式應用的進程間通信。中間件還有其他功能，如持久化服務、信息安全功能或名稱管理。

　　多重性

　　多重性是對集閤可能采取的基數範圍的說明。

　　消息

　　對象之間可以通過消息進行溝通，接收者負責對消息進行解釋。

　　導航

　　通過導航可以觀察哪些對象是可以訪問的（這些對象的類之間存在聯係）。導航就是說明連接一端的對象是否能夠到達連接另一端的對象。對於直接可以導航的就不需要繞路訪問瞭。

　　並行

　　如果事件A和B可以互不依賴地獨自工作，就稱為是並行的。也就是說，“A先發生，然後B發生”和“B先發生，然後A發生”是等效的。

　　注釋

　　注釋是在UML中對一個或者多個模型元素的注解。

　　對象圖

　　對象圖顯示的是在一個特定時刻對象和對象之間的連接。

　　操作

　　一個操作在UML中錶達一個抽象的方法。它包括名稱、參數、返迴值類型、前置條件、後置條件和操作的詳細說明。一個操作將會在一個類中通過方法實現。操作的定義包括操作的名稱，對應於所屬方法的參數和返迴值類型。

　　在操作的詳細說明中，一般說明這個操作可以在不同的類中實現。一個操作通過詳細說明擁有一個特殊的含義（語義）。這個含義對於所有通過方法實現這個操作的類是相同的。例如，一個操作可以通過“給齣名稱和屬性值”來詳細說明。在不同的類裏如何用個數互不相同的屬性來實現。

　　操作視圖

　　操作視圖隻關注對用戶重要的功能，不考慮係統管理員。

　　包

　　UML中的包用作對子包的分組或模型元素的分組，如類、接口、用例等。包可以理解為命名空間，用於訪問保護的單元，使組織結構更加清晰。

　　麵闆

　　麵闆是一種無形的對象容器，可以把圖形組件分成不同的組。

　　範式

　　範式是一種思維模式。

　　持久性

　　對象的持久性意味著它的壽命超過瞭一個會話（session），因為它們存儲在非易失性存儲介質（如磁盤）中。

　　多態性

　　多態性意味著多樣性。例如，一個子類型的對象可以看做是它的基類。

　　協議

　　通信雙方進行通信的一組規則。

　　邊界條件

　　邊界條件經常稱為限製，是必須起作用的條件。它可以正式或非正式地加以描述，可以由相鄰的係統指定。

　　實現關係

　　實現關係是兩個元素間（按照UML分類）的靜態關係。其中一個元素對契約進行描述，另一個元素在實現過程中必須遵守這個契約。例如，一個類實現一個接口，在協作圖中的實現用例都是實現關係。

　　角色

　　角色的概念有多重含義：

　　* 角色可以是代理人1。

　　* 角色可以實現一個接口。

　　在關聯和角色設計模式中，每一個對象可以承載一個角色。對象可以實現角色定義的接口，對外實現角色的功能。

　　接口

　　接口就是操作的清單。操作可以是一個類彆（類或組件）提供的服務。一個接口可以錶達一個類或組件的所有操作或者一部分操作。實現接口的類或組件必須遵守接口中對操作的定義。

　　自我委托

　　一個對象的方法調用自己的另外一個方法。

　　時序圖

　　時序圖按照時間順序描述對象間或對象與角色（係統角色）間信息的交換。

　　序列化

　　序列化（或稱為信號編集）是把方法調用的變化寫入到信息中。

　　編程中的簽名和UML中的簽名

　　簽名的定義在編程和UML中的用法不同：

　　（1）在UML中：導齣接口包括方法名稱、參數類型列錶和返迴值類型。

　　（2）在Java中：導齣接口包括方法名稱和參數類型列錶。

　　會話（Session）

　　會話就是網絡中兩個地址化的單位利用建立起的連接進行數據交換。

　　涉眾（Stakeholder）

　　涉眾是對係統感興趣的自然人、法人或者一組人。這種興趣會影響到係統的軟件和硬件需求。

　　結構

　　係統的結構是其靜態布局。

　　子類

　　參見派生類。

　　錶

　　錶是類似結構的數據的綜閤。在關係數據庫中也稱為關係。

　　類型

　　類型有屬性和操作，對於屬性有取值範圍。

　　繼承

　　在麵嚮對象中，一個類可以繼承另外一個類或者是從一個類派生齣來。通過繼承，類自動擁有瞭基類的屬性和方法，就是說它繼承瞭基類的結構和功能。

　　繼承的層次結構

　　通過類之間的繼承關係，形成瞭層次結構：派生類從屬於基類，或者說基類處於派生類的上一級。

　　在Java中，所有的類都是從類Object派生齣來的，所以這個類在Java中處在繼承層次結構的根部。

　　行為

　　係統的行為是其功能的錶述。

　　連接

　　連接是關聯的一個實例。

　　使用關係

　　人們要錶達一個元素使用另外一個元素，可以在UML中通過 use 錶明它們的依賴關係。use關係就是通常所說的使用關係。使用關係錶明一個元素的含義（語義）依賴於另外一個元素的含義（語義）。

　　狀態圖

　　按照Harel 或者Hatley/Pirbhai的理論，UML的狀態圖是狀態轉化圖的一個變形。狀態圖由要詳細描述的類元的狀態（可能是區域1性的）和轉移組成。狀態可以是延遲、進入行為、退齣行為和狀態行為。轉移描述引起狀態變化的事件、條件以及類元在轉化過程中的行為。在給反應式係統（reactive system）建模時需要狀態圖。

　　狀態轉化圖

　　按照Harel 或者Hatley/Pirbhai的理論，在狀態轉化圖中係統的狀態在建模時以圖形化錶示。圖形藉助於狀態和轉移（狀態的變化）描述瞭一個自動裝置。轉移詳細說明瞭觸發事件、狀態變化的條件以及由狀態變化引起的行動。

评分☆☆☆☆☆

好，计算机科学与技术的大作，推荐！

评分☆☆☆☆☆

不错，内容还行

评分☆☆☆☆☆

书是正版，质量没问题。送货速度快，还在看。

评分☆☆☆☆☆

物流很快

评分☆☆☆☆☆

对于想提高编程水平，很有参考价值

评分☆☆☆☆☆

必须满分的技术架构

评分☆☆☆☆☆

好

评分☆☆☆☆☆

好书，值得推荐。

评分☆☆☆☆☆

此用户未及时填写评价内容，系统默认好评！