第1章 軟件工程學概述

1.1 軟件危機

1.1.1 軟件危機的介紹

軟件危機(軟件蕭條、軟件困擾)：是指在計算機軟件的開發(fā)和維護過程中所遇到的一系列嚴重問題。

軟件危機包含下述兩方面的問題：

如何開發(fā)軟件，滿足對軟件日益增長的需求；

如何維護數(shù)量不斷膨脹的已有軟件。

軟件危機的典型表現(xiàn)：

（1）對軟件開發(fā)成本和進度的估計常常很不準確；

（2）用戶對“已完成的”軟件系統(tǒng)不滿意的現(xiàn)象經(jīng)常發(fā)生；

（3）軟件產(chǎn)品的質量往往靠不?。?/p>

（4）軟件常常是不可維護的；

（5）軟件通常沒有適當?shù)奈臋n資料；

（6）軟件成本在計算機系統(tǒng)總成本中所占的比例逐年上升；

（7）軟件開發(fā)生產(chǎn)率提高的速度，遠遠跟不上計算機應用迅速普及深入的趨勢 。

1.1.2 產(chǎn)生軟件危機的原因

（1）與軟件本身的特點有關

（2）與軟件開發(fā)與維護的方法不正確有關

1.1.3 消除軟件危機的途徑

對計算機軟件有正確的認識。

認識到軟件開發(fā)是一種組織良好、管理嚴密、各類人員協(xié)同配合、共同完成的工程項目。

應該推廣使用在實踐中總結出來的開發(fā)軟件的成功技術和方法，并繼續(xù)研究探索。

應該開發(fā)和使用更好的軟件工具。

總之，為了解決軟件危機，既要有技術措施(方法和工具)，又要有必要的組織管理措施。

1.2
1.2.1 軟件工程的介紹

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

軟件工程的本質特性：

軟件工程關注于大型程序的構造

軟件工程的中心課題是控制復雜性

軟件經(jīng)常變化

開發(fā)軟件的效率非常重要

和諧地合作是開發(fā)軟件的關鍵

軟件必須有效地支持它的用戶

在軟件工程領域中是由具有一種文化背景的人替具有另一種文化背景的人創(chuàng)造產(chǎn)品

1.2.2 軟件工程的基本原理

用分階段的生命周期計劃嚴格管理

堅持進行階段評審

實行嚴格的產(chǎn)品控制

采用現(xiàn)代程序設計技術

結果應能清楚地審查

開發(fā)小組的人員應該少而精

承認不斷改進軟件工程實踐的必要性

1.2.3 軟件工程方法學

軟件工程包括技術和管理兩方面的內容。

軟件工程方法學3要素：方法、工具、過程

1. 傳統(tǒng)方法學(生命周期方法學或結構化范型)——強調自頂向下

2. 面向對象方法學——強調主動地多次反復迭代

面向對象方法學4個要點：對象、類、繼承、消息

1.3 軟件生命周期 （必考）

三個時期八個階段：軟件生命周期由軟件定義、軟件開發(fā)和運行維護(也稱為軟件維護)三個時期組成，每個時期又進一步劃分成若干個階段。

1.4 軟件過程

1.4.1 瀑布模型

1.4.2 快速原型模型

1.4.3 增量模型

1.4.4 螺旋模型

1.4.5 噴泉模型

第2章 可行性研究

2.1 可行性研究的任務

可行性研究的目的：不是解決問題，而是確定問題是否值得去解決?？尚行匝芯康膶嵸|：進行一次大大壓縮簡化了的系統(tǒng)分析和設計的過程，也就是在較高層次上以較抽象的方式進行的系統(tǒng)分析和設計的過程。

可行性研究的內容：首先進一步分析和澄清問題定義，導出系統(tǒng)的邏輯模型；然后從系統(tǒng)邏輯模型出發(fā)，探索若干種可供選擇的主要解法(即系統(tǒng)實現(xiàn)方案)；對每種解法都研究它的可行性，至少應該從三方面研究每種解法的可行性 。

主要方面：技術可行性，經(jīng)濟可行性，操作可行性，

其他方面：運行可行性， 法律可行性，

2.2 可行性研究過程

1. 復查系統(tǒng)規(guī)模和目標

2. 研究目前正在使用的系統(tǒng)

3. 導出新系統(tǒng)的高層邏輯模型4. 進一步定義問題5. 導出和評價供選擇的解法6. 推薦行動方針7. 草擬開發(fā)計劃8. 書寫文檔提交審查2.3 系統(tǒng)流程圖

系統(tǒng)流程圖：是概括地描繪物理系統(tǒng)的傳統(tǒng)工具。表達的是數(shù)據(jù)在系統(tǒng)各部件之間流動的情況，而不是對數(shù)據(jù)進行加工處理的控制過程。

2.4 數(shù)據(jù)流圖

2.4.1 符號

基本符號：

