軟件設計與體系結構復習

軟件設計與體系結構復習

第一章：軟件工程與軟件設計

1.1軟件工程

1.1.1 軟件概述

1. 計算機軟件是與計算機系統操作有關的程序、規程、規則及任何與之有關的文檔及數據，計算機軟件=程序+數據+文檔
2. 軟件由兩部分組成：一是機器可執行的程序及有關數據；二是機器不可執行的，與軟件開發、運行、維護、使用、培訓有關的文檔。
3. 軟件是邏輯產品而不是物理產品
4. 軟件分為：系統軟件、實時軟件、嵌入式軟件、科學和工程計算軟件、事務處理軟件、人工智能軟件、個人計算機軟件

1.1.2 軟件危機

產生軟件危機的原因：

1. 用戶對軟件需求的描述不精確，可能存在遺漏、二義性、錯誤等。在軟件開發過程中，用戶甚至還提出修改軟件功能、界面、支撐環境等方面的要求，導致需求不斷變更。
2. 軟件開發人員對用戶需求的理解與用戶的期望有所差異，這種差異必然導致開發出來的軟件產品與用戶要求不一致。
3. 大型軟件項目需要組織一定的人力共同完成，但多數管理人員缺乏開發大型軟件系統的經驗，而多數軟件開發人員又缺乏管理方面額經驗。各類人員的信息交流不及時、不准確，有時還會產生誤解。
4. 軟件項目開發人員不能有效、獨立自主地處理大型軟件的全部關系和各個分支，因此容易產生疏漏和錯誤。
5. 缺乏有力的方法學和工具方面的支持，過分依靠程序設計人員在軟件開發過程中的技巧和創造性，加劇了軟件產品的個性化。
6. 軟件產品的特殊性和人類智力的局限性，導致人們無力處理“復雜問題”。一旦人們采用先進的組織形式、開發方法和工具提高了軟件的開發效率和能力，新的、更大且復雜的問題又出現在人們面前。

1.1.3 軟件工程的概念

1. 軟件工程的定義包括：
   1. 軟件工程是將系統的、規范的、可度量的方法應用於軟件的開發、運行和維護過程，以及對上述方法的研究
   2. 軟件工程是用工程、科學和數學的原則和方法，研制、維護計算機軟件的有關技術及管理方法
2. 一般認為，軟件工程由方法、工具和過程三個要素組成。

1.1.4 軟件工程的目標與原則

1. 軟件工程的目標是：在給定成本、進度的前提下，開發出具有可修改性、有效性、可靠性、可理解性、可維護性、可復用性、可適應性、可移植性和可追蹤性，並滿足用戶需求的軟件產品。
   1. 可修改性：可修改性是指允許對系統進行修改而不增加原系統的復雜性。
   2. 有效性：有效性是指軟件系統能最有效的利用計算機的時間資源和空間資源，一般將系統的時空開銷作為衡量軟件質量的一項重要技術指標。
   3. 可靠性：可靠性是指軟件在給定環境和時間下不發生故障的概率。
   4. 可理解性： 可理解性是指系統具有清晰的結構，能直接反應問題的需求。
   5. 可維護性： 可維護性是指軟件產品交付用戶使用后能夠方便地對它進行修改，已改正潛在的錯誤以及改進性能和其他屬性，是軟件產品適應環境的變化等。
   6. 可復用性：概念或功能相對獨立的一個或一組相關模塊定義為一個軟部件，軟部件可在多種場合應用的程度成為部件的可復用性。
   7. 可適應性：可適應性是指軟件在不同的系統約束條件下，使用戶需求得到滿足的難易程度。
   8. 可移植性：可移植性是指軟件沖一個計算機系統或環境移植到另一個計算機系統或環境的難易程度。
   9. 可追蹤性： 可追蹤性是指根據軟件需求對軟件設、程序進行正向追蹤，或根據程序、軟件設計對軟件需求進行一行追蹤的能力。
