中南大學(xué)軟件體系結(jié)構(gòu)重點(diǎn)(共47頁)

1、精選優(yōu)質(zhì)文檔-傾情為你奉上第一章 軟件體系結(jié)構(gòu)概述（5分）一、 軟件體系結(jié)構(gòu)的定義l 國內(nèi)普遍接受的定義：軟件體系結(jié)構(gòu)包括構(gòu)件、連接件和約束，它是可預(yù)制和可重構(gòu)的軟件框架結(jié)構(gòu)。l 軟件體系結(jié)構(gòu) = 構(gòu)件 + 連接件 + 約束二、 軟件體系結(jié)構(gòu)的優(yōu)勢(shì)l 容易理解l 重用l 控制成本l 可分析性第二章 軟件體系結(jié)構(gòu)風(fēng)格（10分）一、 軟件體系結(jié)構(gòu)風(fēng)格定義l 軟件體系結(jié)構(gòu)風(fēng)格是描述某一特定應(yīng)用領(lǐng)域中系統(tǒng)組織方式的慣用模式。An architectural style defines a family of systems in terms of a pattern of structural org

2、anization.l 體系結(jié)構(gòu)風(fēng)格定義了一個(gè)系統(tǒng)家族，即一個(gè)體系結(jié)構(gòu)定義一個(gè)詞匯表和一組約束。詞匯表中包含一些構(gòu)件和連接件類型，而這組約束指出系統(tǒng)是如何將這些構(gòu)件和連接件組合起來的。An architectural style defines a vocabulary of components and connector types, and a set of constraints on how they can be combined.二、 常見的體系結(jié)構(gòu)風(fēng)格l 管道和過濾器Ø 每個(gè)構(gòu)件都有一組輸入和輸出，構(gòu)件讀輸入的數(shù)據(jù)流，經(jīng)過內(nèi)部處理，然后產(chǎn)生輸出數(shù)據(jù)流。Ø 過

3、濾器風(fēng)格的連接件就像是數(shù)據(jù)流傳輸?shù)墓艿?，將一個(gè)過濾器的輸出傳到另一個(gè)過濾器的輸入。l 數(shù)據(jù)抽象和面向?qū)ο蠼M織Ø 數(shù)據(jù)的表示方法和它們的相應(yīng)操作被封裝在一個(gè)抽象數(shù)據(jù)類型或?qū)ο笾小?#216; 這種風(fēng)格的構(gòu)件是對(duì)象或者說是抽象數(shù)據(jù)類型的實(shí)例。Ø 對(duì)象通過函數(shù)和過程的調(diào)用來進(jìn)行交互。l 基于事件的隱式調(diào)用Ø 構(gòu)件不直接調(diào)用一個(gè)過程，而是觸發(fā)或廣播一個(gè)或多個(gè)事件。Ø 事件的觸發(fā)者并不知道哪些構(gòu)件會(huì)被這些事件影響。l 分層系統(tǒng)Ø 組織成一個(gè)層次結(jié)構(gòu)。Ø 每一層都為上一層提供了相應(yīng)的服務(wù)，并且接受下一層提供的服務(wù)。l 倉庫系統(tǒng)Ø 構(gòu)件：

4、中心數(shù)據(jù)結(jié)構(gòu)（倉庫）和一些獨(dú)立構(gòu)件的集合。Ø 倉庫和在系統(tǒng)中很重要的外部構(gòu)件之間的相互作用。l 過程控制環(huán)路Ø 源自于控制理論中的模型框架，將事務(wù)處理看成輸入、加工、輸出、反饋、再輸入的一個(gè)持續(xù)的過程模型。Ø 通過持續(xù)性的加工處理過程將輸入數(shù)據(jù)轉(zhuǎn)換成既定屬性的“產(chǎn)品”。l C2風(fēng)格通過連接件綁定在一起的按照一組規(guī)則運(yùn)作的并行構(gòu)件網(wǎng)絡(luò)。l C/S風(fēng)格Ø 基于資源不對(duì)等，且為實(shí)現(xiàn)共享而提出來的。Ø 有三個(gè)主要組成部分：數(shù)據(jù)庫服務(wù)器、客戶應(yīng)用程序和網(wǎng)絡(luò)。Ø 優(yōu)點(diǎn)：ü 具有強(qiáng)大的數(shù)據(jù)操作和事務(wù)處理能力，模型思想簡單，易于人們理解和接

5、受。ü 對(duì)于硬件和軟件的變化顯示出極大的適應(yīng)性和靈活性，而且易于對(duì)系統(tǒng)進(jìn)行擴(kuò)充和縮小。ü 將大的應(yīng)用處理任務(wù)分布到許多通過網(wǎng)絡(luò)連接的低成本計(jì)算機(jī)上，以節(jié)約大量費(fèi)用。Ø 缺點(diǎn)：ü 開發(fā)成本較高。ü 客戶端程序設(shè)計(jì)復(fù)雜。ü 信息內(nèi)容和形式單一。ü 用戶界面風(fēng)格不一，使用繁雜，不利于推廣使用。ü 軟件移植困難。ü 軟件維護(hù)和升級(jí)困難。ü 新技術(shù)不能輕易應(yīng)用。l 三層C/S風(fēng)格Ø 優(yōu)點(diǎn)：ü 能提高系統(tǒng)和軟件的可維護(hù)性和可擴(kuò)展性。ü 具有良好的可升級(jí)性和開放性。ü

