軟件工程整理

基于張海藩老師出版的《軟件工程導論（第六版）》，簡單整理軟件工程各章知識。

第一章 軟件工程學概述

1.1軟件危機

1.1.1軟件危機的介紹

軟件危機是指在計算機軟件的開發和維護過程中所遇到的一系列嚴重問題。

軟件危機包括下述兩個方面：

如何開發軟件，以滿足軟件日益增長的需求。

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

軟件危機主要有一下一些典型表現：

對軟件開發成本和進度的估計常常不準確

用戶對“已完成的”的軟件系統不滿意的現象時常發生

軟件的質量往往靠不住

軟件常常是不可維護的

軟件通常沒有適當的文檔文件

軟件成本在計算機系統總成本中所占的比例逐年上升

軟件開發生產率提高的速度，遠遠跟不上計算機應用迅速普及深入的趨勢

1.1.2產生軟件危機的原因

在軟件開發和維護的過程中存在這么多嚴重問題，一方面與軟件本身的特點有關，另一方面也和軟件開發與維護的方法不正確有關。

1.1.3消除軟件危機的途徑

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

1.2軟件工程

1.2.1軟件工程的介紹

1993年IEEE進一步給出了一個更全面更具體的意義：“軟件工程是：①把系統的、規范的、可度量的途徑應用于軟件開發、運行和維護過程，也及時把軟件工程應用于軟件；②研究①中提到的途徑。”

軟件工程具有以下的本質特征：

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

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

軟件經常變化

開發軟件的效率非常重要

和諧地合作是開發軟件的關鍵

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

在軟件工程領域中通常由具有一種文化背景的人替具有另一種文化背景的人創造產品

1.2.2軟件工程的基本原理

七條基本原理：

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

堅持進行階段評審

實行嚴格的產品控制

采用現代程序設計技術

結果應該能清楚地審查

開發小組的人員應該少而精

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

1.2.3軟件工程方法學

軟件工程包括技術和管理兩個方面的內容，是技術與管理緊密結合所形成的工程學科。

軟件工程方法學包含三要素：方法、工具和過程。

目前最廣泛 的軟件工程方法學，分別是傳統法學和面向對象方法學。

1.3軟件生命周期

軟件生命周期由軟件定義、軟件開發和運行維護3個時期組成。（三時期）

每個時期又進一步劃分成若干階段（八階段）：

軟件定義時期劃分成3個階段，即問題定義、可行性研究和需求分析。

軟件開發時期劃分成4個階段，即總體設計、詳細設計、編碼和單元測試、綜合測試。

對維護時期不再進一步劃分階段，但是每一次維護活動本質上都是一次壓縮和簡化了的定義和開發的過程。（軟件維護）

1.4軟件過程

生命周期模型規定了把規定生命周期劃分成哪些階段及各個階段的執行順序，因此，也成過程模型。

1.4.1瀑布模型

傳統方法學

特點：

階段間具有順序性和依賴性（一定線性）
①必須等前一段的工作完成后，才能開始后一階段的工作。②前一階段的輸出文檔就是后一階段的輸入文檔。

推遲實現的觀點（貢獻：首次提出）

質量保證的觀點

①每個階段都必須完成規定的文檔。②每個階段結束前都要對所完成的文檔進行評審。

總結：文檔驅動。

優點：瀑布模型的成功在很大程度上是由于它基本上是一種文檔驅動的模型

缺點：

用戶很難清晰表達出需求

程序員也不能一下理解

文檔過多

1.4.2快速原型模型

循環

特點：

快速開發工具

循環

低成本

1.4.3增量模型

特點：

在前面增量的基礎上開發后面的增量

每個增量的開發可用瀑布或快速模型

迭代的思路

1.4.4螺旋模型

特點：

瀑布模型+快速原型模型+風險分析

迭代過程

優點：

對可選方案和約束條件的強調有利于已有軟件的重用，也有助于把軟件質量作為軟件開發的一個重要目標。

