軟件工程概論

第一章 軟件工程概論

1.軟件危機

定義

1. *軟件：是計算機程序、方法、規則、相關的文檔以及運行計算機系統時所必需的數據的總和(狹義定義：軟件＝程序+數據+文檔)
2. *軟件的特性：軟件是復雜的、軟件是不可見的、軟件是不斷變化的和軟件質量難以穩定。
3. *軟件的質量特性：功能性、可靠性、易用性、效率、維護性、可移植性。
4. 軟件危機：指在計算機軟件的開發和維護過程中所遇到的一系列嚴重問題。

軟件危機的主要表現：

• 對軟件開發成本和進度估計常常很不准確
• 用戶對"已完成"的系統不滿意的現象經常發生
• 軟件產品的質量往往靠不住
• 軟件常常是不可維護的
• 軟件成本在計算機系統總成本所占的比例逐年上升

軟件危機產生的主要原因:

• 軟件日益復雜和龐大
• 軟件開發管理困難和復雜
• 軟件開發技術落后
• 生產方式落后
• 開發工具落后
• 軟件開發費用不斷增加

軟件危機如何解決

既要有技術措施（方法和工具），又要有必要的組織管理措施。

2.軟件工程的基本概念

軟件工程介紹

1. 軟件工程：是指導計算機軟件開發和維護的一門工程學科。采用工程的概念、原理、技術和方法來開發與維護軟件，把經過時間考驗而證明正確的管理技術和當前能夠得到的最好的技術方法結合起來，以經濟地開發出高質量的軟件並有效地維護它。

2. 軟件工程的本質特征：

   • 軟件工程關注於大型程序的構造
   • 在軟件工程領域中是由具有一種文化背景的人替具有另一種文化背景的人創造產品
   • 開發軟件的效率非常重要
   • 軟件工程的中心課題：控制復雜性
   • 軟件經常變化
   • 軟件必須有效地支持它的用戶
   • 和諧地合作是開發軟件的關鍵

3. 軟件工程的基本原理：

   • 用分階段的生命周期計划嚴格管理
   • 堅持進行階段評審
   • 實行嚴格的產品控制
   • 采用現代程序設計技術
   • 結果應能清楚的審查
   • 開發小組的人員應該少而精
   • 承認不斷改進軟件工程實踐的必要性

軟件工程方法學

1. 軟件工程以關注軟件質量為目標，包括方法、過程、工具、范式四個要素。

2. 軟件工程方法學：把軟件生命周期全過程中使用的一整套技術方法的集合成為方法學(也稱范型paradigm),包括三個要素:方法,工具和過程.目前使用最廣泛的是傳統方法學和面向對象方法學

   • 傳統方法學(也稱生命周期方法學或結構化范型):采用結構化技術(結構化分析,結構化技術,結構化實現)來完成軟件開發的各項任務,並使用適當的軟件工具或軟件環境來支持結構化技術的運用

   • 面向對象方法學:有4個要點;它是一個多次反復迭代的演化的過程;特有的繼承性和多態性進一步提高了面向對象軟件的可重用性

3. 軟件生命周期

• 問題定義:確定要解決的問題是什么(通過客戶的訪問調查,系統分析員寫出問題的性質,工程目標和工程規模的書面報告,並得到客戶的確認)
• 可行性研究:不是具體解決問題,而是研究問題的范圍,探索問題是否值得去解,是否有可行的解決方法
• 需求分析:准確確定"為了解決這個問題,目標系統必須做什么",主要是確定目標系統必須具備哪些功能
• 總體設計:設計出目標系統的多種方案;設計程序的體系結構
• 詳細設計:詳細的設計每個模塊,確定要實現模塊功能所需要的算法和數據結構
• 編碼和單元測試:寫出正確的容易理解,容易維護的程序模塊
• 綜合測試:通過各種類型的測試(及相應的的調試)使軟件達到預定的要求
• 軟件維護:通過各種必要的維護活動使系統持久地滿足用戶的需要

4. 軟件過程

1. 軟件過程:指為了獲得高質量軟件所需完成一系列任務框架,它規定了完成各項任務的工作步驟;通常使用生命周期模型簡潔地描述軟件過程
2. 生命周期模型:也稱過程模型規定了把生命周期划分成哪些階段及各個階段的執行順序

