title: 《軟件工程導(dǎo)論》期末知識(shí)點(diǎn)復(fù)習(xí)
categories: 計(jì)算機(jī)專業(yè)課
tags: "軟件工程"

前言：軟件工程知識(shí)點(diǎn)詳解，是在。本書參考《軟件工程導(dǎo)論》第六版，張海藩，紅色的那本。帶*不重要了解一下即可,黑體重點(diǎn)部分,需記憶。
<--more-->
如果有圖片掛了，去這個(gè)鏈接，都是本人發(fā)的

第一章 軟件工程概論

1. *軟件：是計(jì)算機(jī)程序、方法、規(guī)則、相關(guān)的文檔以及運(yùn)行計(jì)算機(jī)系統(tǒng)時(shí)所必需的數(shù)據(jù)的總和(狹義定義：軟件＝程序+數(shù)據(jù)+文檔)
2. *軟件的特性：軟件是復(fù)雜的、軟件是不可見的、軟件是不斷變化的和軟件質(zhì)量難以穩(wěn)定。
3. *軟件的質(zhì)量特性：功能性、可靠性、易用性、效率、維護(hù)性、可移植性。
4. 軟件危機(jī)：指在計(jì)算機(jī)軟件的開發(fā)和維護(hù)過程中所遇到的一系列嚴(yán)重問題。
5. 軟件危機(jī)的主要表現(xiàn)：

• 對(duì)軟件開發(fā)成本和進(jìn)度估計(jì)常常很不準(zhǔn)確
• 用戶對(duì)"已完成"的系統(tǒng)不滿意的現(xiàn)象經(jīng)常發(fā)生
• 軟件產(chǎn)品的質(zhì)量往往靠不住
• 軟件常常是不可維護(hù)的
• 軟件成本在計(jì)算機(jī)系統(tǒng)總成本所占的比例逐年上升

6. 軟件危機(jī)產(chǎn)生的主要原因:

• 軟件日益復(fù)雜和龐大
• 軟件開發(fā)管理困難和復(fù)雜
• 軟件開發(fā)技術(shù)落后
• 生產(chǎn)方式落后
• 開發(fā)工具落后
• 軟件開發(fā)費(fèi)用不斷增加

7. 軟件危機(jī)如何解決：既要有技術(shù)措施（方法和工具），又要有必要的組織管理措施。
8. 軟件工程：是指導(dǎo)計(jì)算機(jī)軟件開發(fā)和維護(hù)的一門工程學(xué)科。采用工程的概念、原理、技術(shù)和方法來開發(fā)與維護(hù)軟件，把經(jīng)過時(shí)間考驗(yàn)而證明正確的管理技術(shù)和當(dāng)前能夠得到的最好的技術(shù)方法結(jié)合起來，以經(jīng)濟(jì)地開發(fā)出高質(zhì)量的軟件并有效地維護(hù)它。
9. 軟件工程以關(guān)注軟件質(zhì)量為目標(biāo)，包括方法、過程、工具、范式四個(gè)要素。
10. 軟件工程方法學(xué)：把軟件生命周期全過程中使用的一整套技術(shù)方法的集合成為方法學(xué)(也稱范型paradigm),包括三個(gè)要素:方法,工具和過程.目前使用最廣泛的是傳統(tǒng)方法學(xué)和面向?qū)ο蠓椒▽W(xué)

• 傳統(tǒng)方法學(xué)(也稱生命周期方法學(xué)或結(jié)構(gòu)化范型):采用結(jié)構(gòu)化技術(shù)(結(jié)構(gòu)化分析,結(jié)構(gòu)化技術(shù),結(jié)構(gòu)化實(shí)現(xiàn))來完成軟件開發(fā)的各項(xiàng)任務(wù),并使用適當(dāng)?shù)能浖ぞ呋蜍浖h(huán)境來支持結(jié)構(gòu)化技術(shù)的運(yùn)用...略太過了
• 面向?qū)ο蠓椒▽W(xué):有4個(gè)要點(diǎn);它是一個(gè)多次反復(fù)迭代的演化的過程;特有的繼承性和多態(tài)性進(jìn)一步提高了面向?qū)ο筌浖目芍赜眯?/li>

11. 軟件生命周期
    
    軟件生命周期