2. 軟件工程原則：抽象、信息隱藏、模塊化、局部化、一致性、完全性、可驗證性
   1. 抽象：抽象指抽取事務最基本的特性和行為，忽略非基本的細節。
   2. 信息隱藏：信息隱藏是將模塊中的軟件設計決策封裝起來的技術。
   3. 模塊化：模塊是程序中邏輯上相對獨立的成分，它是一個獨立的變成單位，應有良好的接口定義。模塊化有助於信息隱藏和抽象，有助於表示復雜的軟件系統。
   4. 局部化：局部化要求在一個物理模塊內集中邏輯上相互關聯的計算資源，從物理和邏輯兩個方面保證系統模塊之間具有松散的耦合關系，而在模塊內部有較強的內聚性，這樣有助於控制設計的復雜性。
   5. 一致性：一致性指整個軟件系統(包括文檔和程序)的各個模塊均應嚼規格說明與系統
      和術語;程序內部接口應保持一致;軟件與硬件接口應保持一致；系統機
      行為應保持一致;用於形式化規格說明的公理系統應保持一致等。
   6. 完全性: 完全性指軟件系統不丟失任何重要成分，達到完全實現系統所需功能的程度；當系統處於出錯或非預期狀態時，系統行為保持正常的能力。
   7. 可驗證性:開發大型軟件系統需要對系統逐步分解，系統分解應該遵僦案容易檢查、測試評審的原則，以便保證系統的正確性。

1.2軟件的生存周期

軟件產品從形成概念開始，經過開發、使用和維護，直到最后退役的全過程稱為軟件生存周期

1. 可行性研究
2. 需求分析：
   1. 需求分析的任務是確定待開發軟件的功能需求、性能需求和運行環境約束，編制軟件需求規格說明、軟件系統的確認測試准則和用戶手冊概要
   2. 軟件的功能需求應指明軟件必須完成的功能；軟件的性能需求包括軟件的安全性、可靠性、可維護性、精度、錯誤處理、適應性、用戶培訓等
   3. 軟件系統在運行環境方面的約束指待開發的軟件系統必須滿足的運行環境方面的需求。
   4. 軟件需求不僅是軟件開發的依據，也是軟件驗收的標准。
3. 概要設計
4. 詳細設計
5. 軟件構造
6. 單元測試
7. 集成測試
8. 確認測試
9. 使用與維護
10. 退役

1.3軟件開發過程模型

1.3.1 瀑布模型

1. 什么是瀑布模型

   它根據軟件生存周期各階段的任務從可行性研究開始，逐步進行階段性變換，直至通過確認測試並得到用戶確認的軟件產品為止

2. 優點

   1. 瀑布模型在軟件工程出現的早期占有重要的地位，它提供了軟件開發的基本框架。
   2. 有利於大型軟件開發過程中人員的組織、管理
   3. 有利於軟件開發方法和工具的研究與使用，從而提高了大型軟件項目開發的質量和效率

3. 缺點

   1. 瀑布模型在需求分析階段要求用戶和系統分析員必須指明軟件系統的全部需求才能開展后續階段的工作，因此難以適應大規模、復雜軟件系統的開發
   2. 需求確定后，用戶和軟件項目負責人要等相當長的時間才能得到一份軟件的最初版本。如果用戶對這個軟件提出比較大的修改意見，那么整個軟件項目將會蒙受巨大的人力、財力和時間方面的損失。

1.3.2快速原型模型

快速開發原型的途徑有三種

1. 利用個人計算機模擬軟件系統的人機界面和人機交互方式
2. 開發一個工作原型實現軟件系統的部分功能，而這部分功能是重要的，也可能是容易產生誤解的
3. 找來一個或幾個正在運行的類似軟件，利用這些軟件想用戶展示軟件需求中的部分或全部功能

1.3.3 螺旋模型

1. 由四部分組成： 需求定義、風險分析、工程實現和評審
2. 適用場合：