6、可以并行開發(fā)。ü 有效地隔離開表示層與數(shù)據(jù)層，為嚴(yán)格的安全管理奠定了堅(jiān)實(shí)的基礎(chǔ)。Ø 缺點(diǎn)：ü 各層間的通信效率不高。ü 設(shè)計(jì)時(shí)必須慎重考慮三層間的通信方法、通信頻率及數(shù)據(jù)量。l B/S風(fēng)格（瀏覽器/Web服務(wù)器/數(shù)據(jù)庫服務(wù)器）Ø 優(yōu)點(diǎn)：ü 基于B/S體系結(jié)構(gòu)的軟件，系統(tǒng)安裝、修改和維護(hù)全在服務(wù)器端解決。用戶在使用系統(tǒng)時(shí)，僅僅需要一個(gè)瀏覽器就可運(yùn)行全部的模塊，真正達(dá)到了“零客戶端”的功能，很容易在運(yùn)行時(shí)自動(dòng)升級(jí)。ü 提供了異種機(jī)、異種網(wǎng)、異種應(yīng)用服務(wù)器的聯(lián)機(jī)、聯(lián)網(wǎng)、統(tǒng)一服務(wù)的最現(xiàn)實(shí)的開放性基礎(chǔ)。Ø 缺點(diǎn)：ü

7、 缺乏對(duì)動(dòng)態(tài)頁面的支持能力，沒有集成有效的數(shù)據(jù)庫處理功能。ü 系統(tǒng)擴(kuò)展能力差，安全性難以控制。ü 數(shù)據(jù)查詢等響應(yīng)速度上，要遠(yuǎn)遠(yuǎn)低于C/S體系結(jié)構(gòu)。ü 數(shù)據(jù)提交一般以頁面為單位，數(shù)據(jù)的動(dòng)態(tài)交互性不強(qiáng)，不利于在線事務(wù)處理(OLTP)應(yīng)用。第三章 軟件需求與架構(gòu)（15分）一、 軟件需求的概念需求是指明必須實(shí)現(xiàn)什么的規(guī)格說明。它描述了系統(tǒng)的行為、特性或?qū)傩裕窃陂_發(fā)過程中對(duì)系統(tǒng)的約束。二、 軟件需求的流程三、 軟件需求的分類l 按層分：Ø 業(yè)務(wù)需求：反映組織機(jī)構(gòu)或客戶對(duì)系統(tǒng)、產(chǎn)品高層次的目標(biāo)要求，通常問題定義本身就是業(yè)務(wù)需求。領(lǐng)域?qū)＜?#216; 用戶需求：描述

8、用戶使用產(chǎn)品必須要完成什么任務(wù)，怎么完成的需求。用戶Ø 系統(tǒng)需求：從系統(tǒng)的角度來說明軟件的需求。開發(fā)人員l 按類分：Ø 功能需求：系統(tǒng)必須完成的那些事，即為了向它的用戶提供有用的功能，產(chǎn)品必須執(zhí)行的動(dòng)作。Ø 非功能需求：產(chǎn)品必須具備的屬性或品質(zhì)，如正確性、可靠性、性能、容錯(cuò)性和可擴(kuò)展性等。Ø 設(shè)計(jì)約束：對(duì)解決方案的一些約束說明。四、 軟件需求面臨的主要困難l 知識(shí)技能問題l 態(tài)度問題l 合作關(guān)系l 用戶說不清楚需求l 雙方誤解需求l 開發(fā)人員寫不好需求文檔l 用戶經(jīng)常變更需求五、 需求工程l 定義：把所有與需求直接相關(guān)的活動(dòng)通稱為需求工程。l 需求工程創(chuàng)

9、建的第一份文檔是需求陳述，用于在項(xiàng)目開發(fā)之初理解客戶的需求。l 分類：Ø 需求開發(fā)：目的是通過調(diào)查與分析，獲取用戶需求并定義產(chǎn)品需求。包括：ü 需求調(diào)查（需求獲?。┑哪康氖峭ㄟ^各種途徑獲取用戶的需求信息（原始材料），產(chǎn)生需求陳述。ü 需求分析的目的是對(duì)各種需求信息進(jìn)行分析，消除錯(cuò)誤，刻畫細(xì)節(jié)等。常見的需求分析方法有“問答分析法”和“建模分析法”兩類。ü 需求定義的目的是根據(jù)需求調(diào)查和需求分析的結(jié)果，進(jìn)一步定義準(zhǔn)確無誤的產(chǎn)品需求，產(chǎn)生軟件需求規(guī)格說明書。Ø 需求管理：目的是在客戶與開發(fā)方之間建立對(duì)需求的共同理解，維護(hù)需求與其它工作成果的一致性，并

10、控制需求的變更。包括：ü 需求確認(rèn)是指開發(fā)方和客戶共同對(duì)需求文檔進(jìn)行評(píng)審，雙方對(duì)需求達(dá)成共識(shí)后作出書面承諾，使需求文檔具有商業(yè)合同效果。ü 需求跟蹤是指通過比較需求文檔與后續(xù)工作成果之間的對(duì)應(yīng)關(guān)系，建立與維護(hù)“需求跟蹤矩陣”，確保產(chǎn)品依據(jù)需求文檔進(jìn)行開發(fā)。 ü 需求變更控制是指依據(jù)“變更申請(qǐng)審批更改重新確認(rèn)”的流程處理需求的變更，防止需求變更失去控制而導(dǎo)致項(xiàng)目發(fā)生混亂。l 需求工程結(jié)構(gòu)圖：六、 需求獲取技術(shù)l 獲取需求的方法Ø 面談（訪談）：開放式問題和封閉式問題 Ø 問卷調(diào)查：潛在使用者太多或分布太廣時(shí)Ø 會(huì)議（需求討論會(huì)、重點(diǎn)問題

11、討論會(huì)、業(yè)務(wù)專題討論會(huì)、設(shè)計(jì)專題討論會(huì)）Ø 文檔研究Ø 任務(wù)示范（觀察）：通過觀察可以獲得第一手的資料。Ø 用例與角色扮演Ø 原型設(shè)計(jì)（小規(guī)模試驗(yàn)）Ø 研究類似公司l 需求陳述Ø 是一份文檔，陳述用戶對(duì)軟件的期望和需要，并對(duì)可能的規(guī)格要求加以說明。Ø 需求陳述用來明確軟件的用途，它不僅要說明軟件有什么用，還要在宏觀層次上明確軟件應(yīng)具備的特性。Ø 核心內(nèi)容ü 開發(fā)該軟件的動(dòng)機(jī)（愿景）是什么？ü 該項(xiàng)目的主要涉眾是誰？ü 希望該軟件具備哪些主要功能和特性？七、 需求建模l 需求模型分類：&