• 問題定義:確定要解決的問題是什么(通過客戶的訪問調(diào)查,系統(tǒng)分析員寫出問題的性質(zhì),工程目標(biāo)和工程規(guī)模的書面報(bào)告,并得到客戶的確認(rèn))
• 可行性研究:不是具體解決問題,而是研究問題的范圍,探索問題是否值得去解,是否有可行的解決方法
• 需求分析:準(zhǔn)確確定"為了解決這個(gè)問題,目標(biāo)系統(tǒng)必須做什么",主要是確定目標(biāo)系統(tǒng)必須具備哪些功能
• 總體設(shè)計(jì):設(shè)計(jì)出目標(biāo)系統(tǒng)的多種方案;設(shè)計(jì)程序的體系結(jié)構(gòu)
• 詳細(xì)設(shè)計(jì):詳細(xì)的設(shè)計(jì)每個(gè)模塊,確定要實(shí)現(xiàn)模塊功能所需要的算法和數(shù)據(jù)結(jié)構(gòu)
• 編碼和單元測試:寫出正確的容易理解,容易維護(hù)的程序模塊
• 綜合測試:通過各種類型的測試(及相應(yīng)的的調(diào)試)使軟件達(dá)到預(yù)定的要求
• 軟件維護(hù):通過各種必要的維護(hù)活動(dòng)使系統(tǒng)持久地滿足用戶的需要

12. 軟件過程:指為了獲得高質(zhì)量軟件所需完成一系列任務(wù)框架,它規(guī)定了完成各項(xiàng)任務(wù)的工作步驟;通常使用生命周期模型簡潔地描述軟件過程
13. 生命周期模型:也稱過程模型規(guī)定了把生命周期劃分成哪些階段及各個(gè)階段的執(zhí)行順序
14. 瀑布模型

①瀑布模型特點(diǎn)：

• 階段間具有順序性和依賴性:必須等前一階段的工作完成后之后,才能開始后一段的工作;前一段的輸出文檔就是后一階段的輸入文檔
• 推遲實(shí)現(xiàn)的觀點(diǎn):在編碼之前設(shè)置了系統(tǒng)分析和系統(tǒng)設(shè)計(jì)的各個(gè)階段,分析與設(shè)計(jì)階段的基本任務(wù)規(guī)定,這兩個(gè)階段主要考慮目標(biāo)系統(tǒng)的邏輯模型,不涉及物理實(shí)現(xiàn)
• 質(zhì)量保證的觀點(diǎn):每個(gè)階段必須完成規(guī)定的文檔;每個(gè)階段結(jié)束前都要對(duì)完成的文檔進(jìn)行評(píng)審,以便盡早發(fā)現(xiàn)問題

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

③瀑布模型的優(yōu)點(diǎn): 可強(qiáng)迫開發(fā)人員采用規(guī)范的方法;嚴(yán)格規(guī)定了每個(gè)階段必須提交的文檔;要求每個(gè)階段交出的所有產(chǎn)品都必須經(jīng)過質(zhì)量保證小組的仔細(xì)驗(yàn)證

④瀑布模型缺點(diǎn)：瀑布模型是由文檔驅(qū)動(dòng);最終產(chǎn)品不能真正滿足客戶的需求

15. 快速原型模型：首先建立一個(gè)反映用戶主要需求的原型系統(tǒng),讓用戶體驗(yàn),之后提出意見,隨之進(jìn)行修改,再讓用戶體驗(yàn)...直至用戶完全滿意,據(jù)此寫出規(guī)格說明文檔
16. 增量模型：也稱漸增模型，融合了瀑布模型的基本成分（重復(fù)應(yīng)用）和原型實(shí)現(xiàn)的迭代特征，該模型采用隨著日程時(shí)間的進(jìn)展而交錯(cuò)的線性序列，每一個(gè)線性序列產(chǎn)生軟件的一個(gè)可發(fā)布的“增量”。

• 增量模型優(yōu)點(diǎn):人員分配靈活,剛開始不用投入大量人力資源；可先發(fā)布部分功能給客戶，對(duì)客戶起到鎮(zhèn)靜劑的作用；增量能夠有計(jì)劃地管理技術(shù)風(fēng)險(xiǎn)。
• 增量模型缺點(diǎn):需要軟件具備開放式的體系結(jié)構(gòu)；容易退化為邊做邊改模型，從而使軟件過程的控制失去整體性；增加系統(tǒng)內(nèi)部的耦合復(fù)雜性。

