圖片來自湖南大學《軟件工程導論》課程 PPT

一、軟件工程概述

1 軟件和硬件的不同

• 硬件
  • 人工制造
  • 易磨損（硬件磨損后可以使用備件替換）
  • 使用標準化組件制造
  • 相對簡單
  • 制造出來后一般不改變
• 軟件
  • 開發出來的
  • 易退化（需求的不斷變更是軟件退化的根本原因）
  • 自定義組件
  • 較為復雜
  • 開發出來結果后可能會經常改變

2 軟件的概念

• 軟件 = 程序 + 數據 + 文檔
  • 程序：按事先設計的功能和性能需求執行的指令序列
  • 數據：程序能正常操縱信息的數據結構
  • 文檔：與程序開發、維護和使用有關的圖文材料

3 軟件的本質

具有產品和產品交付載體的雙重作用

• 作為產品，顯示了由計算機硬件體現的計算能力，扮演信息轉換的角色
• 作為產品生產的載體，提供了操作系統、網絡、軟件工具和環境等的基礎平臺

4 軟件的特點

無磨損：抽象不可觸摸，潛能不受物理因素的限制（但存在退化）

（磨損是什么？）

可用失效率來衡量

軟件抽象不可觸摸，不受物理因素的限制——軟件不會磨損，但是存在軟件退化現象

磨損說明了軟硬件的不同 軟件的缺陷暗示了設計的缺陷或將設計轉化為代碼過 程中產生的錯誤，軟件維護通常要面對變更請求，比硬件維護更復雜

變更：由于易修改，很容易變得極為復雜

5 軟件發展的階段歷程

5.1 第一階段：程序設計階段

• 時間：計算機誕生后
• 特點：程序設計
• 代表產品：Micrsoft basic、unix、wps1.0
• 軟件工作：代碼編寫
• 軟件評估：程序設計=數據結構+算法，編程技巧

5.2 第二階段：軟件工程階段

• 時間： 大容量、高速度計算機和高級語言出現、操作系統發展、數據庫管理系統誕生；
• 特點：軟件危機，主要表現在軟件開發進度失控， 費用失控可靠性差， 軟件難以維護
  • 代表產品：OS 360、美國火箭爆炸、Therac-25腫瘤放射線治療儀
  • 軟件工作：軟件工程系統的、規范的、定量的工程化方法應用于軟件
  • 軟件評估：可讀性、可理解性、可測試性和易修改性等軟件質量

5.3 第三階段：軟件過程階段

• 時間：互聯網廣泛應用后
• 特點：市場變幻莫測、需求日趨復雜、技術日新月異
• 軟件工作：流程活動+流程活動各要素 (如人員、方法、產品等)
• 軟件評估：多目標函數（軟件質量，開發效率，開發成本）

6 軟件神話

軟件神話就是謬論：

• 如果進度落后，那么增加多的程序員人手則可以趕上進度
• 對目標一般的稱述就足以開始構建項目
• 可以容忍項目需求的變化，因為軟件是靈活多變的
• 一旦我們編寫了一個工作程序，我們就完成任務了
• 直到程序運行，才能評估質量
• 對于一個成功的項目來說，唯一可交付的工作產品就是程序
• 軟件工程會讓我們寫太多文檔，并且減緩我們的開發速度

7 軟件工程的概念

• 將系統化的、規范的、可量化的方法應用于軟件的開發、運行和維護，即將工程化方法應用于軟件
• 以及上述方法的研究

7.1 軟件工程方法

為構建軟件提供技術上的解決方法

7.2 軟件工程工具

為過程和方法提供自動化或半自動化的支持

7.3 軟件工程的實踐

概念、原則、方法和開發工具的集合。

8 軟件過程

8.1 定義

軟件過程是從軟件項目需求定義開始，直至軟件經使用后廢棄為止的，跨越軟件整個生存期內的系統開發、運行和維護等全部活動、動作和任務及相關項的總和。

8.2 內容

5個主要過程、8個支持過程和4個組織過程

• 5個主要過程為：獲取過程、供應過程、開發過程、運行過程、維護過程。
• 8個支持過程為：文檔編制過程、配置管理過程、質量保證過程、驗證過程、確認過程、聯合評審過程、審核過程、問題解決過程。
• 4個組織過程為：管理過程、基礎設施過程、改進過程、培訓過程。

9 軟件過程模型

參考資料：https://www.cnblogs.com/jojop/p/11801241.html

9.1 定義

軟件過程模型是軟件過程中全部活動生命周期結構框架的一種形式化描述，也稱為軟件生命周期模型或軟件生存期模型。

9.2 經典軟件過程模型

9.2.1 瀑布模型——慣例過程模型的一種，又叫作生命周期模型

• 概念
  • 將軟件生命周期分為計劃、分析、設計、編碼、測試、運行/維護六個階段
  • 軟件開發要遵循過程規律，按次序進行
  • 每個階段均有里程碑和提交物
  • 工作==以線性方式==進行，上一階段的輸出是下一階段的輸入
• 特征
  • 瀑布狀：自上而下，相互銜接
  • 各階段及其活動 ：多種模型的基本細粒度元素
• 優點
  • 簡單、易懂、易用
  • 為項目提供了按階段劃分的檢查點，項目管理比較規范
  • 每個階段必須提供文檔，而且要求每個階段的所有產品必須進行正式、嚴格的技術審查
• 缺點
  • 實際的項目很少遵守瀑布模型提出的順序。
  • 客戶通常難以清楚地描述所有的需求。
  • 不支持需求變更
  • 由于早期的錯誤可能要等到開發后期的測試階段才能發現，所以帶來嚴重的后果。
  • 到最后部署才知道產品樣子，返工成本巨大
• 適用場合
  • 需求相當明確、且較穩定
  • 開發團隊對這一領域熟悉
  • 外部不可控因素少
  • 小型的清晰項目或長周期的項目

9.2.1.1 V模型

和瀑布模型順序一樣，但是每個階段都有測試，盡早發現錯誤

9.2.2 增量模型——慣例過程模型的一種

• 概念
  • 軟件被作為一系列的增量來進行開發，每一個增量都提交一個可以操作的產品
  • 第一個增量往往是核心產品：滿足了基本的需求，但是缺少附加的特性
  • 客戶使用上一個增量的提交物并進行自己評價，制定下一個增量計劃，說明需要增加的特性和功能
  • 重復上述過程，直到最終產品產生為止
• 優點
  • 提高對用戶需求的響應：用戶看到可操作的早期版本后會提出一些建議和需求，可以在后續增量中調整。
  • 人員分配靈活：如果找不到足夠的開發人員，可采用增量模型，早期的增量由少量人員實現，如果客戶反響較好，則在下一個增量中投入更多的人力
  • 可規避技術風險：不確定的功能放在后面開發。
• 缺點
  • 加新增量的時候必須不破壞原有已構造好的東西
  • 仍然無法處理需求發生變更的情況
  • 管理人員須有足夠的技術能力來協調好各增量之間的關系
• 適用
  • 以迭代的方式運用瀑布模型，人手不夠
  • 需求被很好理解，項目的邊界固定，可以在短時間內創建全功能系統

9.2.3 演化過程模型

• 演化模型是迭代的過程模型，使得軟件工程師能夠逐步開發出更完整的軟件版本

• 迭代的思想：對一系列活動的重復應用，用以評估一系列論斷，解決一系列風險，達成一系列開發目標，并逐步增量地建立并完善一個有效的解決方案

• 常見的演化過程模型：原型開發、螺旋模型等

9.2.3.1 原型模型——慣例過程模型 中 演化過程模型 的一種（需求仍不明確）

• 內容
  • 第一步：原型 弄清需求并探索可行性
  • 第二步：開發產品
• 優點
  • 快速開發出可以演示的系統，方便了客戶溝通。
  • 采用迭代技術能夠使開發者逐步弄清客戶的需求。
• 缺點
  • 為了盡快完成原型，開發者沒有考慮整體軟件的質量和長期的可維護性，系統結構通常較差
  • 用戶可能混淆原型系統和最終系統，原型系統在完全滿足用戶需求之后可能會被直接交付給客戶使用。
• 特征及適用范圍：減少了需求不明確帶來的風險
• 適用場景
  • （需求不明確）客戶提出了軟件的一些基本功能，但是沒有詳細定義輸入、處理和輸出需求
  • 另一種情況下，開發人員可能對算法的效率、操作系統的兼容性和人機交互的形式等情況不確定

9.2.3.2 螺旋模型——慣例過程模型 中 演化過程模型 的一種（風險分析）

• 特征
  • 加入了風險分析（與原型模型最主要的區別）
  • 迭代演化：識別每個演化層的風險
  • 自上而下
• 優點
  • 結合了原型的迭代性質與瀑布模型的系統性和可控性，是一種風險驅動型的過程模型。
  • 采用循環的方式逐步加深系統定義和實現的深度，同時更好地理解、應對和降低風險。
  • 確定一系列里程碑，確保各方都得到可行的系統解決方案。
    始終保持可操作性，直到軟件生命周期的結束。由風險驅動，支持現有軟件的復用。
• 缺點
  • 螺旋模型依賴大量的風險評估專家來保證成功。如果有較大的風險沒有被發現和管理，肯定會發生問題。
  • 軟件開發人員應該擅長尋找可能的風險，準確的分析風險，否則將會帶來更大的風險
• 適用場景
  • 需求不太穩定
  • 大型軟件開發
  • 內部軟件開發

9.2.4 噴泉模型——面向對象模型的一種

噴泉模型是專門針對面向對象軟件開發方法而提出的。“噴泉”一詞用于形象地表達面向對象軟件開發過程中的迭代和無縫過渡。

• 特征
  • 噴泉狀：自底向上
  • 迭代演化
  • 無縫銜接，復用，并行與集成
• 適用范圍
  • 需求較不穩定