12、#216; 功能模型如UC見下章Ø 業(yè)務(wù)流程模型如DFDü 數(shù)據(jù)流圖(Data Flow Diagram, DFD)是結(jié)構(gòu)化方法中用于表示系統(tǒng)邏輯模型的一種工具，它以圖形的方式描繪數(shù)據(jù)在系統(tǒng)中流動(dòng)和處理的過程。Ø 數(shù)據(jù)建模模型如ERü ER建模用于對(duì)數(shù)據(jù)進(jìn)行建模（概念模型）ü 在ER圖中包含三個(gè)圖形符號(hào)，分別表示：實(shí)體（矩形）、屬性（橢圓）、聯(lián)系（菱形）八、 編寫軟件需求規(guī)格說明書l 需求分析的主要成果：軟件需求規(guī)格說明書(Software Requirement Specification, SRS)l 要求的屬性：Ø 正確：最重要

13、的屬性。Ø 清楚：讓人易讀易懂，不在于文檔的厚度。Ø 無二義性：是指每個(gè)需求只有唯一的含義。Ø 一致：指軟件需求規(guī)格說明書中各個(gè)需求之間不會(huì)發(fā)生矛盾。Ø 必要：其中的各項(xiàng)需求對(duì)用戶而言應(yīng)當(dāng)都是必要的。Ø 完備：指軟件需求規(guī)格說明書中沒有遺漏一些必要的需求。Ø 可實(shí)現(xiàn)：其中各項(xiàng)需求對(duì)開發(fā)方而言應(yīng)當(dāng)都是可實(shí)現(xiàn)的。Ø 可驗(yàn)證：其中的各項(xiàng)需求對(duì)用戶方而言應(yīng)當(dāng)都是可驗(yàn)證的。Ø 確定優(yōu)先級(jí)：先做優(yōu)先級(jí)高的需求，后做（甚至放棄）優(yōu)先級(jí)低的需求，這樣可以將風(fēng)險(xiǎn)降到最低。l 闡述“做什么”而不是“怎么做”九、 需求確認(rèn)l 需求確認(rèn)是

14、指開發(fā)方和客戶方共同對(duì)軟件需求規(guī)格說明書進(jìn)行評(píng)審，雙方對(duì)需求達(dá)成共識(shí)后作出承諾。l 包含兩個(gè)重要工作：Ø 需求評(píng)審Ø 需求承諾十、 需求跟蹤技術(shù)l 需求跟蹤的目的是建立與維護(hù)“需求-設(shè)計(jì)-編程-測試”之間的一致性，確保所有的工作成果符合用戶需求。l 跟蹤有兩種方式： Ø 正向跟蹤。檢查軟件需求規(guī)格說明書中的每個(gè)需求是否都能在后繼工作成果中找到對(duì)應(yīng)點(diǎn)。 Ø 逆向跟蹤。檢查設(shè)計(jì)文檔、代碼、測試用例等工作成果是否都能在軟件需求規(guī)格說明書中找到出處。l 跟蹤矩陣Ø 源跟蹤矩陣（需求與需求來源）Ø 功能跟蹤矩陣（需求與功能）Ø 依賴跟

15、蹤矩陣（一個(gè)需求與另一個(gè)需求）十一、 需求變更控制l 需求發(fā)生變更的起因主要有： Ø 隨著項(xiàng)目的進(jìn)展，人們（包括開發(fā)方和客戶方）對(duì)需求的了解越來越深入。原先的需求文檔可能存在這樣那樣的錯(cuò)誤或不足，因此要變更需求。 Ø 市場發(fā)生了變化，原先的需求文檔可能跟不上當(dāng)前的市場需求，因此要變更需求。l 需求變更控制的目的：Ø 如果需求變更帶來的好處大于壞處，那么允許變更，但必須按照已定義的變更規(guī)程執(zhí)行，以免變更失去控制。Ø 如果需求變更帶來的壞處大于好處，那么拒絕變更。l 需求基線Ø 已經(jīng)通過正式評(píng)審和批準(zhǔn)的規(guī)格說明或產(chǎn)品，它可以作為進(jìn)一步開發(fā)的基礎(chǔ)，并

16、且只有通過正式的變更控制過程才能修改它。Ø 是被明確和固定下來的需求集合，是項(xiàng)目團(tuán)隊(duì)需要在某一特定產(chǎn)品版本中實(shí)現(xiàn)的特征和需求集合。第五章 統(tǒng)一建模語言UML（20分）（Unified Modeling Language）（重點(diǎn)看實(shí)驗(yàn)1）一、 用例圖（Use Case Diagram）l 執(zhí)行者和用例之間的關(guān)聯(lián)關(guān)系（Association）：一根直線來表示l 執(zhí)行者之間的泛化關(guān)系（Generalization）（或繼承關(guān)系）用例之間的關(guān)系：l 包含關(guān)系：描述在多個(gè)用例中都有的公共行為，由用例A指向用例B，表示用例A中使用了用例B中的行為或功能，包含關(guān)系是通過在依賴關(guān)系上應(yīng)用<&l