17. 螺旋模型：把它看作在每個(gè)階段之前增加了風(fēng)險(xiǎn)分析的快速原型模型。
18. *螺旋模型與增量模型的區(qū)別：（1）兩者迭代層級(jí)不同：增量模型在活動(dòng)級(jí)迭代；螺旋模型在過程級(jí)迭代；（2）兩者需求分析的時(shí)間不同：增量模型常常是先做總體需求分析和設(shè)計(jì)，然后在編碼和測試中逐個(gè)增量開發(fā)；螺旋模型在開發(fā)周期內(nèi)采用簡化瀑布模型或快速模型；(3)兩者提交軟件的方式不同：增量開發(fā)在上次增量的基礎(chǔ)上提交新的一部分軟件；螺旋模型每次迭代都提交一個(gè)新的完整的軟件版本；(4)兩者減少風(fēng)險(xiǎn)的方式不同：增量模型使用未成熟技術(shù)和經(jīng)常的客戶反饋等方法減少風(fēng)險(xiǎn)；螺旋模型中直接加進(jìn)風(fēng)險(xiǎn)識(shí)別，風(fēng)險(xiǎn)分析、風(fēng)險(xiǎn)控制，計(jì)劃性較強(qiáng).
19. 噴泉模型:典型的具有面向?qū)ο筌浖_發(fā)過程迭代和無縫的特性
20. Rational 統(tǒng)一過程(Rational Unified Process Rational，RUP): RUP核心：RUP核心是解決可操作性問題，幫助開發(fā)人員盡可能少地依賴那些“不可描述的經(jīng)驗(yàn)”。RUP特點(diǎn)：用例驅(qū)動(dòng)；以體系結(jié)構(gòu)為中心（高內(nèi)聚低耦合）；增量和迭代開發(fā)。
21. RUP最佳實(shí)踐

• 迭代式開發(fā):允許每次迭代過程中需求都可以有變化;采用可驗(yàn)證的方法來減少風(fēng)險(xiǎn)
• 管理需求:RUP采用用例分析來捕獲需求,并由它們驅(qū)動(dòng)設(shè)計(jì)和實(shí)現(xiàn)
• 使用基于構(gòu)件的體系架構(gòu):使用現(xiàn)有的或新開發(fā)的構(gòu)件定義體系結(jié)構(gòu)的系統(tǒng)化方法,從而降低軟件開發(fā)的復(fù)雜性,提高軟件重用率
• 可視化建模:建立軟件系統(tǒng)的可視化模型,提高管理復(fù)雜軟件的能力,如UML
• 驗(yàn)證軟件質(zhì)量:軟件質(zhì)量評(píng)估貫穿整個(gè)開發(fā)過程,由全體成員參與
• 控制軟件的變更:RUP描述了如何控制,跟蹤和監(jiān)控修改,以確保迭代開發(fā)的成功

22. RUP軟件開發(fā)生命周期

①核心工作流 (縱軸代表核心工作流,橫軸代表時(shí)間) 前6個(gè)為核心過程工作流, 后3個(gè)為核心支持工作流

• 業(yè)務(wù)建模:深入了解使用目標(biāo)系統(tǒng)的機(jī)構(gòu)及商務(wù)運(yùn)作評(píng)估目標(biāo)系統(tǒng)對(duì)使用它的機(jī)構(gòu)的影響
• 需求:捕獲客戶的需求并且使開發(fā)人員和用戶達(dá)成對(duì)需求描述的共識(shí)
• 分析與設(shè)計(jì):把需求分析的結(jié)果轉(zhuǎn)化為分析模型和設(shè)計(jì)模型
• 實(shí)現(xiàn):把設(shè)計(jì)模型轉(zhuǎn)化為實(shí)現(xiàn)結(jié)果
• 測試:檢查各子系統(tǒng)的交互與集成,驗(yàn)證所有需求是否都被正確實(shí)現(xiàn),識(shí)別,確認(rèn)缺陷并確保在軟件部署之前消除缺陷
• 部署:成功生成目標(biāo)系統(tǒng)的可運(yùn)行版本,并將軟件移交給用戶
• 配置與變更管理:跟蹤并維護(hù)在軟件過程中產(chǎn)生的所有制品的完整性和一致性
• 項(xiàng)目管理:提供項(xiàng)目管理框架,為軟件開發(fā)制定計(jì)劃,人員配備,執(zhí)行和監(jiān)控等方面的使用準(zhǔn)則,并為風(fēng)險(xiǎn)管理提供框架
• 環(huán)境:向軟件開發(fā)機(jī)構(gòu)提供軟件開發(fā)環(huán)境,包括過程管理和工具支持

②工作階段

• 初始階段:建立業(yè)務(wù)模型,定義最終產(chǎn)品視圖,并確定項(xiàng)目的范圍
• 精化階段:設(shè)計(jì)并確定系統(tǒng)的體系結(jié)構(gòu),制定項(xiàng)目計(jì)劃確定資源需求
• 構(gòu)建階段:開發(fā)出所有構(gòu)件和應(yīng)用程序,把它們集成客戶需要的產(chǎn)品,并且詳細(xì)地測試所有功能
• 移交階段:把開發(fā)出的產(chǎn)品提交給用戶使用

③RUP迭代式開發(fā)

第二章 可行性研究

23. 可行性研究的目的不是為了解決問題，而是確定問題是否值得去解決
24. 可行性：技術(shù)可行性、經(jīng)濟(jì)可行性、操作可行性、運(yùn)行可行性、法律可行性。
25. 可行性研究過程：