瀑布模型

• 瀑布模型特點：

  • 階段間具有順序性和依賴性:
    必須等前一階段的工作完成后之后,才能開始后一段的工作;前一段的輸出文檔就是后一階段的輸入文檔
  • 推遲實現的觀點:
    在編碼之前設置了系統分析和系統設計的各個階段,分析與設計階段的基本任務規定,這兩個階段主要考慮目標系統的邏輯模型,不涉及物理實現
  • 質量保證的觀點:
    每個階段必須完成規定的文檔;每個階段結束前都要對完成的文檔進行評審,以便盡早發現問題
    

• 瀑布模型適用：在開發的早期階段軟件需求被完整確定

• 瀑布模型的優點:

  • 可強迫開發人員采用規范的方法;
  • 嚴格規定了每個階段必須提交的文檔;
  • 要求每個階段交出的所有產品都必須經過質量保證小組的仔細驗證

• 瀑布模型缺點：
  瀑布模型是由文檔驅動;最終產品不能真正滿足客戶的需求

快速原型模型

首先建立一個反映用戶主要需求的原型系統,讓用戶體驗,之后提出意見,隨之進行修改,再讓用戶體驗...直至用戶完全滿意,據此寫出規格說明文檔

2. 增量模型：也稱漸增模型，把產品作為一系列的增量構件來設計、編碼、集成、測試。

• 增量模型優點:
  • 人員分配靈活,剛開始不用投入大量人力資源；
  • 可先發布部分功能給客戶，對客戶起到鎮靜劑的作用；
  • 增量能夠有計划地管理技術風險。
• 增量模型缺點:
  • 需要軟件具備開放式的體系結構；
  • 容易退化為邊做邊改模型，從而使軟件過程的控制失去整體性；
  • 增加系統內部的耦合復雜性。

螺旋模型

把它看作在每個階段之前增加了風險分析的快速原型模型。

• *螺旋模型與增量模型的區別：
  • 兩者迭代層級不同：增量模型在活動級迭代；螺旋模型在過程級迭代；
  • 兩者需求分析的時間不同：增量模型常常是先做總體需求分析和設計，然后在編碼和測試中逐個增量開發；螺旋模型在開發周期內采用簡化瀑布模型或快速模型；
  • 兩者提交軟件的方式不同：增量開發在上次增量的基礎上提交新的一部分軟件；螺旋模型每次迭代都提交一個新的完整的軟件版本；
  • 兩者減少風險的方式不同：增量模型使用未成熟技術和經常的客戶反饋等方法減少風險；螺旋模型中直接加進風險識別，風險分析、風險控制，計划性較強.

噴泉模型

典型的具有面向對象軟件開發過程迭代和無縫的特性
用面向對象開發軟件時，在分析、設計、編碼等各項開發活動之間並不存在明顯的邊界，每個階段都有該階段內的迭代維護。

第二章 可行性研究

1.可行性研究的任務

1. 可行性研究的目的不是為了解決問題，而是確定問題是否值得去解決
2. 可行性：技術可行性、經濟可行性、操作可行性、運行可行性、法律可行性。

2. 可行性研究過程：

• 復查系統規模和目標
• 研究正在使用的系統
• 導出新系統的高層邏輯模型
• 進一步定義問題
• 導出和評價供選擇的解法
• 推薦行動方針
• 草擬開發計划
• 書寫文檔提交審查

3. 系統流程圖

1. *系統流程圖：是概括地描繪物理系統的傳統工具。用圖形符號以黑盒子形式描繪組成系統的每個部件（程序，文檔，數據庫，人工過程等）。表達的是 數據在系統中各部件之間的流動情況。

符號	名稱	說明
矩形	處理	能改變數據值或數據位置的加工或部件。如程序 、處理機、人工加工等都是處理
平行四邊形	輸入輸出	表示輸入或輸出，是一個廣義的不指名具體設備的符號
圓形	連接	指出轉到圖的另一部分或從圖的另一部分轉來，通常在同一頁上
矩形下面 加個三角	換頁連接	指出轉到另一頁圖上或另一頁圖轉來
箭頭	數據流	用來連接其他符號，指明數據流的方向

