軟件工程導論復習重點總結很全第六版

1、第1章 軟1.1 軟件危機1.1.1 軟件危機的介紹軟件危機 （軟件蕭條、 軟件困擾 ） ：是指在計算機軟件的開發(fā)和維護過程中所遇到的一系列嚴 重問題。軟件危機包含下述兩方面的問題： 如何開發(fā)軟件，滿足對軟件日益增長的需求； 如何維護數(shù)量不斷膨脹的已有軟件。對軟件開發(fā)成本和進度的估計常常很不準確； 用戶對“已完成的”軟件系統(tǒng)不滿意的現(xiàn)象經常發(fā)生； 軟件產品的質量往往靠不住； 軟件常常是不可維護的； 軟件通常沒有適當?shù)奈臋n資料； 軟件成本在計算機系統(tǒng)總成本中所占的比例逐年上升； 軟件開發(fā)生產率提高的速度，遠遠跟不上計算機應用迅速普及深入的趨勢軟件危機的典型表現(xiàn)：（1）（2）（3）（4）（5）（6

2、）（7）1.1.2 產生軟件危機的原因（1）與軟件本身的特點有關 （2）與軟件開發(fā)與維護的方法不正確有關1.1.3 消除軟件危機的途徑對計算機軟件有正確的認識。認識到軟件開發(fā)是一種組織良好、管理嚴密、各類人員協(xié)同配合、共同完成的工程項目。 應該推廣使用在實踐中總結出來的開發(fā)軟件的成功技術和方法，并繼續(xù)研究探索。 應該開發(fā)和使用更好的軟件工具?？傊瑸榱私鉀Q軟件危機，既要有技術措施（ 方法和工具 ） ，又要有必要的組織管理措施。1.21.2.1 軟件工程的介紹軟件工程： 是指導計算機軟件開發(fā)和維護的一門工程學科。采用工程的概念、原理、技術和 方法來開發(fā)與維護軟件， 把經過時間考驗而證明正確的管理

3、技術和當前能夠得到的最好的技 術方法結合起來，以經濟地開發(fā)出高質量的軟件并有效地維護它， 這就是軟件工程。 （期中 考）軟件工程的本質特性： 軟件工程關注于大型程序的構造 軟件工程的中心課題是控制復雜性軟件經常變化 開發(fā)軟件的效率非常重要 和諧地合作是開發(fā)軟件的關鍵 軟件必須有效地支持它的用戶 在軟件工程領域中是由具有一種文化背景的人替具有另一種文化背景的人創(chuàng)造產品1.2.2 軟件工程的基本原理用分階段的生命周期計劃嚴格管理堅持進行階段評審實行嚴格的產品控制采用現(xiàn)代程序設計技術結果應能清楚地審查開發(fā)小組的人員應該少而精承認不斷改進軟件工程實踐的必要性1.2.3 軟件工程方法學軟件工程包括技術和

4、管理兩方面的內容。軟件工程方法學3要素：方法、工具、過程1. 傳統(tǒng)方法學（生命周期方法學或結構化范型）一一強調自頂向下2. 面向對象方法學一一強調主動地多次反復迭代面向對象方法學4個要點：對象、類、繼承、消息1.3 軟件生命周期（必考）三個時期八個階段： 軟件生命周期由軟件定義、軟件開發(fā)和運行維護（也稱為軟件維護）三個時期組成，每個時期又進一步劃分成若干個階段。三個時期:八個階段:軟件定義問題定義 可行性研究 需求分析軟件生命周期f軟件開發(fā)f概要設計 1J詳細設計 丁編碼和單元測試 '綜合測試系統(tǒng)設計運行維護1.4軟件過程1.4.1瀑布模型1.4.2快速原型模型1.4.3增量模型1.4