• 復(fù)查系統(tǒng)規(guī)模和目標(biāo)
• 研究正在使用的系統(tǒng)
• 導(dǎo)出新系統(tǒng)的高層邏輯模型
• 進(jìn)一步定義問題
• 導(dǎo)出和評(píng)價(jià)供選擇的解法
• 推薦行動(dòng)方針
• 草擬開發(fā)計(jì)劃
• 書寫文檔提交審查

26. *系統(tǒng)流程圖：是概括地描繪物理系統(tǒng)的傳統(tǒng)工具。用圖形符號(hào)以黑盒子形式描繪組成系統(tǒng)的每個(gè)部件（程序，文檔，數(shù)據(jù)庫，人工過程等）。表達(dá)的是數(shù)據(jù)在系統(tǒng)各部件之間流動(dòng)的情況

27. *數(shù)據(jù)流圖表示方法：實(shí)線表示數(shù)據(jù)流；虛線表示控制流；圓框代表處理數(shù)據(jù)的過程；矩形框表示產(chǎn)生與接收數(shù)據(jù)的對(duì)象；平行線表示數(shù)據(jù)存儲(chǔ)區(qū)。
28. 數(shù)據(jù)字典定義組成：數(shù)據(jù)流；數(shù)據(jù)流分量（即數(shù)據(jù)元素）；數(shù)據(jù)存儲(chǔ)；處理
29. 數(shù)據(jù)字典定義數(shù)據(jù)的方法（對(duì)數(shù)據(jù)自頂向下分解）：

30. 成本效益分析的方法及如何運(yùn)算:
    第一步估計(jì)開發(fā)成本、運(yùn)行費(fèi)用和新系統(tǒng)將帶來的經(jīng)濟(jì)效益。需從貨幣時(shí)間價(jià)值,投資回收期,純收入,投資回收率
    方法有三種：

• 代碼行技術(shù)：軟件成本=每行代碼的平均成本*估計(jì)的源代碼總行數(shù)
• 任務(wù)分解技術(shù)：單本任務(wù)成本=任務(wù)所需人力估計(jì)值*每人每月平均工資；軟件開發(fā)項(xiàng)目總成本=每個(gè)單獨(dú)任務(wù)成本估計(jì)總和
• 自動(dòng)估計(jì)成本技術(shù)：采用自動(dòng)估計(jì)成本的軟件

第三章 需求分析

31. 需求分析的任務(wù)

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

32. 分析建模與規(guī)格說明
    模型: 就是為了理解事物而對(duì)事物作出的一種抽象,是對(duì)事物的一種無歧義的書面描述。通常，模型由一組圖形符號(hào)和組織這些符號(hào)的規(guī)則組成
    需要建立的三種模型：數(shù)據(jù)模型、功能模型和行為模型

• 實(shí)體-聯(lián)系圖：描繪數(shù)據(jù)對(duì)象、數(shù)據(jù)對(duì)象的屬性及數(shù)據(jù)對(duì)象之間的關(guān)系，用于建立數(shù)據(jù)模型
• 數(shù)據(jù)流圖：描繪當(dāng)數(shù)據(jù)在軟件系統(tǒng)中流動(dòng)和被處理的邏輯過程，是建立功能模型的基礎(chǔ)
• 狀態(tài)轉(zhuǎn)換圖：描繪了系統(tǒng)的狀態(tài)及引起狀態(tài)轉(zhuǎn)換的事件，是建立行為模型的基礎(chǔ)

33. 狀態(tài)轉(zhuǎn)換圖符號(hào)含義及怎么畫 P65，P67
34. 層次方框圖：是用樹形結(jié)構(gòu)的一系列多層次的矩形框描繪數(shù)據(jù)的層次結(jié)構(gòu)。最頂層矩形框：代表完整的數(shù)據(jù)結(jié)構(gòu)；下面各層的矩形框代表數(shù)據(jù)的子集；最底層的矩形框代表實(shí)際數(shù)據(jù)元素

第四章 形式化說明技術(shù)

35. 按形式化程度分為三類：

• 非形式化，如用自然語言描述規(guī)格說明
• 半形式化，如用數(shù)據(jù)流圖或?qū)嶓w-聯(lián)系圖建立模型
• 形式化，如描述系統(tǒng)性質(zhì)是基于數(shù)學(xué)的技術(shù)

36. 非形式化的缺點(diǎn)

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

37. 形式化的優(yōu)點(diǎn)：

• 能夠簡潔準(zhǔn)確的描述物理現(xiàn)象、對(duì)象或動(dòng)作的結(jié)果
• 在不同的軟件工程活動(dòng)之間平滑過渡
• 提供了高層確認(rèn)的手段