數(shù)據(jù)存儲：數(shù)據(jù)存儲是處于靜止狀態(tài)的數(shù)據(jù)； 數(shù)據(jù)流：數(shù)據(jù)流是處于運動中的數(shù)據(jù)。

附加符號：星號（*）：表示“與”關系

加號（+）：表示“或”關系異或（⊕）：表示互斥關系

2.5 數(shù)據(jù)字典

數(shù)據(jù)流圖和數(shù)據(jù)字典共同構成系統(tǒng)的邏輯模型。2.5.1 數(shù)據(jù)字典的內容數(shù)據(jù)字典的組成：數(shù)據(jù)流 數(shù)據(jù)流分量(即數(shù)據(jù)元素) 數(shù)據(jù)存儲 處理

2.5.2 定義數(shù)據(jù)的方法

方法：對數(shù)據(jù)自頂向下分解。 數(shù)據(jù)組成方式(三種基本類型)：順序 選擇 重復 附加類型：可選

符號：=意思是等價于(或定義為)；+意思是和(即，連接兩個分量)；［ ］意思是或(即，從方括弧內列出的若干個分量中選擇一個)，通常用“|”號隔開供選擇的分量；{ }意思是重復(即，重復花括弧內的分量)；常常使用上限和下限進一步注釋表示重復的花括弧。( )意思是可選(即，圓括弧里的分量可有可無)。

2.5.3 數(shù)據(jù)字典的實現(xiàn)

計算機實現(xiàn) 人工實現(xiàn)

2.5 成本/效益分析

2.6.1 成本估計：1. 代碼行技術 2. 任務分解技術 3. 自動估計成本技術

2.6.2 成本/效益分析的方法

成本/效益分析涉及的4個概念： 1. 貨幣的時間價值2. 投資回收期3. 純收入4. 投資回收率：P = F1/( 1 + j ) + F2/( 1 + j )2 + …+ Fn( 1 + j )n

第3章 需求分析

需求分析的任務：需求分析是軟件定義時期的最后一個階段，它的基本任務是準確地回答“系統(tǒng)必須做什么?”這個問題。確定系統(tǒng)必須完成哪些工作，也就是對目標系統(tǒng)提出完整、準確、清晰、具體的要求。系統(tǒng)分析員應該寫出軟件需求規(guī)格說明書，以書面形式準確地描述軟件需求

3.1 需求分析的任務

確定對系統(tǒng)的綜合要求 分析系統(tǒng)的數(shù)據(jù)要求 導出系統(tǒng)的邏輯模型 修正系統(tǒng)開發(fā)計劃

3.1.1 確定對系統(tǒng)的綜合要求

1. 功能需求

2. 性能需求3. 可靠性和可用性需求4. 出錯處理需求5. 接口需求6. 約束7. 逆向需求8. 將來可能提出的要求

3.1.2 分析系統(tǒng)的數(shù)據(jù)要求

建立數(shù)據(jù)模型——ER圖 描繪數(shù)據(jù)結構——層次方框圖和Warnier圖 數(shù)據(jù)結構規(guī)范化

3.2 與用戶溝通獲取需求的方法

訪談：1. 正式訪談 2. 非正式訪談 3. 調查表 4. 情景分析技術

面向數(shù)據(jù)流自頂向下求精簡易的應用規(guī)格說明技術 快速建立軟件原型：(1) 第四代技術（4GL）(2) 可重用的軟件構件 (3) 形式化規(guī)格說明和原型環(huán)境

3.3分析建模與規(guī)格說明

3.3.1 分析建模

需求分析過程應該建立3種模型：數(shù)據(jù)模型 功能模型 行為模型數(shù)據(jù)字典是分析模型的核心

實體-聯(lián)系圖用于建立數(shù)據(jù)模型的圖形數(shù)據(jù)流圖是建立功能模型的基礎

狀態(tài)轉換圖是行為建模的基礎

3.4 實體-聯(lián)系圖

數(shù)據(jù)模型中包含3種相互關聯(lián)的信息：數(shù)據(jù)對象、數(shù)據(jù)對象的屬性、數(shù)據(jù)對象彼此間相互連接的關系

3.4 狀態(tài)轉換圖

3.6.1 狀態(tài)

狀態(tài)圖分類：表示系統(tǒng)循環(huán)運行過程，通常不關心循環(huán)是怎樣啟動的。表示系統(tǒng)單程生命期，需要標明初始狀態(tài)和最終狀態(tài)。

3.6.2 事件

事件就是引起系統(tǒng)做動作或(和)轉換狀態(tài)的控制信息。

3.6.3 符號

3.6 其他圖形工具

3.7.1 層次方框圖

3.7.2 Warnier圖

3.7.3 IPO圖

3.7 驗證軟件需求（重點）

3.8.1 從哪些方面驗證軟件需求的正確性

一致性 完整性 現(xiàn)實性 有效性

第五章 總體設計