5、.4螺旋模型1.4.5噴泉模型可行性研究2.1可行性研究的任務可行性研究的目的：不是解決問題，而是確定問題是否值得去解決。可行性研究的實質：進行一次大大壓縮簡化了的系統(tǒng)分析和設計的過程， 行的系統(tǒng)分析和設計的過程?？尚行匝芯康膬热荩菏紫冗M一步分析和澄清問題定義，導出系統(tǒng)的邏輯模型； 然后從系統(tǒng)邏輯模型出發(fā)，探索若干種可供選擇的主要解法也就是在較高層次上以較抽象的方式進（即系統(tǒng)實現(xiàn)方案）；對每種解法都研究它的可行性，至少應該從三方面研究每種解法的可行性 主要方面：技術可行性，經濟可行性，操作可行性， 其他方面：運行可行性，法律可行性，22 可行性研究過程1. 復查系統(tǒng)規(guī)模和目標2. 研究目前正在

6、使用的系統(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ù)擁的源點/終點或數(shù)擁存儲數(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ù)字典的

7、內容數(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)成本估計 ： 1. 代碼行技術 2. 任務

8、分解技術 3. 自動估計成本技術 成本/ 效益分析的方法2.6 成本/ 效益分析2.6.12.6.2 成本/效益分析涉及的 4 個概念：1. 貨幣的時間價值2. 投資回收期+ Fn( 1 + j )n3. 純收入4. 投資回收率： P = F1/（ 1 + j ） + F2/（ 1 + j ）2 +第 3章 需求分析它的基本任務是準確地回答 “系統(tǒng)必須做什么 ?”需求分析的任務： 需求分析是軟件定義時期的最后一個階段， 這個問題。確定系統(tǒng)必須完成哪些工作，也就是對目標系統(tǒng)提出完整、準確、清晰、具體的要求。 系統(tǒng)分析員應該寫出軟件需求規(guī)格說明書，以書面形式準確地描述軟件需求3.1 需求分析的任務