17、t;include>>構(gòu)造型（衍型）來表示的。l 擴(kuò)展關(guān)系：擴(kuò)展用例可以在基用例之上添加新的行為，但是基用例必須聲明某些特定的“擴(kuò)展點(diǎn)”，并且擴(kuò)展用例只能在這些擴(kuò)展點(diǎn)上擴(kuò)展新的行為。擴(kuò)展關(guān)系是通過在依賴關(guān)系上應(yīng)用<<extend>>構(gòu)造型（衍型）來表示的。l 泛化關(guān)系：Ø 當(dāng)多個(gè)用例共同擁有一種類似的結(jié)構(gòu)和行為的時(shí)候，可以將它們的共性抽象成為父用例，其他的用例作為泛化關(guān)系中的子用例。Ø 在用例的泛化關(guān)系中，子用例是父用例的一種特殊形式，子用例繼承了父用例所有的結(jié)構(gòu)、行為和關(guān)系。Ø 泛化關(guān)系一般很少使用。二、 狀態(tài)圖(State

18、Diagram)l 定義：用來描述一個(gè)特定對(duì)象的所有可能狀態(tài)及其引起狀態(tài)轉(zhuǎn)移的事件。Ø 通常用狀態(tài)圖來描述單個(gè)對(duì)象的行為Ø 只有那些具有重要交互行為的類，才會(huì)使用狀態(tài)圖來描述。Ø 一個(gè)狀態(tài)圖包括一系列對(duì)象的狀態(tài)及狀態(tài)之間的轉(zhuǎn)換。l 組成元素：Ø 初始狀態(tài)Ø 終止?fàn)顟B(tài)Ø 狀態(tài)Ø 轉(zhuǎn)移Ø 守護(hù)條件Ø 事件Ø 動(dòng)作三、 活動(dòng)圖（Activity Diagram）l 定義：用來表示系統(tǒng)中各種活動(dòng)的次序，它的應(yīng)用非常廣泛，既可用來描述用例的工作流程，也可以用來描述類中某個(gè)方法的操作行為。l 作用：

19、6; 描述業(yè)務(wù)流程Ø 描述用例路徑Ø 描述方法執(zhí)行流程（程序流程圖）l 組成元素：Ø 起始活動(dòng)(Start Activity)Ø 終止活動(dòng)(End Activity)Ø 活動(dòng)(Activity)Ø 轉(zhuǎn)移(Transition)或流(Flow)Ø 決策(Decision)Ø 守護(hù)條件(Condition)Ø 同步條(Synchronization)Ø 泳道(Swimlane)四、 順序圖l 定義：Ø 用于確認(rèn)和豐富一個(gè)使用情境的邏輯。Ø 將交互關(guān)系表現(xiàn)為一個(gè)二維圖，縱向是時(shí)間軸

20、，時(shí)間沿豎線向下延伸。橫向軸代表了在協(xié)作中各獨(dú)立對(duì)象的類元角色，類元角色的活動(dòng)用生命線表示。l 組成元素：Ø 生命線：用一條縱向虛線表示。Ø 對(duì)象：表示為一個(gè)矩形，其中對(duì)象名稱標(biāo)有下劃線。Ø 激活：是過程的執(zhí)行，包括等待過程執(zhí)行的時(shí)間。激活部分替換生命線，使用長條的矩形表示。Ø 消息：對(duì)象之間的通信ü 調(diào)用消息：對(duì)應(yīng)于激活，表示它將會(huì)激活一個(gè)對(duì)象。ü 發(fā)送消息：沒有對(duì)應(yīng)激活框，表示它不是一個(gè)調(diào)用消息，不會(huì)引發(fā)其他對(duì)象的活動(dòng)。ü 返回消息ü 自身消息ü 創(chuàng)建消息ü 銷毀消息ü 同步消息&

21、#252; 異步消息Ø 交互片段：一個(gè)復(fù)雜的順序圖可以劃分為幾個(gè)小塊，每一個(gè)小塊稱為一個(gè)交互片段。ü alt:多條路徑，條件為真時(shí)執(zhí)行。ü opt:任選，僅當(dāng)條件為真時(shí)執(zhí)行。ü par:并行，每一片段都并發(fā)執(zhí)行。ü loop:循環(huán)，片段可多次執(zhí)行。ü critical:臨界區(qū)，只能有一個(gè)線程對(duì)它立即執(zhí)行。五、 類圖l 類之間的關(guān)系：Ø 關(guān)聯(lián)關(guān)系(Association)ü 用于表示一類對(duì)象與另一類對(duì)象之間有聯(lián)系ü 用實(shí)線連接有關(guān)聯(lián)的對(duì)象所對(duì)應(yīng)的類ü 通常將一個(gè)類的對(duì)象作為另一個(gè)類的屬性Ø

22、; 自關(guān)聯(lián)ü 一些類的屬性對(duì)象類型為該類本身Ø 多重性關(guān)聯(lián) ü 表示一個(gè)類的對(duì)象與另一個(gè)類的對(duì)象連接的個(gè)數(shù)。Ø 聚合關(guān)系(Aggregation)ü 表示一個(gè)整體與部分的關(guān)系。ü 成員類是整體類的一部分，即成員對(duì)象是整體對(duì)象的一部分，但是成員對(duì)象可以脫離整體對(duì)象獨(dú)立存在。ü 在UML中，聚合關(guān)系用帶空心菱形的直線表示。Ø 組合關(guān)系(Composition)ü 部分和整體具有統(tǒng)一的生存期。ü 部分對(duì)象與整體對(duì)象之間具有同生共死的關(guān)系。ü 整體類可以控制成員類的生命周期，即成員類的存在依賴

23、于整體類。ü 在UML中，組合關(guān)系用帶實(shí)心菱形的直線表示。Ø 依賴關(guān)系(Dependency)ü 使用關(guān)系。ü 體現(xiàn)在某個(gè)類的方法使用另一個(gè)類的對(duì)象作為參數(shù)。ü 在UML中，依賴關(guān)系用帶箭頭的虛線表示。Ø 泛化關(guān)系(Generalization)ü 用于描述父類與子類之間的關(guān)系，父類又稱作基類或超類，子類又稱作派生類。ü 在UML中，泛化關(guān)系用帶空心三角形的直線來表示。Ø 接口與實(shí)現(xiàn)關(guān)系(Realization)ü 類實(shí)現(xiàn)了接口，類中的操作實(shí)現(xiàn)了接口中所聲明的操作。ü 在UML中，類與

24、接口之間的實(shí)現(xiàn)關(guān)系用帶空心三角形的虛線來表示。六、 包圖l 定義Ø 一種把元素組織到一起的通用機(jī)制Ø 用于描述包與包之間的關(guān)系Ø 包的圖標(biāo)是一個(gè)帶標(biāo)簽的文件夾。l 包之間的關(guān)系Ø 引入關(guān)系：ü 一個(gè)包中的類可以被另一個(gè)指定包（以及嵌套于其中的那些包）中的類引用。ü 在依賴線上增加一個(gè)<<import>>衍型。Ø 泛化關(guān)系：表示一個(gè)包繼承了另一個(gè)包的內(nèi)容，同時(shí)又補(bǔ)充自己增加的內(nèi)容。Ø 嵌套關(guān)系：一個(gè)包中可以包含若干個(gè)子包，構(gòu)成了包的嵌套層次結(jié)構(gòu)。七、 組件圖（Component Diagram