4.數據流圖

數據流圖(Data Flow Diagram)是一種簡單的圖形方式，用來描述數據和信息流從輸入移動到輸出過程中所經受的變換。

數據流圖的表示

5. 數據字典

數據字典是關於數據的信息的集合，也就是對數據流圖中所有元素的定義的集合。

數據字典定義組成

• 數據流
• 數據流分量（即數據元素）
• 數據存儲
• 處理
  

6. 成本效益分析

第一步估計開發成本、運行費用和新系統將帶來的經濟效益。需從貨幣時間價值,投資回收期,純收入,投資回收率

方法有三種：

• 代碼行技術：軟件成本=每行代碼的平均成本*估計的源代碼總行數
• 任務分解技術：單本任務成本=任務所需人力估計值*每人每月平均工資；軟件開發項目總成本=每個單獨任務成本估計總和
• 自動估計成本技術：采用自動估計成本的軟件

第三章 需求分析

1. 需求分析的任務

• 確定對系統的綜合要求
  • 功能需求
  • 性能需求
  • 可靠性和可用性需求
  • 出錯處理需求
  • 接口需求
  • 約束
  • 逆向需求
  • 將來可能提出的需求
• 分析系統的數據要求
• 導出系統的邏輯模型
• 修正系統開發計划

2. 分析建模與規格說明

模型: 就是為了理解事物而對事物作出的一種抽象,是對事物的一種無歧義的書面描述。通常，模型由一組圖形符號和組織這些符號的規則組成
需要建立的三種模型：數據模型、功能模型和行為模型

* 實體-聯系圖

描繪數據對象、數據對象的屬性及數據對象之間的關系，用於建立數據模型

* 數據規范化

同數據庫中一二三范式

* 狀態轉換圖

描繪了系統的狀態及引起狀態轉換的事件，是建立行為模型的基礎

• 狀態
  • 任何可以被觀察到的系統行為模式
• 事件
  • 對引起系統做動作或從一個狀態轉換到另一個狀態的外界事件的抽象
• 符號

舉例如下:

其他圖形工具

• 層次方框圖
  用樹形結構的一些了多層級的矩形框描繪的數據的層次結構。
• Warnier圖
  表面信息的邏輯組織
  
• IPO圖
  輸入處理輸出圖的簡稱。

3.驗證軟件需求

驗證的方面

• 一致性
• 完整性
• 現實性
• 有效性

第四章 形式化說明技術

軟件工程使用方法按形式化程度分為三類：

• 非形式化，如用自然語言描述規格說明
• 半形式化，如用數據流圖或實體-聯系圖建立模型
• 形式化，如描述系統性質是基於數學的技術

1. 概述

非形式化的缺點

• 矛盾性：在需求規格說明書中對同一問題前后存在不同的描述
• 二義性：讀者可以用不同的方式理解的陳述
• 含糊性：需求規格說明書對某一問題描述不清晰，不可理解
• 不完整性：需求規格說明書對某一問題只說明了局部，沒說明整體
• 抽象層次混亂：指在非常抽象的陳述中混入了關於低層次的細節陳述

形式化的優點：

• 能夠簡潔准確的描述物理現象、對象或動作的結果
• 在不同的軟件工程活動之間平滑過渡
• 提供了高層確認的手段

2. 應用形式化准則

• 選用適當的表示方法
• 應該形式化，但不要過分形式化
• 應該估算成本
• 應該有形式化顧問隨時提供咨詢
• 不應該放棄傳統的開發方法
• 應該建立詳盡的文檔
• 不應該放棄質量標准
• 應該測試，測試再測試
• 應該重用

第五章 總體設計

設計過程：

總體設計分為

2個階段：

• 系統設計階段
  確定系統的具體實現方案
• 結構設計階段
  確定軟件結構

9個步驟：

• 設想供選擇的方案
• 選取合理的方案
• 推薦最佳方案
• 功能分解
• 設計軟件結構
• 設計數據庫
• 制定測試計划
• 書寫文檔
• 審查和復審

2.設計原理

設計原理的相關概念

• 模塊化：
  就是把程序划分成獨立命名且可獨立訪問的模塊，每個模塊完成一個子功能，這些模塊集成起來構成一個整體，可以完成指定的功能滿足用戶的需求