1.4 軟件設計

1.4.1 軟件設計的重要性

1. 軟件設計是對軟件需求的直接體現
2. 軟件設計為軟件實現提供直接依據
3. 軟件設計將綜合考慮軟件系統的各種約束條件並給出相應方案
4. 軟件設計的質量將決定最終軟件系統的質量
5. 及早發現軟件設計中存在的錯誤將極大減少軟件修復和維護所需的成本。

1.4.3 軟件設計的要素

1. 目標描述
2. 設計約束
3. 產品描述
4. 設計軟則
5. 開發規划
6. 使用描述

1.5 軟件體系結構

1.5.1軟件體系結構的定義

1. 軟件體系結構是軟件系統的結構，包括軟件元素、軟件元素外部可見的屬性以及這些軟件元素之間的關系
2. 軟件體系結構是軟件系統的基本組織，包含構件、構件之間、構建與環境之間的關系，以及相關的設計與演化原則

第二章 統一建模語言UML

2.1UML概述

2.1.2 UML 的特點和用途

UML 在表達能力、對新技術的包容能力和拓展性等方面有顯著優勢

1. 為使用者提供了統一的、表達能力強大的可視化建模語言，以描述應用問題的需求模型、設計模型和實現模型
2. 提供對核心概念的拓展機制，用戶可加入核心概念中沒有的概念和符號，可為特定應用領域提出具體的概念、符號表示和約束
3. 獨立於實現語言和方法學，但支持所有的方法學，覆蓋率面向對象分析和設計的相關概念和方法學
4. 獨立於任何開發過程，但支持軟件開發全過程
5. 提供對建模語言進行理解的形式化基礎，用元模型描述基本語義，OCL描述良定義規則，自然語言描述動態語義
6. 增強面對對象工具之間互操作性，便於不同系統間的集成
7. 支持較高抽象層次開發所需的各種概念，便於系統的重用

2.1.3 UML2.0的建模機制

1. 結構建模：
   1. 類圖： 描述系統的靜態邏輯結構，即構成系統的抽象元素以及元素間的關系
   2. 包圖：是一種特殊類型的類圖，描述類和接口如何進行邏輯上的划分，常用來描述軟件系統的體系結構
   3. 對象圖： 可以看作類圖的一個實例
   4. 構件圖： 描述了系統實現中的結構和依賴關系，可以用來表示軟件開發、編譯、鏈接、部署或執行時構件之間的關系
   5. 組合結構圖： 用於描述較為復雜的系統元素以及元素間的關系
   6. 部署圖： 描述系統硬件的物理拓撲結構以及在此結構上運行的構件
2. 行為建模：
   1. 活動圖： 描述行為或活動的流程，與傳統的流圖類似，但表達能力更強
   2. 順序圖：描述對象在其生存周期內的交互活動
   3. 通信圖： 描述特定行為中參與交互的對象及其連接關系
   4. 交互概覽圖： 活動圖的簡化版本，強調執行活動所涉及的元素
   5. 時序圖： 強調小的詳細時需說明，常用來對實時系統進行建模
   6. 狀態圖： 刻畫一個元素內部的狀態遷移，也常用來對嵌入式系統、協議規范及實現進行建模
   7. 用例圖： 通過用力來描述系統的功能性需求，從用戶的角度以一種與實現無關的方式刻畫系統將能作什么，還能描述用力之間的關系。

2.2 面向對象開發方法

2.2.1 基本概念

面向對象方法學包含以下核心概念

1. 對象：對象是現實世界中個體或事物的抽象表示，是其屬性和相關操作的封裝
2. 類： 類 是某些對象的共同特征的表示
3. 繼承： 類之間的繼承關系是現實世界中遺傳關系的直接模擬，它表示類之間的內在聯系以及對屬性和操作的共享
4. 聚集： 在劇集關系下，部分類的對象是整體類對象的一個組成部分
5. 多態： 多態指在弗雷繼器子類中，對外結構的定義形式相同，卻可以對應多種結構的實現形態
6. 消息： 消息傳遞是對象及其外部世界相互關聯的唯一途徑