9、確定對系統(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分析建模與

10、規(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.7其他圖形工具3.7.1層次方框圖3.7.2Warn

11、ier 圖3.7.3IPO圖3.8驗證軟件需求（重點）狀卷芟駅I初昭屮fi-活功養(yǎng)13.8.1 從哪些方面驗證軟件需求的正確性一致性 完整性 現(xiàn)實性 有效性第五章 總體設計5.1 設計過程由兩個主要階段組成：系統(tǒng)設計階段， 確定系統(tǒng)的具體實現(xiàn)方案： 設想供選擇的方案 選取合理的方案 推薦最佳 方案結構設計階段，確定軟件結構 : 功能分解 設計軟件結構 設計數(shù)據(jù)庫 制定測試文檔 書寫文檔 審查和復查5.2 設計原理抽象逐步求精 信息隱藏和局部化模塊獨立5.2.1 模塊化 模塊化的作用： 采用模塊化原理可以使軟件結構清晰，不僅容易設計也容易閱讀和理解。 模塊化使軟件容易測試和調試，因而有助于提高軟

12、件的可靠性。 模塊化能夠提高軟件的可修改性。 模塊化也有助于軟件開發(fā)工程的組織管理。5.2.25.2.35.2.45.2. 5盡量使用數(shù)據(jù)耦合， 少用控制耦合和特征耦合， 限制公共環(huán)境耦合的范圍， 完全不用內容耦合。七種內聚的優(yōu)劣評分結果：高內聚：中內聚：低內聚：功能內聚 順序內聚 通信內聚過程內聚 時間內聚邏輯內聚偶然內聚1.5.3 啟發(fā)規(guī)則2.3.改進軟件結構提高模塊獨立性 模塊規(guī)模應該適中 深度、寬度、扇出和扇入都應適當模塊的作用域應該在控制域之內M丄旳柞用城上的挖制威違反規(guī)則的悄況4.5.6.力爭降低模塊接口的復雜程度7.6. 設計單入口單出口的模塊7. 模塊功能應該可以預測5.4描繪

13、軟件結構的圖形工具5.4.1 層次圖和HIPO圖1. 層次圖（H圖）層次圖用來描繪軟件的層次結構。很適于在自頂向下設計軟件的過程中使用。2. HIPO 圖7.4.2結構圖7.5面向數(shù)據(jù)流的設計方法結構化設計方法（簡稱SD方法），也就是基于數(shù)據(jù)流的設計方法。5.5.1概念面向數(shù)據(jù)流的設計方法把信息流映射成軟件結構，信息流的類型決定了映射的方法。 信息流有兩種類型：變換流事務流第6章詳細設計6.1 結構程序設計經典的結構程序設計：只允許使用順序、IF-THEN-ELSE型分支和DO-WHILE型循環(huán)這3種基本控制結構；擴展的結構程序設計：如果除了上述3種基本控制結構之外，還允許使用 DO-CASE

14、型多分支結構和DO-UNTIL型循 環(huán)結構；修正的結構程序設計 ：再加上允許使用 LEAVE或BREAK結構。6.2 人機界面設計6.2.1 設計問題 設計人機界面過程中會遇到的 4 個問題： 系統(tǒng)響應時間：長度 易變性 用戶幫助設施：集成的幫助設施附加的幫助設施 出錯信息處理命令交互6.2.3 人機界面設計指南一般交互指南信息顯示指南 數(shù)據(jù)輸入指南6.3 過程設計的工具而不6.3.1 程序流程圖（程序框圖） 程序流程圖的主要缺點： 程序流程圖本質上不是逐步求精的好工具， 它誘使程序員過早地考慮程序的控制流程， 去考慮程序的全局結構。程序流程圖中用箭頭代表控制流， 因此程序員不受任何約束， 可

15、以完全不顧結構程序設計的 精神，隨意轉移控制。程序流程圖不易表示數(shù)據(jù)結構。632盒圖（N-S圖） 盒圖具有下述特點： 功能域明確。不可能任意轉移控制。 很容易確定局部和全程數(shù)據(jù)的作用域。很容易表現(xiàn)嵌套關系，也可以表示模塊的層次結構。6.3.3 PAD 圖它用二維樹形結構的圖來表示程序的控制流，將這種圖翻譯成程序代碼比較容易。(ill二PAD圖的主要優(yōu)點如下：使用表示結構化控制結構的PAD符號設計出來的程序必然是結構化程序。PAD圖所描繪的程序結構十分清晰。PAD圖表現(xiàn)程序邏輯易讀、易懂、易記。容易將PAD圖轉換成高級語言源程序，這種轉換可用軟件工具自動完成。 即可表示程序邏輯，也可描繪數(shù)據(jù)結構

16、。PAD圖的符號支持自頂向下、逐步求精方法的使用。634判定表判定表卻能夠清晰地表示復雜的條件組合與應做的動作之間的對應關系。所有條件條件組合矩陣所有動作條件組合對應的動作判定表的缺點：判定表的含義不是一眼就能看出來的，初次接觸這種工具的人理解它需要有一個簡短的學習過程。當數(shù)據(jù)元素的值多于兩個時，判定表的簡潔程度也將下降。635判定樹判定樹的優(yōu)點：它的形式簡單，一眼就可以看出其含義，因此易于掌握和使用。判定樹的缺點：簡潔性不如判定表，數(shù)據(jù)元素的同一個值往往要重復寫多遍，而且越接近樹的葉端重復次數(shù)越多。畫判定樹時分枝的次序可能對最終畫出的判定樹的簡潔程度有較大影響。6.3.6過程設計語言（偽碼）

17、偽代碼的基本控制結構： 簡單陳述句結構：避免復合語句。判定結構：IF_THEN_ELSE或CASE_0結構。 選擇結構：WHILE_DO或 REPEAT_UNTlL吉構。PDL的優(yōu)點：可以作為注釋直接插在源程序中間。有助于保持文檔和程序的一致性，提高了文檔的質量。可以使用普通的正文編輯程序或文字處理系統(tǒng)，很方便地完成PDL的書寫和編輯工作。已經有自動處理程序存在，而且可以自動由PDL生成程序代碼。PDL的缺點：不如圖形工具形象直觀，描述復雜的條件組合與動作間的對應關系時，不如判定表清晰簡單。6.4 面向數(shù)據(jù)結構的設計方法面向數(shù)據(jù)結構的設計方法的最終目標是得出對程序處理過程的描述。A由B C、D

18、 3個元素順序組成根據(jù)條件A是B或C或D中的某一個> 0)組成6.4.26.4.3改進的Jacks on圖Jacks on 方法A 由B出現(xiàn)N次(N6.5程序復雜程度的定量度量McCabe方法6.5.11.流圖(程序圖)mLj_J2. 計算環(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。 預

19、測程序長度的公式如下：H = n1 log2n1 + n2 log2n2 預測程序中包含錯誤的個數(shù)的公式如下：E = N log2 （n1+n2）/3000第7章 實現(xiàn)編碼和測試統(tǒng)稱為實現(xiàn)。7.1 編碼7.1.1 選擇程序設計語言主要的實用標準：7.1.2 編碼風格1. 程序內部的文檔 : 恰當?shù)臉俗R符 適當?shù)淖⒔?. 數(shù)據(jù)說明3. 語句構造4. 輸入輸出5. 效率 :程序運行時間程序的視覺組織存儲器效率輸入輸出的效率系統(tǒng)用戶的要求 可以使用的編譯程序 可以得到的軟件工具 工程規(guī)模 程序員的知識 軟件可移植性要求 軟件的應用領域7.2 軟件測試基礎7.2.1 軟件測試的目標 測試是為了發(fā)現(xiàn)程序

20、中的錯誤而執(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)測試

21、把經過單元測試的模塊放在一起形成一個子系統(tǒng)來測試； 著重測試模塊的接口。3. 系統(tǒ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 測試階段的信息流 輸入信息有兩類： 軟件配置，包括需求說明書、設計說明書和源程序清單等； 測試配置，包

22、括測試計劃和測試方案。7.3 單元測試 單元測試集中檢測模塊； 單元測試和編碼屬于軟件過程的同一個階段； 可以應用人工測試和計算機測試這樣兩種不同類型的測試方法； 單元測試主要使用白盒測試技術，對多個模塊的測試可以并行地進行。7.3.1 測試重點 模塊接口 局部數(shù)據(jù)結構 重要的執(zhí)行通路 出錯處理通路 邊界條件7.3.2 代碼審查 由審查小組正式進行測試稱為代碼審查； 一次審查會上可以發(fā)現(xiàn)許多錯誤，可以減少系統(tǒng)驗證的總工作量。傳送給被測試的模塊， 并且印出有關的結果。 它使用被它代替的模塊的接口， 可能做最少量的 并且把控制歸還給調用它的模塊。7.3.3 計算機測試 驅動程序是一個 “主程序”

23、，它接收測試數(shù)據(jù)， 存根程序代替被測試的模塊所調用的模塊。 數(shù)據(jù)操作，印出對入口的檢驗或操作結果，7.4 集成測試由模塊組裝成程序時有兩種方法：非漸增式 集成測試策略J7.4.3 不同集成測試策略的比較/深度優(yōu)先自頂向下漸增式%''寬度優(yōu)先自底向上混合策略：改進的自頂向下測試方法混合法7.4.4 回歸測試7.5 確認測試確認測試也稱為驗收測試，它的目標是驗證軟件的有效性。7.5.3 Alp ha 和 Beta 測試Alpha測試是在受控的環(huán)境中進行的。Beta測試是軟件在開發(fā)者不能控制的環(huán)境中的“真實”應用。1. 接口測試2. 路徑測試3. 功能測試4. 健壯性測試5. 性能測

24、試6. 用戶界面測試7. 信息安全測試8. 壓力測試9. 可靠性測試10. 安裝/反安裝測試確認測試也稱為驗收測試，它的目標是驗證軟件的有效性。 Alpha測試是在受控的環(huán)境中進行的。Beta測試是軟件在開發(fā)者不能控制的環(huán)境中的“真實”應用。4. 接口測試5. 路徑測試6. 功能測試4. 健壯性測試5. 性能測試6. 用戶界面測試7. 信息安全測試8. 壓力測試9. 可靠性測試10. 安裝/反安裝測試7.6白盒測試技術廠測試目的測試方案I測試數(shù)據(jù)、測試用例；q預期結果邏輯覆蓋7.6.1語句覆蓋:比語句覆蓋強，但對程序邏輯的覆蓋程度仍不高。:判定覆蓋不一定包含條件覆蓋，條件覆蓋也不一定包含判定覆

25、蓋。:有時判定/條件覆蓋也并不比條件覆蓋更強。:條件組合覆蓋標準的測試數(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)結構的有效性。在結

26、構化的程序中通常只有3種循環(huán)，即簡單循環(huán)、串接循環(huán)和嵌套循環(huán)。7.7黑盒測試技術7.7.17.7.27.7.3等價劃分 邊界值分析 錯誤推測7.9軟降可靠性7.9.1基本概念軟件可靠性：程序在給定的時間間隔內，按照規(guī)格說明書的規(guī)定成功地運行的概率。 軟件的可用性：程序在給定的時間點，按照規(guī)格說明書的規(guī)定，成功地運行的概率。第8章維護軟件工程的目的是要提高軟件的可維護性， 減少軟件維護所需要的工作量， 降低軟件系統(tǒng)的 總成本。8.1 軟件維護的定義軟件維護：在軟件已經交付使用之后，為了改正錯誤或滿足新的需要而修改軟件的過程。 可分為 4 項活動：改正性維護 適應性維護 完善性維護 預防性維護結構

27、化維護與非結構化維護差別巨大8.2 軟件維護的特點8.2.18.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）按照子類和父類的關系，把若干個對象類組成一個層次結

28、構的系統(tǒng)（4）對象彼此之間僅能通過傳遞消息相互聯(lián)系9.1.2 面向對象開發(fā)方法 面向對象 =對象 +類 +繼承 +通信9.1.4 面向對象方法組成 面向對象的分析 面向對象的設計 面向對象的程序設計1. 與人類習慣的思維方式一致2. 穩(wěn)定性好3. 可重用性好4. 可維護性好5. 較易開發(fā)大型軟件產品9.2 面向對象的概念9.2.1 對象是客觀事物或概念的抽象表述， 即對客觀存在的事物的描述統(tǒng)稱為對象， 對象可以是事、 物、 或抽象概念 ，是將一組數(shù)據(jù)和使用該數(shù)據(jù)的一組基本操作或過程封裝在一起的實體。以數(shù)據(jù)為中心。 對象是主動的。 實現(xiàn)了數(shù)據(jù)封裝。 本質上具有并行性。 模塊獨立性好。對象的特點(

29、1)(2)(3)(4)(5)9.2.2 類是一組具有相同屬性和相同操作的對象的集合。9.2.3 實例由某個特定的類所描述的一個具體的對象。3 個部分：接收消息的對9.2.4 消息 向對象發(fā)出的服務請求(互相聯(lián)系、協(xié)同工作等)。一個消息包含 象，消息名，消息變元9.2.5 方法方法就是對象所能執(zhí)行的操作，也就是類中所定義的服務。9.2.6 屬性屬性就是類中所定義的數(shù)據(jù)，它是對客觀世界實體所具有的性質的抽象。9.2.7 封裝對象封裝了對象的數(shù)據(jù)以及對這些數(shù)據(jù)的操作。9.2.8 繼承 (I) 繼承是子類自動地共享基類中定義的數(shù)據(jù)和方法的機制。 單重繼承：子類僅從一個父類繼承屬性和方法 多重繼承：子類

30、可從多個父類繼承屬性和方法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）分為：publicprivatep rotected公有的，即模型中的任何類都可以訪問該屬性。 私有的，表示不能被別的類訪問。類名屬性服務屬性名：類型=缺省值性質串表示該屬性對類外的元素是否可見。（+）（-）（#）受保護的，表示該屬性只能被該類及

31、其子類訪問。如果可見性未申明，表示其可見性不確定。3. 定義操作可見性 操作名（參數(shù)表）：返回類型性質串9.4.2 表示關系的符號（I）942.1 關聯(lián)（I）關聯(lián)表示兩個類的對象之間存在某種語義上的聯(lián)系。（1）普通關聯(lián)9.4.2.2 聚集（I）（1）共享聚集則該聚集稱為如果在聚集關系中處于部分方的對象可同時參與多個處于整體方對象的構成, 共享聚集。9.4.2.5 細化*O-（2）組合聚集如果部分類完全隸屬于整體類，部分與整體共存，整體不存在了部分也會隨之消失，則該聚集稱為組合聚集。多重、不相交、完全和不完全。4種:9.4.2.3 泛化（I）（1 ）普通泛化（2 ）受限泛化 預定義的約束有942

32、.4 依賴SystemfirnM I悴叫)* Dismay FormFerm(Tron MtMLRMOer)ofmActionO*slartO9.5動態(tài)模型9.6功能模型刑類9.6.1用例圖模型元素：系統(tǒng)、行為者、用例及用例之間的關系用例的實例是腳本（擴展關系、使用關系）第10章面向對象分析10.1面向對象分析的基本過程面向對象分析：抽取和整理用戶需求并建立問題域精確模型的過程理解-表達驗證-用戶、分析員和領域專家需求規(guī)格說明書（對象模型、動態(tài)模型、功能模型） 二義性，完善性對象模型最基本、最重要、最核心。靜態(tài)結構（對象模型）交互次序（動態(tài)模型）數(shù)據(jù)變換（功能模型）3 個子模型主題涇 類與対象

33、定 結構層 鳳性層 «務層復雜問題的對象模型的 5個層次面向對象分析的過程尋找類與對象識別結構識別主題定義屬性建立動態(tài)模型建立功能模型定義服務10.2需求陳述需求陳述是闡明“做什么”，而不是“怎樣做”問題范圍第11章功能需求 性能需求 應用環(huán)境 假設條件面向對象設計11.1面向對象設計的準則1. 模塊化2. 抽象3.信息隱藏4. 弱耦合耦合指不同對象之間相互關聯(lián)的緊密程度。 對象之間的耦合分兩類：交互耦合則這種耦合就是交互耦合。交互耦合應盡可能松如果對象之間的耦合通過消息連接來實現(xiàn)，散。繼承耦合與交互耦合相反，應該提高繼承耦合程度。5. 強內聚在面向對象設計中存在下述3種內聚：服務內

34、聚：一個服務應該完成一個且僅完成一個功能。類內聚：一個類應該只有一個用途，它的屬性和服務應該是高內聚的。 般-特殊內聚：設計出的一般-特殊結構，應該符合多數(shù)人的概念6. 可重用11.2 啟發(fā)規(guī)則1. 設計結果應該清晰易懂2. 一般-特殊結構的深度應適當3. 設計簡單的類4. 使用簡單的協(xié)議5. 使用簡單的服務6. 把設計變動減至最小第13章軟件項目管理L度量軟件規(guī)模軟件工程L計劃一估算工作量明確軟件開發(fā)的目標進度計劃一組織提供組織機構和資源配置方面的保證廠風險管理-質量保證 保證開發(fā)目標的實現(xiàn)13.1估算軟件規(guī)模13.1.1 代碼行技術估算方法：由多名有經驗的軟件工程師分別做出估計。每個人都估

35、計程序的最小規(guī)模（a）、最大規(guī)模（b）和最可能的規(guī)模（m），分別算出這3種規(guī)模的平均值之后，再用下式計算程序規(guī)模的估計值：單位：LOC 或 KLOC代碼行技術的優(yōu)點：代碼是所有軟件開發(fā)項目都有的“產品”，而且很容易計算代碼行數(shù)； 有大量參考文獻和數(shù)據(jù)。代碼行技術的缺點：源程序僅是軟件配置的一個成分，由源程序度量軟件規(guī)模不太合理； 用不同語言實現(xiàn)同一個軟件所需要的代碼行數(shù)并不相同； 不適用于非過程性語言。13.1.2 功能點技術功能點技術依據(jù)對軟件信息域特性和軟件復雜性的評估結果，估算軟件規(guī)模。 這種方法用功能點（FP）為單位度量軟件規(guī)模。1. 信息域特性輸入項數(shù)（Inp）、輸出項數(shù)（Out）、

36、查詢數(shù)（Inq）、主文件數(shù)（Maf）、外部接口數(shù)（Inf）每個特征根據(jù)其復雜程度分配一個功能點數(shù)，即信息域特征系數(shù)a1, a2, a3, a4, a52.估算功能點的步驟 計算未調整的功能點數(shù)UFPUFP=a1x Inp+a2 X Out+a3X Inq+a4 X Maf+a5X Inf計算技術復雜性因子 TCF技術因素對軟件規(guī)模的綜合影響程度DI:（1）技術復雜性因子 TCF由下式計算：TCF = 0.65 + 0.01 X DI 因為DI的值在070之間，所以TCF的值在0.651.35之間。（3）計算功能點數(shù)FPFP = UFP X TCF功能點技術優(yōu)點：與所用的編程語言無關，比代碼行技

37、術更合理。對經功能點技術缺點：在判斷信息域特性復雜級別和技術因素的影響程度時主觀因素較大, 驗依賴性較強。13.2 工作量估算13.2.1 靜態(tài)單變量模型E = A + B X (ev) C 仃ev是估算變量(KLOC或 FP)£13.2.2動態(tài)多變量模型動態(tài)多變量模型也稱為軟件方程式， 的函數(shù)。a KLOC b fii 1該模型把工作量看作是軟件規(guī)模和開發(fā)時間這兩個變量E=(LOCX B0.333/P)3 X (1/t)413.2.3 COCOM 02模型(構造性成本模型)3個層次的估算模型：應用系統(tǒng)組成模型：這個模型主要用于估算構建原型的工作量，模型名字暗示在構建原型時大量使用已

38、有的構件。早期設計模型：這個模型適用于體系結構設計階段。后體系結構模型：這個模型適用于完成體系結構設計之后的軟件開發(fā)階段。COCOMO使用的5個分級因素：項目先例性、開發(fā)靈活性、風險排除度、項目組凝聚力、過 程成熟度13.3 進度計劃估算開發(fā)時間規(guī)律：向一個已經延期的項目增加人力，只會使得它更加延期。13.3.1Brooks13.3.2 Gantt 圖Gantt圖的主要優(yōu)點：Gantt圖能很形象地描繪任務分解情況，以及每個子任務(作業(yè))的開始和結束時間。具有直觀簡明和容易掌握、容易繪制的優(yōu)點。Gantt圖的3個主要缺點：不能顯式地描繪各項作業(yè)彼此間的依賴關系； 進度計劃的關鍵部分不明確，難于判定哪些部分應當是主攻和主控的對象； 計劃中有潛力的部分及潛力的大小不明確，往往造成潛力的浪費。13.3.3 工程網絡工程網絡是系統(tǒng)分析和系統(tǒng)設計的強有力的工具。13.3.4 估算工程進度HKT最遲時刻LETEET之和;EET3條簡單規(guī)則:計算最早時刻EET使用下述考慮進入該事件的所有作業(yè)；對于每個作業(yè)都計算它的持續(xù)時間與起始事件的 選取上述和數(shù)中的最大值作為該事件的最早時刻 計算最遲時刻LET使用下