• 抽象：
  抽出事物本質特性而暫時不考慮細節
• 逐步求精：
  為了能集中精力解決最主要問題而盡量推遲對問題細節的考慮。逐步求精是人類解決復雜問題時采用的基本方法，也是許多軟件工程技術的基礎
• 信息隱藏：
  應該這樣設計和確定模塊，使得一個模塊內包含的信息對於不需要這些信息的模塊來說是不能訪問的
• 局部化：
  是指把一些關系密切的軟件元素物理地址放得彼此靠近
• 模塊獨立：
  是模塊化、抽象、信息隱藏和局部化的概念的直接結果。獨立的程度測量標准：內聚、耦合

  • 耦合：是對一個軟件結構內不同模塊之間互連程度的度量。耦合強弱取決於模塊間接口的復雜程度，進入或訪問一個模塊的點，以及通過接口的數據。耦合程度強烈影響着系統的可理解性、可測試性、可靠性、可維護性。設計原則：盡量使用數據耦合，少用控制耦合和特征耦合，限制公共環境的耦合的范圍，完全不用內容耦合。

    • 數據耦合：如果兩個模塊彼此間通過參數交換信息，而且交換的信息僅僅是數據。數據耦合是低耦合
    • 控制耦合：傳遞的信息中有控制信息。中等耦合，增加了系統的復雜性
    • 特征耦合：當整個數據結構作為參數傳遞而被調用的模塊只需要使用其中一部分數據元素時
    • 公共環境耦合：當兩個或多個模塊通過一個公共數據環境互相作用時。公共環境可以是全程變量、共享通信區、內存的公共覆蓋區、任何存儲介質的文件、物理設備等。
    • 內容耦合：如果發生之一就是:
      • 一個模塊訪問另一個模塊的內部數據
      • 一個模塊不通過正常入口而轉到另一個模塊的內部
      • 兩個模塊有一部分程序代碼重疊
      • 一個模塊有多個入口

  • 內聚：標志着一個模塊內各個元素彼此之間結合的緊密程度，它是信息隱藏和局部化概念的擴展。設計原則：力求高內聚，通過提高模塊間的內聚降低耦合從而使模塊獲得較高的獨立性。高內聚意味着低耦合

    • 低內聚
      • 偶然內聚：如果一個模塊完成一組任務，這些任務彼此之間有關系，關系也是很松散的。如在一個程序內有一組語句在兩處或多處出現，於是把這些語句作為一個模塊以節省內存
      • 邏輯內聚：如果一個模塊完成的任務在邏輯上屬於相同或相似的一類。如一個模塊產生各種類型的全部輸出
      • 時間內聚：如果一個模塊包含的任務必須在同一時間內執行。如模塊完成各種初始化工作
    • 中內聚
      • 過程內聚：如果一個模塊內的處理元素是相關的，且必須以特定次序執行。如流程圖確定模塊的划分，得到的往往是過程內聚的模塊
      • 通信內聚：如果一個模塊中所有元素都是用同一個輸入數據和產生同一個輸出數據
    • 高內聚
      • 順序內聚：如果一個模塊內的處理元素和同一個功能密切相關，且這些處理必須順序執行。如一個處理元素的輸出數據作為下一個處理元素的輸入數據，根據數據流圖划分模塊得到往往是順序內聚模塊
      • 功能內聚：如果模塊內的所有處理元素屬於一個整體，完成單一的功能

    內聚評分

    類型	功能內聚	順序內聚	通信內聚	過程內聚	時間內聚	邏輯內聚	偶然內聚
    評分	10	9	7	5	1	1	0

3. 啟發規則

• 改進軟件結構提高模塊的獨立性
• 模塊規模應該適中
• 深度、寬度、扇出和扇入都應適當
  • 深度：軟件結構控制的層數
  • 寬度：同一個層次上的模塊總數的最大值
  • 扇出：一個模塊直接控制(調用)的模塊數，平常應該控制在3-4個(上限5-9個)
  • 扇入：有多少個上級模塊之間調用它，越大越好，但不能盲目追求多
• 模塊的作用域應該在控制域內
• 力爭降低模塊接口的復雜程度
• 設計單入口單出口的模塊
• 模塊的功能應該可預測