減少了過多測試（浪費資金）或測試不足（產品故障多）所帶來的風險。

在螺旋模型中維護只是模型的另一個周期，在維護和開發之間并沒有本質區別。

風險驅動即時優點的主要來源，也可能是弱點。

1.4.5噴泉模型

面向對象開發學

“噴泉”這個詞體現了面向對象軟件開發過程迭代和無縫的特性。

1.4.6Rational統一過程

面向對象開發學

1.4.7敏捷過程與極限編程

敏捷過程

敏捷宣言：

①個體和交互勝過過程和工具
②可以工作的軟件勝過面面俱到的文檔
③客戶合作勝過合同談判
④響應變化勝過遵循計劃

極限編程

1.4.8微軟過程

1.5小結

第二章 可行性研究

2.1可行性研究

目的：是否值得去解決；是否能夠解決。

實質：進行一次達達壓縮化簡了的系統分析和設計的過程，也就是在較高層次上以抽象的方式進行的系統分析和設計的過程。

方面：

技術可行性

經濟可行性

操作可行性

法律、社會效益等更廣泛的方面

2.2可行性研究過程

步驟：

復查系統規模和目標

研究目前正在使用的系統

導出新系統的高層邏輯模型

進一步定義問題

導出和評價選擇的解法

推薦行動方針

草擬開發

書寫文檔提交審查

2.3系統流程圖

物理數據圖

描繪了組成系統的主要物理元素以及信息在這些元素間流動和處理的情況。（而不是對數據分析進行加工處理的控制過程）

2.4數據流圖

基本邏輯功能

功能模型的基礎

繪制方法：由內向外，自頂向下，分層繪制，逐步求精。

2.5數據字典

名稱，別名，描述，定義，位置

2.6成本/效益分析

2.6.1成本估計

代碼行技術

任務分解技術

自動估計成本技術

2.6.2成本/效益分析的方法

貨幣的時間價值

投資回收期

純收入

投資回收率

2.7小結

第三章 需求分析

常用方法有面向數據流的結構化分析方法，面向數據結構的分析方法，面向對象的分析方法。

3.1需求分析的任務

功能需求，性能需求，可靠性和可用性需求，出錯處理需求，接口需求，約束，逆向需求，將來可能提出的需求

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

3.2.1訪談

不理想

正式和非正式

3.2.2面向數據流自頂向下求精

不理想

結構化分析方法

3.2.3簡易的應用規格說明技術

主流

3.2.4快速建立軟件原型

最準確、最有效、最強大

“快速”、“容易修改”

3.3分析建模與規格說明

3.4實體-聯系圖

描述數據對象之間的關系

數據模型的基礎

3.4.1數據對象

有一組屬性來定義

3.4.2屬性

定義了數據對象的性質

3.4.3聯系

數據對象之間相互連接的方式

3.4.4實體-聯系圖的符號

實體：矩形
關系：菱形
屬性：橢圓

3.5數據規范化

范式

減少數據冗余

避免插入或刪除異常

3.6狀態轉換圖

外部事件結果的系統行為

行為建模的基礎

3.7其他圖形工具

3.7.1層次方框圖

屬性描繪數據的層次結構

3.7.2Warnier圖

樹形 > 層次方框圖

最著名的數據結構設計方法：Jackson + Warnier

3.7.3IPO圖

輸入、處理、輸出圖

簡略描述簡單算法

3.8驗證軟件需求

15%的錯誤來源

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

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

3.8.2驗證軟件需求的方法

人工/形式化

根據以往開發經濟

原型系統

3.8.3用于需求分析的軟件工具

PSL/PSA

第四章 形式化說明技術

4.1概述

4.1.1非形式化方法的缺點

矛盾、二義性、不完整性及抽象層次混亂

4.1.2形式化方法的優點

準確、簡介描述

不同軟件活動中平滑過渡

高層確認的手段

4.1.3應用形式化方法的準則