2.2.2 面向對象方法的優勢

1. 簡化軟件開發過程
2. 支持軟件復用
3. 改善軟件結構

2.3UMl2.0結構建模

結構建模常常也被稱為靜態建模，主要用來描述系統中包含的元素以及元素之間的關系

2.3.1類圖

1. 類

   類用來描述具有相同特征、約束和語義的一類對象，這些對象具有共同的屬性和操作

2. 抽象類

   抽象類指一個類只提供操作名，而不對其進行實現

3. 接口

   接口用來聲明一些屬性或方法，但並不實現他們。接口能夠用來規定一種契約，對接口進行實現的元素必須遵循該契約

4. 依賴關系

   兩個類之間存在依賴關系，表明一個類使用或需要知道另一個類中包含的信息

5. 關聯關系

   兩個類之間存在關聯關系，表明這兩個類的實例之間存在語義上的聯系

6. 聚集關系

   聚集關系表明兩個類的實例之間存在一種擁有或屬於關系，可以看作一種較弱的整體-部分關系，或是一種邏輯上的隸屬關系。

7. 構成關系

   構成關系表明兩個類的實例之間存在一種包含關系，是一種比聚集關系更強的整體-部分關系

8. 泛化（繼承）關系

   泛化關系就是指兩個類之間存在繼承關系，即一個是父類，一個是子類

9. 實現關系

   實現關系表示一個元素是另一個元素的實現

10. 關聯類

    關聯類用來記錄與關聯有關的信息，提供與關聯有關的操作

2.3.2包圖

包用來對一組元素進行划分，是對復雜模型的一種分而治之的層次划分，因此也常常用來描述一個復雜系統邏輯上的子系統划分。包圖主要是由寶玉包之間的關系組成

1. 包
2. 依賴關系
3. 導入關系
4. 合並關系

2.3.3對象圖

對象是類的實例，對象圖可以看作類圖的實例，對象之間的連接是類之間關聯關系的實例。

2.3.4 構件圖

1. 構件

   構件是系統中一個具有良好封裝、可替換的模塊，一個簡單構建由帶有《component》構造型的方框表示

2. 接口

3. 裝配連接子

2.3.6部署圖

部署圖用來描述軟件開發過程中生成的物理文件形式的軟件或信息，運行平台的物理節點和通信，以及軟件文件到相應硬件節點的部署或映射。

部署圖很重要的一點就是描述制品怎樣在節點上部署，以及節點如何連接起來形成一個完整的系統

第三章 軟件設計基礎

3.1 軟件設計的基本概念

3.1.1 抽象與逐步求精

抽象是管理、控制復雜性的基本策略

逐步求精是一個與抽象密切相關的概念，可視為一種早期的自頂向下設計策略，主要思想是，針對某個功能的宏觀描述用逐步求精的方法不斷分解，逐步確定過程細節，直至該功能用程序語言描述的算法實現為止。

3.1.2 模塊化與信息隱藏

1. 模塊化： 把軟件划分為可獨立命名和訪問的部件，每個部件成為一個模塊，當把所有模塊組裝到一起時則獲得了滿足問題需要的一個解。
2. 信息隱藏： 采用信息隱藏原理指導模塊設計的好處十分明顯：不僅支持模塊的並行開發，而且還可以減少測試和后期維護的工作量

3.1.3內聚和耦合

1. 內聚

   內聚是信息隱藏和局部化概念的自然擴展，他標志一個模塊內部各成分彼此結合的緊密程度。

   1. 低等級內聚
      1. 偶然性內聚
      2. 邏輯內聚
      3. 時序內聚
   2. 中等級內聚
      1. 過程內聚
      2. 通信性內聚
   3. 高等級內聚
      1. 順序性內聚
      2. 功能性內聚