4. 描繪軟件結構的圖形工具

• 層次圖：描繪軟件的層次結構。一個矩形框代表一個模塊，方框間的連線表示調用關系
  
• HIPO圖："層次圖加輸入/處理/輸出圖"，就是在層次圖的每個方框加編號
  
• 結構圖：每個方框代表一個模塊，框內注明模塊的名字或主要功能，方框間的箭頭（或直線）代表模塊的調用關系，注釋表示來回傳遞的信息
  

  尾部空心圓表示傳遞數據，實心圓代表傳遞控制信息

5. 面向數據流的設計方法

概念

• 變換流：
  信息以外部世界的形式進入軟件系統，經過處理后再以外部時間的形式離開系統
• 事務流：
  據沿輸入通路到達一個處理T,這個處理根據輸入數據的類型在若干個動作序列中選出一個來執行。這類數據流應該划為一類特殊的數據流﹐稱為事務流。
  

變換分析

變換分析是一系列設計步驟的總稱,經過這些步驟把具有變換流特點的數據流圖按預先確定的模式映射成軟件結構。

第六章 詳細設計

詳細設計階段的根本目標是確定應該怎樣具體地實現所要求的系統，也就是說,經過這個階段的設計工作,應該得出對目標系統的精確描述,從而在編碼階段可以把這個描述直接翻譯成用某種程序設計語言書寫的程序。

1. 結構程序設計

如果只允許使用順序、IF THEN_ELSE型分支和 DO_WHILE型循環這3種基本控制結構,則稱為經典的結構程序設計;如果除了上述3種基本控制結構之外,還允許使用DO-CASE型多分支結構和DO_UNTIL型循環結構,則稱為擴展的結構程序設計;如果再允許使用LEAVE(或BREAK)結構,則稱為修正的結構程序設計。

2. 人機界面設計指南

• 一般交互指南
• 信息顯示指南
• 數據輸入指南

3. 過程設計的工具

程序流程圖：

• 優點：對控制流程的描繪直觀，初學者很容易掌握
• 缺點：
  • 程序流程圖不是精益求精的好工具，它誘使程序員過早地考慮程序的控制流程，而不去考慮全局結構
  • 程序流程圖中用箭頭代表控制流 ，因此程序員不受任何約束，可以完全不顧結構程序設計的思想，隨意轉移
  • 程序流程圖不易表示數據結構

盒圖（N-S圖）

• 功能域明確
• 不可能任意轉移控制
• 很容易確定局部和全局數據的作用域
• 很容易表現嵌套關系，也可以表示模塊的層次結構

問題分析圖（PAD圖）

使用二維結構的圖來表示程序的控制流。

其優點：

• 使用PAD符號設計出來必然是結構化程序
• PAD圖描繪的程序結構十分清楚
• PAD圖表現程序的邏輯，易讀、易懂、易記
• 很容易將PAD圖轉化為高級語言程序
• 即可表示程序邏輯，也可表示數據結構
• PAD符號支持自動向下，逐步求精

判定表

當算法中含有多重嵌套的條件選擇時

• 優點：能清晰表示復雜的條件組合與應做的動作之間的關系
• 缺點：
  • 判定表的含義不能一眼看出來
  • 當數據元素多於兩個時，判定表的簡潔程度下降

判定樹

判定表變種

• 優點：一眼看出其含義，易於掌握，使用
• 缺點：
  • 簡潔性不如判定表，數據元素需重復寫多遍
  • 判定樹的分支次序對畫出的判定樹的簡潔程度有較大影響

4. 面向數據結構的設計方法

Jackson方法和Warnier方法是兩個著名的面向數據結構的設計方法。

Jackson方法

數據元素彼此間的邏輯關系只有順序、選擇、重復三種。

Jackson方法由以下步驟組成：