辯證地看待

4.2有窮狀態機

準確描述一個系統，表達規格說明的一種形式化方法

4.3Petri網

確定系統中隱含的定時問題，也可用于設計中

4.4Z語言

第五章 總體設計

劃分物理元素、設計軟件結構

5.1設計過程

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

5.2設計原理

5.2.1模塊化

程序劃分成獨立命名且可獨立訪問的模塊，每個模塊完成一個子功能，這些模塊集成起來成一個整體，可完成制定功能滿足客戶需求。

模塊：邊界元素限定相鄰程序元素的序列，且有一總體標識符代表它。

5.2.2抽象

抽出失誤的本質特征而暫時不考慮細節 / 分層次考慮與處理系統 / 一種忽略多余細節同時強調有關的細節

5.2.3逐步求精

為了能集中精力解決主要問題而盡量推遲對問題細節的考慮 / 是設計者在設計過程中逐步揭開底層細節

5.2.4信息隱藏和局部化

模塊內的信息對不需要的模塊是不可見的

將關系相近的物理放得近

“隱藏”意味著有效的模塊化可以通過定義一組獨立的模塊而實現，這些獨立的模塊彼此間僅僅交換那些為了完成系統功能而必須交換信息。

5.2.5模塊獨立

模塊獨立的概念是模塊化、抽象、信息隱蔽和局部化概念的直接結果

耦合

盡量使用數據耦合，少用控制耦合和特征耦合，限制公共環境耦合的范圍，完全不用內容耦合。

內聚

功能內聚、順序內聚、通信內聚、過程內聚、時間內聚、邏輯內聚、偶然內聚

5.3啟發規則

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

模塊規模應該適中

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

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

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

設計單入口單出口的模塊

模塊功能應該可以預測

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

5.4.1層次圖和HIPO圖

HIPO = 層次圖 + IPO

5.4.2結構圖

SC圖

5.5面向數據流的設計方法

變換流和事務流

第六章 詳細設計

6.1結構程序設計

3種基本控制結構：順序、循環、選擇

6.2人機界面設計

可使用性※、靈活性、可靠性

6.2.1設計問題

系統響應時間、用戶幫助設施、出錯信息處理、命令交互

6.2.2設計過程

迭代的過程

四個預示：

規格說明書的長度和復雜程度 → 學習工作量

命令和動作 → 系統交互時間和總體效率

動作、命令和系統狀態的數量 → 需要記憶的內容

界面風格、幫助設施和出錯處理協議 → 界面復雜度、用戶接受該界面的程度

6.2.3人機界面設計指南

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

6.3過程設計的工具

圖示、表格、語言

6.3.1程序流程圖

歷史長、最混亂

三個缺點：

本質上不是逐步求精的好工具，它誘使程序員過早地考慮程序的控制流，而不去考慮程序的全劇結構。

程序流程圖中用箭頭代表控制流，因此程序員不受任何約束，可以完全不顧程序設計的精神，隨意轉移控制。

程序流程圖不易表示數據結構。

6.3.2盒圖

結構程序設計精神

四個特點：

結構化功能域清晰

控制不能隨意轉移

數據的作用域清晰

易表示嵌套、層次關系

6.3.3PAD圖

問題分析圖、二維樹形、易譯成代碼

六個優點:

結構化程序

程序結構十分清晰

程序邏輯，易讀、易懂、易記（三個易）

可用軟件工具自動完成

既可以表示程序邏輯，也可用于描繪數據結構

PAD圖的符號支持自頂向下、逐步求精方法的使用（def符號增加細節）

6.3.4判定表

用于清楚地表示復雜的條件組合和應做的動作之間的關系

6.3.5判定樹

形式簡單，但重復多，分支的次序影響判定樹的復雜度。

6.3.6過程設計語言

不如圖形清晰

= 自然語言 + 結構化語言

四個特點：

結構化控制結構、數據說明和模塊化

自然語言的自由語法

數據說明的手段