9.2.5 專用過程模型

9.2.5.1 基于構件的開發

能夠使軟件復用，為軟件工程師帶來極大收益

9.2.5.2 形式化方法模型

• 優點

  • 軟件工程師可以應用嚴格的數學符號來說明、開發和驗證基于計算機的系統
  • 提供了一種機制，使得在軟件開發中可以避免一些問題，如歧義性問題、不完整問題、不一致問題等

• 缺點

  • 開發非常耗時，成本也很高。
  • 只有極少數程序員具有應用形式化方法的背景，因此需要大量的培訓
  • 對于技術水平不高的客戶，很難用這種模型進行溝通。

• 適用場景

  • 用來開發高度關注安全的軟件。
  • 開發軟件出錯將導致重大經濟損失的軟件。

10 軟件工程師道德規范

公眾、客戶和雇主、產品、判斷、管理、專業、同僚、自身

二、軟件需求綜述

1 軟件項目成功的三個主要因素

• 需求的清晰表述
• 用戶的參與
• 主管層的支持

2 軟件人成功的三個主要因素

• 需求的把握與控制能力
• 良好的溝通能力
• 責任心與承擔責任的能力

3 軟件工程和需求工程區別與聯系

• 軟件需求工程屬于軟件工程的大范疇，是軟件工程的一個分支，其主要對象是軟件需求。
• 軟件工程是求解軟件的工程，需求工程是求解軟件需求的工程。
• 將軟件工程的原理、方法、技術、手段與軟件需求的實際緊密結合，并創造性的應用于軟件需求領域。
• 除此之外，還要根據軟件需求的特點來發展需求工程的理論、方法、技術和工具。

4 需求的定義和意義

• 什么樣的陳述可以作為需求？

  必要的、無歧義的、可測的、可跟蹤的、可測量的

• 什么是需求？

  需求就是以一種清晰、簡潔、一致且無二義性的方式， 對一個待開發軟件系統中各個有意義功能和性能等方面的陳述的一個集合。

  需求是對應當執行的任務的規范說明，描述系統的行為特性或屬性，是一種對系統開發進程的約束。

• 意義

  需求是軟件項目和產品的根源，是后續設計、實現、測試、維護等所有活動的依據；需求工作的優劣對產品影響最大。

5 軟件需求的三個層次

業務需求

• 描述用戶組織對系統、產品==高層次的業務目標要求==；

  通過項目遠景與范圍文檔予以說明

  • 項目前景(遠景)：遠景目標
  • 項目范圍：近期目標，如版本v1.0、v1.2、v2.0

用戶需求

• 站在==用戶角度==描述的產品的功能和性能的概要

  通過實例（ use-case ）文檔予以說明

系統需求

• 站在==軟件開發和測試人員角度==的產品應當做什么的詳細描述；即系統需求是用戶需求的詳細版本，并且實現用戶世界到軟件世界的轉換，是系統軟件設計的起點。

  通過系統需求規格說明予以說明

6 軟件需求的分類

• 功能性需求，是整個需求的主體，沒有它就沒有非功能需求

  描述系統應該做什么，即為用戶和其他系統完成的功能、提供的服務，規約了系統或系統構件必須執行的功能；

  關鍵詞：系統應…、系統能夠…

• 非功能性需求

  • 業務規則（屬于業務需求）：公司政策，政府法規，應遵從的標準與規范
  • 性能需求：規約了一個系統必須具有的性能特性
  • 外部接口：包括系統、用戶、硬件、軟件接口，規定了必須與之交互的硬件、軟件、數據庫等
  • 設計約束：限制編程語言，界面，系統或系統構件的設計方案
  • 質量屬性（屬于用戶需求）：可靠性，可維護性，可移植性，安全性，用戶友好性

  關鍵詞：網絡安全法及相關管理條例、網絡應用軟件的用戶行為記錄的日志、性能、外部接口

7 需求工程的內容和過程

定義：所有與需求直接相關的活動。

7.1 需求開發

• 需求描述：編寫SRS
• 需求驗證：產生經過驗證的SRS

7.2 需求管理

以 SRS 為基線，對需求變更進行控制和管理

7.3 需求工程過程：螺旋迭代過程

8 需求工程方法

需求獲取的方法(11個)

• 定義需求的開發過程
  確定需求的收集、分析、細化和核實的步驟、方法、模板。
• 定義項目前景與范圍
  前景說明所有涉眾對產品目標的達成的共識；
  范圍定義了需求是否屬于某個特定版本的界線。
• 確定用戶群
  將可能使用產品的用戶組，以避免出現某一用戶群的需求被忽略的情況。
• 選擇用戶代表
  為每類用戶至少選擇一位能代表他們需求的、有時間、有熱情、有權利參與需求工作的用戶代表。
• 建立核心隊伍
  把同類產品或產品前版本的用戶代表召集起來，從他們那里收集目前產品的功能需求和非功能需求。
• 確定用例
  從用戶代表處收集他們使用軟件完成所需任務的描述——用例，討論用戶與系統間的交互方式和對話要求。
• 確定系統事件和響應
  列出系統可能發生的外部事件以及對每個事件所期待的響應時間。
• 舉行進一步需求獲取的討論
  專門的需求獲取討論會可以方便分析員和客戶進行合作。
• 觀察用戶如何工作
  觀察用戶執行業務的過程。畫一張簡單的數據流程圖或業務流程圖，描繪出用戶什么時候獲得什么數據，并怎樣使用這些數據進行業務處理。
• 檢查問題報告
  客戶對當前系統的問題報告及補充需求為新產品或新版本提供了大量豐富的改進及增加特性的想法。
• 需求重用
  如果客戶要求的功能與已有的某產品很相似，則可查看需求是否有足夠的靈活性以允許重用一些已有的軟件組件。

需求分析的方法(8個)

• 編制關聯圖
  定義系統與外部實體的界限和接口
• 創建開發原型
  當開發人員或用戶不能確定需求時，可構建一個開發原型。它可使許多概念和可能發生的事更為直觀明了。通過評價原型，能更好地相互理解所要解決的問題
• 分析需求的可行性
  在允許的成本、性能要求下，分析每項需求實施的可行性，明確與每項需求實現相聯系的風險，包括與其它需求的沖突、對外界因素的依賴和技術障礙。
• 確定需求優先級
  應用分析方法來確定use-case、產品特性或單項需求實現的優先級別。以優先級為基礎確定產品版本應包含的需求和特性。
• 為需求建立模型
  需求的圖形分析模型是SRS的極好補充說明。這樣的模型包括用例圖、數據流程圖、實體關系圖、狀態變換圖、對話框圖、對象類及交互作用圖等。
• 編寫數據字典
  通過建立數據字典，對系統用到的所有數據項和數據結構進行定義。
• 將需求分解到子系統
  必須將包括多個子系統的復雜產品的需求分配到各個軟件、硬件以及人員子系統和部件中去。
• 應用質量功能調配（QFD）
  質量功能調配（QFD）是一種高級系統技術，它將產品功能、屬性與對客戶的重要性聯系起來。QFD將需求分為三類：普通需求、期望需求、興奮需求。

需求描述方法（SRS）、需求驗證方法、獲取知識技能方法、需求管理方法、項目管理方法（略）

方法的使用原則

• 從低到高，先易再難的使用原則
• 方法有效性判定原則

三、需求獲取與分析

需求獲取與分析是需求工程中最關鍵、也是最困難的活動

1 需求獲取與分析面臨的挑戰

• 需求的模糊性：說不清→誘導性訪談，如原型
• 需求的隱蔽性：需求是表象，隱藏在話里或不愿說，自己都不知道→深入型觀察和挖掘
• 需求的多樣性：每個用戶只自己如何使用系統，但沒有任何人知道系統整體運行情況 → user cases → 統一user cases
• 需求的變化性：隨著項目進展開發人員與客戶對系統理解的變化；商務與技術環境的變化→過程迭代-敏捷

2 需求獲取與分析的過程

3 獲取需求的手段（各種方法有什么區別）

3.1 訪談

• 挑戰：需求的模糊性

• 特別關注意料之外的需求，需求建議誘導，關鍵點：誘導型訪談

• 基于快速原型的 “需求訪談”

  • 原型 - 需求建議誘導的有效形式之一

    1 概念

    • 原型是一種技術，可用它減少客戶對產品不滿意的風險。
    • 原型可以使新產品實在化，為使用實例帶來生機，并消除人們在需求理解上的差異
    • 采用原型方法是得到客戶真實意圖和寶貴信息的最有效方式

    2 三個目的

    • 明確并完善需求
    • 探索設計選擇方案
    • 發展為最終的產品原型

    3 開發步驟

    • 快速分析：在分析人員與用戶密切配合下，迅速確定系統的基本需求
    • 構造原型：在快速分析的基礎上，根據基本需求說明盡快實現一個可行的系統，并忽略最終系統在某些細節上的要求，主要考慮原型系統能夠充分反映所要評價的特性
    • 運行原型：這是發現問題、消除誤解、開發者與用戶充分協調的一個步驟
    • 評價原型：在運行基礎上考核評價原型的特性，是否滿足用戶的愿望，糾正過去交互中的誤解與分析中的錯誤，增添新的要求
    • 修改(回到開始)：若原型未滿足需求說明的要求，說明對需求說明存在不一致的理解或實現方案不夠合理，則根據明確的要求迅速修改原型

    4 分類

    • 快速原型（拋棄型）
    • 目的是為解決不可測性,并提高需求質量；
    • 通過花最小的代價，采用忽略很多具體的軟件構造技術、快速地建立原型，并在原型達到預期目的以后選擇拋棄或者進化。
    • 當遇到需求中的含糊性、不確定性、二義性、不完整性時，可以考慮建立拋棄式模型。
    • 快速原型能夠幫助用戶和開發者想象如何實現需求并發現需求中的漏洞；還可以使用戶判斷出這些需求是否可以完成必要的業務過程。
    • 進化原型（漸近型）
    • 一個進化型原型必須重視軟件系統性和完整性的設計原則，它必須易于升級和優化。
    • 從測試和使用中獲得的信息將引起下一次軟件原型的更新。
    • 原型的不斷增長和更新，使軟件從一系列進化型原型發展為最終的產品。
    • 進化型原型比建立拋棄型原型所花的時間和代價要多得多。