• 分析並確定輸入數據和輸出數據的邏輯結構，並用Jackson圖描繪這些圖的結構。
• 找出輸入數據結構和輸出結構中有對應關系的數據單元。
• 利用以下規則從描繪數據結構的Jackson圖導出描繪程序結構的Jackson圖
  • 為每對有對應關系的數據單元﹐按照它們在數據結構圖中的層次在程序結構圖的相應層次畫一個處理框(注意﹐如果這對數據單元在輸入數據結構和輸出數據結構中所處的層次不同,則和它們對應的處理框在程序結構圖中所處的層次與它們之中在數據結構圖中層次低的那個對應)。
  • 根據輸入數據結構中剩余的每個數據單元所處的層次,在程序結構圖的相應層次分別為它們畫上對應的處理框。
  • 根據輸出數據結構中剩余的每個數據單元所處的層次,在程序結構圖的相應層次分別為它們畫上對應的處理框。
• 列出所有的操作和條件，並分配到程序結構圖的適當位置。
• 用偽代碼表示。

5. 程序復雜程度的定量度量

McCabe方法

McCabe根據程序控制流的復雜程度度量 程序的復雜程度，這樣度量出的結果稱為程序的環形復雜度

• 流圖的表示：

  • 結點：用圓表示，一個圓代表一條或多條語句
  • 邊：箭頭線稱為邊，代表控制流
  • 區域：由邊和結點圍成的面積 稱為區域，當計算區域數時應該包括圖外未被圍起來的區域
  • 判定結點：包含條件的結點

• 計算環形復雜度的方法:

  • 流圖中線性無關的區域數等於環形復雜度
  • 流圖G的環形復雜度 V(G)=E-N+2,其中E是流圖中邊的條數，N是結點數
  • 流圖G的環形復雜度 V(G)=P+1,其中P是流圖中判定結點的數目

第七章 實現

實現包括編碼和測試

1.編碼

編碼：把詳細設計結果翻譯成某種程序語言書寫的程序
軟件測試：是保證軟件質量的關鍵步驟，是對軟件規格說明、設計和編碼的最后復審

2.測試

測試的目標

• 測試是為了發現程序中的錯誤而執行程序的過程。
• 好的測試方案是極可能發現迄今為止尚未發現的錯誤的測試方案。
• 成功的測試是發現了至今為止尚未發現的錯誤的測試。

測試的准則

• 所有測試都應該能追溯到用戶需求
• 應該遠在測試開始之前就制定出測試計划
• 應用Pareto原理

  測試中發現的80%的錯誤是由於20%的模塊引起的

• 應該從小規模測試開始，並逐步進行大規模測試
• 窮舉測試是不可能的
• 應該由獨立的第三方從事測試工作

測試步驟

1. 模塊測試
2. 子系統測試
3. 系統測試
4. 驗收測試
5. 平行測試

單元測試

單元測試集中檢測軟件設計中的最小單元——模塊。

單元測試的測試重點包括：

• 模塊接口
• 局部數據結構
• 重要的執行通路
• 出錯處理通路
• 邊界條件

集成測試

集成測試是測試和組裝軟件的系統化技術。

由模塊組裝成程序時有兩種方法。

• 非漸增式測試方法：分別測試每個模塊，再按要求結合
• 漸增式測試：把下一個要測試的模塊同已經測試好的模塊結合起來測試。

漸增式測試包括兩種集成策略:

• 自頂向下集成
  從主控制模塊開始，沿着程序的控制層次向下移動，逐漸將各個模塊結合起來
• 自底向上集成
  從“原子”模塊開始組裝和測試

回歸測試是指重新執行已經做過的測試的某個子集，以保證上述這些變化沒有帶來非預期的作用。

確認測試

確認測試也叫驗收測試，目的式驗證軟件的有效性

• 測試范圍：有用戶積極參與，以用戶為主的測試
• 內容：復制軟件配置
• 方法：
  • alpha測試
    由用戶在開發者的場所進行，在開發者對用戶的指導下進行測試
  • beta測試
    由軟件的最終用戶們在一個或多個客戶場所進行。

測試方法

• 白盒測試
  把程序看成裝在一個透明的白盒子里，測試者完全知道程序的結構和處理算法。

  白盒測試的典型技術

  • 邏輯覆蓋
    • 語句覆蓋
    • 判定覆蓋
    • 條件覆蓋
    • 判定\條件覆蓋
    • 條件組合覆蓋
    • 點覆蓋
    • 邊覆蓋
    • 路徑覆蓋
  • 控制結構測試
    • 基本路徑結構
    • 條件測試
    • 循環測試