應提供接口描述模式

優點：

可以作為注釋，以提高文檔的質量。

可以使用普通的正文編輯程序或文字處理。

有程序可以自動由PDL生成程序代碼。

缺點：不如圖形工具形象直觀，不如判定表清晰簡單。

6.4面向數據結構的設計方法

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

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

6.5.1McCabe方法

根據程序控制流圖的復雜度定量度量程序的復雜度。

環形復雜度V（G）= 圖形數 = E - N + 2 = P + 1

V（G） ≤ 10最好

6.5.2Halstead方法

根據程序中的運算符（包括關鍵字）和操作數的總數度量程序的復雜度。

第七章 實現

開發是自頂向下、逐步細化，測試是自頂向上、逐步集成。

軟件測試不等于程序測試，軟件測試應貫穿于軟件定義與開發的整個期間。

7.1編碼

7.1.1選擇程序設計語言

實用標準：

系統用戶要求

可以使用的編譯程序

可以得到的軟件工具

工程規模

程序員的知識

軟件可移植性要求

軟件的應用領域

7.1.2編碼風格

程序內部的文檔

數據說明

語句構成

輸入輸出

效率

7.2軟件測試基礎

7.2.1軟件測試的目標

G.Myers測試定義：

測試是為了發現程序中的錯誤而執行程序的過程

好的測試方案是極可能發現迄今為止尚未發現的錯誤的測試方案

成功的測試是發現了至今為止尚未發現的錯誤的測試

7.2.2軟件測試準則

測試準則：

所有測試都應該能追溯到用戶需求

應該遠在測試開始之前就制定出測試計劃

Pareto原理：80%的錯誤在20%的模塊中

測試順序應該是從“小規模”測試開始，并逐步進行“大規模”測試

窮舉測試是不可能的

應有獨立的第三方從事測試工作

7.2.3測試方法

黑盒測試，即功能測試

白盒測試，即結構測試

7.2.4測試步驟

模塊測試、子系統測試、系統測試、驗收測試、平行運行

7.2.5測試階段的信息流

7.3單元測試

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

應用人工測試和計算機測試完成單元測試

7.3.1測試重點

模塊接口

局部數據結構

重要的執行通路

出錯處理通路

邊界條件

7.3.2代碼審查

人工測試和計算機測試是相互補充，相輔相成的，缺少其中任何一種方法都會使查找錯誤的效率降低。

7.3.3計算機測試

需要驅動模塊、存根模塊，通常不把它們作為產品的一部分交給用戶。

模塊的內聚程度高可以簡化單元測試過程

7.4集成測試

集成測試是測試和組裝軟件的系統化技術，主要目標是發現與**接口**有關的問題。

分為漸增測試方法與非漸增測試方法

7.4.1自頂向下集成

深度優先或寬度優先

在測試的早起對主要的控制或關鍵的抉擇進行檢驗

優點：不需要測試驅動程序，能夠在測試階段的早期實現并驗證系統的主要功能，而且能在早期發現上層模塊的接口錯誤

缺點：需要存根程序，可能遇到與此相聯系的測試困難，低層關鍵模塊中的錯誤發現較晚，而且用這種方法在早期不能充分展開人力

7.4.2自底向上集成

優缺點與自頂向下集成剛好相反

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

混合法，即對軟件結構中較上層使用的自頂向下方法與對軟件結構中較下層使用的自底向上方法相結合，可能是**最好的**折衷方法。

7.4.4回歸測試

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

7.5確認測試

※確認測試計劃在需求分析階段制定，其他測試都在總體設計階段制定。

7.51確認測試的范圍

通常使用黑盒測試法

要保證軟件能滿足所有功能要求，能達到每個性能要求，文檔資料是準確而完整的，此外，還應該保證軟件能滿足其他預定的要求（例如安全性、可移植性、兼容性和可維護性）

7.5.2軟件配置復查

確認測試的一個重要內容是復查軟件配置。