2. 耦合

   耦合是對軟件結構中模塊間關聯程度的一種度量。耦合的強弱取決於模塊間接口的復雜性、進入或調用模塊的位置以及通過接口傳送數據的多少等。

   1. 如果兩模塊中任意個都不依賴對方而能夠獨立工作，稱這兩模塊為非直接耦合，這類耦合的耦合度最低
   2. 如果兩模塊之間通過參數交換信息，而信息僅限於數據，則稱這兩模塊為數據耦合
      1. 特征耦合
      2. 外部耦合
      3. 公共耦合
   3. 最該耦合度為內容耦合： 出現內容耦合的情形包括
      1. 一個模塊使用另一個模塊內部的數據或控制信息
      2. 一個模塊直接轉移到另一個模塊內部等

3.2軟件設計過程

3.2.1軟件設計的一般過程

軟件設計可分為概要設計和詳細設計。

1. 概要設計是根據需求確定軟件和數據的總體框架
2. 詳細設計是將其進一步精化稱軟件的算法表示和數據結構
3. 在技術上，概要設計和詳細設計又由若干活動組成，主要包括軟件體系結構設計、界面設計、模塊、子系統設計、數據模型設計、過程、算法設計

3.2.2 軟件設計的主要活動

1. 軟件設計計划

   軟件設計計划的任務是，明確設計過程的輸入制品並使其處於就緒狀態，定義設計過程的目標，輸出制品及其驗收准則，確定覆蓋設計過程中各個階段的全局性設計策略，分配設計過程相關人員的職責，針對設計過程中的活動制定工作計划。

2. 體系結構設計

   對軟件結果進行評價時，常用的幾個概念

   1. 一個軟件的”深度“和”寬度“分別說明其控制的層數和跨度
   2. 一個模塊的”扇出率“指該模塊直接控制的其他模塊數，一個模塊的”扇入率“指能夠直接控制該模塊的模塊數

3.4 軟件體系結構設計

3.4.1 軟件體系結構設計方法概述

1. 軟件體系結構的多視圖建模（4+1建模）

   1. 邏輯視圖

      該視圖關注功能需求，即系統應該為最終用戶提供什么服務，它與應用領域緊密相關。

   2. 進程視圖

      該視圖捕獲設計中關於並發和同步的內容，重現一些非功能需求

   3. 開發視圖

      該視圖主要描述軟件在開發環境中的靜態結構，開發人員和項目經理對此都會感興趣

   4. 物理視圖

      該視圖描述軟件到硬件的映射關系，反映了軟件的分布特征

   5. 場景

      可以使用一組重要場景，也就是用力的實例，將四種視圖緊密聯系起來。場景通常是最重要的需求，一方面作為設計中發現體系結構元素的驅動器，另一方面在設計完成后，充當確認和驗證的依據

3.4.2軟件體系結構設計的步驟

1. 軟件體系結構設計過程中的數據為軟件需求規格說明和軟件設計計划，最終輸出為軟件體系結構設計文檔

3.5.7 嵌入式和實時軟件設計

1. 嵌入設軟件具有以下主要特征
   1. 嵌入設軟件一般用於單一任務
   2. 嵌入式軟件有多種類型的處理器體系結構支撐
   3. 嵌入式軟件的資源約束更加嚴格
   4. 嵌入式軟件的需要更高的可靠性和安全性
   5. 嵌入式軟件對反應性和實施性要求很高
   6. 嵌入式軟件通常固化存儲

第四章面向對象的軟件設計方法

4.1 基於UML的分析與設計過程

1. 頂層架構設計：

   頂層架構設計的主要目的是為后續的分析和設計活動建立一種結構和划分，一邊開發人員在不同的開發階段，以及同一開發階段的不同開發人員，能夠聚焦於系統的不同部分。

4.2 用例分析與設計