5.1 設計過程

由兩個主要階段組成：系統(tǒng)設計階段，確定系統(tǒng)的具體實現(xiàn)方案：設想供選擇的方案 選取合理的方案 推薦最佳方案結構設計階段，確定軟件結構:功能分解 設計軟件結構 設計數(shù)據(jù)庫 制定測試文檔 書寫文檔 審查和復查

5.2 設計原理

5.2.1 模塊化

模塊化的作用：采用模塊化原理可以使軟件結構清晰，不僅容易設計也容易閱讀和理解。模塊化使軟件容易測試和調試，因而有助于提高軟件的可靠性。模塊化能夠提高軟件的可修改性。模塊化也有助于軟件開發(fā)工程的組織管理。

5.2.2 抽象

5.2.3 逐步求精

5.2.4 信息隱藏和局部化

5.2.5 模塊獨立

盡量使用數(shù)據(jù)耦合，少用控制耦合和特征耦合，限制公共環(huán)境耦合的范圍，
完全不用內容耦合。

七種內聚的優(yōu)劣評分結果：高內聚：功能內聚 順序內聚 中內聚：通信內聚 過程內聚 低內聚：時間內聚 邏輯內聚 偶然內聚

5.2 啟發(fā)規(guī)則

1. 改進軟件結構提高模塊獨立性

2. 模塊規(guī)模應該適中

3. 深度、寬度、扇出和扇入都應適當

4. 模塊的作用域應該在控制域之內

5. 力爭降低模塊接口的復雜程度

6. 設計單入口單出口的模塊

7. 模塊功能應該可以預測

5.4 描繪軟件結構的圖形工具

5.4.1 層次圖和HIPO圖

1. 層次圖(H圖)層次圖用來描繪軟件的層次結構。很適于在自頂向下設計軟件的過程中使用。

2. HIPO圖

5.4.2 結構圖

5.4 面向數(shù)據(jù)流的設計方法

結構化設計方法(簡稱SD方法)，也就是基于數(shù)據(jù)流的設計方法。

5.5.1 概念

面向數(shù)據(jù)流的設計方法把信息流映射成軟件結構，信息流的類型決定了映射的方法。信息流有兩種類型：變換流 事務流

第6章 詳細設計

6.1 結構程序設計

經(jīng)典的結構程序設計：

只允許使用順序、IF-THEN-ELSE型分支和DO-WHILE型循環(huán)這3種基本控制結構；擴展的結構程序設計：

如果除了上述3種基本控制結構之外，還允許使用DO-CASE型多分支結構和DO-UNTIL型循環(huán)結構；修正的結構程序設計：

再加上允許使用LEAVE(或BREAK)結構。

6.2 人機界面設計

6.2.1 設計問題

設計人機界面過程中會遇到的4個問題：系統(tǒng)響應時間：長度 易變性 用戶幫助設施：集成的幫助設施附加的幫助設施出錯信息處理命令交互 6.2.3 人機界面設計指南

一般交互指南信息顯示指南數(shù)據(jù)輸入指南6.3過程設計的工具

6.3.1 程序流程圖（程序框圖）

程序流程圖的主要缺點：程序流程圖本質上不是逐步求精的好工具，它誘使程序員過早地考慮程序的控制流程，而不去考慮程序的全局結構。程序流程圖中用箭頭代表控制流，因此程序員不受任何約束，可以完全不顧結構程序設計的精神，隨意轉移控制。程序流程圖不易表示數(shù)據(jù)結構。

6.3.2 盒圖(N-S圖)

盒圖具有下述特點：功能域明確。不可能任意轉移控制。很容易確定局部和全程數(shù)據(jù)的作用域。很容易表現(xiàn)嵌套關系，也可以表示模塊的層次結構。6.3.3 PAD圖

它用二維樹形結構的圖來表示程序的控制流，將這種圖翻譯成程序代碼比較容易。

PAD圖的主要優(yōu)點如下：使用表示結構化控制結構的PAD符號設計出來的程序必然是結構化程序。PAD圖所描繪的程序結構十分清晰。PAD圖表現(xiàn)程序邏輯易讀、易懂、易記?！∪菀讓AD圖轉換成高級語言源程序，這種轉換可用軟件工具自動完成。即可表示程序邏輯，也可描繪數(shù)據(jù)結構。PAD圖的符號支持自頂向下、逐步求精方法的使用。6.3.4 判定表

判定表卻能夠清晰地表示復雜的條件組合與應做的動作之間的對應關系。

所有條件

條件組合矩陣

所有動作

條件組合
對應的動作

判定表的缺點：

判定表的含義不是一眼就能看出來的，初次接觸這種工具的人理解它需要有一個簡短的學習過程。

當數(shù)據(jù)元素的值多于兩個時，判定表的簡潔程度也將下降。

6.3.5 判定樹

判定樹的優(yōu)點：