3.2 觀察與挖掘

• 挑戰：需求的隱蔽性
• 形式：現場觀察，例如：與用戶一起工作(敏捷開發)；挖掘用戶的意圖和目標收益
• 案例：扎根蘑菇群；挖掘用戶意圖（弄匹馬）

3.3 User Case

• 挑戰：需求的多樣性

• 從每個用戶 Case 或 Story 進行各項需求評判

• 基于用例 (User Case) 的需求獲取與分析過程

  • User分類，確定沒類用戶的用戶代表

  • Case/Story構建：基于前述訪談或觀察挖掘結果，為每一類 User 構建 Case 或 Story，

  • 匯總所有 User Case 或 User Story

  • 多個 User Case 協商確定和優先級排序

    需求強度 = 潛在用戶數 + 使用頻率（需求的存續期 = 軟件壽命）

四、需求規格說明

1 軟件需求規格說明

• SRS (Software Requirement Specification ) 也稱為功能規格說明、產品規格說明、需求文檔或 系統規格說明
• 有三個層次的 SRS
• 作用：記錄共識、確認共識、完整正確地傳遞共識給開發人員
• 要求： 完整性 一致性 可閱讀性 無二義性 可修改性 可跟蹤性 可維護性
• 一般性方法： 套用模板法，最好是根據組織和個人的經驗和項目情況， 對模板進行修改，采用應用模板、適用為主； 優化模板、實用為本的原則編寫文檔。
  • 滿足 SRS 的一般性要求
  • 描述語言包括自然語言、結構化的自然語言（例如標準化的表格模板）、圖形化的建模語言（如 UML，見本章課程后續第三部分）

2 用戶需求規格說明的撰寫

• 用例（User Case）的構成：要求小型化、獨立化

  ? 名稱

  ? User (用戶)

  ? Case（事件/場景）： 描述

  • User 與系統的交互 ，系統給反饋
  • 通過交互，系統為用戶提供的功能/價值
  • 提供的功能/價值不涉及內部具體實現

  ? 每個用例給優先級

• 用戶界面

  用戶界面的設計編入系統 SRS 中既有好處也有壞處

  • 好處：有助于精化需求并使用戶對系統有親和感和現實感，有助于用戶需求的表述和交流。
  • 壞處：屏幕圖像和用戶界面構架是系統設計，而不是用戶需求，所以對它的關注可能使需求走入歧途。也限制了開發人員的發揮。
  • 合理的權衡點：在系統SRS中加入用戶界面組件的概念草圖，而在設計和實現時并不一定要精確地遵循 這些草圖模型。

• 需求的標識

  為了保證 SRS 的可跟蹤性和可修改性的質量標準， 必須唯一標識每個軟件需求。

  序列號、層次型編碼、層次型文本標簽

• 處理不確定的需求

  在實現一個需求集之前，必須解決所有 TBD (to be determined) 問題。

3 需求分析建模與統一建模語言UML

• 分析建模方法：1.結構化分析；2.面向對象分析

3.1 結構化分析方法

• 結構化分析（又稱面向過程的分析）是面向數據流進行分析的方法

• 適合于數據處理類型軟件

• 具體來說，結構化分析方法就是用抽象模型的概 念，按照軟件內部數據傳遞、變換的關系，自頂向下逐層分解，直到找到滿足功能要求的所有可實現的軟件為止。

• 結構化方法的分析建?？傆[

  • 數據模型：實體-關系圖 E-R 圖
  • 功能模型：數據流圖 DFD
    • 頂層流圖：僅包含一個加工，它代表被開發系統。
    • 中間層流圖：對其上層父圖的細化。
    • 底層流圖：其加工不需再做分解
  • 行為模型：狀態變遷圖 STD

3.2 面向對象

• 面向對象的本質特征
  • 抽象
    將一類對象的共同特征總結出來構造類的過程，包括數據抽象和行為抽象兩方面
  • 封裝
    把數據和操作數據的方法綁定起來，對數據的訪問只能通過已定義的接口
  • 繼承
    從已有類得到繼承信息創建新類，子類繼承父類屬性和方法
  • 多態
    包括重載和重寫，允許相同或不同子類型的對象對同一消息作出不同響應
• 幾種著名的面向對象的方法
  • Booch，Coad 一 Yourdon，Rumbaugh，Jacobson
• 統一建模語言UML
  • UML 是軟件界第一個統一的建模語言，該方法結 合了 Booch, OMT 和 OOSE 方法的優點，統一了符號 體系，并從其它的方法和工程實踐中吸收了許多經 過實際檢驗的概念和技術。
  • UML 一種面向對象的可視化的通用建模語言，由 圖和元模型組成。圖是 UML 的語法，而元模型給 出圖的含義，是 UML 的語義
  • 一個模型、多個視圖
  • 這些圖提供了對系統進行分析、設計、開發不同 階段多角度描述。
• 面向對象方法的分析建模總覽
  • 數據模型：類圖 CD
  • 功能模型：用例圖 UCD
  • 行為模型：活動圖、狀態圖、順序圖

3.3 用例圖

• 命名格式：動（賓）結構，執行者視角（用戶觀點而非系統觀點）

• 命名用詞：避免弱動詞、弱名詞

• 用例選擇：選取有意義的目標，如“設置查詢條件”就是無意義的

• 用例間的關系

  • 關聯關系：參與者與用例之間的通信
  • 泛化關系：可以是用戶之間的職責共享，也可以是用例之間的場景共享

  • 依賴關系

    • 包含關系：把一個較復雜的用例所表示的功能分解成較小的步驟，一個用例包含另一個用例

      在執行基本用例時，一定會執行包含用例部分

    • 擴展關系：用例功能的延伸，相當于為基礎用例提供一個附加功能，插入基礎用例不能說明的擴展部分

      一個基本用例執行時，可以執行、也可以不執行擴展

五、需求驗證與變更

5.1 需求驗證的任務

很重要的一步，如果不進行在后序發現是需求錯誤的話，會導致成倍的代價。

驗證需求文檔，發現錯誤并修改，需要檢查：

• 有效性檢查：檢查不同用戶使用功能的有效性
• 一致性檢查：需求之間不應該沖突
• 完備性檢查：包括所有用戶想要的功能和約束
• 現實性檢查：能夠用現有技術實現

5.2 需求驗證的方法（5種）

• 需求評審
  • 正式與非正式（審查），風險分析模型
• 原型法
  • 首先，**確定合適原型(**見“需求獲取與分析”章節)， 準備需求驗證。
  • 將需求驗證涉及的業務過程或場景定義出來， 以輔助需求驗證過程的開展。
  • 根據已定義過程和場景，按照原型執行過程， 發現需求的缺陷、問題并記錄，以待后續修正。
• 編寫測試用例
  • 在需求開發階段不可能真正進行任何測試，因為還沒有可執行的軟件，然而可以以需求文檔為基礎編寫測試用例
• 編寫用戶手冊
  • 系統的運行環境，硬件要求，環境配置
  • 系統功能的詳細操作過程
  • 問題和故障的解決辦法
• 自動的一致性分析（如CASE工具）
  • 些自動化工具能部分支持需求定義內在的一致性和完備性檢查

需求定義是否準確地反映用戶需求的驗證 在目前還主要依賴于需求評審和原型示范等技術，缺乏行之有效的系統化方法

5.3 需求簽約

簽約的意義與作用

• 軟件產品最大的問題是需求與范圍的不確定性、易動性和軟件產品（包括中間產品） 的隱蔽性。
• 軟件需求管理和軟件項目管理的有效手段 是 “簽字確認” 。
• 簽約一旦生效，至少表明：
  • 1?? 需求開發階段結束。被確認的SRS表述了雙方對項目軟件 需求的了解，它是軟件需求的基線，開發人員將按基線進行系統開發。
  • 2?? 此后的需求變更，要在此基線上通過項目定義的變更過程不定期進行。以后的變更可能會使雙方重新協商成本、資源和項目進度等。
• 軟件需求的簽約，是權利、義務和責任的體現，是軟件產品基線、變更控制、軟件開發和驗收的依據，是軟件項目最關鍵的一步，也是人們最不愿面對的地方。

5.4 需求變更管理

六、 敏捷軟件開發 (Agile Process, AP)

• AP 的內容

  • 軟件開發宣言 →

    軟件團隊具有快速工作、快速響應變化的能力，

    4 價值觀 + 12 原則，過程模型的敏捷性、對變化的快速響應性

  • 一種典型的軟件過程模式：過程模型 + 人員 + 方法 + 產品及關系

• 敏捷開發 (Agile Development) 是一種以人為核心、迭代、循序漸進的開發方法。

• Scrum 和 XP 的區別是，Scrum 偏重于過程，XP 則偏重于實踐，但是實際中，兩者是結合一起應用的

1 敏捷軟件開發宣言

1.1 4條基本價值觀

鼓勵集中精力重視左邊的內容，但并不是完全排除右邊的內容

• 個體和交互 勝過 過程和工具
  • 人是軟件項目獲得成功最為重要的因素
  • 合作、溝通以及交互能力要比單純的編程能力更為重要
  • 合適的工具對于成功來說非常重要，工具的作用不能被過分夸大
  • 團隊的構建要比環境的構建重要得多，應首先致力于構建團隊
  • 個體和交互建設的難度也高于過程和工具
• 可以工作的軟件 勝過 面面俱到的文檔
  • 軟件開發的主要目標是交付給用戶可以工作的軟件而不是文檔
  • 編制眾多的文檔需要花費大量的時間，要保持文檔和代碼同步，要花費更多的時間
  • 編寫并維護一份系統原理和結構方面的文檔，并且是短小的并且主題突出的
  • 直到迫切需要并且意義重大時，才來編制文檔 —— Martin文檔第一定律
• 客戶合作 勝過 合同談判
  • 客戶不可能做到一次性地將他們的需求完整清晰地表述在合同當中
    • 客戶需求的多樣性
    • 客戶需求還可能隨時發生變化
  • 全方位的滿足客戶需求的有效途徑
    • 開發團隊與客戶緊密溝通和協作
    • 為開發團隊和客戶的協同工作方式提供指導的合同是最好的合同
  • 成功的項目需要有序、頻繁的客戶反饋，成功的關鍵在于和客戶之間真誠的協作，經受住變更
• 響應變化 勝過 遵循計劃
  • 響應變化的能力常常決定著一個軟件項目的成敗
  • 商務環境可能會變化，這會引起需求的變動
  • 隨著系統逐漸開始運做，項目關系人（包括開發人員與客戶）對系統的理解也會發生變化
  • 技術隨著時間也在變化
  • 意義：敏捷 “變更代表機遇” 的重大認識
  • 響應變化的有效途徑之一是制定靈活可塑的計劃
    • 細致度逐漸降低的計劃

1.2 12條原則

幫助人們更好的理解宣言中表達的基本價值觀

其中第 10 條：簡單 —— 使未完成的工作最大化的藝術 —— 是根本的

2 敏捷過程——XP極限編程（敏捷過程模型+方法）

XP 的迭代過程框架：

• 提出了 14 項實踐（技術方法 ）
  • 第 5. 結對編程
  • 第 8. 持續集成
    • 方法：提倡在一天中集成系統多次，而且隨著需求的改變，要不斷的進行回歸測試；持續集成需要良好的軟件配置變更管理工具的有效支持
    • 作用：可以使得團隊保持一個較高的開發速度，同時避免了一次系統集成的惡夢
  • 第 12. 簡單的設計
  • 第 13. 重構
    • 指在不改變系統行為的前提下，重新調整、優化系統的內部結構以減少復雜性、消除冗余、增加靈活性和提高性能

3 敏捷過程之一 —— SCRUM（敏捷過程模型+人員）

發展歷史：KenSchwaber 和 Jeff Sutherland 提出

3.1 概念

• Scrum 是包括預定義角色和一系列實踐的過程框架
• Scrum 是迭代式增量軟件開發過程，通常用于敏捷軟件開發
• 迭代：開發一部分，就提交一部分，用戶就使用一部分，就反饋一部分，我們就修改一部分
• 最有效的反饋就是當用戶用這個軟件（或其一部分）時給出的意見
• 目的：一定程度上提供敏捷項目進展狀況的外部可見性
• 基本假設
• 外部需求模糊而難以理解
• 開發軟件如同開發新產品
• 團隊生存在一個快速變化且充滿競爭的世界

3.2 角色

• 豬（全身投入項目中）
  • Product Owner 產品負責人
  • ScrumMaster Scrum 團隊的服務式領導
  • Scrum Team 開發團隊
• 雞（參與沖刺評審、計劃并提供反饋）

3.3 3種工件

Product Blacklog (產品待辦事項列表)

產品待辦事項列表是一個排序的列表，包含所有產品需要的東西,也是產品需求變動的唯一來源。

Sprint Backlog (Sprint待辦事項列表)

迭代待辦事項是由Scrum團隊成員確定的在迭代期間完成的任務。

Sprint Burn-down Chart (燃盡圖)

每天由Scrum Master 對迭代中預估的工作剩余量進行計算并繪制成圖表，從而生成如下迭代燃盡圖。

3.4 5個會議

Sprint計劃會議（Sprint Planning Meeting）

每日站會（Daily Scrum Meeting）

Sprint評審會議（Sprint Review Meeting）

Sprint回顧會議（Sprint Retrospective Meeting）

產品Backlog梳理會議（ Product Backlog Refinement）（如果問的是 4 個會議就沒有這個）

3.5 過程模型——迭代式增量過程

計劃體系結構設計

• 按優先級排序形成 Backlog 列表，核心工件：

  Backlog 為急待完成的一系列任務，列表條目的體現形式通常為用戶故事，包括：未細化的品功能要求、Bugs、缺陷、用戶提出的改進、具競爭力的功能及技術升級等，按優先級排序形成Backlog 列表，根據該表和風險評估制訂產品交付基線。

• 建立系統體系結構并分解 Backlog 項：

  建立系統體系結構（如為已有系統改進，則只作有限分析、調整），將Backlog項按高內聚低耦合的原則分解為一系列問題包(Packets,每個 Packet 是一組對象或構件的集合) ，依據同樣原則相應劃分若干個開發小組（SCRUM 小組），分配各小組合適的Backlog 項或問題包。建立開發運行環境

Sprint

在Sprint中，Scrum團隊從產品Backlog中挑選最高優先級的需求進行開發。挑選的需求在Sprint計劃會議上經過討論、分析和估算得到相應的任務列表，我們稱它為Sprint backlog。

若干快速迭代的 Sprint (沖刺) 組成：

一個短的迭代周期稱為一個Sprint

一個Sprint限定周期為2-4周；

一個Sprint由開發（設計、開發、實施、測試、文檔化)、打包(Wrap)、評審(Review)、調整(Adjust) 組成；