• 黑盒測試
  把程序看作一個黑盒子，完全不考慮程序的內部結構和處理過程

  黑盒測試的典型技術

  • 等級划分
  • 邊界值分析
  • 錯誤推理

3. 調試

調試是指在測試發現錯誤之后排除錯誤的過程。
調試途徑包括：

• 蠻干法
• 回溯法
• 原因排除法

4.軟件可靠性

軟件可靠性

軟件可靠性是指程序在給定的時間間隔內，按照規格說明書的規定成功地運行的概率。

軟件可用性

軟件可用性是指程序在給定的時間點，按照規格說明書上的規定，成功地運行的概論。

第八章 維護

軟件維護的定義：就是在軟件已經交付使用之后，為了改正錯誤或滿足新的需要而修改軟件的過程

1. 軟件維護的特點

結構化維護和非結構化維護

非結構化維護

• 如果軟件配置的唯一成分是程序代碼，那么維護活動從評價代碼開始，而且由於內部文檔不足而使評價更困難
• 非結構化維護需要付出巨大代價，是沒有使用良好定義的方法學開發出來的必然結果

結構化維護

• 如果有一個完整軟件配置存在，那么維護從評價設計文檔開始就很規范
• 減少精力的浪費，提高維護的總體質量

2. 決定軟件可維護的因素：

• 可理解性
• 可測試性
• 可修改性
• 可重用性

第九章 面向對象方法學引論

1. 面向對象方法學要點：

• 基本原則：

  盡可能模擬人類習慣的思維方式，是開發軟件的方法和過程盡可能接近人類認識的世界解決問題的方法和過程

• 4個要點

  • 軟件是由對象組成的，任何元素都是對象，復雜軟件對向由比較簡單的軟件對象組成
  • 所有對象都划分成對象類，類都定義了一組數據和一組方法
  • 若干對象類組成一個層次的系統
  • 對象間僅能通過傳遞消息互相聯系

• 面向對象方法學優點

  • 與人類習慣的思維方法一致
  • 穩定性好
  • 可重用性好
  • 較易開發大型軟件產品
  • 可維護性好

2.面向對象的概念

對象：是描述該對象屬性的數據以及對這些數據施加的所有操作封裝在一起構成的統一體

對象的定義

• 對象是具有相同狀態的一組操作的集合
• 對象是對問題域中某個東西的抽象
• 對象::=

對象的特點

• 以數據為中心
• 對象是主動
• 實現了數據的封裝
• 本質上具有並行性
• 模塊獨立性好

其它概念

• 類：是一組具有相同屬性和相同操作的對象的集合。
• 實例：由某個特定的類所描述的一個具體的對象。
• 消息：要求某個對象執行在定義它的那個類中所定義的某個操作的規格說明。組成部分：接收消息的對象；消息名；消息變元
• 方法：就是對象所能執行的操作，也就是類中所定義的服務。
• 屬性：屬性就是類中所定義的數據，它是對客觀世界實體所具有的性質的抽象。
• 封裝：對象封裝了對象的數據以及對這些數據的操作。
• 繼承：繼承是子類自動地共享基類中定義的數據和方法的機制。
• 單重繼承：子類僅從一個父類繼承屬性和方法
• 多重繼承：子類可從多個父類繼承屬性和方法
• 多態性：指子類對象可以像父類那樣使用
• 函數重載：指在同一作用域內的若干參數特征不同的函數可以使用相同的函數名
• 運算符重載：指在同一個運算符可以施加於不同類型的操作數上面

第十章 面向對象分析

1. 建立對象模型

• 三個子模型，按所解決的問題進行划分

  • 靜態結構（對象模型）
  • 交互次序（動態模型）
  • 數據變換（功能模型）

• 5個層次

  • 主題層
  • 類與對象層
  • 結構層
  • 屬性層
  • 服務層

對象模型創建的步驟

• 確定類與對象
• 確定關聯
• 划分主題
• 確定屬性
• 識別繼承關系
• 反復修改

第十一章 面向對象設計

面向對象設計准則

• 模塊化
• 抽象
• 信息隱藏
• 弱耦合
• 強內聚
• 可重用

類構件的重用方式：

• 實例重用
• 繼承重用
• 多態重用