它的形式簡單，一眼就可以看出其含義，因此易于掌握和使用。

判定樹的缺點：

簡潔性不如判定表，數(shù)據(jù)元素的同一個值往往要重復寫多遍，而且越接近樹的葉端重復次數(shù)越多。

畫判定樹時分枝的次序可能對最終畫出的判定樹的簡潔程度有較大影響。

6.3.6 過程設計語言(偽碼）

偽代碼的基本控制結構：

簡單陳述句結構：避免復合語句。

判定結構：IF_THEN_ELSE或CASE_OF結構。

選擇結構：WHILE_DO或REPEAT_UNTIL結構。

PDL的優(yōu)點：

可以作為注釋直接插在源程序中間。有助于保持文檔和程序的一致性，提高了文檔的質量。

可以使用普通的正文編輯程序或文字處理系統(tǒng)，很方便地完成PDL的書寫和編輯工作。

已經(jīng)有自動處理程序存在，而且可以自動由PDL生成程序代碼。

PDL的缺點：

不如圖形工具形象直觀，描述復雜的條件組合與動作間的對應關系時，不如判定表清晰簡單。

6.4 面向數(shù)據(jù)結構的設計方法

面向數(shù)據(jù)結構的設計方法的最終目標是得出對程序處理過程的描述。

6.4.1Jackson

A由B、C、D 3個元素順序組成 根據(jù)條件A是B或C或D中的某一個 A由B出現(xiàn)N次(N≥0)組成

6.4.2 改進的Jackson圖

6.4.3 Jackson方法

6.5 程序復雜程度的定量度量

6.5.1 McCabe方法

1. 流圖（程序圖）

2. 計算環(huán)形復雜度的方法

V(G)=流圖中的區(qū)域數(shù)

V(G)=E-N+2

其中E是流圖中的邊數(shù)，N是結點數(shù)

V(G)=P+1

其中P是流圖中判定結點的數(shù)目

6.5.2 Halstead方法

令N1為程序中運算符出現(xiàn)的總次數(shù)，N2為操作數(shù)出現(xiàn)的總次數(shù)，程序長度N定義為：

N=N1+N2

程序中使用的不同運算符(包括關鍵字)的個數(shù)n1，以及不同操作數(shù)(變量和常數(shù))的個數(shù)n2。預測程序長度的公式如下：

H = n1 log2n1 + n2 log2n2

預測程序中包含錯誤的個數(shù)的公式如下：

E = N log2 (n1+n2)/3000

第7章 實現(xiàn)

編碼和測試統(tǒng)稱為實現(xiàn)。

7.1編碼

7.1.1 選擇程序設計語言

主要的實用標準：

系統(tǒng)用戶的要求

可以使用的編譯程序

可以得到的軟件工具

工程規(guī)模

程序員的知識

軟件可移植性要求

軟件的應用領域

7.1.2 編碼風格

1. 程序內部的文檔:恰當?shù)臉俗R符 適當?shù)淖⒔?程序的視覺組織

2. 數(shù)據(jù)說明

3. 語句構造

4. 輸入輸出

5. 效率:程序運行時間 存儲器效率 輸入輸出的效率

7.2軟件測試基礎

7.2.1 軟件測試的目標

測試是為了發(fā)現(xiàn)程序中的錯誤而執(zhí)行程序的過程；

好的測試方案是極可能發(fā)現(xiàn)迄今為止尚未發(fā)現(xiàn)的錯誤的測試方案；

成功的測試是發(fā)現(xiàn)了至今為止尚未發(fā)現(xiàn)的錯誤的測試。

7.2.3 測試方法

黑盒測試(功能測試)：

把程序看作一個黑盒子；

完全不考慮程序的內部結構和處理過程；

是在程序接口進行的測試。

白盒測試(結構測試)：

把程序看成裝在一個透明的盒子里；

測試者完全知道程序的結構和處理算法；

按照程序內部的邏輯測試程序，檢測程序中的主要執(zhí)行通路是否都能按預定要求正確工作。

7.2.4 測試步驟

1. 模塊測試(單元測試)

保證每個模塊作為一個單元能正確運行；

發(fā)現(xiàn)的往往是編碼和詳細設計的錯誤。

2. 子系統(tǒng)測試

把經(jīng)過單元測試的模塊放在一起形成一個子系統(tǒng)來測試；

著重測試模塊的接口。

3. 系統(tǒng)測試

把經(jīng)過測試的子系統(tǒng)裝配成一個完整的系統(tǒng)來測試；

發(fā)現(xiàn)的往往是軟件設計中的錯誤，也可能發(fā)現(xiàn)需求說明中的錯誤；

不論是子系統(tǒng)測試還是系統(tǒng)測試，都兼有檢測和組裝兩重含義，通常稱為集成測試。

4. 驗收測試(確認測試)

把軟件系統(tǒng)作為單一的實體進行測試；