每個 SCRUM 小組并行開發且同步完成；

交付和鞏固

類似于傳統方法中的維護和改善：

在每個迭代結束時，Scrum團隊將遞交潛在可交付的產品增量。一旦根據風險評估結果認為可交付產品時，即進入該階段。

該階段的活動包括：組裝，系統測試和回歸測試（Regression），準備培訓材料，完成最終文檔。SCRUM 過程認為一個產品的開發將一直持續下去，除非經風險評估后認為應停止。

3.6 SCRUM以上三個過程的特點

確定性過程(Defined Process)

可明確描述的、可預測的過程，因而可重復（Repeatable）執行并能產生預期的結果，并能通過科學理論對其最優化

經驗性過程(Empirical Process)

與確定性過程相反，作為一個黑箱（Black box）處理，通過對黑箱的輸入輸出不斷進行度量，在此基礎上，結合經驗判斷對黑箱進行調控，使其不越出設定的邊界，從而產生滿意的輸出。

SCRUM將開發中的分析、設計、實施視為一個Sprint黑箱，認為應加強黑箱內部的混沌性，使項目組工作在混沌的邊沿，充分發揮人的創造力。如將經驗性過程按確定性過程處理（如瀑布模型），必將使過程缺乏適應變化的能力

3.7 作為一種迭代式增量過程，SCRUM的過程模型與螺旋模型有何不同

七、統一過程 (Rational Unified Process, RUP)

各種過程模型之間要做比較

1 RUP的定義、內容及特點

定義：統一過程（RUP/UP，Rational Unified Process）是一種以用例驅動、以體系結構為核心、迭代式增量的軟件過程模型，由UML方法和工具支持，廣泛應用于各類面向對象項目

特點：RUP的開放性、通用性、完善性、多功能性和廣泛的適用性

RUP軟件過程模型特點：迭代 & 增量 & 并行

2 RUP的軟件過程模型

2.1 縱軸

生命周期中的靜態結構——九個核心工作流程

• 核心過程工作流程：前 6 個
• 核心支持工作流程：后 3 個
• 表示方法：UML 中：協同圖、時序圖、活動圖；RUP 中：采用活動圖（交互 + 狀態結果）
• 內容：一套完整的 UML 使用指南
• ① 業務建模：產生的主要工件 ：業務模型（業務用例模型+業務對象模型）
• ② 需求：用例模型，用戶界面模型
• ③ 分析設計：一個設計模型
• ④ 實現：實施模型（模型元素包括實施子系統和構件）
• ⑤ 測試：測試模型（模型元素包括測試用例、測試過程和測試構件）+ 測試結果
• ⑥ 部署：產品的一個版本+文檔培訓資料
• ⑦ 配置和變更管理：配置管理計劃、變更請求、項目存儲庫和工作區
• ⑧ 項目管理：商業理由、迭代計劃、風險管理計劃、質量保證計劃及相應的評估文檔
• ⑨ 環境：工作流程指南、工具、工具指南

2.2 橫軸

生命周期中的動態結構——四個階段

• 每個階段：由一次或多次迭代完成
• ① Inception 先啟階段：目標：建立業務用例、確定項目的邊界
• ② Elaboration 精化階段：目標：建立穩定的構架、編制項目計劃、淘汰項目中最高風險的元素
• ③ Construction 構建階段：目標：所有構件和應用程序功能被開發并集成為產品、所有的功能被詳盡的測試
• ④ Transition 產品化階段：目標：將軟件產品交付給用戶群體

3 比較RUP的生命周期模型與螺旋模型的異同點

相同點：迭代特性

重復一系列組成系統生命周期的循環

每次循環的結束是向用戶交付產品的一個運行版本

每個循環由若干次迭代組成

每次迭代需要進行風險分析處理

每次迭代結束的標志是交付一個增量

螺旋模型：每次迭代歷經笛卡兒坐標系中四個象限的四個方面活動

RUP：每次迭代歷經九個核心工作流程中的若干個

不同點：螺旋模型RUP

未給出每次迭代過程結束交付的增量原型的具體要求	將整個生命周期劃分為四個階段，明確給出了每個階段內的若干次迭代過程完成后交付的增量的具體要求，即四個階段的主要里程碑——生命周期目標里程碑、生命周期構架里程碑、最初操作性能里程碑和產品發布里程碑
也未給出不同次迭代在歷經的笛卡兒坐標系中四個象限的四個方面活動的內容與重點的不同	同時詳細闡述了不同階段中的不同迭代過程歷經的九大核心工作流程中活動內容的重點和強度的不同
	提供了對每次迭代過程中不同核心工作流程活動的并行化支持
	RUP的二維生命周期結構對“迭代”意義的體現比螺旋模型更深刻、具體、詳盡、全面，更具可操作性