復查的目的是保證軟件配置的所有成分都齊全，質量符合要求，文檔與程序完全一致，具有完成軟件維護所必須的細節，而且已經編好目錄。

7.5.3Alpha和Beta測試

Alpha測試：在開發場所進行測試，并有開發人員指導。

Beta測試：在使用環境下進行測試，盡量使用真實數據。

7.6白盒測試技術

設計測試方案的基本目的是，確定一組最可能發現某個錯誤或某類錯誤的測試數據。

7.6.1邏輯覆蓋

語句覆蓋

判定覆蓋

條件覆蓋

判定/條件覆蓋

條件組合覆蓋

點覆蓋

邊覆蓋

路徑覆蓋

7.6.2控制結構測試

基本路徑測試

條件測試

循環測試

7.7黑盒測試

黑盒測試力圖發現下述類型的錯誤：

功能不正確或遺漏了功能

界面錯誤

數據從結構錯誤或外部數據倉庫訪問錯誤

性能錯誤

初始化和終止錯誤

7.7.1等價劃分

7.7.2邊界值劃分

7.7.3錯誤推測

7.8調試

調試就是把癥狀和原因聯系起來的尚未被人深入認識的智力過程。

7.8.1調試過程

調試不是測試，但是他總是發生在測試之后。

7.8.2調試途徑

蠻干法

回溯法

原因排除法：包括對分查找法、歸納法和演繹法

7.9軟件可靠性

7.9.1基本概念

可靠性：在給定的時間間隔內，按照規格說明書的規定成功運行的概率。

可用性：在給定的時間點，按照規格說明書的規定成功運行的概率。

7.9.2估算平均無故障時間的方法

MTTF

第八章 維護

開發成本的四倍，組織中60%的人手

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

8.1軟件維護的定義

軟件已經交付使用后，為了改正錯誤或滿足新需求而修改軟件的過程。

8.2軟件維護的特點

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

區別：有無完整軟件配置

結構化維護：評價文檔 → 估量、設計 → 修改設計 → 修改代碼 → 回歸測試 → 交付

8.2.2維護的代價高昂

費用高、用戶不滿、新的錯誤、開發混亂、產率下降

8.2.3維護的問題很多

缺少軟件配置、不易理解且與代碼不一致、編寫者已不在、設計時沒考慮維護、軟件維護不是一件吸引人的事

8.3軟件維護過程

維護組織、維護報告、維護的事件流、保存維護記錄、評價維護活動

8.4軟件的可維護性

維護人員理解、改正、改動或改進這個軟件的難易程度

8.4.1決定軟件可維護性的因素

可理解性、可測試性、可修改性、可移植性、可重用性

8.4.2文檔

文檔是影響軟件可維護性的決定因素

文檔分為：用戶文檔，主要描述系統功能和使用方法。
系統文檔，描述系統設計、實現和測試等。

用戶文檔至少包括：功能描述、安裝文檔、使用手冊、參考手冊、操作員指南

8.4.3可維護性復審

8.5預防性維護

實質是軟件再工程

8.6軟件再工程過程

該模型所定義的六類活動：庫存目錄分析、文檔重構、逆向工程、代碼重構、數據重構、正向工程

第九章 面向對象方法學

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

9.1面向對象方法學概述

盡可能模擬人類習慣的思維方式

9.1.1面向對象方法學的要點

四個要點：

對象：作為由數據及可以施加在這些數據上的操作所構成的統一體。

類：對具有相同數據和相同操作的一組相似對象的定義。

繼承：下層的派生類自動具有和上層的基類相同的特性。

消息：對象彼此之間僅能通過傳遞消息相互聯系。

9.1.2面向對象方法的優點

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

穩定性好

可重用性好

較易開發大型軟件產品

可維護性好

9.2面向對象的概念

9.2.1對象

對象是對問題域中某個實體的抽象

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

9.2.2其他概念

類

就是對具有相同數據和相同操作的一組對象的定義