它是在用戶積極參與下進行的，而且可能主要使用實際數(shù)據(jù)(系統(tǒng)將來要處理的信息)進行測試；

發(fā)現(xiàn)的往往是系統(tǒng)需求說明書中的錯誤。

5. 平行運行

7.2.5 測試階段的信息流

輸入信息有兩類：

軟件配置，包括需求說明書、設計說明書和源程序清單等；

測試配置，包括測試計劃和測試方案。

7.3 單元測試

單元測試集中檢測模塊；

單元測試和編碼屬于軟件過程的同一個階段；

可以應用人工測試和計算機測試這樣兩種不同類型的測試方法；

單元測試主要使用白盒測試技術，對多個模塊的測試可以并行地進行。

7.3.1 測試重點

模塊接口

局部數(shù)據(jù)結構

重要的執(zhí)行通路

出錯處理通路

邊界條件

7.3.2 代碼審查

由審查小組正式進行測試稱為代碼審查；

一次審查會上可以發(fā)現(xiàn)許多錯誤，可以減少系統(tǒng)驗證的總工作量。

7.3.3 計算機測試

驅動程序是一個“主程序”，它接收測試數(shù)據(jù)，傳送給被測試的模塊，并且印出有關的結果。

存根程序代替被測試的模塊所調用的模塊。它使用被它代替的模塊的接口，可能做最少量的數(shù)據(jù)操作，印出對入口的檢驗或操作結果，并且把控制歸還給調用它的模塊。

7.4 集成測試

集成測試是測試和組裝軟件的系統(tǒng)化技術，主要目標是發(fā)現(xiàn)與接口有關的問題。

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

7.4.3 不同集成測試策略的比較

混合策略：

改進的自頂向下測試方法

混合法

7.4.4 回歸測試

7.5 確認測試

確認測試也稱為驗收測試，它的目標是驗證軟件的有效性。

7.5.3 Alpha和Beta測試

Alpha測試是在受控的環(huán)境中進行的。

Beta測試是軟件在開發(fā)者不能控制的環(huán)境中的“真實”應用。

1. 接口測試

2. 路徑測試

3. 功能測試

4. 健壯性測試

5. 性能測試

6. 用戶界面測試

7. 信息安全測試

8. 壓力測試

9. 可靠性測試

10. 安裝/反安裝測試確認測試也稱為驗收測試，它的目標是驗證軟件的有效性。

Alpha測試是在受控的環(huán)境中進行的。

Beta測試是軟件在開發(fā)者不能控制的環(huán)境中的“真實”應用。

4. 接口測試

5. 路徑測試

6. 功能測試

4. 健壯性測試

5. 性能測試

6. 用戶界面測試

7. 信息安全測試

8. 壓力測試

9. 可靠性測試

10. 安裝/反安裝測試

7.6 白盒測試技術

7.6.1 邏輯覆蓋

語句覆蓋

判定覆蓋 ：比語句覆蓋強，但對程序邏輯的覆蓋程度仍不高。

條件覆蓋 ：判定覆蓋不一定包含條件覆蓋，條件覆蓋也不一定包含判定覆蓋。

判定/條件覆蓋 ：有時判定/條件覆蓋也并不比條件覆蓋更強。

條件組合覆蓋 ：條件組合覆蓋標準的測試數(shù)據(jù)并不一定能使程序中的每條路徑都執(zhí)行到。

6. 點覆蓋（語句覆蓋標準相同）

7. 邊覆蓋（判定覆蓋一致)

8. 路徑覆蓋

7.6.2 控制結構測試覆蓋

1. 基本路徑測試

基本路徑測試是Tom McCabe提出的一種白盒測試技術。

首先計算程序的環(huán)形復雜度；

以該復雜度為指南定義執(zhí)行路徑的基本集合；

2.條件測試

從該基本集合導出的測試用例可保證程序中的每條語句至少執(zhí)行一次，而且每個條件在執(zhí)行時都將分別取真、假兩種值。

3. 循環(huán)測試

循環(huán)測試是一種白盒測試技術，它專注于測試循環(huán)結構的有效性。

在結構化的程序中通常只有3種循環(huán)，即簡單循環(huán)、串接循環(huán)和嵌套循環(huán)。

7.7 黑盒測試技術

7.7.1 等價劃分

7.7.2 邊界值分析

7.7.3 錯誤推測

7.9 軟降可靠性

7.9.1 基本概念

軟件可靠性：

程序在給定的時間間隔內，按照規(guī)格說明書的規(guī)定成功地運行的概率。

軟件的可用性：

程序在給定的時間點，按照規(guī)格說明書的規(guī)定，成功地運行的概率。

第8章 維護

軟件工程的目的是要提高軟件的可維護性，減少軟件維護所需要的工作量，降低軟件系統(tǒng)的總成本。

8.1 軟件維護的定義

軟件維護：在軟件已經(jīng)交付使用之后，為了改正錯誤或滿足新的需要而修改軟件的過程。