4.2.2 生成用例圖

參與者與用例之間的關系有兩種：觸發執行與信息交換

4.3 概念模型與頂層架構設計

4.3.1 概念模型設計

1. 關鍵概念的來源包括
   1. 業務需求描述、用例說明
   2. 業務領域中的相關規范、標准、術語定義
   3. 反映業務領域只是的既往經驗
2. 描述概念模型的UMl類圖主要由分析類組成。分析類是指直接服務於用戶功能性需求的概念層面的類，他們與待開發軟件系統的具體實現技術無關。三種分析類
   1. 邊界類：負責目標軟件系統與參與者之間的交互
   2. 控制類： 作為完成用例任務的責任承擔者，負責協調、控制其他類共同完成用例規定的功能或行為
   3. 實體類：是體力負責保存目標軟件系統中具有持久意義的信息項並向其他類提供讀、寫信息項內容的必要操作接口，一般不涉及業務邏輯處理

4.5數據模型設計

1. 持久數據模型設計主要包括以下幾個步驟
   1. 確定設計模型中需要持久保存的類的對象及其屬性，其中實體類是主要關注對象
   2. 確定持久存儲的數據之間的組織方式
   3. 確定數據模型中的操作行為
   4. 進一步優化持久數據操作的性能

4.8 部署模型設計

1. 部署圖對於復雜的分布式軟件系統尤其有用，因為最終軟件可能分為不同的子系統和制品形式，並部署在不同的物理節點中。此外，部署圖還可以用來描述對整個系統結構的一些特殊需求。

2. 部署模型設計一般需要考慮以下幾點

   1. 最終開發完成的軟件包括哪些制品形式
   2. 軟件運行環境存在哪些類型的物理節點
   3. 不同節點之間的連接和通信形式是什么
   4. 軟件制品應該如何在物理節點上進行部署，即它們的部署映射關系

第五章 面向數據流的軟件設計方案

5.1 數據流圖與數據字典

數據流圖就是用來刻畫數據流和轉換的信息系統建模技術

5.2實體關系圖

1. 數據對象、屬性與關系
   1. 命名性屬性： 對數據對象的實例命名，其中必含有一個或一組關鍵數據，以便唯一的標識數據對象的實例
   2. 描述性屬性： 對數據對象實例的性質進行描述
   3. 引用性屬性： 將自身與其他數據對象的實例關聯起來
2. 規范化規則
   1. 數據對象的任何實例對每個屬性必須有且僅有一個屬性值
   2. 屬性是原子數據項，不能包含內部數據結構
   3. 如果數據對象的關鍵屬性多於一個，那么其他的非關鍵屬性必須表示整個數據對象而不是部分關鍵屬性的特征
   4. 所有的非關鍵屬性必須表示整個對象而不是部分屬性的特征。

5.4 面向數據流的設計過程

5.4.1變換流與事務流

1. 面向數據流的方法能方便的將數據流圖轉換為軟件結構，其過程分為5步
   1. 確定信息流的類型
   2. 划定流界
   3. 將數據流圖映射為程序結構
   4. 提取層次控制結構
   5. 通過設計復審和使用啟發式策略進一步精化所得到的結構
2. 信息流一般可以分為變換流和事務流兩種類型
   1. 變換流： 在基本系統模型中信息通常以”外部世界“所具有的形式進入系統，經過處理后又以這種形式離開系統
   2. 事務流： 由於基本系統模型呈變換流，故任意系統中的信息均可用變換流描述。

5.5 啟發式設計策略

啟發式設計策略式人們從長期的大量軟件開發過程中集類總結的經驗

1. 改造程序結構、減小耦合度，提高內聚度
2. 改造程序結構，減少高扇出，在增加程序深度的前提下追求高扇入
3. 改造程序結構，使任一模塊作用域在其控制域之內
4. 改造程序結構，減少接口的復雜性和冗余程度，提高協調性
5. 模塊功能應該可語言，避免對模塊施加過多限制
6. 改造程序結構，追求單入口單出口的模塊
7. 為滿足設計或可移植性的要求，把某些軟件用包的形式封裝起來