對相同屬性和行為的一個或多個對象的描述

實例

一個具體的對象

就是類的實際例子

消息

要求某個對象執行在定義它的那個類中所定義的某個操作的規格說明

方法

對象所能執行的操作，也就是類中所定義的服務

屬性

類中所定義的數據，它是對客觀世界實體所具有的性質的抽象

封裝

把數據和實現操作的代碼集中起來放在對象內部

三個條件：清晰邊界、確定的接口、受保護的內部實現

繼承

子類自動地共享基類中定義的數據和方法的機制

多態性

是指子類對象可以像父類對象那樣使用，同樣的消息既可以發送給父類對象也可以發送給子類對象

是指在父類中定義的屬性或服務被子類繼承后，可以具有不同的數據類型或表現出不同的行為

在類等級不同層次可共享一個方法名，不同層次每個類按各自需要實現這個方法

重載

有兩種重載：函數重載，同一作用域內的若干參數特征不同的函數可以使用相同的函數名字

? 運算符重載，同一個運算符可以施加于不同類型的操作數上面

9.3面向對象建模

三種基本模型：對象模型（類圖）、動態模型（狀態圖）、功能模型（用例圖）

9.4對象模型

最重要的、實質性的框架

靜態的、結構化的數據性質

9.4.1類圖的基本符號

類與類之間的靜態關系、一種靜態模型

9.4.2表示關系的符號

關聯、聚合、泛化、依賴和細化

9.5動態模型

基于事件共享而關聯起來的狀態圖

9.6功能模型

9.6.1用例圖

包含的模型元素有系統、行為者、用例及用例之間的關系

9.6.2用例建模

尋找行為者和用例是關鍵

9.7三種模型之間的關系

針對每個類建立的動態模型，描述了類實例的生命周期或運行周期。

狀態轉換驅使行為發生，這些行為在數據流圖中被映射成處理，在用例圖中被映射成用例，它們同時與類圖中的服務相對應。

功能模型中的處理對應于對象模型中的類所提供的服務。

數據流圖中的數據存儲，以及數據的源點/終點，通常是對象模型中的對象。

數據流圖中的數據流，往往是對象模型中對象的屬性值，也可能是整個對象。

用例圖中的行為者，可能是對象模型中的對象。

功能模型中的處理可能產生動態模型中的事件。

對象模型描述了數據流圖中的數據流、數據存儲以及數據源點/終點的結構。

第十章 面向對象分析

面向對象分析：不可能是順序線性的、需求陳述不是一成不變的

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

抽取和整理用戶需求并建立精準問題域精確模型的過程

10.1.1概述

尋找類與對象、確認結構、確認主題、確認屬性、建立動態模型、建立功能模型、確認服務

10.1.2三個子模型與五個層次

子模型：對象模型、動態模型、功能模型

五個層次：主題層、類與對象層、結構層、屬性層、服務層

10.2需求陳述

10.2.1書寫要點

需求陳述的內容包括問題范圍、功能需求、應用環境及假設條件等

10.2.2例子

10.3建立對象模型

OOA的首要工作

對象模型對細節依賴少，容易確定；需求變化時，更穩定。

10.3.1確定類與對象

對象是對問題域中有意義的事物的抽象，它們既可能是物理實體，也可能是抽象概念。

10.3.2確定關聯

兩個或多個對象之間的相互依賴、相互作用的關系就是關聯

10.3.3劃分主題

為了降低復雜程度，人們習慣于把系統再進一步劃分成幾個不同的主題，也就是在概念上把系統包含的內容分解成若干個范疇。

10.3.4確定屬性

屬性是對象的性質，屬性使人們能對類與對象和結構有更深入更具體的認識。

分析階段不需要屬性來表示對象之間的關系，使用關聯能表示任何對象之間的關系，且清晰、醒目。

10.3.5識別繼承關系

可以使用兩種方法建立繼承關系：自底向上、自頂向下