38. 應(yīng)用形式化準(zhǔn)則

• 選用適當(dāng)?shù)谋硎痉椒?/li>
• 應(yīng)該形式化，但不要過分形式化
• 應(yīng)該估算成本
• 應(yīng)該有形式化顧問隨時(shí)提供咨詢
• 不應(yīng)該放棄傳統(tǒng)的開發(fā)方法
• 應(yīng)該建立詳盡的文檔
• 不應(yīng)該放棄質(zhì)量標(biāo)準(zhǔn)
• 應(yīng)該測試，測試再測試
• 應(yīng)該重用

第五章 總體設(shè)計(jì)

39. 設(shè)計(jì)過程：2個(gè)階段(系統(tǒng)設(shè)計(jì)階段:確定系統(tǒng)的具體實(shí)現(xiàn)方案 和 結(jié)構(gòu)設(shè)計(jì)階段:確定軟件結(jié)構(gòu)); 9個(gè)步驟：

• 設(shè)想供選擇的方案
• 選取合理的方案
• 推薦最佳方案
• 功能分解
• 設(shè)計(jì)軟件結(jié)構(gòu)
• 設(shè)計(jì)數(shù)據(jù)庫
• 制定測試計(jì)劃
• 書寫文檔
• 審查和復(fù)審

40. 設(shè)計(jì)原理的相關(guān)概念

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

41. 耦合：是對(duì)一個(gè)軟件結(jié)構(gòu)內(nèi)不同模塊之間互連程度的度量。耦合強(qiáng)弱取決于模塊間接口的復(fù)雜程度，進(jìn)入或訪問一個(gè)模塊的點(diǎn)，以及通過接口的數(shù)據(jù)。耦合程度強(qiáng)烈影響著系統(tǒng)的可理解性、可測試性、可靠性、可維護(hù)性。設(shè)計(jì)原則：盡量使用數(shù)據(jù)耦合，少用控制耦合和特征耦合，限制公共環(huán)境的耦合的范圍，完全不用內(nèi)容耦合。

• 數(shù)據(jù)耦合：如果兩個(gè)模塊彼此間通過參數(shù)交換信息，而且交換的信息僅僅是數(shù)據(jù)。數(shù)據(jù)耦合是低耦合
• 控制耦合：傳遞的信息中有控制信息。中等耦合，增加了系統(tǒng)的復(fù)雜性
• 特征耦合：當(dāng)整個(gè)數(shù)據(jù)結(jié)構(gòu)作為參數(shù)傳遞而被調(diào)用的模塊只需要使用其中一部分?jǐn)?shù)據(jù)元素時(shí)
• 公共環(huán)境耦合：當(dāng)兩個(gè)或?qū)€(gè)模塊通過一個(gè)公共數(shù)據(jù)環(huán)境互相作用時(shí)。公共環(huán)境可以是全程變量、共享通信區(qū)、內(nèi)存的公共覆蓋區(qū)、任何存儲(chǔ)介質(zhì)的文件、物理設(shè)備等。
• 內(nèi)容耦合：如果發(fā)生之一就是①一個(gè)模塊訪問另一個(gè)模塊的內(nèi)部數(shù)據(jù),②一個(gè)模塊不通過正常入口而轉(zhuǎn)到另一個(gè)模塊的內(nèi)部,③兩個(gè)模塊有一部分程序代碼重疊,④一個(gè)模塊有多個(gè)入口

42. 內(nèi)聚：標(biāo)志著一個(gè)模塊內(nèi)各個(gè)元素彼此之間結(jié)合的緊密程度，它是信息隱藏和局部化概念的擴(kuò)展。設(shè)計(jì)原則：力求高內(nèi)聚，通過提高模塊間的內(nèi)聚降低耦合從而使模塊獲得較高的獨(dú)立性。高內(nèi)聚意味著低耦合
43. 低內(nèi)聚

• 偶然內(nèi)聚：如果一個(gè)模塊完成一組任務(wù)，這些任務(wù)彼此之間有關(guān)系，關(guān)系也是很松散的。如在一個(gè)程序內(nèi)有一組語句在兩處或多處出現(xiàn)，于是把這些語句作為一個(gè)模塊以節(jié)省內(nèi)存
• 邏輯內(nèi)聚：如果一個(gè)模塊完成的任務(wù)在邏輯上屬于相同或相似的一類。如一個(gè)模塊產(chǎn)生各種類型的全部輸出
• 時(shí)間內(nèi)聚：如果一個(gè)模塊包含的任務(wù)必須在同一時(shí)間內(nèi)執(zhí)行。如模塊完成各種初始化工作

44. 中內(nèi)聚