4 RUP的優點

5 比較敏捷開發與統一過程在過程模型方面的異同

（略）

八、面向對象和UML

1 面向對象的開發 OOD

• 面向對象的分析、設計和編程是相關的，但是不同的。
• OOA 面向對象分析法 關注開發應用程序領域的對象模型。
• OOD 關心的是開發面向對象的系統模型來實現需求。
• OOP 關心的是使用 OO 編程語言（如 Java 或 C++） 實現 OOD。

2 OOD的特性

• 對象是現實世界或系統實體的抽象，并自我管理。
• 對象是獨立的，封裝數據和方法。
• 系統功能以對象服務表示。
• 消除了共享數據區域。對象通過消息傳遞進行通信。
• 對象可以分布，可以按順序或并行執行。

3 OOD的優勢

• 更易于維護。對象可理解為獨立實體。
• 對象可能是可重用的組件。
• 對于某些系統，可能有從真實世界的實體到系統對象的明顯映射。

4 UML概述

• UML 是軟件界第一個統一的建模語言，該方法結 合了 Booch, OMT 和 OOSE 方法的優點，統一了符號體系，并從其它的方法和工程實踐中吸收了許多經過實際檢驗的概念和技術。
• UML 是第三代面向對象的開發方法，是一種面向對象的可視化的通用建模語言，由 圖和元模型組成。圖是UML的語法，而元模型給 出圖的含義，是 UML 的語義
• 一個模型、多個視圖
• 這些圖提供了對系統進行分析、設計、開發不同 階段多角度描述。
• 不是軟件開發過程或方法，可用于開發周期中所有流程/階段，跨越不同的實施技術

5 UML用途

• 使用用例和參與者顯示系統中的主要功能和邊界。
• 使用交互圖說明用例實現。
• 使用類圖表示系統的靜態結構。
• 使用狀態圖對對象行為進行建模。
• 使用組件和部署圖顯示物理體系結構的實現。
• 使用構造型增強功能。

6 UML 圖表類型

第一種分類

• 結構圖（靜態）

  • 類圖（對象圖）

  • 組件圖

  • 部署圖

• 行為圖（動態）

  • 用例圖 ：顯示了外部參與者所觀察到的系統功能
  • 序列圖
  • 協作圖
  • 狀態圖
  • 活動圖

第二種分類

• 用況圖，從用況角度描述系統功能

  • 用例圖 ：顯示了外部參與者所觀察到的系統功能，由一些角色、一組用例、一些接口，以及這些元素之間的關系構成的圖，關系是指角色和用例之間的關系。用例是對一個參與者使用系統一項功能時所進行的交互過程的一個文字描述序列。

• 結構圖（靜態）

  • 類圖（對象圖） ，類圖是一組靜態的描述模型元素相互連接的集合圖，模型元素包括類、接口和類與接口之間的關系

• 交互圖，描述對象間的交互關系

  • 順序圖，是指為得到一個期望的結果而在多個分類器角色之間進行的交互序列，這些對象是按時間順序排列的。順序圖有兩維，垂直維代表時間，水平維表示對象。垂直維自上至下代表時間向前推進。
  • 協作圖，主要描述協作對象間的交互和鏈接(一條鏈接是一個關聯的實例化) 序列圖和協作圖都描述交互但是序列圖強調的是時間而協作圖強調的是空間。協作圖表示協作，包含一組由對象扮演的角色，以及在一個特定的上下文中的關系。協作圖描述相互聯系的對象之間的關系，或者分類器角色和關聯角色之間的關系

• 實現圖，用于描述系統的物理實現

  • 組件圖，也叫構件圖，表示軟件構件之間的依賴關系，可以有以下幾種：源代碼、二進制、可執行構件。

  • 部署圖，也叫配置圖，表示運行時處理元素、軟件構件以及基于處理元素和軟件構件進程和對象的配置情況。

• 行為圖（動態），描述系統的動態模型和組成對象間的交互關系

  • 狀態圖，用來描述一個特定對象的所有可能的狀態及其引起狀態轉移的事件，起點只有一個，終點有多個。

  • 活動圖，用于描述系統的工作流程和并發行為，活動圖是特殊的狀態圖。

  • 狀態圖和活動圖的異同

    相同點

    • 都是對系統的動態行為建模
    • 有相同的開始和結束點

    不同點

    • 兩者描述重點不同。狀態圖描述的是對象的狀態及狀態之間的轉移，活動圖描述的是從活動到活動的控制流。
    • 兩者使用的場合不同。若是為了顯示一個對象在其生命周期內的行為，則使用狀態圖較好，若為了分析用例、理解涉及多個用例的工作流程或處理多線程應用等，則使用活動圖較好。
    • 活動圖中的動作狀態之間的遷移不是靠事件觸發，當動作狀態中的活動完成時，遷移就被觸發。
    • 活動圖還用到了泳道的概念。
    • 活動圖通常用于描述事件由內部動作完成的情況。狀態圖則用于表示異步事件。

類圖和順序圖

1 類圖

1.1 類圖中的關系

• 依賴（虛線箭頭，use a關系，知道其存在）
  
• 單向關聯（一般箭頭，強依賴關系）
  
• 雙向關聯（實線，互相引用）
  
• 繼承/泛化（三角箭頭，指向父類）
  
• 實現（類指向接口，三角虛線箭頭）
  
• 組合（整體指向部分，整體實心菱形，部分不可以獨立存在）
  
• 聚合（整體指向部分，整體空心菱形，部分可以脫離整體存在）
  

1.2 類圖中的類

• “目”，類名-屬性-方法，窗可以為空但不能缺少
• 權限 屬性名：類型 [ = 默認值 ]
• 權限 方法名稱(參數列表) [ : 返回類型]

其中權限表示為：

• public：+
• protected：#
• private：-
  

1.3 題目要求

• 屬性要5個以上
• 方法要寫3個
• 類個數不能少于3個
• 類之間的關系要寫正確
• 英文命名，可以打個括號寫中文解釋

2 順序圖

• 要求：5個交互對象以上
• 對象名：從實現的角度，類名
  [外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-zqRJF6Oj-1618209073327)(C:\Users\89167\AppData\Roaming\Typora\typora-user-images\image-20210401152104995.png)]

活動圖和狀態圖

1 活動圖

1.1 注意事項

• 表達規范、統一（如果線如果是直線就一直是直線）
• 分支要寫【條件】，一定要用中括號！
• 要包括 5 個活動以上
• 一律用原矩形框
• 起點終點的畫法
• 分支表示選擇；分叉表示并行
• 用什么方式分出去，就用什么方式會合

1.2 完整例子

需熟練掌握畫法：

2 狀態圖

2.1 要求

• 5個狀態以上
• 圓角矩形
• 注意開始符號和結束符號
• 每個圓角矩形里只需要寫狀態名字

2.2 狀態轉移條件

• 事件
  • 啟動
• 事件【事件的條件】
  • 請求載人【位于不同樓層】
• 事件A/事件B
  • 超時/用戶主動關門
• 【條件】
  • 【時間>2秒】

2.3 示例

九、組件設計

1 什么是好的設計？

• 設計目標
  • 將系統分解為組件
    • 識別軟件體系結構
    • 設計模式
  • 描述組件功能
    • 正式或非正式
  • 確定組件之間的關系
    • 確定組件依賴關系和組件間通信機制
  • 指定組件接口
    • 接口應定義良好
    • 促進組件測試和團隊溝通
• 主要概念和原則（夢幻聯動到 < 十三, 3 >）
  • 軟件設計，具有利弊的編程范式
  • 內聚
  • 耦合
  • 信息隱蔽
  • 依賴管理的重要性
• 良好設計的標準
• 良好設計的原則與規則

2 什么是良好的組件設計？

• 準則guideline、規則rules、啟發式heuristcs

3 如何應用良好的設計？

• 架構模式（樣式）
• 設計模式

4 組件接口

組件接口由幾個部分組成：

• 出口：向其他組件提供的服務
• 進口：其他組件所需的服務
• 訪問控制：例如受保護/私有/公共（java 中的包訪問）

5 分解

通過將大問題拆分為較小的問題來處理復雜性，“分而治之”

5.1 如何分解

選擇問題的一部分（從整個問題開始）

使用設計范式確定本作品中的組件

描述組件交互（依賴性、通信間）

重復步驟 1 到 3，直到滿足某些終止條件

5.2 分解原理

• P1.不要針對執行步驟來設計組件 (不要設計與執行步驟對應的組件)

  • 因為設計決策通常超越執行時間

• P2.分解以限制設計決策的效果

  • 任何在系統內傳播的東西都非常昂貴。

• P3.組件應由使用組件所需的所有信息指定

  • 從用戶的角度來看

6 組件

6.1 組件可以是

• 一個代碼單位，
  • 有一個 （或多個） 名稱
  • 具有可識別的邊界 可（重新）
  • 由其他組件使用
  • 封裝數據
  • 隱藏不必要的細節
  • 可以單獨編譯
• 封裝抽象表示的 SW 實體（包括數據及其操作）
• "工作"分配
  • 程序員或程序員組

6.2 組件接口的組成

• exports 出口：向其他組件提供的服務
• imports 進口：其他組件所需的服務
• Access Control：訪問控制，如java中的protected/private/public

7 模塊化

模塊化系統應構建成可識別的抽象（稱為組件）

• 組件應具有指定良好的抽象接口
• 組件應具有高內聚和低耦合性

7.1 模塊化的好處