第六章 用戶界面設計

6.1 界面設計的基本原則

1. 設計人員要考慮的重要因素
   1. 人只有有限的短暫記憶能力，通常人只能夠瞬時記憶七條左右信息
   2. 人都會犯錯，熱別實在必須處理大量信息或承受壓力的情況下，
   3. 人們都有不同程度的生理特征
   4. 人都有不同程度的交互和喜好
2. 設計原則
   1. 用戶熟悉程度：界面應該采用經常使用系統的用戶所熟悉的術語和概念
   2. 一致性： 界面必須一致，在任何可能的情況下，相同的操作應以同樣的方式被激活
   3. 使驚訝最小化：盡量避免是用戶對系統的行為感到驚訝
   4. 可恢復性：界面應該為用戶提供錯誤恢復機制
   5. 用戶幫助：界面應該錯誤發生時提供有意義的反饋，並且提供上下文敏感的用戶幫助系統
   6. 用戶多樣性：界面應該為不同類型的用戶提供恰當的交互方式

6.2 設計良好界面的主要途徑

• 使系統處於用戶控制之中
• 減少用戶的記憶負擔
• 保持界面的一致性

6.5.2界面設計需要考慮的問題

系統響應時間、用戶幫助、錯誤信息處理、命令標記、友好性、國際化

6.6 用戶界面原型

兩個階段

1. 早期必須構建出紙上的原型，包括屏幕設計的實體模型，然后和用戶進行商討
2. 之后可以開始對設計進行精化，並且開發逐漸復蘇的界面原型，然后把它們提供給用戶來進行測試和動作模擬

第七章 軟件體系結構風格與設計模式

7.1 基本概念

1. 軟件設計模式：在類和對象的層次描述的可重復使用的軟件設計問題解決方案
2. 軟件體系結構風格： 是軟件體系結構設計上的模式，可以看作一種廣義的軟件設計模式，但一般不認為是狹義的軟件設計模式。
3. 兩者的區別：
   1. 軟件體系結構風格描述系統整體結構框架上的特點，粒度更大
   2. 軟件設計模式則更加面向具體問題，指出的是一個在更小的粒度上的設計特點

7.3軟件體系結構風格

1. 3種常用的體系結構
   1. 管道/過濾器風格
   2. 層次風格
   3. 客戶/服務器風格
2. 如何刨析
   1. 核心特征
   2. 應用場合
   3. 注意問題

7.4 設計模式

具有代表性的7個設計模式

1. 創造型設計模式
   1. Factory Method
   2. Abstract Factory
   3. Singleton
2. 結構型設計模式
   1. Composite
   2. Proxy
3. 行為型設計模式
   1. Iterator
   2. Observer

對於每個設計模式，從模式的動機和實例、適用場合、結構以及核心思想四個方面進行介紹

第八章 基於分布構件的體系結構

8.1 EJB分布構件框架

8.1.1 EJB簡介

1. EJB分布構件框架由SUN公司主導指定，基於Java語言，面向企業界的分布式系統開發。

2. 3種分布構件

   1. 繪畫Bean(Session Bean)
   2. 消息驅動Bean（Message-Driven Bean）
   3. 實體Bean（Entity Bean）

3. EJB構件容器提供了EJB構件生存的環境，控制了EJB構件的生存周期，並提供了許多企業級應用所需的中間件服務，如事務服務、持久化服務和安全服務等

4. EJB3.0標准規定了EJB構件容器和EJB構件之間的契約關系，對EJB構件容器和EJB構件的開發都做了約束。因此，原則上符合EJB標准的EJB構件就能夠在所有符合EJB標准的應用服務器上運行

8.2.DCOM分布構件框架