10.3.6反復修改

軟件開發過程就是一次多次反復修改、逐步完善的過程。

10.4建立動態模型

在開發交互式系統時，建立正確的動態模型是至關重要的。

10.4.1編寫腳本

腳本是指系統在某一執行期間內出現的一系列事件。

編寫腳本的目的，是保證不遺漏重要的交互步驟，它有助于確保整個交互過程的正確性和清晰性。

10.4.2設想用戶界面

大多交互行為都可以分為應用邏輯和用戶界面兩部分

應用邏輯是內在的、本質的內容，用戶界面是外在的表現形式。

10.4.3畫事件跟蹤圖

確定事件

畫出事件跟蹤圖

腳本中容易找出正常事件，但不要遺漏了異常事件和出錯條件。

10.4.4畫狀態圖

10.4.5審查動態模型

10.5建立功能模型

功能模型表明了系統中數據之間的依賴關系，以及有關的數據處理功能。

10.5.1畫出基本系統模型圖

10.5.2畫出功能級數據流圖

10.5.3描述處理框功能

10.6定義服務

常規行為

從事件導出的操作

與數據流圖中處理框對應的操作

利用繼承減少冗余操作

第十一章 面向對象設計

把需求分析階段得到的需求轉變成符合質量和成本要求的、抽象的系統實現方案的過程

11.1面向對象設計的準則

除了第五章講述的幾條基本原理，還應增加模塊化、抽象、信息隱蔽、弱耦合、強內聚、可重用。

11.2啟發規則

設計結果應該清晰易懂

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

設計簡單的類

使用簡單的協議

使用簡單的服務

把設計變動減至最小

11.3軟件重用

11.3.1概述

重用：知識重用、方法和標準的重用、軟件成分的重用

軟件成分的重用級別：代碼重用、設計結果重用、分析結果重用

典型的可重用軟件成分：項目計劃、成本估計、體系結構、需求模型和規格說明、設計、源代碼、用戶文檔和技術文檔、用戶界面、數據、測試用例

11.3.2類構件

可重用軟構件應具備的特點：模塊獨立性強、具有高度可塑性、接口清晰簡明可靠

類構件的重用方式：實例重用、繼承重用、多態重用

11.3.3軟件重用的效益

質量、生產率、成本

11.4系統分解

子系統之間的兩種交互方式

組織系統的兩種方案

設計系統的拓撲結構

11.5設計問題域子系統

調整需求：①用戶需求或外部環境發生了變化；②分析員對問題域理解不夠透徹或缺乏領域專家幫助

重用已有的類

把問題域類組合在一起：引入根類而吧問題域類組合在一起

增添一般化類一建立協議

調整繼承層次：使用多重繼承機制、使用單繼承機制

ATM系統實例

11.6設計人機交互子系統

分類用戶、描述用戶、設計命令層次、設計人機交互類

11.7設計任務管理子系統

分析并發性、設計任務管理子系統

11.8設計數據管理子系統

11.8.1選擇數據存儲管理模式

文件管理系統、關系數據庫管理系統、面向對象數據庫管理系統

11.8.2設計數據管理子系統

11.8.3例子

11.9設計類中的服務

11.9.1確定類中應有的服務

11.9.2設計實現服務的方法

設計實現服務的算法、選擇數據結構、算法與數據結構的關系、定義內部類和內部操作

11.10設計關聯

關聯的遍歷、實現單向關聯、實現雙向關聯、關聯對象的實現

11.11設計優化

11.11.1確定優先級

11.11.2提高效率的幾項技術

增加冗余關聯以提高訪問的效率

調整查詢次序

保留派生屬性

11.11.3調整繼承關系

抽象與具體

為提高繼承程度而修改類定義

利用委托實現行為共享

第十二章 面向對象實現

面向對象實現主要包括兩項工作：①把面向對象設計結果翻譯成用某種程序語言書寫的面向對象程序②測試并調試面向對象的程序

12.1程序設計語言