模塊化有利于軟件質量因素，例如：

• 可擴展性：定義良好的抽象接口
• 可重用性：低耦合、高內聚性
• 可移植性：隱藏計算機依賴關系（限制修改）

模塊化對于良好的設計非常重要，因為它：

• 增強以分離關注點
• 使開發人員能夠通過分散式軟件架構降低整體系統復雜性
• 通過支持多個人員的獨立和并發開發，提高可擴展性

7.2 Meyer評估模塊化的五項標準

• 可分解性 Decomposability 較大的組件是否分解成更小的組件？
• 可組合性 Composability 較大的組件是否由較小的組件組成？
• 可理解性 Understandability 組件是否單獨理解？
• 連續性 Continuity 對規范的少量更改是否會影響本地化和有限的組件數量？
• 保護性 Protection 運行時異常的影響是否局限于少數相關組件，并以預定義的方式處理？

7.3 Meyer模塊化的五個規則

• 直接映射：使解決方案的結構與建模問題域的結構兼容
• 很少接口：每個組件都應盡可能少地與其他組件通信，減少依賴 （不要太多依賴）
• 小型接口：如果任何兩個組件進行通信，它們應盡可能少地交換信息 （不要太復雜）
• 明確的接口：每當兩個組件 A 和 B 通信時，這必須從 A 或 B 的文本中明顯或兩者同時出現 （不要竊竊私語）
• 信息隱蔽：信息隱藏是增強抽象的一個手段

十、詳細設計

1 設計模式六原則

原則含義實現方法

開閉原則 Open-Closed Principle (OCP)	對擴展開放，對修改關閉	多使用抽象類和接口
依賴倒轉原則 Dependency Inversion Principle (DIP)	高層組件不依賴低層組件	盡量使用合成/聚合，而不是使用繼承
里氏代換原則 Liskov Substitution Principle (LSP)	基類可以被子類替換	使用抽象類繼承，不使用具體類繼承
迪米特法則（最少知道原則）LKP	一個軟件實體應當盡可能少地與其他實體發生相互作用	通過中間類建立聯系
接口隔離原則 Interface Segregation Principle (ISP)	使用多個隔離的接口，比使用單個接口好	建立最小的接口
單一職責原則 Single Responsibility Principle (SRP)	一個類只負責一項職責	應該有且僅有一個原因引起類的變更

1.1 里氏代換原則（LSP）

• 含義：基類可以被子類替換

• 解釋：

  • 繼承應確保關于超類對象所擁有的屬性也適用于子類對象
  • 為了讓 LSP 保持，并據其一起使用 OCP，使用基類的指針或引用的函數必須能夠在不知道的情況下使用派生類的對象。所有的衍生工具必須符合客戶對它們所使用的基類的期望行為

• 實現方法：使用抽象類繼承，不使用具體類繼承

• 通過合同設計

  在派生類中重新定義方法時，只能將其先決條件替換為較弱的預置條件，將其后置條件替換為更強的預置條件。（子類比父類要求更少，但做的更多）

  Advertised Behavior of an object 對象的播發行為：

  • advertised Requirements (Preconditions)（先決條件）
  • advertised Promises (Postconditions)（后置條件）

• OOD 中的 is-a 關系

  • LSP 明確表明，在 OOD 中，ISA 關系與行為相關。
    • 不是內在的私有行為，而是外在的公共行為；
    • 客戶端所依賴的行為。
  • 為了讓 LSP 保持，并據其一起使用"開放-關閉"原則，
    • 所有衍生工具必須符合客戶端期望他們使用的基類的行為。

• LSP 是 語義 (Semantics) 和 可替換 (Replacement) 相關的

  • 設計前understand
    • 必須明確記錄每個方法和類的含義和目的，用戶理解會導致實際違反 LSP
  • 可替換性至關重要
    • 每當任何系統中的任何代碼引用任何類時，該類的任何未來或現有子類都必須是 100% 可替換的；
    • 遲早會有人用子類代替子類，這幾乎是不可避免的。

• LSP 和 可替換性

  任何代碼都可以合法地調用另一個類方法，即必須能夠替換該類的任何子類，而無需修改

• 相關啟發式

  派生類使用 NOP 方法重寫基類方法是非法的，NOP = 無操作

  • 解決方案1：反向繼承關系
    • 如果初始基類只有其他行為
      • 例如.狗 - DogNoWag
  • 解決方案 2：提取通用基類
    • 如果初始類和派生類都有不同的行為
      • 企鵝和→鳥，飛鳥，企鵝
  • 狀態差的類
    • 愚蠢的或癱瘓的狗…

• （百度）意義

• 防止重寫父類方法，出現父類復用性差的情況。
• 程序運行正確性的保證，即類的擴展不會給系統帶來新的錯誤，降低了出錯的可能性。因為子類重寫了父類方法，在使用多態特性時，程序可能會出現不可預知的錯誤。

• （百度）做法

  • 子類可以實現父類的抽象方法，但不能覆蓋父類的非抽象方法。
  • 子類中可以增加自己特有的方法。
  • 當子類的方法覆蓋或實現父類的方法時，方法的前置條件（即方法的形參）要比父類方法的輸入參數更寬松。
  • 當子類的方法實現父類的抽象方法時，方法的后置條件（即方法的返回值）要比父類更嚴格。

• 例子：
  [外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-nU1rxVcI-1618209073330)(C:\Users\89167\AppData\Roaming\Typora\typora-user-images\image-20210401151524889.png)]

1.2 開閉原則（open-close principle, OCP）

• OCP的關鍵：抽象與多態性

• 含義：對擴展開放（模塊的行為可以擴展），對修改關閉（模塊的源代碼不得更改），應編寫無需修改即可擴展的模塊

• 實現方法：多使用抽象類和接口

• 原則：可維護、可重復使用且健壯。

• 解釋：

  • 模塊的行為可以拓展，但模塊的源代碼不可以修改；
  • 一個類不依賴于一個具體的類，而是依賴抽象類或接口，使用多態。

• 戰略關閉（將變與不變的東西隔離開）

  • 關閉不完整，但具有戰略意義
    • 通常，無論模塊有多"封閉"，總會有某種更改，而該更改不會關閉。
  • 使用抽象獲取顯式關閉
    • 提供可以動態調用的類方法
    • 使用抽象祖先類進行設計
  • 使用"數據驅動"方法實現關閉（數據驅動例如配置文件）
    • 將易失性政策決策放在單獨的位置，如文件
    • 最小化未來更改位置

• 相關啟發式

  1.使所有成員變量都私有，無全局變量！全局變量易“牽一發而動全身”

  • 對公共數據的更改始終面臨"打開"模塊的風險
    • 它們可能具有波普爾效應，需要在許多意外位置進行更改
    • 錯誤可能難以完全找到和修復，修復一處可能導致其他位置出現錯誤。
  • 非私有成員可修改

  2.RTTI是丑陋和危險的（RTTI = 運行時類型標識）

  • 如果模塊嘗試動態地將基類指針強制轉換到多個派生類，則每次擴展繼承層次結構時，都需要更改模塊
  • 通過類型開關或 if-else-if 結構識別它們
  • 并非所有這些情況都違反 OCP，當僅用為"過濾器"時（只需繪制一個圓圈）

• 舉例：

• 違反 LSP 或 DIP 總是導致違反 OCP，LSP 違規是 OCP 的潛在違規

1.3 依賴倒轉原則（DIP）

• 含義：高層模塊不依賴底層模塊（抽象應該屬于高層模塊，并由低層模塊實現）（百度）程序要依賴于抽象接口，不要依賴于具體實現。簡單的說就是要求對抽象進行編程，不要對實現進行編程，這樣就降低了客戶與實現模塊間的耦合。當高層的模塊依賴于低層的模塊時，這些高層模塊就很難在不同的環境中復用。但是，當那些高層模塊獨立于低層模塊時，它們就能很簡單地被復用了。這正是位于框架設計的最核心之處的原則。

• 實現方法：盡量使用合成/聚合，而不是使用繼承

• 解釋：

  • 高層模塊不應依賴低層模塊，兩者都應該依賴于抽象（在繼承層次結構中，基類不應該知道它的任何子類，面向接口編程）；
  • 抽象不應該依賴于具體（已經詳細實現的模塊），具體應該依賴于抽象

• OCP 指出目標，DIP 指出該機制，LSP 是 DIP 的保證

• 相關啟發式

  1.設計到接口，而不是實現！

  • 使用繼承避免直接綁定到類：（橋接模式）
  • 抽象類/接口：
    • 往往變化較少
    • 抽象是"鉸鏈點"，它更容易擴展/修改
    • 不必修改表示抽象的類/接口，但可擴展它們 （OCP）
  • 異常
    • 有些類不太可能改變; 因此，插入抽象層沒有什么好處
    • 在這種情況下，可以直接使用混凝土類 如在 Java 或 C++

  2.避免傳遞依賴

  • 避免較高級別的層依賴于較低級別的抽象的結構： 例如，策略層最終取決于實用程序層。

  • 使用繼承和抽象祖先類有效消除傳遞依賴關系：也是接口所有權的問題

    （百度：當只實現第一部分：“依賴抽象”，但不實現第二部分“抽象屬于高層模塊”時，一種常見的做法是將接口與其實現類放在同一個表示低層抽象的包內）

  3.如果有疑問，請添加間接級別

  • 如果無法為要設計的課程找到令人滿意的解決方案，請嘗試將責任委派給一個或多個類

  • 刪除或順便傳遞現有間接級別比以后添加它們容易：

• 實例：
  [外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-ZfUTYolU-1618209073335)(C:\Users\89167\AppData\Roaming\Typora\typora-user-images\image-20210401151600366.png)]

1.4 迪米特法則（最少知道原則）（LKP）

• 含義：一個軟件實體應當盡可能少的與其他實體發生相互作用