DCOM 分布構件對象模型是一個二進制代碼層面的構建模型。

1. DCOM客戶

   泛指所有與DCOM構件交互的程序片段

小結

構件框架使用的難易程度

1. EJB最簡單
2. CORBA次之
3. DCOM難

第九章 軟件體系結構評估

軟件體系結構是一個軟件系統的基礎，他影響到系統的很多質量屬性,如可變性、性能、安全性、可用性、可靠性等

9.1 軟件體系結構評估概述

軟件體系結構是早期設計階段的產物，它對系統和項目的影響比較深遠。如果軟件體系結構不合適，將可能導致軟件項目的災難，系統的性能目標也得不到滿足。此外，客戶將由於正當功能的不可用而變得不愛飯，但如果要修改系統來添加或修復這項功能也會很困難

9.1.1 評估時機和參與人員

1. 早評估

   早評估對已做出和正在考慮的軟件體系結構決策都使用。它不需要完整的軟件體系結構描述，可以在軟件體系結構創建過程中的任何階段使用評估方法，對已做出的軟件體系結構決策進行檢查，或者確定還沒有決定的軟件體系結構選項。

2. 遲評估

   遲評估的時間是軟件體系結構已明確並且實現已完成的時候，這種情況在某個組織繼承某些遺留系統時發生，這些遺留系統可能是在市場中購買的，也可能是從本組織現有的存檔中發掘的。

9.2 軟件體系結構評估方法

1. 軟件體系結構這種分析方法（Architecture Tradeoff Analysis Method, ATAM）
2. 軟件體系結構分析方法（Software Architecture Analysis Method, SAAM）
3. 中間設計的積極評審（Active Reviews for Intermediate Designs,ARID）

9.2.1 ATAM方法

1. ATAM方法能夠反映出一個軟件體系結構滿足某些特定質量目標的程度，同時還能給出這些質量目標之間的交互方式，即它們之間的這種方案。在遺留系統需要進行大的改動、與其他系統繼承或者重大升級時，也可以用ATAM方法對一六系統進行分析
2. 主要步驟
   1. 介紹ATAM方法
   2. 商業動機的介紹
   3. 軟件體系結構介紹
   4. 確定軟件體系結構方案
   5. 產生質量屬性效果樹
   6. 分析軟件體系結構方案
   7. 集中討論並確定場景的優先級
   8. 進一步分析軟件體系結構方案
   9. 展示結果

9.2.2 SAAM方法

1. SAAM方法基於以下觀察： 實踐人員會定期對他們的軟件體系結構有所聲明，如這個系統比之前的版本更加健壯、使用CORBA將會是系統更易於修改和升級、MVC模式能夠保證整個軟件體系結構的可維護性等等
2. 主要步驟：
   1. 場景的形成
   2. 描述軟件體系結構
   3. 場景的分類和優先級划分
   4. 間接場景的單獨評論
   5. 評估場景交互
   6. 形成總體評價

第十章 軟件設計的進化

10.2.1 進化策略的分類

1. 完全放棄該軟件

   當遺留軟件對於用胡德業務過程起不到任何貢獻時，可采用

2. 不改變該軟件系統並繼續進行常規的維護

   當軟件系統依然是需要的，並且運行相當穩定，系統使用者只有相對較少的變更需要時，可采用

3. 對軟件系統實時再工程以提高可維護性

   當系統由於經常的變更而質量下降，並且依然需要對系統進行經常變更時，可采用

4. 用新系統替換遺留軟件系統的全部或其中一部分

   當某些其他因素出現時，例如使用信息硬件是的已有軟件系統無法繼續運行，或存在第三方軟件系統使得可以在合理成本的基礎上開發新系統時，可采用

10.3軟件再工程

優點

1. 減少風險： 對關鍵軟件完全進行重新開發具有很高的風險

2. 減少成本： 根據以往的實踐經驗和統計，再工程的成本要明顯比開發一個全新的軟件低。