• 過程內(nèi)聚：如果一個(gè)模塊內(nèi)的處理元素是相關(guān)的，且必須以特定次序執(zhí)行。如流程圖確定模塊的劃分，得到的往往是過程內(nèi)聚的模塊
• 通信內(nèi)聚：如果一個(gè)模塊中所有元素都是用同一個(gè)輸入數(shù)據(jù)和產(chǎn)生同一個(gè)輸出數(shù)據(jù)

45. 高內(nèi)聚

• 順序內(nèi)聚：如果一個(gè)模塊內(nèi)的處理元素和同一個(gè)功能密切相關(guān)，且這些處理必須順序執(zhí)行。如一個(gè)處理元素的輸出數(shù)據(jù)作為下一個(gè)處理元素的輸入數(shù)據(jù)，根據(jù)數(shù)據(jù)流圖劃分模塊得到往往是順序內(nèi)聚模塊
• 功能內(nèi)聚：如果模塊內(nèi)的所有處理元素屬于一個(gè)整體，完成單一的功能

46. 7種內(nèi)聚的優(yōu)劣評(píng)分

47. 啟發(fā)規(guī)則

• 改進(jìn)軟件結(jié)構(gòu)提高模塊的獨(dú)立性
• 模塊規(guī)模應(yīng)該適中
• 深度、寬度、扇出和扇入都應(yīng)適當(dāng)
• 模塊的作用域應(yīng)該在控制域內(nèi)
• 力爭降低模塊接口的復(fù)雜程度
• 設(shè)計(jì)單入口單出口的模塊
• 模塊的功能應(yīng)該可預(yù)測

48. 描繪軟件結(jié)構(gòu)的圖形工具（例子見P102,P103）

• 層次圖：描繪軟件的層次結(jié)構(gòu)。一個(gè)矩形框代表一個(gè)模塊，方框間的連線表示調(diào)用關(guān)系
• HIPO圖：“層次圖加輸入/處理/輸出圖”，就是在層次圖的每個(gè)方框加編號(hào)
• 結(jié)構(gòu)圖：每個(gè)方框代表一個(gè)模塊，框內(nèi)注明模塊的名字或主要功能，方框間的箭頭（或直線）代表模塊的調(diào)用關(guān)系，注釋表示來回傳遞的信息【尾部空心圓表示傳遞數(shù)據(jù)，實(shí)心圓代表傳遞控制信息】

第六章 詳細(xì)設(shè)計(jì)

49. 人機(jī)界面設(shè)計(jì)指南：P123,P124

• 一般交互指南
• 信息顯示指南
• 數(shù)據(jù)輸入指南

50. 程序流程圖：

• 優(yōu)點(diǎn)：對(duì)控制流程的描繪直觀，初學(xué)者很容易掌握
• 缺點(diǎn)：①程序流程圖不是精益求精的好工具嗎，它誘使程序員過早地考慮程序的控制流程，而不去考慮全局結(jié)構(gòu)②程序流程圖中用箭頭代表控制流 ，因此程序員不受任何約束，可以完全不顧結(jié)構(gòu)程序設(shè)計(jì)的思想，隨意轉(zhuǎn)移③程序流程圖不易表示數(shù)據(jù)結(jié)構(gòu)

51. 盒圖（N-S圖）的特點(diǎn)：

• 功能域明確
• 不可能任意轉(zhuǎn)移控制
• 很容易確定局部和全局?jǐn)?shù)據(jù)的作用域
• 很容易表現(xiàn)嵌套關(guān)系，也可以表示模塊的層次結(jié)構(gòu)

52. 問題分析圖（PAD圖）：使用二維結(jié)構(gòu)的圖來表示程序的控制流。其優(yōu)點(diǎn)：

• 使用PAD符號(hào)設(shè)計(jì)出來必然是結(jié)構(gòu)化程序
• PAD圖描繪的程序結(jié)構(gòu)十分清楚
• PAD圖表現(xiàn)程序的邏輯，易讀、易懂、易記
• 很容易將PAD圖轉(zhuǎn)化為高級(jí)語言程序
• 即可表示程序邏輯，也可表示數(shù)據(jù)結(jié)構(gòu)
• PAD符號(hào)支持自動(dòng)向下，逐步求精

53. 判定表：當(dāng)算法中含有多重嵌套的條件選擇時(shí)

• 優(yōu)點(diǎn)：能清晰表示復(fù)雜的條件組合與應(yīng)做的動(dòng)作之間的關(guān)系
• 缺點(diǎn)：①判定表的含義不能一眼看出來②當(dāng)數(shù)據(jù)元素多于兩個(gè)時(shí)，判定表的簡潔程度下降

54. 判定樹：判定表變種