• 實現方法：通過中間類建立聯系

• 解釋：方法不能亂調用，只能調用下面類型（直接 friend）的方法：

  • 同一個類中的其他方法
  • 傳遞進來的參數對象的方法
  • 在方法中自己實例化的任何對象的方法
  • 當前對象內部的組件的方法

• 一個類對于其他類知道的越少越好，就是說一個對象應當對其他對象有盡可能少的了解，只和朋友通信，不和陌生人說話。

• 優勢

  • 耦合控制

    減少數據和通信的耦合

  • 信息隱蔽

    阻止檢索對象的子部分

  • 信息限制

    限制提供信息的方法的使用

  • 接口少

  • 明確的接口
    顯式說明方法中可以使用哪些類

1.5 接口隔離原則（ISP）

• 含義：使用多個隔離的接口，比使用單個接口好
• 實現方法：建立最小的接口
• 解釋
  • 面向接口編程而不是面向實現編程

1.6 單一職責原則（SRP）

• 含義：一個類只負責一項職責
• 實現方法：應該有且僅有一個原因引起類的變更

十一、構建分析模型

兩種分析類型：結構化分析（SA）、面向對象分析（OOA）

1 分析模型的元素

• 基于場景：從用戶的視角描述系統；user case、活動圖、泳道圖
• 面向流：表示數據對象在系統移動時如何轉換；數據流圖（不考）
• 基于類：三大基本特征：封裝、繼承、多態；UML類圖
• 基于行為：顯示了軟件如何對外部事件或激勵作出響應；順序圖

2 面向對象設計最關鍵之處：選擇類，選擇類的6個準則

（教材P110 P128）

保留信息：：記錄潛在類的信息

必須的服務：潛在類有一組可改變類屬性的操作

多個屬性

公共屬性

公共操作

必須的需求：外部實體，任何系統解決方案運行時所必需的生產或消費信息

2.1 基于類來分析SafeHome的步驟

描述屬性

系統類圖

定義操作

• 操作定義了某個對象的行為。盡管存在很多不同類型的操作，但通?？梢源致缘貏澐譃樗姆N類型：

  • 以某種方式操作數據；
  • 執行計算的操作；
  • 請求某個對象的狀態的操作；
  • 監視某個對象發生某個控制事件的操作。

• 這些功能通過在屬性和/或相關屬性上的操作實現。因此，操作必須“理解”類的屬性和相關屬性的本質。

…

十二、構建設計模型 1

1 良好的軟件設計應展示

• Firmness（穩定性）：程序不應有任何錯誤來抑制其功能。
• Commodity（適用性）：程序應適合其預期目的。
• Delight（令人愉快）：使用程序的經驗應該是愉快的。

2 設計概念

• 抽象：數據，過程，控制
• 架構：軟件的整體結構
• 模式：“傳達”一個經過驗證的設計解決方案
• 模塊化：數據和功能的劃分
• 信息隱蔽：接口
• 功能獨立性：高內聚和低耦合
• 重構：在不影響行為的情況下改進設計
• 細化：對所有抽象的細節進行細化

3 模式

• 體系結構模式表示軟件系統的基本結構組織架構。它提供了一組預定義的子系統，指定了它們的職責，并包括了組織它們之間關系的規則和準則。
• 設計模式提供了一種方案，用于優化軟件系統的子系統或組件，或它們之間的關系。它描述了一種常見的通信組件結構，用于解決特定上下文中的一般設計問題。
• 習慣用法是特定于編程語言的低級模式。習慣用法描述了如何使用給定語言的功能實現組件的特定方面或它們之間的關系。

4 為什么模塊化modularity

定義：軟件被劃分為獨立命名的、可處理的構件

• 使開發工作更易于規劃
• 可以定義和交付軟件增量
• 更容易實施變更
• 能夠有效地開展測試和調試
• 可以進行長期維護而沒有嚴重的副作用

5 說明解釋模塊化和軟件成本的關系

開發單個軟件模塊的工作量（成本）隨著模塊數的增加而下降。給的同樣的需求，更多的模塊意味著每個模塊的規模更小。然而，隨著模塊數量的增加，集成模塊的工作量（成本）也在增加。事實上，存在一個模塊數量M可以帶來最小的總體軟件開發成本。但是我們缺乏成熟的技術來精確地預測M。在進行模塊化時，注意保持在M附件，避免不足的模塊化或過度的模塊化問題。

6 信息隱蔽Information hiding

6.1 定義

通過一系列獨立的模塊得到有效的模塊化，獨立模塊之間只交流實現軟件功能所必需的信息

6.2 特征

每個模塊對其他模塊都隱蔽自己的設計決策

6.3 信息隱蔽的目的

將數據結構和處理過程的細節隱藏在模塊接口之后，用戶不需要了解模塊內部的具體細節。

6.4 為什么信息隱蔽

加強對模塊內過程細節的訪問約束以及對模塊所使用的任何局部數據結構的訪問約束

將信息隱蔽作為系統模塊化的一個設計標準將很有用。

• 降低"副作用"的可能性
• 限制本地設計決策的全球影響
• 強調通過受控接口進行通信
• 不鼓勵使用全局數據
• 導致封裝 - 高質量設計的屬性
• 產生更高質量的軟件

7 功能獨立functional

獨立性通過內聚性和耦合性進行評估。

7.1 內聚性cohesion

• 顯示了某個模塊相關功能的強度
• 一個內聚的模塊執行一個獨立的任務，與程序的其他部分構件只需要很少的交互

7.2 耦合性coupling

• 顯示了模塊之間的相互依賴性
• 耦合性依賴于模塊之間的接口復雜性、引用或進入模塊所在的點以及什么數據通過接口進行傳遞

8 逐步求精Stepwise Refinement

通過連續化過程細節層進行應用開發，…（略）

9 橫切Aspect

…（略）

10 重構

重構是更改軟件系統的過程，它不會改變代碼 [設計] 的外部行為而是改進其內部結構。

在重構軟件時，將檢查現有設計的冗余性、未使用的設計元素、低效或不必要的算法、拙劣或不當的數據結構、其他設計不足，修改這些不足以產生更好的設計。

11 設計類

用戶接口類，定義人機交互

業務域類，識別實現某些業務域所必需的屬性和服務

過程類，管理業務域類的較低級別的業務抽象。

持久類，在軟件執行后持續存在的數據存儲（數據庫）。

系統類，管理和控制功能，使系統能夠在其計算環境和與外部世界之間運行和通信。

12 什么才是組織良好的設計類

• 完整性與充分性 – 完整地封裝所有合理預見的存在于類中的屬性和方法。
• 原始性 – 每種方法都應該專注于實現某一個服務。
• 高內聚性 – 具有小的、集中的職責，并專注于使用屬性和方法來實現職責。
• 低耦合性 – 協作應保持在可接受的最低水平。

13 設計模型的元素

前四個是主要元素。詳情看書上P146 P165

• Data 數據設計元素
• Architectural 體系結構：設計元素給人總體的外貌設計
• Component 構件設計元：數據結構、算法；設計原則：開閉原則
• Interface 接口設計元素：用戶界面(關鍵)、外部接口、內部接口
• Deployment 部署設計元素

設計模型的維度

• 縱軸
  • 高：分析模型
  • 低：設計模型
• 橫軸，從左到右
  • 體系結構元素
  • 接口元素
  • 構件級元素
  • 部署級元素

十三、構件級設計

以面向對象的觀點來看，構件是協作類的集合。組件級設計定義分配給每個組件的數據結構、算法、接口特征和通信機制。

1 構件設計的基本原則

• 依據合同設計 Design by Contract
• 開閉原則 OCP：模塊應打開以進行擴展（+），但關閉以進行修改。
• 可替代性，子類型替換 LSP：子類應可替代基類
• 依賴于抽象 DIP：取決于抽象，不要依賴具體
• 接口分解 ISP：許多特定于客戶端的接口優于一個通用接口；接口的粒度要合適：太大的粒度容易導致重用性差；但是粒度也不能太小，太小導致導致容易變化。

2 內聚性

內聚關系意味著單個組件或類只封裝彼此之間以及類或組件本身密切相關的屬性和操作。

2.1 分類

• 功能內聚

  通常應用于操作，當一個模塊完成一組且只有一組操作并返回結果。

• 分層內聚

  適用于包、組件和類。高層可以訪問低層的服務，但低層不能訪問高層的服務。

• 通信內聚

  訪問相同數據的所有操作被定義在一個類中。 通常，這些類只著眼于有關數據的查詢、訪問和存儲。

2.2 方法

• 少使用全局變量
• 少使用類的繼承，多用接口隱藏實現的細節
• 模塊的功能化分盡可能的單一

3 耦合性

類或組件之間彼此聯系程度的一種定性度量，耦合強弱取決于模塊間接口的復雜程度、進入或訪問一個模塊的點以及通過接口的數據。

• 要避免
  • 內容耦合：當一個組件暗中修改其他組件的內部數據時發生，這違反了基本的軟件設計概念中的信息隱蔽原則
• 謹慎使用
  • 通用耦合：當許多組件都使用全局變量時發生。
• 需注意
  • 常規調用耦合：在面向對象的編程中，某些類型的耦合經常發生。
  • 類型使用耦合
  • 包含或導入耦合

3.1 方法

• 模塊只對外暴露最小限度的接口，形成最低的依賴關系。

十四、用戶體驗與可用性

1 什么是用戶體驗

包括終端用戶與公司、服務和產品交互的所有方面

• 滿足客戶的確切需求，無需大驚小怪或覺得麻煩
• 簡單和優雅，生產出的產品讓人擁有和使用都很愉快
• 遠遠超出了滿足客戶的需求，不僅僅是其提供的功能列表
• 高質量的用戶體驗應是多學科的綜合：工程、市場、圖形和工業設計、接口設計

2 設計的三個層次：好的設計應同時達到三個維度