25、）l 定義：Ø 顯示編譯、鏈接或執(zhí)行時(shí)組件之間的依賴關(guān)系，以及組件的接口和調(diào)用關(guān)系。Ø 組件就是一個(gè)實(shí)際文件，可以有以下幾種類型：ü 源代碼組件：一個(gè)源代碼文件或者與一個(gè)包對(duì)應(yīng)的若干個(gè)源代碼文件。ü 二進(jìn)制組件：一個(gè)目標(biāo)碼文件，一個(gè)靜態(tài)的或者動(dòng)態(tài)的庫文件。ü 可執(zhí)行組件：在一臺(tái)處理器上可運(yùn)行的一個(gè)可執(zhí)行的程序單位，即所謂可執(zhí)行程序。l 組件間關(guān)系：泛化關(guān)系、依賴關(guān)系l 組成元素：Ø 組件：系統(tǒng)中可以替換的部分，一般對(duì)應(yīng)一個(gè)實(shí)際文件，如exe、jar、dll等文件，它遵循并提供了一組接口的實(shí)現(xiàn)。Ø 接口：一組操作的集合，它指明

26、了由類或組件所請(qǐng)求或者所提供的服務(wù)。Ø 部件：組件的局部實(shí)現(xiàn)。Ø 端口：被封裝的組件與外界的交互點(diǎn)，遵循指定接口的組件通過它來收發(fā)消息。Ø 連接件：在特定語境下組件中兩個(gè)部件之間或者兩個(gè)端口之間的通信關(guān)系。Ø 供(Provided)接口與需(Required)接口八、 部署圖(Deployment Diagram)l 定義：Ø 描述系統(tǒng)硬件的物理拓?fù)浣Y(jié)構(gòu)及在此結(jié)構(gòu)上執(zhí)行的軟件。Ø 顯示了系統(tǒng)的硬件和安裝在硬件上的軟件，以及用于連接異構(gòu)計(jì)算機(jī)之間的中間件。l 組成元素：Ø 節(jié)點(diǎn)和連接：節(jié)點(diǎn)(Node)代表一個(gè)物理設(shè)備。在 UM

27、L 中，使用一個(gè)立方體表示一個(gè)節(jié)點(diǎn)。節(jié)點(diǎn)之間的連線表示系統(tǒng)之間進(jìn)行交互的通信路徑，在 UML 中被稱為連接。Ø 組件：在部署圖中，組件代表可執(zhí)行的物理代碼模塊，如一個(gè)可執(zhí)行程序，邏輯上它可以與類或包對(duì)應(yīng)。九、 對(duì)象圖l 定義：對(duì)象圖是類圖在某一時(shí)刻的一個(gè)實(shí)例。十、 組合結(jié)構(gòu)圖l 定義：Ø 將每一個(gè)類放在一個(gè)整體中，從類的內(nèi)部結(jié)構(gòu)來審視一個(gè)類。Ø 組合結(jié)構(gòu)圖可用于表示一個(gè)類的內(nèi)部結(jié)構(gòu)。l 組成元素：Ø 部件(Part)：表示被描述事物所擁有的內(nèi)部成分。Ø 連接件(Connector)：表示部件之間的關(guān)系。Ø 端口(Port)：表示部件和

28、外部環(huán)境的交互點(diǎn)。十一、 通信圖l 定義：Ø 通信圖強(qiáng)調(diào)參與一個(gè)交互對(duì)象的組織。Ø 它與順序圖是同構(gòu)圖，也就是它們包含了相同的信息，只是表達(dá)方式不同而已，通信圖與順序圖可以相互轉(zhuǎn)換。Ø 當(dāng)對(duì)象及其連接有利于理解交互時(shí)，選擇通信圖；當(dāng)只需了解交互的次序時(shí)，選擇順序圖。l 組成元素：執(zhí)行者(Actor)、對(duì)象(Object)、連接(Link，也稱為鏈)、消息(Message)和守護(hù)條件(Condition)。十二、 定時(shí)圖l 定義：Ø 采用一種帶數(shù)字刻度的時(shí)間軸來精確地描述消息的順序Ø 可視化地表示每條生命線的狀態(tài)變化Ø 可以把狀態(tài)發(fā)生變

29、化的時(shí)刻以及各個(gè)狀態(tài)所持續(xù)的時(shí)間具體地表示出來。十三、 交互概覽圖l 定義：Ø 交互圖與活動(dòng)圖的混合物，可以把交互概覽圖理解為細(xì)化的活動(dòng)圖，在其中的活動(dòng)都通過一些小型的順序圖來表示；也可以將其理解為利用標(biāo)明控制流的活動(dòng)圖分解過的順序圖。Ø 用于將一些零散的順序圖組織在一起，它采用了活動(dòng)圖的構(gòu)造方式，利用了活動(dòng)圖的各種控制節(jié)點(diǎn)，并把活動(dòng)圖的每個(gè)活動(dòng)結(jié)點(diǎn)替換為一個(gè)交互或者交互使用。每個(gè)交互或者交互使用都使用一個(gè)順序圖表示。面向?qū)ο笤O(shè)計(jì)原則1、 單一職責(zé)原則(Single Responsibility Principle, SRP)定義：一個(gè)對(duì)象應(yīng)該只包含單一的職責(zé)，并且該職責(zé)被