可分為4項活動：

改正性維護

適應性維護

完善性維護

預防性維護

8.2軟件維護的特點

8.2.1 結構化維護與非結構化維護差別巨大

8.2.2 維護的代價高昂

8.2.3 維護的問題很多

8.3軟件維護過程

1.維護組織 2.維護報告 3.維護的事件流 4.保存維護記錄 5.評價維護活動

8.4 軟件的可維護性

決定軟件可維護性的因素主要有7個：

可理解性

可測試性

可修改性

可靠性

可移植性

可使用性

效率

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

9.1面向對象方法學概述

9.1.1面向對象方法學要點

（1)認為客觀世界是由各種對象組成的，任何事物都是對象

（2)把所有對象都劃分成各種類對象，每個對象類都定義了一組數(shù)據(jù)和一組方法

（3)按照子類和父類的關系，把若干個對象類組成一個層次結構的系統(tǒng)

（4)對象彼此之間僅能通過傳遞消息相互聯(lián)系

9.1.2 面向對象開發(fā)方法

面向對象=對象+類 +繼承+通信

9.1.4 面向對象方法組成

面向對象的分析

面向對象的設計

面向對象的程序設計

9.1.6 面向對象方法的優(yōu)點

1.與人類習慣的思維方式一致

2.穩(wěn)定性好

3.可重用性好

4.可維護性好

5.較易開發(fā)大型軟件產(chǎn)品

9.2 面向對象的概念

9.2.1 對象

是客觀事物或概念的抽象表述，即對客觀存在的事物的描述統(tǒng)稱為對象，對象可以是事、物、或抽象概念 ，是將一組數(shù)據(jù)和使用該數(shù)據(jù)的一組基本操作或過程封裝在一起的實體。

對象的特點

(1) 以數(shù)據(jù)為中心。

(2) 對象是主動的。

(3) 實現(xiàn)了數(shù)據(jù)封裝。

(4) 本質上具有并行性。

(5) 模塊獨立性好。

9.2.2 類

是一組具有相同屬性和相同操作的對象的集合。

9.2.3 實例

由某個特定的類所描述的一個具體的對象。

9.2.4 消息

向對象發(fā)出的服務請求（互相聯(lián)系、協(xié)同工作等）。一個消息包含3個部分：接收消息的對象，消息名，消息變元

9.2.5 方法

方法就是對象所能執(zhí)行的操作，也就是類中所定義的服務。

9.2.6 屬性

屬性就是類中所定義的數(shù)據(jù)，它是對客觀世界實體所具有的性質的抽象。

9.2.7 封裝

對象封裝了對象的數(shù)據(jù)以及對這些數(shù)據(jù)的操作。

9.2.8 繼承(I)

繼承是子類自動地共享基類中定義的數(shù)據(jù)和方法的機制。

單重繼承：子類僅從一個父類繼承屬性和方法

多重繼承：子類可從多個父類繼承屬性和方法

9.2.9 多態(tài)性

9.2.10 重載

9.3 面向對象建模(II)

面向對象開發(fā)軟件，需要建立3種形式的模型。

對象模型。描述系統(tǒng)數(shù)據(jù)結構—數(shù)據(jù)結構。

動態(tài)模型。描述系統(tǒng)控制結構—執(zhí)行操作。

功能模型。描述系統(tǒng)功能—數(shù)值變化。

9.4 對象模型

9.4.1類圖的基本符號(I)

1. 定義類

2. 定義屬性

可見性 屬性名 ：類型 = 缺省值 {性質串}

可見性(visibility)表示該屬性對類外的元素是否可見。

分為：

public（+） 公有的，即模型中的任何類都可以訪問該屬性。

private（-） 私有的，表示不能被別的類訪問。

protected（#） 受保護的，表示該屬性只能被該類及其子類訪問。

如果可見性未申明，表示其可見性不確定。

3. 定義操作

可見性 操作名（參數(shù)表)：返回類型{性質串}

9.4.2 表示關系的符號(I)

9.4.2.1 關聯(lián)(I)

關聯(lián)表示兩個類的對象之間存在某種語義上的聯(lián)系。

（1） 普通關聯(lián)

遞歸關聯(lián)：一個類與本身有關聯(lián)關系

（3） 限定關聯(lián)

（4） 關聯(lián)類

9.4.2.2 聚集(I)

（1） 共享聚集

如果在聚集關系中處于部分方的對象可同時參與多個處于整體方對象的構成，則該聚集稱為共享聚集。

（2） 組合聚集

如果部分類完全隸屬于整體類，部分與整體共存，整體不存在了部分也會隨之消失，則該聚集稱為組合聚集。

9.4.2.3 泛化(I)

（1）普通泛化

（2）受限泛化

預定義的約束有4種： 多重、不相交、完全和不完全。

9.4.2.4 依賴