該模型基于ABC model (affect, behavior, and cognition). 但添加了新的內容。

• Visceral 直覺設計：由外觀解釋產品本身，即設計可視性
• Behavioral 行為設計：產品的使用效率與滿意度，即使用性的范疇；外表并不重要。理由并不重要。性能。(功能、可理解性、可用性和物理感覺)
• Reflective 反映設計：與產品的合理性與其推理性有關

3 可用性的四個屬性和目標（目標通常由以下屬性的一部分定義或衡量）

• Effectiveness 有效性：能夠完成任務
• Efficiency 高效性：效率高，用戶的目標可以準確和全面地完成，通常以任務時間、完成任務所需的工作量來衡量
• Learnability 可學習性：容易用，易上手，指經過培訓和花費一定的時間在操作系統上，用戶熟練操作系統的能力。
• Satisfaction 滿意度：用戶對其任務滿意度，通常通過書面和口頭提問捕獲。

4 用戶體驗和可用性的區別

• 用戶體驗包含了個體在與產品交互的過程中，對產品的思想、感受和感知等
• 可用性更注重功能

（這后面用戶什么的東西就沒咋看了）

5 以用戶為中心的設計原則

產品開發前，用戶早期參與，以免后期改動；

在產品原型階段的可用性測試

迭代設計

將以用戶為中心的設計原則融入產品生命周期

6 是什么造就了成功的產品

• Capability：技術能力，我們的技術能構建什么樣的產品
• Viability：生存能力，怎樣才能留g住顧客
• Desirability：可取性，客戶想要擁有產品

十五、SOA

1 基本思想

• SOA：Service Oriented Architecture，面向服務的架構，或者說，以服務為基礎搭建的企業IT架構

• SOA中服務（Service）的理念，本質上是一種業務和技術完全分離，業務和技術又能自由組合的思想。它達到了目前軟件設計思想的最高境界。

• 面向對象是對面向過程的一次解耦和封裝，把邏輯緊密相關的程序結合成獨立的對象單元；

  面向組件是將面向對象的程序進行進一步封裝，發布成獨立的組件（與面向對象最大的區別在于通過傳輸協議來進行遠程調用的）；

  面向服務是對面向組件編程的進一步解耦和封裝，業務組件可以自由地綁定各種傳輸協議。所謂”面向服務”，就是如何實現獨立于技術的服務接口。

2 基本要素（三個元素）

• 松散耦合

  指相互之間的依賴程度，包括了

  【服務】（不同服務的功能不要互相依賴, 相對獨立而完整）、

  【接口和實現】（J2EE或.NET只需WSDL就可以調用WEB SERVICE的服務接口）、

  【業務組件和傳輸協議】（傳輸協議和位置的透明）

  之間的松散耦合

• 粗粒度

  意思是SOA中服務的接口應該比面向對象的編程的API要大一些。

• 位置和傳輸協議透明（最根本的區別于目前面向組件編程的地方）

  目前的一些服務組件都是和特定的應用服務器綁定在一起的，如果某個服務組件的URL位置 修改了，客戶端程序就必須要做出相應的修改，此即為位置組件的不透明

  • 位置透明：指不論服務組件的實際位置URL如何變化，客戶端的調用程序的URL都不需要改變
  • 傳輸協議的透明：指不管服務組件的傳輸協議如何變化，客戶端的調用程序的傳輸協議都不需要改變。

3 服務架構模式

• 以服務為核心的體系架構，并涵蓋服務的整個生命周期，是分層架構：建模-開發-裝配-運行-管理。
• SOA的核心理念是業務驅動，采用松耦合的、靈活的體系架構來滿足隨需應變的業務需求。
• 以服務為核心的體系架構可以提供松耦合、異構的企業級計算環境。

3.1 服務與服務總線

• 最底層的功能性服務，到原子服務和服務構件，到頂層的業務流程服務，目的是最大限度地封裝不同的服務，從而達到復用的目的；無論哪一個層次，其核心都是服務。

4 SOA架構的三種角色

• 服務提供者：發布自己的服務，并且對服務請求進行響應。
• 服務注冊中心：注冊已經發布的web service，對其進行分類，并提供搜索服務。
• 服務請求者：利用服務中心查找所需要的服務，然后使用該服務。

5 SOA架構的工作流程

• 發布操作：為了使服務可訪問，需要發布服務描述以使服務使用者可以發現它。
• 查找操作：服務請求者定位服務，方法是查詢服務注冊中心來找到滿足其標準的服務。
• 綁定操作：在檢索到服務描述之后，服務使用者繼續根據服務描述中的信息來調用服務。

6 SOA的相關標準

• SOAP: 簡單對象訪問協議 (Simple Object Access Protocol)
• WSDL: Web服務描述語言 WSDL (Web Services Description Language)
• UUDI: 統一描述、發現和集成 (Universal Description, Discovery and Integration)

7 可用性 / 可見性

十六、云計算

1 什么是云計算

• 云是互聯網的隱喻，是它隱藏的復雜基礎設施的抽象。
• 從工程觀點：在分配給大型物理機器的虛擬機上提供服務
• 從商業觀點：一種解決大規模應用程序可伸縮性的方法

2 為什么要用云

2.1 背景

某個公司想更新它的設備還是什么容器，發現不夠了/或者不用設備的時候又空閑著很浪費。用了云計算有什么好處 為什么要云計算，不用云計算會咋樣呢

應用程序的不規則負荷，導致預測負荷穩步增長

傳統IT容量由于資本的原因一般是逐步購買的（很難一次到位）

（開始分析）大多數組織明顯高估或低估他們需要運行其應用程序的資源量，這將導致為基礎設施和整體應用交付更高的成本。

隨著時間的推移，實際負載高度變量

期間，有產能過剩、資本鋪設閑置、運營成本浪費供電和冷卻的服務器

期間，由于沒有足夠的能力而讓我們的客戶得到一個好的體驗

2.2 為什么

• 不必支付硬件，降低成本
• 減少冗余容量的浪費，使資源充分利用
• 按需提供計算容量，確保我們可以隨時為高峰期提供足夠的IT容量
• 容量可以流的方式快速購買(無需提前訂購的服務器)，可以減少容量需求消退

3 云計算的基本形式 服務的三種形式

含義，區別，舉個例子說明是什么

• IaaS（基礎設施即服務）：只提供云計算的基礎平臺（只提供網絡、存儲、服務器、虛擬化(沒有虛擬化就沒有云計算)）。如VMware

• PaaS（平臺即服務）：在IaaS基礎上還提供操作系統、中間件、運行時的組件（團隊項目部署屬于這個）

  提供在其平臺上構建和部署自定義應用程序的能力。 它減少了對專有 SaaS 平臺的依賴，這些平臺通常將用戶和組織鎖定到平臺。如google app engine

• SaaS（軟件即服務）：在PaaS的基礎上還提供了數據、應用

  用于描述通過互聯網部署的軟件和供應商向訂閱者許可應用程序作為"按需服務"。如社交服務FaceBook

• 他們之間的關系就像：

  IaaS：提供廚房、爐子、煤氣，你可以使用這些基礎設施，來烤你的披薩。

  PaaS：除了基礎設施，還提供披薩餅皮。你只要把自己的配料灑在餅皮上，讓他幫你烤出來就行了。也就是說，你要做的就是設計披薩的味道（海鮮披薩或者雞肉披薩），他人提供平臺服務，讓你把自己的設計實現。

  SaaS：他人直接做好了披薩，不用你的介入，到手的就是一個成品。你要做的就是把它賣出去，最多再包裝一下，印上你自己的 Logo。

4 虛擬化的優勢

簡介：虛擬化 (Virtualization) 是資源的邏輯表示，其不受物理限制約束。

• 效率：將原本一臺服務器的資源分配給了數臺虛擬化的服務器，有效的利用了閑置資源，確保企業應用程序發揮出最高的可用性和性能。
• 隔離：雖然虛擬機可以共享一臺計算機的物理資源，但它們彼此之間仍然是完全隔離的，就像它們是不同的物理計算機一樣。因此，在可用性和安全性方面，虛擬環境中運行的應用程序之所以遠優于在傳統的非虛擬化系統中運行的應用程序，隔離就是一個重要的原因。
• 可靠：虛擬服務器是獨立于硬件進行工作的，通過改進災難恢復解決方案提高了業務連續性，當一臺服務器出現故障時可在最短時間內恢復且不影響整個集群的運作，在整個數據中心實現高可用性。
• 成本： 降低了部署成本，只需要更少的服務器就可以實現需要更多服務器才能做到的事情，也間接降低了安全等其他方面的成本。
• 兼容：所有的虛擬服務器都與正常的x86系統相兼容，他改進了桌面管理的方式，可部署多套不同的系統，將因兼容性造成問題的可能性降至最低。
• 便于管理：提高了服務器/管理員比率，一個管理員可以輕松的管理比以前更多的服務器而不會造成更大的負擔。

5 虛擬化的種類

• 處理器虛擬化
• 內存的虛擬化
• I/O 的虛擬化
• 網絡虛擬化

5.1 處理器的虛擬化

• 敏感指令
  • 系統資源：處理器的指令集和寄存器；I/O設備的狀態和控制寄存器；
  • 影響處理器設備狀態和行為的寄存器稱為關鍵資源或特權資源；
  • 可以讀寫關鍵資源的指令叫做敏感指令（與CPU架構有關）；
• 特權級別
  • 現代計算機體系結構一般至少有兩個特權級，用戶態和核心態；
  • 除X86外，敏感指令即特權指令，特權指令只能在最高級別（內核態）執行，否則會引發異常。

5.2 內存虛擬化

（略）

5.3 I/O 的虛擬化

（略）

5.4 網絡虛擬化

（略）

總結

以上是生活随笔為你收集整理的《软件工程导论》知识点期末复习整理的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。