30、完整地封裝在一個(gè)類中。Every object should have a single responsibility, and that responsibility should be entirely encapsulated by the class.2、 開閉原則(Open-Closed Principle, OCP)定義：一個(gè)軟件實(shí)體應(yīng)當(dāng)對(duì)擴(kuò)展開放，對(duì)修改關(guān)閉。Software entities should be open for extension, but closed for modification.3、 里氏代換原則(Liskov Substitution Princi

31、ple, LSP)定義：所有引用基類（父類）的地方必須能透明地使用其子類的對(duì)象。Functions that use pointers or references to base classes must be able to use objects of derived classes without knowing it.4、 依賴倒轉(zhuǎn)原則(Dependence Inversion Principle, DIP)定義：高層模塊不應(yīng)該依賴低層模塊，它們都應(yīng)該依賴抽象。抽象不應(yīng)該依賴于細(xì)節(jié)，細(xì)節(jié)應(yīng)該依賴于抽象。High level modules should not depend upon

32、low level modules, both should depend upon abstractions. Abstractions should not depend upon details, details should depend upon abstractions.5、 接口隔離原則(Interface Segregation Principle, ISP)定義：客戶端不應(yīng)該依賴那些它不需要的接口。Clients should not be forced to depend upon interfaces that they do not use.6、 合成復(fù)用原則(Comp

33、osite Reuse Principle, CRP)定義：盡量使用對(duì)象組合，而不是繼承來達(dá)到復(fù)用的目的。Favor composition of objects over inheritance as a reuse mechanism.7、 迪米特法則(Law of Demeter, LoD)定義：一個(gè)軟件實(shí)體應(yīng)當(dāng)盡可能少的與其他實(shí)體發(fā)生相互作用。設(shè)計(jì)模式（重點(diǎn)看實(shí)驗(yàn)2、3）一、 創(chuàng)建型模式l 簡單工廠模式（Simple Factory）Ø 定義：根據(jù)參數(shù)的不同返回不同類的實(shí)例，專門定義一個(gè)類來負(fù)責(zé)創(chuàng)建其他類的實(shí)例，被創(chuàng)建的實(shí)例通常都具有共同的父類。Ø 優(yōu)點(diǎn)：ü

34、; 實(shí)現(xiàn)了對(duì)責(zé)任的分割，它提供了專門的工廠類用于創(chuàng)建對(duì)象。ü 客戶端無須知道所創(chuàng)建的具體產(chǎn)品類的類名，只需要知道具體產(chǎn)品類所對(duì)應(yīng)的參數(shù)即可。ü 通過引入配置文件，可以在不修改任何客戶端代碼的情況下更換和增加新的具體產(chǎn)品類，在一定程度上提高了系統(tǒng)的靈活性。Ø 缺點(diǎn)：ü 工廠類集中了所有產(chǎn)品創(chuàng)建邏輯，職責(zé)過重，不符合單一職責(zé)原則。ü 增加系統(tǒng)中類的個(gè)數(shù)。ü 系統(tǒng)擴(kuò)展困難，不符合開閉原則。ü 由于使用了靜態(tài)工廠方法，造成工廠角色無法形成基于繼承的等級(jí)結(jié)構(gòu)。Ø 適用范圍：ü 工廠類負(fù)責(zé)創(chuàng)建的對(duì)象比較少。ü

35、; 客戶端只知道傳入工廠類的參數(shù)，對(duì)于如何創(chuàng)建對(duì)象不關(guān)心。l 工廠方法模式(Factory Method Pattern)Ø 定義：ü 工廠父類負(fù)責(zé)定義創(chuàng)建產(chǎn)品對(duì)象的公共接口，而工廠子類則負(fù)責(zé)生成具體的產(chǎn)品對(duì)象，這樣做的目的是將產(chǎn)品類的實(shí)例化操作延遲到工廠子類中完成，即通過工廠子類來確定究竟應(yīng)該實(shí)例化哪一個(gè)具體產(chǎn)品類。ü Define an interface for creating an object, but let subclasses decide which class to instantiate. Factory Method lets a cla

36、ss defer instantiation to subclasses.Ø 優(yōu)點(diǎn)：ü 用戶只需要關(guān)心所需產(chǎn)品對(duì)應(yīng)的工廠，無須關(guān)心創(chuàng)建細(xì)節(jié)，甚至無須知道具體產(chǎn)品類的類名。ü 工廠可以自主確定創(chuàng)建何種產(chǎn)品對(duì)象，而如何創(chuàng)建這個(gè)對(duì)象的細(xì)節(jié)則完全封裝在具體工廠內(nèi)部。ü 在系統(tǒng)中加入新產(chǎn)品時(shí)，無須修改抽象工廠和抽象產(chǎn)品提供的接口，無須修改客戶端，也無須修改其他的具體工廠和具體產(chǎn)品，而只要添加一個(gè)具體工廠和具體產(chǎn)品就可以了。Ø 缺點(diǎn)：ü 在添加新產(chǎn)品時(shí)，需要編寫新的具體產(chǎn)品類，而且還要提供與之對(duì)應(yīng)的具體工廠類，系統(tǒng)中類的個(gè)數(shù)將成對(duì)增加，在一定程度

37、上增加了系統(tǒng)的復(fù)雜度。ü 增加了系統(tǒng)的抽象性和理解難度。Ø 適用范圍：ü 一個(gè)類不知道它所需要的對(duì)象的類。ü 一個(gè)類通過其子類來指定創(chuàng)建哪個(gè)對(duì)象。ü 將創(chuàng)建對(duì)象的任務(wù)委托給多個(gè)工廠子類中的某一個(gè)，客戶端在使用時(shí)可以無須關(guān)心是哪一個(gè)工廠子類創(chuàng)建產(chǎn)品子類，需要時(shí)再動(dòng)態(tài)指定。l 抽象工廠模式(Abstract Factory Pattern)Ø 定義：ü 提供一個(gè)創(chuàng)建一系列相關(guān)或相互依賴對(duì)象的接口，而無須指定它們具體的類。ü Provide an interface for creating families of re

