軟體工程個人筆記
僅作個人整理，期末背答案用。
軟體工程導論第六版答案見：軟體工程導論(第六版)課後習題答案
mark一個詳細筆記：《軟體工程導論》學習筆記
mark一個軟工導論簡答題：軟體工程複習資料簡答題
章節
- 第1章 軟體工程學概述
- 第2章 可行性研究
- 第3章 需求分析
- 第4章 形式化說明技術
- 第5章 總體設計
- 第6章 詳細設計
- 第7章 實作
- 第8章 維護
- 第9章 面向對象方法學引論
- 第10-12章 面向對象分析、設計和實作
第1章 軟體工程學概述
1.1 軟體生命周期各階段任務是什麼？
軟體生命周期由軟體定義，軟體開發和運作維護三個時期組成。每個時期又分為若幹階段。
軟體定義時期：問題定義、可行性研究、需求分析。
開發時期：總體設計、詳細設計、編碼和單元測試、綜合測試。
運作維護時期：軟體維護。
1、問題定義：要解決的問題是什麼
2、可行性研究：确定問題是否值得解，技術可行性、經濟可行性、操作可行性
3、需求分析：系統必須做什麼
4、總體設計：系統如何實作，包括系統設計和結構設計
5、詳細設計：具體實作設計的系統
6、實作：編碼和測試
7、運作維護：保證軟體正常運作。
各階段說明見：軟體開發生命周期各階段的任務
1.2 什麼是軟體危機？它有哪些典型表現？為什麼會出現軟體危機？
軟體危機是指在計算機軟體開發、 使用與維護過程中遇到的一系列嚴重問題和難題。 它包括兩方面：如何開發軟體，已滿足對軟體日益增長的需求；如何維護數量不斷增長的已有軟體。
軟體危機的典型表現：
(1) 對軟體開發成本和進度的估計常常很不準确。
(2) 使用者對已完成的軟體不滿意的現象時有發生。
(3) 軟體産品的品質往往是靠不住的。
(4) 軟體常常是不可維護的。
(5) 軟體通常沒有适當的文檔資料。 文檔資料不全或不合格， 必将給軟體開發和維護工作帶來許多難以想象的困難和難以解決的問題。
(6) 軟體成本、軟體維護費在計算機系統總成本中所占比例逐年上升。
(7) 開發生産率提高的速度遠跟不上計算機應用普及的需求。
軟體危機出現的原因：
(1) （客觀）來自軟體自身的特點：是邏輯部件，缺乏可見性；規模龐大、複雜，修改、維護困難。
(2) （主觀）軟體開發與維護的方法不當：忽視需求分析；認為軟體開發等于程式編寫；輕視軟體維護。
(3) 供求沖突将是一個永恒的主題：面對日益增長的軟體需求，人們顯得力不從心。
1.3 什麼是軟體工程？它有哪些本質特征？怎樣用軟體工程消除軟體危機？
1993 年 IEEE的定義：軟體工程是：① 把系統的、規範的、可度量的途徑應用于軟體開發、運作和維護過程，也就是把工程應用于軟體；② 研究①中提到的途徑。
軟體工程的本質特征：
(1) 軟體工程關注于大型程式 ( 軟體系統 ) 的構造 。
(2) 軟體工程的中心課題是分解問題，控制複雜性。
(3) 軟體是經常變化的，開發過程中必須考慮軟體将來可能的變化。
(4) 開發軟體的效率非常重要，是以，軟體工程的一個重要課題就是，尋求開發與維護軟體的更好更有效的方法和工具。
(5) 和諧地合作是開發軟體的關鍵。
(6) 軟體必須有效地支援它的使用者。
(7) 在軟體工程領域中是由具有一種文化背景的人替具有另一種文化背景的人 ( 完成一些工作 )。
消除軟體危機的途徑：(技術措施：方法、工具；組織管理措施)
(1) 對計算機軟體有一個正确的認識 ( 軟體≠程式，軟體是程式、資料及相關文檔的完整集合）
(2) 必須充分認識到軟體開發不是某種個體勞動的神秘技巧， 而應該是一種組織良好、 管理嚴密、各類人員協同配合、共同完成的工程項目
(3) 推廣使用在實踐中總結出來的開發軟體的成功技術和方法
(4) 開發和使用更好的軟體工具
1.4 軟體工程方法學包含三個要素：方法、工具和過程。
簡述結構化範型和面向對象範型的要點，并分析他們的優缺點。
-
傳統方法學：也稱為生命周期方法學或結構化範型。
優點：把軟體生命周期劃分成若幹個階段，每個階段的任務相對獨立，而且比較簡單，便于不同人員分工協作， 進而降低了整個軟體開發過程的困難程度。
缺點：當軟體規模龐大時，或者對軟體的需求是模糊的或會承受時間而變化的時候，開發出的軟體往往不成功；而且維護起來仍然很困難。
-
面向對象方法學=對象+類+繼承+用消息通信
優點：降低了軟體産品的複雜性；提高了軟體的可了解性；簡化了軟體的開發和維護工作； 促進了軟體重用。
缺點：沒有準确的定義、維護困難、不适合所有的應用。
第2章 可行性研究
2.1可行性研究的任務
可行性研究的目的就是用最小代價在盡可能短的時間内确定問題是否能夠解決。
可行性研究應從以下幾個方面來分析:
(1)技術可行性∶使用現有技術能實作這個系統嗎?
(2)經濟可行性:該系統的經濟效益能超過他的開發成本嗎?
(3)操作可行性∶系統的操作方式在這個使用者組織内性的通嗎?
(4)有時需從法律、社會效益等更廣泛方面分析可行性。
2.2 資料流圖DFD（自行看題）
資料流圖有4種成分：源點或終點，處理，資料存儲和資料流。
資料字典由下列4類元素定義組成：資料流、資料流分量、資料存儲、處理。
點\邊周遊方法
銀行計算機儲蓄系統資料流圖和結構圖：銀行拟開發計算機儲蓄系統
航空公司機票預定系統資料流圖：機票預定系統
第3章 需求分析
3.1 為什麼要進行需求分析？通常對軟體系統有哪些要求？
使用者需求、系統需求。
1)為了開發出真正滿足使用者需求的軟體産品，首先必須知道使用者的需求。對軟體需求的深入了解是軟體開發工作獲得成功的前提條件， 不論我們把設計和編碼工作做得如何出色， 不能真正滿足使用者需求的程式隻會令使用者失望，給開發者帶來煩惱。
2)确定對系統的綜合要求： 1、功能需求； 2、性能需求； 3、可靠性和可用性需求； 4、出錯處理需求； 5、接口需求； 6、限制； 7、逆向需求； 8、将來可以提出的要求，分析系統的資料要求。
3.2 IPO圖、E-R圖（自行看題）
3.3 用例圖、類圖、對象圖
第4章 形式化說明技術
4.1 形式化說明技術和欠形式化方法的優缺點。
自然語言系統規格說明書，可能存在沖突、二義性、含糊性、不完整性及抽象層次混亂等問題。
形式化說明優點：1，簡潔準确的描述實體現象，對象獲動作的結果。2，可以在不同軟體工程活動之間平滑的過度。3，它提供了高層确認的手段。
缺點：大多形式化的規格說明主要關注系統的功能和資料，而時序的問題，控制和行為等方面的需求卻更難于表示。
4.2 其他都好難、應該不考吧
第5章 總體設計
5.1 總體設計由兩個主要階段構成：
- 系統設計階段——确定系統具體實作方案
- 結構設計階段——确定軟體結構
共9個步驟：設想供選擇的方案、選取合理的方案、推薦最佳方案、功能分解、設計軟體結構、設計資料庫、制定測試計劃、書寫文檔、審查和複審。
5.2 設計原理
對比面向對象的設計原理10.2
- 子產品化
- 抽象
- 逐漸求精
- 資訊隐藏和局部化
-
子產品獨立：
耦合（由低到高）：度量子產品之間互相連接配接的緊密程度。
非直接耦合、資料耦合、控制耦合、特征耦合、公共環境耦合、内容耦合。
内聚（由高到低）：度量一個子產品内部各個元素彼此結合的緊密程度。
功能内聚、順序内聚、通信内聚、過程内聚、時間内聚、邏輯内聚、偶然内聚。
5.3 層次圖、結構圖（自行看題）
5.4事務流-事務分析、變換流-變換分析（自行看題）：将資料流圖轉換為軟體結構
5.5 面向過程（結構化）的啟發規則：見10.3
5.6 某BBS模闆的發文章系統有如下功能:(1)記錄發帖内容:訪客在表單中輸入文字,系統進行檢查,存入檔案。
(2)顯示發帖内容:讀出檔案,按一定格式顯示在螢幕上。請根據功能要求畫出該系統的資料流圖,并将其轉換為軟體結構圖。
第6章 詳細設計
6.1 為了實作使用程式流程圖描述結構化程式，必須限制程式流程圖隻使用以下五種基本控制結構：順序型 、 選擇型 、 DO while 型循環、DO until 型循環、 DO case型選擇。
6.2 軟體的詳細設計可以采用圖、表、過程設計語言 三種形式的描述工具表示子產品的處理過程。
6.3 狹義的定義結構化程式設計：程式代碼僅通過順序、選擇和循環這3種基本控制結構進行連接配接，并且代碼塊單入口單出口。
6.4 程式流程圖、盒圖（N-S圖）、PAD圖（自行看題）
6.5 程式流圖轉資料流圖
第7章 實作
7.1 把編碼和測試統稱為實作
7.2 軟體測試的目标：
測試是為了發現程式中的錯誤而執行程式的過程。
好的測試方案是極有可能發現迄今為止尚未發現的錯誤的測試方案。
成功的測試是發現了至今為止尚未發現的錯誤的測試。
7.3 軟體測試包括哪些步驟?分别說明這些步驟的對象是什麼，
(1)子產品測試（單元測試），測試對象為單元子產品。這個步驟往往發現的是編碼和詳細設計的錯誤。
(2)內建測試 ,測試對象為組裝後的程式子產品。子系統測試着重測試子產品接口，系統測試發現的往往是軟體設計中的錯誤及需求說明中的錯誤。
(3)驗收測試（确認測試） ,測試對象為可運作的目标軟體系統。往往發現系統需求說明書的錯誤。
(4)最後一步是平行運作 ,同時運作新開發的系統和舊系統，比較兩個系統處理結果。
7.4 白盒測試中的邏輯覆寫有哪幾種常用的覆寫技術？試對它們的檢錯能力進行比較。
答： (1)語句覆寫
(2) 判定覆寫 (比語句覆寫嚴格些 )
(3) 條件覆寫 (比單是判定覆寫要嚴格 )
(4) 判定 /條件測試 （條件覆寫也不一定滿足判定覆寫， 因為隻符合條件覆寫的用例
可能會不滿足每個判定語句均有真值或假值出現。是以要兩者兼顧）
(5) 條件組合覆寫 （是前兩個覆寫的組合）
(6) 路徑覆寫 （指設計足夠的測試用例，覆寫被測程式中所有可能的路徑）
點覆寫：同語句覆寫
邊覆寫：同判定覆寫
條件組合發現錯誤的能力較強，凡滿足其标準的測試用例，也必然滿足前四種覆寫标準，在實際的邏輯測試中，一般以條件組合覆寫為主設計測試用例，然後再補充部分用例來達到路徑覆寫的測試标準。
7.5 黑盒測試技術：等價劃分、邊界值分析、錯誤推測。
7.6 黑盒測試、白盒測試的差別、優缺點
7.7 輸入三個整數,判斷是否構成三角形。如構成三角形,則輸出三條邊的值,否則輸出“不能構成三角形”。
3.輸入三個整數,判斷是否構成三角形。如構成三角形,則輸出三條邊的值,否則輸出“不能構成三角形”。
(1)用程式流程圖表示該問題的算法;(2）計算程式的環形複雜度;(3)設計路徑覆寫的測試用例。
7.8 4.某企業進行公開招聘,規定報名者年齡應在16~35歲之間（1982年1月1日到1999年12月31日為止),出生年日不早于1967年2月，不晚于1986年3月。報名程式具有自動檢驗輸入教據的功能，如出生年日不在上述範圍内将拒絕接受,并顯示“年齡不合格”等出錯資訊。
（1)試用等價分類法,設計出生年月的等價分類表:(2)設計有效等價類、無效等價類需要的測試用例:(3)采用邊界值分析法來選擇測試用例。
第8章 維護
8.1 軟體的可維護性與哪些因素有關？
（1）可了解性（2）可預測性（3）可修改性（4）可移植性（5）可重用性
8.2 軟體維護是軟體生命周期的最後一個階段。主要任務：維護軟體的正常運作，不斷改進軟體的性能和品質，為軟體的進一步推廣應用和更新替換做積極工作。
8.3 軟體文檔分為使用者文檔和系統文檔兩大類。使用者文檔主要描述系統文檔和使用方法（功能描述、安裝文檔、使用手冊、參考手冊、操作員指南）。系統文檔包含系統設計、實作、測試等方面。
第9章 面向對象方法學引論
9.1 什麼是面向對象方法學？它有什麼什麼優點？
面向對象方法是一種運用對象、類、封裝、繼承、多态和消息等概念來構造、測試、重構軟體的方法。
面向對象方法學的優點：
- 與人類習慣的思維方法一緻。
- 穩定性好。
- 可重用性好。
- 較易開發軟體産品。
-
可維護性好。
補：面向對象方法四個要點：對象、類、繼承和消息
9.2 請分析UML2.0中的順序圖和協作圖兩者之間的主要差别和各自的優缺點。
答:協作圖可視化地表示了對象之間随事件發生的互動，他除了展示對象之間的關聯，還顯示出對象之間的消息傳遞。與順序圖一樣，協作圖也展示對象之間的互動關系。順序圖強調的是互動的時間順序，而協作圖強調的是互動的語境和參與互動的對象的整體組織。順序圖按照時間順序布圖，而協作圖按照空間組織布圖。順序圖可以清晰地表示消息之間的順序和時間關系，但需要較多的水準方向的空間協作圖在增加對象時比較容易，而且分支也比較少，但如果消息比較多，則難以表示消息之間的順序。
9.3 面向對象模組化：3種形式的模型
第一是描述系統資料結構 的對象模型(UML類圖)，
第二是描述系統控制結構的動态模型(狀态轉化圖)；
第三是描述系統功能的功能模型(用例圖)。
9.4 類與類之間通常有關聯、泛化(繼承)、依賴和 細化等4種關系。
第10-12章 面向對象分析、設計和實作
10.1 面向對象模組化是OOA的關鍵。OOA的模型要表示出系統的資料、功能和行為三方面的基本特征，是以通常需要建立三種模型，分别是對象模型、動态模型和功能模型。其中：
（1）對象模型描述系統的資料結構，它是用來描述系統包含的對象及對象之間關系的模型；
（2）動态模型描述系統的控制結構，它是用來确定各個對象之間互動及整體的控制結構的模型；
（3）功能模型描述系統的功能，它是用來描述系統要實作的功能的模型
10.2 面向對象設計的準則，簡述每條準則内容
子產品化：對象就是子產品。
抽象：類實際上是一種抽象資料類型，對外開放公共接口。
資訊隐藏：通過對象的封裝性實作，類結構分離了接口與實作，進而支援了資訊隐藏。
弱耦合：對象是最基本的子產品，耦合指不同對象之間互相關聯的緊密程度。對象不可能完全孤立，兩個對象互相依賴時通過公共接口耦合，不應該依賴類的具體實作細節。
強内聚：内聚衡量一個子產品内各個元素彼此結合的緊密程度，面向對象設計存在三種内聚：服務内聚、類内聚、一般-特殊内聚。
可重用：一方面指使用已有的類，二是建立新類時考慮将來的可重複使用性。
10.3 面向對象設計的啟發式規則
- 設計結果應該清晰易懂
- 一般/特殊結構的深度應适當
- 設計簡單的類
- 使用簡單的協定
- 設計簡單的服務
- 最小設計變動
對比結構化設計的啟發規則：
- 改進軟體結構提高子產品獨立性
- 子產品規模應該适中
- 深度、寬度、扇入和扇出都應該适中
- 子產品的作用域應該在控制域之内
- 力争降低子產品接口的複雜程度
- 設計單入口單出口的子產品
- 子產品功能應該可以預測
10.4 面向對象實作應該選用哪種設計語言？
- 是否能占主導地位
- 可重用性
- 類庫和開發環境等
- 其他因素
10.6 程式設計風格
- 提高可重用性
- 提高可擴充性
- 提高健壯性