• 優(yōu)點(diǎn)：一眼看出其含義，易于掌握，使用
• 缺點(diǎn)：①簡潔性不如判定表，數(shù)據(jù)元素需重復(fù)寫多遍②判定樹的分支次序?qū)Ξ嫵龅呐卸涞暮啙嵆潭扔休^大影響

55. PDL（過程設(shè)計(jì)語言）：也稱偽碼，具有嚴(yán)格的關(guān)鍵字外部語法，用于定義控制結(jié)構(gòu)和數(shù)據(jù)結(jié)構(gòu)，內(nèi)部語法靈活自由，適應(yīng)各種工程項(xiàng)目。

其優(yōu)點(diǎn)：

• 可作為注釋直接插在源程序中間
• 可使用普通的正文編輯程序或文字處理系統(tǒng)完成PDL的書寫和編輯
• 已有自動(dòng)處理PDL的程序，可自動(dòng)生成程序代碼

其缺點(diǎn)：

• 不如圖形工具形象直觀，描述復(fù)雜的條件組合與動(dòng)作間的對(duì)應(yīng)關(guān)系時(shí)，不如判定表清晰簡單

56. McCabe方法：McCabe根據(jù)程序控制流的復(fù)雜程度度量 程序的復(fù)雜程度，這樣度量出的結(jié)果稱為程序的環(huán)形復(fù)雜度

①流圖的表示：

• 結(jié)點(diǎn)：用圓表示，一個(gè)圓代表一條或多條語句
• 邊：箭頭線稱為邊，代表控制流
• 區(qū)域：由邊和結(jié)點(diǎn)圍成的面積 稱為區(qū)域，當(dāng)計(jì)算區(qū)域數(shù)時(shí)應(yīng)該包括圖外未被圍起來的區(qū)域
• 判定結(jié)點(diǎn)：包含條件的結(jié)點(diǎn)

②計(jì)算環(huán)形復(fù)雜度的方法:

• 流圖中線性無關(guān)的區(qū)域數(shù)等于環(huán)形復(fù)雜度
• 流圖G的環(huán)形復(fù)雜度V(G)=E-N+2,其中E是流圖中邊的條數(shù)，N是結(jié)點(diǎn)數(shù)
• 流圖G的環(huán)形復(fù)雜度V(G)=P+1,其中P是流圖中判定結(jié)點(diǎn)的數(shù)目

第七章 實(shí)現(xiàn)

編碼：把詳細(xì)設(shè)計(jì)結(jié)果翻譯成某種程序語言書寫的程序
軟件測試：是保證軟件質(zhì)量的關(guān)鍵步驟，是對(duì)軟件規(guī)格說明、設(shè)計(jì)和編碼的最后復(fù)審

第七章實(shí)現(xiàn)(編碼和測試).png

測試用例：所謂測試用例是為特定的目的而設(shè)計(jì)的一組測試輸入、執(zhí)行條件和預(yù)期的結(jié)果；測試用例是執(zhí)行測試的最小實(shí)體。

白盒測試主要用于對(duì)模塊的測試，包括：程序模塊中的所有獨(dú)立路徑至少執(zhí)行一次；對(duì)所有邏輯判定的取值（“真”與“假”）都至少測試一次；在上下邊界及可操作范圍內(nèi)運(yùn)行所有循環(huán)；測試內(nèi)部數(shù)據(jù)結(jié)構(gòu)的有效性等。

黑盒測試可用于各種測試，它試圖發(fā)現(xiàn)以下類型的錯(cuò)誤：不正確或遺漏的功能；界面錯(cuò)誤；數(shù)據(jù)結(jié)構(gòu)錯(cuò)誤或外部信息(如外部數(shù)據(jù)庫)訪問錯(cuò)誤；性能錯(cuò)誤；初始化和終止錯(cuò)誤。

第八章 維護(hù)

57. 軟件維護(hù)的定義：就是在軟件已經(jīng)交付使用之后，為了改正錯(cuò)誤或滿足新的需要而修改軟件的過程
58. 結(jié)構(gòu)化維護(hù)和非結(jié)構(gòu)化維護(hù)

①非結(jié)構(gòu)化維護(hù)

• 如果軟件配置的唯一成分是程序代碼，那么維護(hù)活動(dòng)從評(píng)價(jià)代碼開始，而且由于內(nèi)部文檔不足而使評(píng)價(jià)更困難
• 非結(jié)構(gòu)化維護(hù)需要付出巨大代價(jià)，是沒有使用良好定義的方法學(xué)開發(fā)出來的必然結(jié)果
  ②結(jié)構(gòu)化維護(hù)
• 如果有一個(gè)完整軟件配置存在，那么維護(hù)從評(píng)價(jià)設(shè)計(jì)文檔開始就很規(guī)范
• 減少精力的浪費(fèi)，提高維護(hù)的總體質(zhì)量