38、lated or dependent objects without specifying their concrete classes.Ø 優(yōu)點(diǎn)：ü 隔離了具體類的生成。ü 可以實(shí)現(xiàn)高內(nèi)聚低耦合的設(shè)計(jì)目的。ü 能夠保證客戶端始終只使用同一個(gè)產(chǎn)品族中的對(duì)象。ü 增加新的具體工廠和產(chǎn)品族很方便，無須修改已有系統(tǒng)，符合“開閉原則”。Ø 缺點(diǎn)：ü 難以擴(kuò)展抽象工廠來生產(chǎn)新種類的產(chǎn)品。ü 開閉原則的傾斜性（增加新的工廠和產(chǎn)品族容易，增加新的產(chǎn)品等級(jí)結(jié)構(gòu)麻煩）Ø 適用范圍：ü 一個(gè)系統(tǒng)不應(yīng)當(dāng)依賴于產(chǎn)品類實(shí)

39、例如何被創(chuàng)建、組合和表達(dá)的細(xì)節(jié)。ü 系統(tǒng)中有多于一個(gè)的產(chǎn)品族，而每次只使用其中某一產(chǎn)品族。ü 屬于同一個(gè)產(chǎn)品族的產(chǎn)品將在一起使用。ü 系統(tǒng)提供一個(gè)產(chǎn)品類的庫，所有的產(chǎn)品以同樣的接口出現(xiàn)，從而使客戶端不依賴于具體實(shí)現(xiàn)。l 單例模式(Singleton Pattern)Ø 定義：ü 確保某一個(gè)類只有一個(gè)實(shí)例，而且自行實(shí)例化并向整個(gè)系統(tǒng)提供這個(gè)實(shí)例，這個(gè)類稱為單例類，它提供全局訪問的方法。ü Ensure a class has only one instance and provide a global point of access t

40、o it.Ø 優(yōu)點(diǎn)：ü 提供了對(duì)唯一實(shí)例的受控訪問。ü 可以節(jié)約系統(tǒng)資源ü 允許可變數(shù)目的實(shí)例。Ø 缺點(diǎn)：ü 單例類的擴(kuò)展有很大的困難。ü 單例類的職責(zé)過重。ü 濫用單例將帶來一些負(fù)面問題。Ø 適用范圍：ü 系統(tǒng)只需要一個(gè)實(shí)例對(duì)象。ü 客戶調(diào)用類的單個(gè)實(shí)例只允許使用一個(gè)公共訪問點(diǎn)。二、 結(jié)構(gòu)型模式l 適配器模式(Adapter Pattern)Ø 定義：ü 將一個(gè)接口轉(zhuǎn)換成客戶希望的另一個(gè)接口，適配器模式使接口不兼容的那些類可以一起工作，其別名為包裝器(Wrappe

41、r)。適配器模式既可以作為類結(jié)構(gòu)型模式，也可以作為對(duì)象結(jié)構(gòu)型模式。ü Convert the interface of a class into another interface clients expect. Adapter lets classes work together that couldn't otherwise because of incompatible interfaces.類適配器對(duì)象適配器Ø 優(yōu)點(diǎn)：ü 將目標(biāo)類和適配者類解耦。ü 增加了類的透明性和復(fù)用性。ü 靈活性和擴(kuò)展性都非常好。Ø 缺點(diǎn)：

42、52; 類適配器模式的缺點(diǎn)是適配器類在很多編程語言中不能同時(shí)適配多個(gè)適配者類。ü 對(duì)象適配器模式的缺點(diǎn)是很難置換適配者類的方法。Ø 適用范圍：ü 系統(tǒng)需要使用現(xiàn)有的類，而這些類的接口不符合系統(tǒng)的需要。ü 想要建立一個(gè)可以重復(fù)使用的類，用于與一些彼此之間沒有太大關(guān)聯(lián)的一些類一起工作。l 橋接模式(Bridge Pattern)Ø 定義：ü 將抽象部分與它的實(shí)現(xiàn)部分分離，使它們都可以獨(dú)立地變化。ü Decouple an abstraction from its implementation so that the two ca

43、n vary independently.Ø 優(yōu)點(diǎn)：ü 分離抽象接口及其實(shí)現(xiàn)部分。ü 橋接模式是比多繼承方案更好的解決方法。ü 提高了系統(tǒng)的可擴(kuò)充性，在兩個(gè)變化維度中任意擴(kuò)展一個(gè)維度，都不需要修改原有系統(tǒng)。ü 實(shí)現(xiàn)細(xì)節(jié)對(duì)客戶透明，可以對(duì)用戶隱藏實(shí)現(xiàn)細(xì)節(jié)。Ø 缺點(diǎn)：ü 會(huì)增加系統(tǒng)的理解與設(shè)計(jì)難度。ü 其使用范圍具有一定的局限性。Ø 適用范圍：ü 需要在構(gòu)件的抽象化角色和具體化角色之間增加更多的靈活性，避免在兩個(gè)層次之間建立靜態(tài)的繼承聯(lián)系。ü 抽象化角色和實(shí)現(xiàn)化角色可以以繼承的方式獨(dú)立擴(kuò)展

44、而互不影響。ü 一個(gè)類存在兩個(gè)獨(dú)立變化的維度，且這兩個(gè)維度都需要進(jìn)行擴(kuò)展。ü 設(shè)計(jì)要求需要獨(dú)立管理抽象化角色和具體化角色。ü 不希望使用繼承或因?yàn)槎鄬哟卫^承導(dǎo)致系統(tǒng)類的個(gè)數(shù)急劇增加的系統(tǒng)。l 組合模式(Composite Pattern)Ø 定義：組合多個(gè)對(duì)象形成樹形結(jié)構(gòu)以表示“整體-部分”的結(jié)構(gòu)層次。組合模式對(duì)單個(gè)對(duì)象（即葉子對(duì)象）和組合對(duì)象（即容器對(duì)象）的使用具有一致性。Compose objects into tree structures to represent part-whole hierarchies. Composite lets cl