12.1.1面向對象語言的優點

一致的表示方法；可重用性；可維護性

12.1.2面向對象語言的技術特點

支持類與對象概念的機制

實現整體-部分（即聚集）結構的機制

實現一般-特殊（即泛化）結構的機制

實現屬性和服務的機制

類型檢查

類庫

效率

持久保存對象

參數化類

開發環境

12.1.3選擇面向對象語言

將來能否占主導地位

可重用性

類庫和開發環境

其他因素

12.2程序設計風格

12.2.1提高可重用性

提高方法的內聚

減小方法的規模

保持方法的一致性

把策略與實現分開

全面覆蓋

盡量不使用全局信息

利用繼承機制

12.2.2提高可擴充性

封裝實現策略

不要用一個方法遍歷多條關鍵鏈

避免使用多分支語句

精心確定公有方法

12.2.3提高健壯性

預防用戶的操作錯誤

檢查參數的合法性

不要預先確定限制條件

先測試后優化

12.3測試策略

測試軟件的經典策略是，從“小型測試”開始，逐步過渡到“大型測試”。

12.3.1面向對象的單元測試

不能再鼓勵地測試單個操作，而應該吧操作作為類的一部分來測試

12.3.2面向對象的集成測試

相較于結構化測試，難度增加

兩種不同的策略：①基于線程的測試 ②基于使用的測試

12.3.3面向對象的確認測試

可以用傳統的黑盒測試方法也可用于設計確認測試用例，但主要還是根據動態模型和描述系統行為的腳本來設計確認測試用例。

12.4設計測試用例

12.4.1測試類的方法

隨機測試

劃分測試

基于故障的測試

12.4.2集成測試方法

多類測試

從動態模型導出測試用例

第十三章 軟件項目管理

先于任何技術開始之前并貫穿于整個生命周期

13.1估算軟件規模

13.1.1代碼行技術

優點：容易計算

缺點：①源代碼僅是軟件配置的一部分②不同語言書寫同一程序所需代碼不同③不適用于非過程語言

13.1.2功能點技術

克服了代碼行的缺點

13.2工作量估算

13.2.1靜態單變量模型

13.2.2動態多變量模型

13.2.3COCOMO2模型

13.3進度計劃

13.3.1估算開發模型

Walston_Felix、COCOMO、COCOMO2、PUTNAM（動態多變量）

13.3.2Gantt圖

歷史悠久、應用廣泛

缺點：
①不能顯示地描繪各項作業彼此間的依賴關系
②進度計劃的關鍵部分不明確
③計劃中有潛力的部分及潛力的大小不明確

13.3.3工程網絡

13.3.4估算工程進度

13.3.5關鍵路徑

13.3.6機動時間

13.4人員組織

13.4.1民主制程序員組

小組成員完全平等，享有充分民主，通過協商作出技術決策

13.4.2主程序員組

主程序員既有技術又有行政管理能力

13.4.3現代程序員組

兩種程序員組的綜合

13.5質量保證

13.5.1軟件質量

軟件質量就是“軟件與明確地和隱含地定義的需求相一致的程度”

13.5.2軟件質量保證

為保證產品和服務充分滿足消費者要求的質量而進行的有計劃、有組織的活動

13.6軟件配置管理

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

這組活動用來：①表示變化②控制變化③確保適當地實現了變化④想需要知道這類信息的人報告變化

13.6.1軟件配置

軟件配置項：①計算機程序②描述計算機程序的文檔③數據

基數

各開發階段末尾的特定點

已經通過正式復審的規格說明或中間產品，它可以作為進一步開發的基礎，并且只有通過正式的變化控制工程才能改變他。

13.6.2軟件配置管理過程

軟件配置管理主要有五項任務：標識、版本控制、變化控制、配置審計和報告

13.7能力成熟度模型

初始級、可重復級、已定義級、已管理級、優化級

總結

以上是生活随笔為你收集整理的软件工程的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。