59. 決定軟件可維護(hù)的因素：

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

第八章 面向?qū)ο蠓椒▽W(xué)引論

60. 面向?qū)ο蠓椒▽W(xué)要點(diǎn)：

①基本原則：盡可能模擬人類習(xí)慣的思維方式，是開發(fā)軟件的方法和過程盡可能接近人類認(rèn)識(shí)的世界解決問題的方法和過程
②4個(gè)要點(diǎn)

• 軟件是由對(duì)象組成的，任何元素都是對(duì)象，復(fù)雜軟件對(duì)向由比較簡單的軟件對(duì)象組成
• 所有對(duì)象都劃分成對(duì)象類，類都定義了一組數(shù)據(jù)和一組方法
• 若干對(duì)象類組成一個(gè)層次的系統(tǒng)
• 對(duì)象間僅能通過傳遞消息互相聯(lián)系
  ③面向?qū)ο蠓椒▽W(xué)優(yōu)點(diǎn)
• 與人類習(xí)慣的思維方法一致
• 穩(wěn)定性好
• 可重用性好
• 較易開發(fā)大型軟件產(chǎn)品
• 可維護(hù)性好

61. 對(duì)象：是描述該對(duì)象屬性的數(shù)據(jù)以及對(duì)這些數(shù)據(jù)施加的所有操作封裝在一起構(gòu)成的統(tǒng)一體

①對(duì)象的定義

• 對(duì)象是具有相同狀態(tài)的一組操作的集合
• 對(duì)象是對(duì)問題域中某個(gè)東西的抽象
• 對(duì)象::=<ID,MS,DS,MI>。ID是對(duì)象的標(biāo)識(shí)或名字，MS操作集合，DS數(shù)據(jù)結(jié)構(gòu)，MI對(duì)象受理的消息名集合
  ②對(duì)象的特點(diǎn)
• 以數(shù)據(jù)為中心
• 對(duì)象是主動(dòng)
• 實(shí)現(xiàn)了數(shù)據(jù)的封裝
• 本質(zhì)上具有并行性
• 模塊獨(dú)立性好

62. 其它概念

• 類：是一組具有相同屬性和相同操作的對(duì)象的集合。
• 實(shí)例：由某個(gè)特定的類所描述的一個(gè)具體的對(duì)象。
• 消息：要求某個(gè)對(duì)象執(zhí)行在定義它的那個(gè)類中所定義的某個(gè)操作的規(guī)格說明。組成部分：接收消息的對(duì)象；消息名；消息變?cè)?/li>
• 方法：就是對(duì)象所能執(zhí)行的操作，也就是類中所定義的服務(wù)。
• 屬性：屬性就是類中所定義的數(shù)據(jù)，它是對(duì)客觀世界實(shí)體所具有的性質(zhì)的抽象。
• 封裝：對(duì)象封裝了對(duì)象的數(shù)據(jù)以及對(duì)這些數(shù)據(jù)的操作。
• 繼承：繼承是子類自動(dòng)地共享基類中定義的數(shù)據(jù)和方法的機(jī)制。
• 單重繼承：子類僅從一個(gè)父類繼承屬性和方法
• 多重繼承：子類可從多個(gè)父類繼承屬性和方法
• 多態(tài)性：指子類對(duì)象可以像父類那樣使用
• 函數(shù)重載：指在同一作用域內(nèi)的若干參數(shù)特征不同的函數(shù)可以使用相同的函數(shù)名
• 運(yùn)算符重載：指在同一個(gè)運(yùn)算符可以施加于不同類型的操作數(shù)上面

第十章 面向?qū)ο蠓治?/h3>

63. 建立對(duì)象模型

①三個(gè)子模型，按所解決的問題進(jìn)行劃分

• 靜態(tài)結(jié)構(gòu)（對(duì)象模型）
• 交互次序（動(dòng)態(tài)模型）
• 數(shù)據(jù)變換（功能模型）

②5個(gè)層次

• 主題層
• 類與對(duì)象層
• 結(jié)構(gòu)層
• 屬性層
• 服務(wù)層

③對(duì)象模型創(chuàng)建的步驟

• 確定類與對(duì)象
• 確定關(guān)聯(lián)
• 劃分主題
• 確定屬性
• 識(shí)別繼承關(guān)系
• 反復(fù)修改

第十一章 面向?qū)ο笤O(shè)計(jì)

64. 面向?qū)ο笤O(shè)計(jì)準(zhǔn)則

• 模塊化
• 抽象
• 信息隱藏
• 弱耦合
• 強(qiáng)內(nèi)聚
• 可重用

65. 類構(gòu)件的重用方式：

• 實(shí)例重用
• 繼承重用
• 多態(tài)重用