9.4.2.5 細化

9.5動態(tài)模型

9.6功能模型

9.6.1用例圖

模型元素：系統(tǒng)、行為者、用例及用例之間的關系(擴展關系、使用關系）

用例的實例是腳本

第10章 面向對象分析

10.1 面向對象分析的基本過程

面向對象分析：抽取和整理用戶需求并建立問題域精確模型的過程.

理解----用戶、分析員和領域專家

表達----需求規(guī)格說明書（對象模型、動態(tài)模型、功能模型）

驗證----二義性，完善性

對象模型最基本、最重要、最核心。

靜態(tài)結構（對象模型）

3個子模型 交互次序（動態(tài)模型）

數(shù)據(jù)變換（功能模型）

復雜問題的對象模型的5個層次

面向對象分析的過程

尋找類與對象

識別結構

識別主題

定義屬性

建立動態(tài)模型

建立功能模型

定義服務

10.2 需求陳述

需求陳述是闡明“做什么”，而不是“怎樣做”

問題范圍

功能需求

性能需求

應用環(huán)境

假設條件

第11章 面向對象設計

11.1 面向對象設計的準則

1. 模塊化 2. 抽象 3. 信息隱藏

4. 弱耦合

耦合指不同對象之間相互關聯(lián)的緊密程度。

對象之間的耦合分兩類：

交互耦合

如果對象之間的耦合通過消息連接來實現(xiàn)，則這種耦合就是交互耦合。交互耦合應盡可能松散 。

繼承耦合

與交互耦合相反，應該提高繼承耦合程度。

5. 強內聚

在面向對象設計中存在下述3種內聚：

服務內聚：一個服務應該完成一個且僅完成一個功能。

類內聚：一個類應該只有一個用途，它的屬性和服務應該是高內聚的。

一般-特殊內聚：設計出的一般-特殊結構，應該符合多數(shù)人的概念

6. 可重用

11.2 啟發(fā)規(guī)則

1. 設計結果應該清晰易懂

2. 一般-特殊結構的深度應適當

3. 設計簡單的類

4. 使用簡單的協(xié)議

5. 使用簡單的服務

6. 把設計變動減至最小

第13章 軟件項目管理

13.1估算軟件規(guī)模

13.1.1 代碼行技術

估算方法：

由多名有經(jīng)驗的軟件工程師分別做出估計。

每個人都估計程序的最小規(guī)模(a)、最大規(guī)模(b)和最可能的規(guī)模(m)，

分別算出這3種規(guī)模的平均值之后，再用下式計算程序規(guī)模的估計值：

單位：

LOC或KLOC。

代碼行技術的優(yōu)點：

代碼是所有軟件開發(fā)項目都有的“產(chǎn)品”，而且很容易計算代碼行數(shù)；

有大量參考文獻和數(shù)據(jù) 。

代碼行技術的缺點：

源程序僅是軟件配置的一個成分，由源程序度量軟件規(guī)模不太合理；

用不同語言實現(xiàn)同一個軟件所需要的代碼行數(shù)并不相同；

不適用于非過程性語言。

13.1.2 功能點技術

功能點技術依據(jù)對軟件信息域特性和軟件復雜性的評估結果，估算軟件規(guī)模。

這種方法用功能點(FP)為單位度量軟件規(guī)模。

1. 信息域特性

輸入項數(shù)(Inp)、輸出項數(shù)(Out)、查詢數(shù)(Inq)、主文件數(shù)(Maf)、外部接口數(shù)(Inf)

每個特征根據(jù)其復雜程度分配一個功能點數(shù)，即信息域特征系數(shù)a1，a2，a3，a4，a5

2. 估算功能點的步驟

(1) 計算未調整的功能點數(shù)UFP

UFP=a1×Inp+a2×Out+a3×Inq+a4×Maf+a5×Inf

(2) 計算技術復雜性因子TCF

技術因素對軟件規(guī)模的綜合影響程度DI：

技術復雜性因子TCF由下式計算：

TCF = 0.65 + 0.01 × DI

因為DI的值在0~70之間，所以TCF的值在0.65~1.35之間。

(3) 計算功能點數(shù)FP

FP = UFP × TCF

功能點技術優(yōu)點：與所用的編程語言無關，比代碼行技術更合理。

功能點技術缺點：在判斷信息域特性復雜級別和技術因素的影響程度時主觀因素較大，對經(jīng)驗依賴性較強。

13.2 工作量估算

13.2.1 靜態(tài)單變量模型

E = A + B × (ev) C

ev是估算變量（KLOC或FP）。

13.2.2 動態(tài)多變量模型

動態(tài)多變量模型也稱為軟件方程式，該模型把工作量看作是軟件規(guī)模和開發(fā)時間這兩個變量的函數(shù)。

E=(LOC×B0.333/P)3×(1/t)4

13.2.3 COCOMO2模型（構造性成本模型）

3個層次的估算模型：

應用系統(tǒng)組成模型：這個模型主要用于估算構建原型的工作量，模型名字暗示在構建原型時大量使用已有的構件。

早期設計模型：這個模型適用于體系結構設計階段。

后體系結構模型：這個模型適用于完成體系結構設計之后的軟件開發(fā)階段。

COCOMO2使用的5個分級因素：項目先例性、開發(fā)靈活性、風險排除度、項目組凝聚力、過程成熟度

13.3 進度計劃

13.3.1 估算開發(fā)時間

Brooks規(guī)律：向一個已經(jīng)延期的項目增加人力，只會使得它更加延期。

13.3.2 Gantt圖

Gantt圖的主要優(yōu)點：

Gantt圖能很形象地描繪任務分解情況，以及每個子任務(作業(yè))的開始和結束時間。

具有直觀簡明和容易掌握、容易繪制的優(yōu)點。

Gantt圖的3個主要缺點：

不能顯式地描繪各項作業(yè)彼此間的依賴關系；

進度計劃的關鍵部分不明確，難于判定哪些部分應當是主攻和主控的對象；

計劃中有潛力的部分及潛力的大小不明確，往往造成潛力的浪費。

13.3.3 工程網(wǎng)絡

工程網(wǎng)絡是系統(tǒng)分析和系統(tǒng)設計的強有力的工具。

13.3.4 估算工程進度

計算最早時刻EET使用下述3條簡單規(guī)則：

考慮進入該事件的所有作業(yè)；

對于每個作業(yè)都計算它的持續(xù)時間與起始事件的EET之和；

選取上述和數(shù)中的最大值作為該事件的最早時刻EET。

計算最遲時刻LET使用下述3條規(guī)則：

考慮離開該事件的所有作業(yè)；

從每個作業(yè)的結束事件的最遲時刻中減去該作業(yè)的持續(xù)時間；

選取上述差數(shù)中的最小值作為該事件的最遲時刻LET。

13.3.5關鍵路徑

關鍵事件：EET=LET

13.3.5 機動時間=(LET)結束－(EET)開始－持續(xù)時間

=右下角－左上角－持續(xù)時間

13.4 人員組織

13.4.1 民主制程序員組

如果小組內有n個成員，則可能的通信信道共有n(n-1)/2條。

13.4.2 主程序員組

主程序員組的兩個重要特性：專業(yè)化、 層次性

13.4.3 現(xiàn)代程序員組

13.5質量保證

13.5.1 軟件質量

13.5.2 軟件質量保證措施

13.6 軟件配置管理

基于非執(zhí)行的測試（復審或評審），主要用來保證在編碼之前各階段產(chǎn)生的文檔的質量；

基于執(zhí)行的測試（軟件測試），需要在程序編寫出來之后進行，它是保證軟件質量的最后一道防線；

程序正確性證明，使用數(shù)學方法嚴格驗證程序是否與對它的說明完全一致。

1. 技術復審的必要性

2. 走查:參與者驅動法、文檔驅動法

3. 審查：綜述 準備 審查 返工 跟蹤

4. 程序正確性證明

軟件配置管理是在軟件的整個生命期內管理變化的一組活動。

具體地說，這組活動用來：①標識變化；②控制變化；③確保適當?shù)貙崿F(xiàn)了變化；④向需要知道這類信息的人報告變化。