45、ients treat individual objects and compositions of objects uniformly.Ø 優(yōu)點(diǎn)：ü 可以清楚地定義分層次的復(fù)雜對(duì)象。ü 客戶端可以一致的使用組合結(jié)構(gòu)或其中單個(gè)對(duì)象。ü 更容易在組合體內(nèi)加入對(duì)象構(gòu)件。Ø 缺點(diǎn)：ü 設(shè)計(jì)變得更加抽象。ü 很難對(duì)容器中的構(gòu)件類型進(jìn)行限制。Ø 適用范圍：ü 需要表示一個(gè)對(duì)象整體或部分層次。ü 客戶端可以針對(duì)抽象構(gòu)件編程，無須關(guān)心對(duì)象層次結(jié)構(gòu)的細(xì)節(jié)。ü 對(duì)象的結(jié)構(gòu)是動(dòng)態(tài)的并且復(fù)雜程度不一樣，但客

46、戶需要一致地處理它們。l 外觀模式(Facade Pattern)Ø 定義：ü 外部與一個(gè)子系統(tǒng)的通信必須通過一個(gè)統(tǒng)一的外觀對(duì)象進(jìn)行，為子系統(tǒng)中的一組接口提供一個(gè)一致的界面，外觀模式定義了一個(gè)高層接口，這個(gè)接口使得這一子系統(tǒng)更加容易使用。ü Provide a unified interface to a set of interfaces in a subsystem. Facade defines a higher-level interface that makes the subsystem easier to use.Ø 優(yōu)點(diǎn)：ü 對(duì)

47、客戶屏蔽子系統(tǒng)組件，減少了客戶處理的對(duì)象數(shù)目并使得子系統(tǒng)使用起來更加容易。ü 實(shí)現(xiàn)了子系統(tǒng)與客戶之間的松耦合關(guān)系。ü 降低了大型軟件系統(tǒng)中的編譯依賴性，并簡化了系統(tǒng)在不同平臺(tái)之間的移植過程。ü 只是提供了一個(gè)訪問子系統(tǒng)的統(tǒng)一入口，并不影響用戶直接使用子系統(tǒng)類。Ø 缺點(diǎn)：ü 不能很好地限制客戶使用子系統(tǒng)類。ü 在不引入抽象外觀類的情況下，增加新的子系統(tǒng)可能需要修改外觀類或客戶端的源代碼，違背了“開閉原則”。Ø 適用范圍：ü 當(dāng)要為一個(gè)復(fù)雜子系統(tǒng)提供一個(gè)簡單接口時(shí)可以使用外觀模式。ü 客戶程序與多個(gè)子系統(tǒng)之間

48、存在很大的依賴性。ü 使用外觀模式定義系統(tǒng)中每一層的入口，層與層之間不直接產(chǎn)生聯(lián)系，而通過外觀類建立聯(lián)系，降低層之間的耦合度。l 代理模式(Proxy Pattern)Ø 定義：ü 給某一個(gè)對(duì)象提供一個(gè)代理，并由代理對(duì)象控制對(duì)原對(duì)象的引用。ü Provide a surrogate or placeholder for another object to control access to it.Ø 優(yōu)點(diǎn)：ü 協(xié)調(diào)調(diào)用者和被調(diào)用者。ü 遠(yuǎn)程代理使得客戶端可以訪問在遠(yuǎn)程機(jī)器上的對(duì)象。ü 虛擬代理通過使用一個(gè)小對(duì)象來代

49、表一個(gè)大對(duì)象，可以減少系統(tǒng)資源的消耗，對(duì)系統(tǒng)進(jìn)行優(yōu)化并提高運(yùn)行速度。ü 保護(hù)代理可以控制對(duì)真實(shí)對(duì)象的使用權(quán)限。Ø 缺點(diǎn)：ü 有些類型的代理模式可能會(huì)造成請(qǐng)求的處理速度變慢。ü 實(shí)現(xiàn)代理模式需要額外的工作，有些代理模式的實(shí)現(xiàn)非常復(fù)雜。Ø 適用范圍：ü 遠(yuǎn)程(Remote)代理。ü 虛擬(Virtual)代理。ü Copy-on-Write代理。ü 保護(hù)(Protect or Access)代理。ü 緩沖(Cache)代理。ü 防火墻(Firewall)代理。ü 同步化(Sync

50、hronization)代理。ü 智能引用(Smart Reference)代理。三、 行為型模式l 職責(zé)鏈模式(Chain of Responsibility Pattern)Ø 定義：避免請(qǐng)求發(fā)送者與接收者耦合在一起，讓多個(gè)對(duì)象都有可能接收請(qǐng)求，將這些對(duì)象連接成一條鏈，并且沿著這條鏈傳遞請(qǐng)求，直到有對(duì)象處理它為止。Avoid coupling the sender of a request to its receiver by giving more than one object a chance to handle the request. Chain the re

51、ceiving objects and pass the request along the chain until an object handles it.Ø 優(yōu)點(diǎn)：ü 降低耦合度。ü 可簡化對(duì)象的相互連接。ü 增強(qiáng)給對(duì)象指派職責(zé)的靈活性。ü 增加新的請(qǐng)求處理類很方便。Ø 缺點(diǎn)：ü 不能保證請(qǐng)求一定被接收。ü 系統(tǒng)性能將受到一定影響，而且在進(jìn)行代碼調(diào)試時(shí)不太方便；可能會(huì)造成循環(huán)調(diào)用。Ø 適用范圍：ü 有多個(gè)對(duì)象可以處理同一個(gè)請(qǐng)求，具體哪個(gè)對(duì)象處理該請(qǐng)求由運(yùn)行時(shí)刻自動(dòng)確定。ü 在不明確指定接收者的情況下，向多個(gè)對(duì)象中的一個(gè)提交一個(gè)請(qǐng)求。ü 可動(dòng)態(tài)指定一組對(duì)象處理請(qǐng)求。l 命令模式(Command Pattern)Ø 定義：ü 將一個(gè)請(qǐng)求封裝為一個(gè)對(duì)象，從而使我們可用不同的請(qǐng)求對(duì)客戶進(jìn)行參數(shù)化；對(duì)請(qǐng)求排隊(duì)或者記錄請(qǐng)求日志，以及支持可撤銷的操作。ü Encapsulate a request as an object, thereby letting you parameterize clients with different requests, queue or l