軟件配置管理的目標：使變化更正確且更容易被適應，在必須變化時減少所需花費的工作量。

13.6.1 軟件配置

1.軟件過程的輸出信息（軟件配置項）：

計算機程序（源代碼和可執(zhí)行程序）；

描述計算機程序的文檔（供技術人員或用戶使用）；

數(shù)據(jù)（程序內包含的或在程序外的）

2. 基線

基線就是通過了正式復審的軟件配置項。

13.6.2 軟件配置管理過程

軟件配置管理主要有5項任務：

1. 標識軟件配置中的對象：基本對象、聚集對象

2. 版本控制

3. 變化控制

4. 配置審計

5. 狀態(tài)報告

13.7 能力成熟度模型

1. 初始級

軟件過程的特征是無序的，有時甚至是混亂的。

2. 可重復級

軟件機構建立了基本的項目管理過程(過程模型)，可跟蹤成本、進度、功能和質量。

3. 已定義級

軟件機構已經(jīng)定義了完整的軟件過程（過程模型），軟件過程已經(jīng)文檔化和標準化。

4. 已管理級

軟件機構對軟件過程（過程模型和過程實例）和軟件產(chǎn)品都建立了定量的質量目標，所有項目的重要的過程活動都是可度量的。

5. 優(yōu)化級

軟件機構集中精力持續(xù)不斷地改進軟件過程。這一級的軟件機構是一個以防止出現(xiàn)缺陷為目標的機構，它有能力識別軟件過程要素的薄弱環(huán)節(jié)，并有足夠的手段改進它們。