DFD:海南專升本-軟件工程復習資料

Billions項目組軟件工程

奧賽資料：

軟件工程：

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

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

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

3）軟件經常變化

4）開發軟件的效率非常重要

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

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

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

軟件工程的基本原理

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

2）堅持進行階段評審

3）實行嚴格的產品控制

4）采用現代程序設計技術

5）結果應能清楚地審查

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

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

軟件工程方法學

在軟件生命周期全過程中使用的一整套技術方法的集合稱為方法學。

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

1）傳統方法學

2）面向對象方法學

軟件生命周期：定義、開發、維護

問題定義

可行性研究

需求分析

總體設計

詳細設計

編碼和單元測試

綜合測試

軟件維護

軟件過程：為了獲得高質量軟件所需要完成的一系列任務的框架，它規定了完成各項任務的工作步驟。通常使用生命周期模型簡潔的描述軟件過程。

瀑布模型

1）各個階段的順序性和依賴性；

2）劃分邏輯設計與物理設計，盡可能推遲程序的物理實現；

3）每個階段必須完成規定的文檔，對其中問題通過復審及早發現，及早解決。

快速還原模型

增量模型

1）從部分需求出發，先建立一個不完全的系統，通過測試運行該系統取得經驗和信息反饋，加深對軟件需求的理解，進一步使系統擴充和完善。如此反復,直至軟件人員和用戶對所設計完成的軟件系統滿意為止。

2）在漸增型開發下的軟件是隨軟件開發的過程而逐漸形成的。

3）漸增型開發方法適合于知識型軟件的開發，設計系統時對用戶需求的認識開始不是很清楚的，需要在開發過程中不斷認識、不斷獲得新的知識去豐富和完善系統。多數研究性質的試驗軟件，一般采用此方法。

(4)螺旋模型

(5)噴泉模型

(6)Rational統一過程

(7)敏捷過程與極限編程

(8)微軟過程

噴泉模型

Rational統一過程

敏捷過程與極限編程

微軟過程

可行性研究

可行性研究的目的，就是用最小的代價在盡可能短的時間內確定問題是否能夠解決。

問題定義的任務：將用戶提出的要求具體化、定量化；確定研制系統的范圍，明確研制的邊界。

問題定義階段的工作：

1）通過調查研究，了解系統需求；

2）確定系統的功能需求、性能需求、可靠性需求、安全及保密性、資源、開發費用及開發

進度等的需求；

3）問題定義階段的產品-系統目標與范圍說明書。

1.可行性研究的任務

技術可行性

經濟可行性

操作可行性

2.可行性研究的過程

復查系統規模和目標

研究目前正在使用的系統

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

進一步定義問題

導出和評價供選擇的解法

推薦行動方針

草擬開發計劃

書寫文檔提交審查

3.系統流程圖

系統流程圖是描述物理系統的傳統工具。它的基本思想是用圖形符號以黑盒子形式描繪系統里的每個部件。系統流程圖表達的是部件的信息流程，而不表示對信息進行加工處理的控制過程。

4.數據流圖

DFD是一種圖形化技術，它描繪信息流和數據從輸入移動到輸出的過程中所經受的變換。與程序流程圖不同，DFD不表示程序的控制結構，只描述數據的流動DFD分成多層表示，從而逐步展開數據流和功能的細節。

繪制數據流圖步驟

確定所開發的系統的外部項，即系統的數據來源和去處。

確定整個系統的輸出數據流和輸入數據流，把系統作為一個加工環節，畫出關聯圖。

確定系統的主要信息處理功能，按此將整個系統分解成幾個加工環節確定每個加工的輸出與輸入數據流以及與這些加工有關的數據存儲。

根據自頂向下，逐層分解的原則，對上層圖中全部或部分加工環節進行分解。

重復步驟,直到逐層分解結束。

對圖進行檢查和合理布局，主要檢查分解是否恰當、徹底，DFD中各層是否有遺漏、重夏、沖突之處，各層DFD及同層DFD之間關系是否爭取及命名、編號是否確切、合理等，對錯誤與不當之處進行修改。

和用戶進行交流，在用戶完全理解數據圖的內容的基礎上征求用戶的意見。

注意事項：

不要把控制流作為數據流

不要標出激發條件

數據流必須要么從某個加工流出、要么流入某個加工，而不能直接從外部項流向數據存儲等等。

5.數據字典

數據字典是關于數據的信息的集合，也就是對數據流圖中包含的所有元素的定義的集合。

數據字典的內容

數據流、數據流分量、數據存儲、處理

數據字典要對數據流圖中出現的所有名字進行定義。數據字典的條目由三大類組成，分別是：數據流條目、數據項條目、文件條目、加工條目。

定義數據的方法

+：和，連接兩個分量=：等價于：或，用|隔開分量｛｝：重復花括號內的分量。｛字母或數字｝7表示8位字符串O：可選，即可有可無

數據字典的用途

數據字典的實現

6.成本/效益分析

成本估計

1）代碼行技術

2）任務分解技術

3）自動估計成本技術

成本/效益分析方法

1）貨幣時間價值F=Pn次方

2）投資回收期

3）純收入

4）投資回收率

海南安邁云CEO吳文杰：AI時代去中心化計算和存儲成為必須:金色財經現場報道，2020 Cointelegraph中文大灣區·國際區塊鏈周8月7日在深圳舉行。海南安邁云網絡技術有限公司CEO吳文杰在會上表示，AI時代，人均算力水平將達到10000-29000 GLOPS，數據容量每年翻1倍。到2022年，70%的數據將不會存在中心化的數據中心。在AI時代，算力成為能源，存儲成為土壤，隨著算力需求越來越多，存儲容量越來越不夠，去中心化計算和存儲成為必須，也將成為人類AI新文明基石。[2020/8/7]

需求分析

1）需求分析目的：

可行性分析研究階段已經粗略的描述了用戶的需求，甚至還提出了一些可行的方案，但是，許多細節被忽略了，在最終目標系統中是不能忽略、遺漏任何一個微小細節的，所以,可行性研究不能代替需求分析。需求分析的任務還不是確定系統怎樣完成它的工作,而僅僅是確定系統必須完成哪些工作，也就是對目標提出完整、準確、清晰、具體的要求。

通過需求分析，明確用戶對目標軟件系統在功能、性能、行為、設計約束等方面的期望，回答軟件系統“必須做什么”。

開發人員準確的理解用戶的要求，進行細致的調查分析，講用戶形式的需求陳述轉化為完整的需求定義，再由需求定義轉換到相應的需求規格說明的過程。

2）需求分析的方法：

需求分析方法由對軟件的數據域和功能域的系統分析過程及其表示方法組成，它定義了表示系統邏輯視圖和物理視圖的方式，大多數的需求分析方法是由數據驅動的，也就是說,這些方法提供了一種表示數據域的機制，分析員根據這種表示，確定軟件功能及其特性，最終建立一個待開發軟件的抽象模型，即目標系統的邏輯模型。

2.需求分析的任務

問題識別、分析與綜合導出軟件邏輯模型、編寫文檔它的基本任務是準確地回答“系統必須做什么？”這個問題。需求分析所要做的工作是深入描述軟件的共能和性能，確定軟件設計的限制和軟件同其它系統元素的接II細節，定義軟件的其它有效性需求。需求分析的任務不是確定系統如何完成它的工作，而是確定系統必須完成哪些工作，也就是對目標系統提出完整、準確、清晰、具體的要求。其實現步驟如下

圖所示：

⑴確定對系統的綜合要求

系統功能需求

系統性能需求

可靠性和可用性需求、

錯處理需求

接口需求、

約束

逆向需求

將來可能提出的需求

(2)分析系統的數據需求

就是在理解當前系統“怎樣做”的基礎上，抽取其“做什么”的本質，明確目標系統要“做什么”，可以導出系統的詳細的邏輯模型。具體做法：首先確定目標系統與當前系統的邏輯差別；然后將變化部分看作是新的處理步驟，對功能圖(一般為數據流圖)及對象圖進行調整；最后有外及里對變化的部分進行分析，推斷其結構，獲得目標系統的邏輯模型。

通常用數據流圖、數字字典和主要的處理算法描述這個邏輯模型。

分析系統的數據要求通常采用建立數據模型的方法,常常利用圖形工具輔助描繪數據結

構。

⑶導出系統的邏輯模型

⑷修正系統開發計劃

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

(1)訪談

正式和非正式訪談、發調查表、情景分析

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

結構化分析:使用數據流程圖、數據字典、結構化英語、判定表和判定樹等工具，來建立一種新的、稱為結構化說明書的目標文檔-需求規格說明書。結構化分析法就是面向數據流自頂向下逐步求精進行需求分析的方法，把數據流和數據存儲定義到元素級

(3)簡易的應用規格說明技術

(4)快速建立軟件原型

4.分析建模與規格說明

(1)分析建模

數據模型(ER圖)、功能模型(數據流圖，描繪當數據在軟件系統中移動時被變換的邏輯過程，指明系統具有的變換數據的功能)、行為模型(狀態圖，指明了作為外部事件結果的系統行為)

(2)軟件需求規格說明書

為了消除用自然語言書寫的軟件需求規格說明書中可能存在的不一致、歧義、含糊、不完整及抽象層次混亂等問題，用形式化方法描述用戶對軟件系統的需求。

5.實體一聯系圖(數據對象及數據對象之間的關系)

(1)數據對象

一系列不同性質或屬性的事務

(2)屬性

數據對象的性質

(3)聯系

數據對象彼此之間相互連接的方式稱為聯系，也稱為關系

6.數據規范化

為了減少數據冗余，避免出現插入或刪除異常，簡化修改數據的過程，通常需要把數據結構規范化。

第一范式

第二范式

第三范式

7.狀態轉換圖

通過描繪系統的狀態及引起系統狀態轉換的事件，來表示系統的行為。狀態圖還指明了作為特定事件的結果系統將做哪些動作。

狀態

事件

符號

8.其他圖

層次方框圖:用樹形結構的一系列多層次的矩形描繪數據的層次結構。

wanrnier圖IPO圖：輸入、處理、輸出圖的簡稱。

9.軟件需求的驗證：

需求分析階段的工作結果是開發軟件系統的重要基礎，大量統計數字表明，軟件系統中15%的錯誤起源于錯誤的需求。為了提高軟件質量，確保軟件開發成功，降低軟件開發成本,一旦對目標系統提出一組要求之后，必須嚴格驗證這些需求的正確性。

應該從下述4個方面進行驗證：

1）一致性所有需求必須是一致的，任何一條需求不能和其他需求互相矛盾。

2）完整性需求必須是完整的，規格說明書應該包括用戶需要的每一個功能或性能。

3）現實性指定的需求應該是用現有的硬件技術和軟件技術基本上可以實現的。對硬件技術的進步可以做些預測，對軟件技術的進步則很難做出預測，只能從現有技術水平出發判斷需求的現實性。

4）有效性必須證明需求是正確有效的，確實能解決用戶面對的問題。

驗證軟件需求的方法

用于需求分析的軟件工具RSLPSL/PSA

形式化說明技術

用自然語言描述需求規格說明，是典型的非形式化方法。用數據流圖或實體-聯系圖建立模型，是典型的半形式化方法。所謂形式化方法，是描述系統性質的基于數學的技術，也就是說，如果一種方法有堅實的數學基礎，那么它就是形式化的。

1.概述

非形式化方法的缺點：用自然語言書寫的系統規格說明書，可能存在矛盾、二義性、含糊性、不完整性及抽象層次混亂等問題。

形式化方法的優點

應用形式化方法的準則

2.有窮狀態機

當前狀態+事件+謂詞一下個狀態

3.Petri網4.Z語言

形式化的規格說明可以用數學方法研究、驗證。此外，形式化的規格說明消除了二義性，而且它鼓勵軟件開發者在軟件工程過程的早期階段使用更嚴格的方法，從而可以減少差錯。

當然，形式化方法也有缺點：大多數形式化的規格說明主要關注于系統的功能和數據，而問題的時序、控制和行為等方面的需求卻更難于表示。此外，形式化方法比欠形式化方法更難學習，不僅在培訓階段要花大量的投資，而且對某些軟件工程師來說，它代表了一種“文化沖擊”。

朱綿茂：海南應通過數字加密和區塊鏈等引入監管沙盒模式:海南政法學院副院長朱綿茂認為，《海南自由貿易港建設總體方案》在金融風險防控和制度建設方面進行了部署，海南必須借鑒國際金融監管經驗，建立容錯機制，在努力營造寬松有序的經商環境同時，堅守金融風險底線，通過數字加密、區塊鏈等模式，引入監管沙盒模式。（國際旅游島商報）[2020/6/24]

總體設計

總體設計的基本目的就是回答“概括地說，系統應該如何實現？”這個問題，因此，總體設計又稱為概要設計或初步設計。

總體設計過程兩個主要階段：

系統設計階段，確定系統的具體實現方案

結構設計階段，確定軟件結構

1.設計過程

設想供選擇的方案

選取合理的方案

推薦最佳方案

功能分解

設計軟件結構

設計數據庫

制定測試計劃

書寫文檔：系統說明、用戶手冊、測試計劃、詳細的實現計劃、數據庫設計結果；

審查和復審

2.設計原理

模塊化

就是把程序劃分成獨立命名且可獨立訪問的模塊,每個模塊完成一個子功能,把這些模塊集成起來構成一個整體，可以完成指定的功能滿足用戶的需求.把復雜的問題分解成許多容易解決的小問題，原來的問題也就容易解決了.模塊化和軟件成本關系:根據總成本曲線，每個程序都相應地有一個最適當的模塊數目M,,使得系統的開發成本最小.

抽象

抽出事務的本質特性而暫時不考慮它們的細節.

逐步求精

信息隱藏和局部化

模塊中所包括的信息不允許其它不需這些信息的模塊調用信息局部化：是把一些關系密切的軟件元素物理地放得彼此靠近

模塊獨立

是軟件系統中每個模塊只涉及軟件要求的具體子功能,而和軟件系統中的其它的模塊接口是簡單的。模塊獨立的概念是模塊化、抽象、信息陷蔽和局部化概念的直接結果。

1）耦合

也稱塊間聯系。指軟件系統結構中各模塊間相互聯系緊密程度的一種度量。模塊之間聯系越緊密，其耦合性就越強，模塊的獨立性則越差。模塊間耦合高低取決于模塊間接口的狂雜性、調用的方式及傳遞的信息。

數據耦合：如果兩個模塊彼此間通過參數交換信息，而且交換的信息僅僅是數據。

控制耦合：模塊傳遞的信息中有控制信息，就稱作控制耦合。

特征耦合:把整個數據結構作為參數傳遞而被調用的模塊只要使用其中一部分數據元素。

公共耦合：一組模塊通過同一個公共數據環境相互作用，則它們之間的耦合稱為公共耦合。

內容耦合：如果發生下列情形之一，兩個模塊之間就發生了內容耦合。一個模塊直接訪問另一個模塊的內部數據一個模塊不能通過正常入口轉到另一模塊的內部兩個模塊有一部分程序代碼重疊一個模塊有多個入口

2）內聚

又稱塊內聯系。指模塊的功能強度的度量，即一個模塊內部各個元素彼此結合的緊密程度的度量。若一個模塊內各元素聯系得越緊密，則它的內聚性就越高。

偶然內聚：如果一個模塊各部分之間沒有關系，或者即使有關系，這種關系也是很松散的，則稱作偶然內聚。

時間內聚：如果一個模塊所包含的任務必須在同一時間內執行，稱作時間內聚。

邏輯內聚:一個模塊完成的任務在邏輯上屬于相同或相似的一類

過程內聚：如果一個模塊內的處理是相關的，而且必須以特定次序執行，則稱為過程內聚。

通信內聚：如果一個模塊中的所有元素都使用了相同的輸入數據，或產生了相同的輸出數據，則稱為通信內聚。

順序內聚：如果一個模塊內的處理元素和同一個功能密切相關，而且這些處理必須順序執行，則稱為順序內聚。

功能內聚：如果一個模塊內所有處理元素屬于一個整體，完成一個單一的功能，則稱作功能內聚。

耦合性與內聚性是模塊獨立性的兩個定性標準，將軟件系統劃分模塊時，盡量做到高內聚低耦合，提高模塊的獨立性，為設計高質量的軟件結構奠定基礎。模塊的高內聚、低耦合的原則稱為模塊獨立原則，也稱為模塊設計的原則。

3.啟發規則

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

模塊規模應該適中

深度、寬度、扇出、和扇入都應適當深度表示軟件結構中控制的層數，它往往能粗略地標志一個系統的大小和復:雜程度。寬度是軟件結構內同一個層次上的模塊總數的最大值；一般來說，寬度越大系統越復雜。

寬度影響最大的因素是模塊的扇出。

一個模塊的扇入是指直接調用該模塊的上級模塊的個數。

一個模塊的扇出是指該模塊直接調用的下級模塊的個數。

設計原則：低扇出、高扇入。

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

模塊的作用域定義為受該模塊內一個判定影響的所有模塊的集合。模塊的控制域是這個模塊本身以及所有直接或間接從屬于它的模塊的集

合。

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

設計單入口和單出口的模塊

模塊功能應該可以預測

4.描繪軟件結構的圖形工具

層次圖和HIPO層次圖是用來描述軟件的層次結構的。

圖結構

結構圖和層次圖類似，都是描述軟件結構的圖形工具產生最佳解

5.面向數據流的設計方法

面向數據流的設計方法把信息流映射成軟件結構，信息流的類型決定了映射的方法。面向數據流的設計要解決的任務，就是上述需求分析的基礎上，將DFD圖映射為軟件系統的結構。

概念

變換流

事務流

數據流圖的類型：交換型結構和事務型結構

交換型結構：由3部分組成，傳入路徑，變換中心，輸出路徑。系統的傳入流經過變換中心的處理，變換為系統的傳出流。

事務型結構：有至少一條接受路徑，一個事務中心與若干條動作路徑組成。當外部信息沿著接受路徑進入系統后，經過事務中心獲得某個特定值，就能據此啟動某一條動作路徑的操作。

變換分析

變換分析是一系列設計步驟的總稱，經過這些步驟把具有變換流特點的數據流圖按預先確定的模式映射成軟件結構。

事務分析

設計優化

詳細設計

詳細設計階段的根本目標是確定應該怎樣具體地實現所要求的系統，也就是說，經過這個階段的設計工作，應該得出對目標系統的精確描述，從而在編碼階段可以把這個描述直接翻譯成用某種程序設計語言書寫的程序。

1.結構程序設計

2.人機界面設計

設計問題

系統響應時間

用戶幫助設施

出錯信息處理

命令交互

設計過程

人機界面設計指南

一般交互指南

信息顯示指南

數據輸入指南

3.過程設計的工具

程序流程圖

盒圖

PAD圖

火幣李林：五年內海南區塊鏈技術發展會有一個爆發期:火幣集團創始人、董事長兼CEO李林表示，《海南自由貿易港建設總體方案》提及區塊鏈的地方一共有六處，明確定位為信息產業的一部分，所涉領域包括知識產權交易、存證、社會治理、區塊鏈產業基地、區塊鏈金融等方面，這說明區塊鏈技術已經被視為海南自貿港發展的重要基礎技術之一。《方案》中關于2025年前的重點任務部分，提到要建設海南國家區塊鏈技術和產業創新發展基地。從這一目標可以預見，五年內海南的區塊鏈技術發展會有一個爆發期，這也給了區塊鏈技術從業者很多契機。（第一財經）[2020/6/3]

判定表

判定樹

過程設計語言

它是正文形式表示數據和處理過程的設計工具

4.面向數據結構的設計方法

Jackson圖改進的Jackson圖Jackson方法Jackson方法是最著名的面向數據結構的設計方法,而不是面向數據流的設計方法。它是以信息驅動的，是將信息轉換成軟件的程序結構

Jackson方法的基本步驟是：

1）分析并確定輸入數據和輸出數據的邏輯結果，并用Jackson圖描繪這些數據結構.

2）找出輸入數據結構和輸出數據結構中有對應關系的數據單元。

3）從描繪數據結構的Jackson圖導出描繪程序結構的Jackson圖

4）列出所有操作和條件，并且把他們分配到程序結構圖的適當位置

5）用偽代碼表示程序

5.程序復雜程度的定量度量

(1)McCabe方法

根據程序控制流的復雜程度定量度量程序的復雜程度，稱為程序的環形史:復雜程度。程序的環形復雜度取決于程序控制流的復:復雜程度，即取決于程序結構的復雜難度。

(2)Halstead方法根據程序中運算符和操作數的總數來度量程序的復雜程度。

實現

通常把編碼和測試統稱為實現

1.編碼

選擇程序設計語言

編碼風格

1）程序內部文檔：符號名的命名、程序的注釋、標準的書寫格式

2）數據說明：數據說明的次序應當規范化。使數據屬性容易查找，也有利于測試，排錯和維護

3）語句構造：語句結構力求簡單、直接，不能為了片面追求效率而使語句復雜化，可以從以下幾點注意：使用標準的控制結構、盡可能使用庫函數、程序編寫首先應該考慮清晰性、注意使用got。語句

4）輸入輸出：輸入/輸出地方式和格式應當盡可能做到對用戶友善，盡可能方便用戶的使用。

5）效率：程序效率：程序效率是指程序的執行速度及程序占用的存儲空間。影響程序效率的因素是多方面的。

2.軟件測試基礎

軟件測試的目標：為了發現程序中的錯誤而執行程序的過程

軟件測試的準則

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

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

3）把Pareto原理應用到軟件測試中4）應該從“小規模”測試開始，并逐步進行“大規模”測試

5）窮舉測試是不可能的。

6）為了達到最佳的測試效果，應該由獨立的第三方從事測試工作。

測試方法

1）黑盒測試：把程序看成一個黑盒子，完全不考慮程序內部結構和處理過程，黑盒測試是在程序接口進行的測試，它只檢查程序功能能否按照規格說明書的規定正常使用，程序能否適當地接收輸入數據并產生正確的輸出信息。

2）白盒測試：結構測試，把程序看成裝在一個透明的白盒子里，測試者完全知道程序的結構和處理算法。

測試步驟

1）單元測試：保證每個模塊正常運行，發現編碼和詳細設計的錯誤。

2）子系統測試：把經過單元測試的模塊放在一起形成一個子系統測試。

3）系統測試：經過測試的子系統裝配成一個完整的系統來測試。

4）驗收測試：驗證系統能否滿足用戶需要。

5）平行運行：運行新舊系統，相比較。

測試階段的信息流

3.單元測試

主要使用白盒測試技術，集中檢測軟件設計的最小單元模塊。

測試重點

1）模塊接口

2）局部數據結構

3）重要執行通路

4）出錯處理通路

5）邊界條件

代碼審查

計算機測試

驅動程序：接收測試數據，把這些數據傳送給被測試的模塊，并且印出有關結果。存根程序：代替被測試的模塊所調用的模塊，也可稱為虛擬子程序。

4.集成測試

也稱為組裝測試，在單元測試的基礎之上，把所有的模塊組裝成一個系統進行測試。主要測試設計階段產生的錯誤，集成測試計劃應該在概要設計階段制定。

非漸增式測試方法：先分別測試每個模塊，再把所有模塊按設計要求放在一起結

合所要的程序。

漸增式測試：把下一個要測試的模塊同已經測試好的那些模塊結合起來進行測試,測試完以后再把下一個應該測試的模塊結合進來測試。

比較：

非漸增式測試方法把單元測試和集成測試分成兩個不同的階段，前一階段完成模塊的單元測試，后一階段完成集成測試。而漸增式測試往往把單元測試與集成測試和在一起，同時完成。

非漸增式需要更多的工作量，因為每個模塊都需要驅動模塊和樁模塊，而漸增式利用已測試過的模塊作為驅動模塊或樁模塊，因此工作量較少。

漸增式可以較早的發現接口之間的錯誤，非漸增式最后組裝是才發現。

漸增式有利于排錯，發生錯誤往往和最近加進來的模塊有關，而非漸增式發現接口錯誤推遲到最后，很難判斷是哪一部分接口出錯。

漸增式比較徹底，已測試的模塊和新的模塊再測試。

內漸增式占用的時間較多，但非漸增式須更多的驅動模塊、樁模塊也占用一些時間。（心非漸增式開始可并行測試所有模塊，能充分利用人力，對測試大型軟件很有意義。

自頂向下集成:從主控制模塊開始，沿著程序的控制層次向下移動，逐漸把各個模塊結合起來。

自底向上集成：從原子模塊即在軟件結構最底層的模塊開始組裝和測試。

不同集成測試策略的比較

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

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

混合策略：改進的自頂向下測試方法、混合法

回歸測試：集成測試中當每一個新模塊結合進來時，程序就發生了變化，所謂回歸測試是指重新執行已經做過的測試的某個子集。

5.確認測試：也稱為驗收測試，目標是嚴重軟件的有效性

驗證：保證軟件正確實現了某個特定要求的一系列活動

確認：為了保證軟件確實滿足了用戶需求

有效性：如果軟件的功能和性能如圖用戶所合理期待的那樣，軟件就是有效的

確認測試的范圍

軟件配置復查

Alpha測試：用戶在開發者場所進行，并在開發者對用戶指導下進行測試。Beta測試：軟件的最終用戶們在一個或多個客戶場所進行。

6.白盒測試技術

白盒測試時將程序看作是一個透明的盒子，也就是說測試人員完全了解程序的內部結構和處理過程。所以測試時按照程序內部的邏輯測試程序、檢驗程序中的每條通路是否都能按預定的要求正確工作。白盒測試又稱為結構測試。

聲音 | 海南省委宣傳部文改辦主任：海南自貿區(港)區塊鏈試驗區將致力于區塊鏈前沿技術研發:據人民網消息，2018人民網區塊鏈技術冬季論壇在海南生態軟件園召開。海南省委宣傳部文改辦主任譚敏表示，當前區塊鏈擁有分布式計算、點對點傳輸、不可篡改等特點，價值互聯網正在醞釀一場新的革命，作為國內正式授牌的首個區塊鏈試驗區，海南自貿區(港)區塊鏈試驗區將致力于區塊鏈前沿技術研發、人才培養制度創新和場景應用構建，打造完善的區塊鏈產業生態圈，打造千億級產業集群。

海南是區塊鏈得天獨厚的自然、人文政策環境，中央明確將海南全面深化改革上升到國家戰略，支持海南大膽試大膽闖，自主改，推動產業創新和制度創新；要求海南深化供給側結構性改革，統籌實施網絡強國戰略，大數據戰略，互聯網 行動，大力推進新一代信息技術產業發展，推動互聯網、大數據、衛星導航、人工智能、實體經濟深度融合，這為區塊鏈產業發展提供了千載難逢的發展機遇。

區塊鏈是新生事物，要包容地去培育，研討、交流、學習是重要手段。通過具有前瞻性、理論性、實驗性的探討和交流，相信大家會對區塊鏈有一個全新的認識。[2018/12/22]

白盒測試多用于單元測試階段。邏輯覆蓋是主要的白盒測試技術。白盒測試時，確定測試數據應根據程序的內部邏輯和指定的覆蓋方式。

邏輯覆蓋

1）語句覆蓋：使被測程序中每個語句至少執行一次

2）判斷覆蓋：不僅每個語句至少執行一次，每個判定的每種可能結果應該至少執行一次，也就是每個判定的每個分支至少執行一次

3）條件覆蓋：不僅每個語句至少執行一次，而且使判定表達式中的每個條件都取到各種可能結果。

4）判斷/條件覆蓋：使判定表達式中的每個條件都取到各種可能的值，而且每個判定表達式都能取到各種可能的結果

5）條件組合覆蓋：使每個判定表達式中條件的各種可能組合都至少出現一次

6）點覆蓋

7）邊覆蓋

8）路徑覆蓋

控制結構測試

1）基本路徑測試

2）條件測試

3）循環測試

7.黑盒測試技術

黑盒測試時完全不考慮程序內部的結構和處理過程，只按照規格說明書的規定來檢查程序是否符合它的功能要求。黑盒測試是在程序接口進行的測試，又稱為功能測試。

等價劃分

把程序的輸入域劃分成若干個數據類，據此導出測試用例。使用等價劃分法設計測試方案首先需要劃分輸入數據的等價類，為此需要研究程序的功能說明，從而確定輸入數據的有效等價類和無效等價類。

邊界值分析

錯誤推測

8.調試

調試過程

調試途徑

1）蠻干法

2）回溯法

3）原因排除法

9.軟件可靠性

基本概念

1）軟件可靠性定義：程序在給定的時間間隔內，按照規格說明書的規定成功的運行的概率

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

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

1）符號

2）基本假定

3）估算平均無故障時間

4）估計錯誤總數的方法

維護

1.軟件維護的定義

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

改正性維護：糾正開發期間未發現的遺留錯誤，即在程序使用期間發現的程序錯誤進行診斷和改正的過程。

完善性維護：滿足用戶在使用過程中提出增加新的功能或修改已有功能，以滿足用戶日益增長的需要而進行的工作；該維護活動通常占軟件維護工作的大部分；

預防性維護：為了改善未來的可維護性或可靠性而修改軟件的工作。用于維護工作的勞動可以分成生產性活動和非生產性活動。

適應性維護：是為了和變化的環境適當地配置而進行的修改軟件的活動，是既必要又經常的維護活動。是軟件適應新的運行環境而進行的工作；

2.軟件維護的特點

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

1）非結構化維護（軟件配置唯一成分是程序代碼

2）結構化維護

維護的代價高昂

維護的問題很多

3.軟件維護過程

維護組織

維護報告

維護的事件流

保存維護記錄

評價維護活動

4.軟件的可維護性

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

決定軟件可維護性的因素

1）可理解性

2）可測試性

3）可修改性

4）可移植性

5）可重用性

文檔

1）用戶文檔

2）系統文檔

可維護性復審

5.預防性維護

6.軟件再工程過程

庫存目錄分析

文檔重構

逆向工程:分析程序以便在比源代碼更高的抽象層次上創建出程序的某種表示的過程，也就是說，逆向工程是一個恢復:設計結果的過程，逆向工程工具從現存的代碼中抽取有關數據、體系結構和處理過程的設計信息。

代碼重構

數據重構

正向工程：革新或改造，不僅從現有程序中恢復設計信息，而且使用該信息去改變或重構現有系統，以提高其整體質量。軟件的可理解性、可測試性、可修改性、可移植性和可重用性是決定軟件可維護性的基本因素。

面向對象方法學引論

1.面向對象方法學概述

面向對象方法學的要點

面向對象方法學的出發點和基本原則，是盡可能模擬人類習慣的思維方式，使開發軟件的方法與過程盡可能接近人類認識世界解決問題的方法與過程，也就是使描述問題的問題空間與實現解法的解空間在結構上盡可能一致。OO=objects+classes+inheritance+communicationwithmessages面向對象就是既使用對象又使用類和繼承等機制，而且對象之間僅能通過傳遞消

息實現彼此通信。

面向對象方法學的優點

1）與人類習慣的思維方法一致

2）穩定性好

3）可重用性好

4）較易開發大型軟件產品

5）可維護性好

1）、面向對象的軟件穩定性比較好

2）、面向對象的軟件比較容易修改

3）、面向對象的軟件比較容易理解

4）、易于測試和調試

2.面向對象的概念

對象

對象：它是封裝了數據結構及可以施加在這些數據結構上的操作的封裝體，這個封裝體有可以唯一地標識它的名字，而且向外界提供一組服務。對象的特點：以數據為中心；對象是主動的；實現了數據封裝；本質上具有并行性；模塊獨立性好

其他概念

1）類：對具有相同數據和相同操作的一組相似對象的定義，也就是說，類是對

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

2）實例：就是由某個特定的類所描述的一個具體的對象。

3）消息：消息傳遞時對象與外界相互關系的唯一途徑。對象可以向其它對象發送消息以請求服務，也可以響應其他對象傳來的消息，完成自身固有的某些操作，從而服務于其他對象。

午后滬深兩市股指繼續走強 區塊鏈、海南等板塊漲幅居前:午后，滬深兩市股指繼續走強，截止發稿，上證指數漲2.12%，報3267點，深圳成指漲2.21%，創業板指漲1.84%，上證50指數亦漲2.13%。

盤面上看，民航機場，水泥建材，有色，軟件服務，國產芯片，保險，雄安，稀土永磁，區塊鏈，海南等板塊漲幅居前。[2018/2/22]

消息就是要求某個對象執行在定義它的那個類中所定義的某個操作的規格

說明。一個消息有3部分組成：接收消息的對象；消息選擇符；零個或多個變元。

4）方法：方法就是對象所能執行的操作，也就是類中所定義的服務。方法描述了對象執行操作的算法，響應消息的方法。

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

6）封裝：封裝也就是信息隱藏，通過封裝對外界隱藏了對象的實現細節。

7）繼承：是現實世界中遺傳關系的直接模擬。可用來表示類之間的內在聯系以及對屬性和操作的共享。子類可以沿用父類的某些特征，同時子類也可以具有自己獨立的屬性和特征。

8）多態性：子類對象可以像父類對象那樣使用，同樣的消息既可以發送給父類對象也可以發送給子類對象。

9）重載：函數重載是指在同一作用域內的若干個參數特征不同的函數可以使用相同的函數名字。運算符重我是指同一個運算符可以施加于不同類型的操作數上面。

3.面向對象建模

模型，就是為了理解事物而對事物作出的一種抽象，是對事物的一種無歧義的書面描述。

描述系統數據結構的對象模型、描述系統控制結構的動態模型、描述系統功能的功能模型。通常，模型由一組圖形符號和組織這些符號的規則組成，利用它們來定義和描述問

題域中的術語和概念。更進一步地講，模型是一種思維工具，利用這種工具可以把知識規范地表示出來。

4.對象模型

對象模型表示靜態的、結構化的系統的“數據”性質，描述數據結構。它是對模擬客觀

世界實體的對象以及對象彼此間的關系的映射，描述了系統的靜態結構。

通常，使用UML提供的類圖來建立對象模型。在UML中術語“類”的實際含義是，“一個類及屬于該類的對象”。

類圖的基本符號

1）定義類

UML中類的圖形符號為長方形，用兩條橫線把長方形分成上、中、下3個區域，3個區域分別放類的名字、屬性和服務，如圖所示。

類名

展性

服務

2）定義屬性

UML描述屬性的語法格式如下：可見性屬性名：類型名=初值｛性質串｝

3）定義服務

服務也就是操作，UML描述操作的語法格式如下：

可見性操作名：返回值類型｛性質串｝

表示關系的符號

1）關聯：表示兩個類的對象之間存在某種語義上的聯系。

普通關聯：只要類與類之間存在連接關系。

關聯的角色:在任何關聯中都會涉及到參與此關聯的對象所扮演的角色，在某些情況下顯式標明角色名有助于別人理解類圖。

(c)限定關聯：限定關聯通常用在一對多或多對多的關聯關系中，可以把模型中的重數從一對多變成一對一，或從多對多簡化成多對一。在類圖中把限定詞放在關聯關系末端的一個小方框內。

(d)關聯類：為了說明關聯的性質，可能需要一些附加信息。可以引入一個關聯類來記錄這些信息。關聯類通過一條虛線與關聯連接。

2)聚集：聚集也稱為聚合，是關聯的特例。聚集表示類與類之間的關系是整體與部分的關系。

(a)共享聚集:如果在聚集關系中處于部分方的對象可同時參與多個處于整體方對象的構成。

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

3)泛化：即繼承關系，它是通用元素和具體元素之間的一種分類關系。用一端為空心三角形的連線表示泛化關系。(a)普通泛化(b)受限泛化(附加約束條件)

4)依賴和細化

(a)依賴關系：依賴關系描述兩個模型元素(類、用例等)之間的語義連接關系：其中一個模型元素是獨立的，另一個模型元素不是獨立的,它依賴于獨立的模型元素，如果獨立的模型元素改變了，將影響依賴于它的模型元素。

(b)細化關系：當對同一個事物在不同抽象層次上描述時，這些描述之間具有細化關系。

5.動態模型

6.功能模型：功能模型表示變化的系統的“功能”性質，它指明了系統應該“做什么”，因此更直接地反映了用戶對目標系統的需求。通常，功能模型由一組數據流圖組成。

(1)用例圖：一幅用例圖包含的模型元素有系統、行為者、用例及用例之間的關系。

1)系統

2)用例：系統完成的一系列動作，動作的結果能被特定的行為者察覺到。用例是一個類，它代表一類功能而不是使用該功能的某個具體實例。用例的實例是系統的一種實際使用方法，通常把用例的實例稱為腳本。腳本是系統的一次具體執行過程。

3）行為者：與系統交互的人或其他系統，代表外部實體。

4）用例之間的關系

擴展關系：向一個用例中添加一些動作后構成了另一個用例，這兩個用例之間的關系就是擴展關系，后者繼承前者的一些行為，通常把后者稱為擴展用例。

使用關系：當一個用例使用另一個用例時，這兩個用例之間就構成了使用關系。

用例建模

1）尋找行為者

2）尋找用例

7.三種模型之間的關系

在面向對象方法學中，對象模型是最基本最重要的，它為其他兩種模型奠定基礎。

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

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

3）功能模型中的處理對應于對象模型中的類所提供的服務。通常，復雜的處理對應于生雜對象提供的服務，簡單的處理對應于更基本的對象提供的服務。有時一個處理對應多個服務，也有一個服務對應多個處理。

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

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

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

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

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

總之，功能模型指明了系統應該“做什么”;動態模型明確規定了什么時候做;對象模型則定義了做事情的實體。

面向對象的分析

開發軟件，分析的過程都是系統需求提取的過程，它要求系統分析員通過與用戶及相關領域的專家交流，充分理解用戶的需求和相關領域的背景知識，最終把這種理解制作成文檔資料的過程，但由于問題的復雜性，該理解過程并不能達到理想的成程度，因此需要進一步去驗證說明規格文檔的正確性、完整性、有效性。

1、分析工作主要內容：理解、表達、驗證。

2、分析過程得出的結果就是軟件需求規格說明文檔，相對于面向對象，由對象模型、動態模型、功能模型組成。

面向對象分析的關鍵是識別出問題域內的類與對象，分析確定它們之間的關系，最終建立起問題域的對象模型、動態模型和功能模型。

1.面向對象分析的基本過程

概述

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

基本過程流程：

1）從分析陳述用戶需求的文件開始。

2）需求陳述通常是不完整、不準確的、還是非正式的。因此，需求陳述不是一成不變，應通過分析，補充和改正其內容。

3）系統人員深入分析理解用戶的需求，抽象出系統的本質屬性，并用模型準確表示出來。

4）建模過程中，分析員應該認真向領域專家學習，還應仔細研究以前針對相同的或類似問題域進行面向對象分析得出的結果。

3個子模型與5個層次

a）對象模型：幾乎解決任何一個問題，都需要從客觀世界實體及實體間相互關系抽象出極有價值的對象模型。

b）動態模型：問題涉及交互作用和時序時最重要。c）功能模型：解決運算量很大的問題時很重要。五個層次：主題層、類與對象層、結構層、屬性層、服務層與之對應的面向對象分析過程中建立的對象模型為：找出類與對象、識別結構、識別主題、定義屬性、定義服務，綜合以上知，面向對象分析可按下列順序進行：找出類與對象、識別結構、識別主題、定義屬性、建議動態模型、建立功能模型、定義服務。

2.需求陳述

書寫要點：需求陳述通常包括：問題范圍，功能需求，性能需求，應用環境及假設條件等。

應該闡明“做什么”，而不是“怎么做”

應該描述用戶的需求，而不是提出解決問題的方法

應該指出哪些是系統必要的性質，哪些是任選的性質

應該避免對設計策略施加過多的約束，也不要描述系統的內部結構，

否則將限制實現的靈活性

對系統性能及外界環境交互協議的描述是合適的需求

對采用的軟件工程標準、模塊構造準則、將來可能做的擴充以及可維

護性要求等方面描述，也都是適當的需求

系統分析員必須與用戶及領域專家密切配合協同工作，共同提煉和整理用戶需求

例子

3.建立對象模型

對象模型描述了現實世界中的“類與對象”以及它們之間的關系，表示了目標系統的靜態數據結構。靜態數據結構對應用細節依賴較少，比較容易確定當用戶的需求變化時，靜態數據結構相對來說比較穩定

確定類與對象

1）找出候選的類與對象

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

2）篩選出正確的類與對象

非正式分析僅僅幫助我們找到一些候選的類與對象，接下來應該嚴格考察每個候選對象，從中去掉不正確的或不必要的，僅保留確實應該記錄其信息或需要其提供服務的那些對象

1）冗余

2）無關

3）籠統

4）屬性

5）操作

在需求陳述中有時可能使用一些既可作為名詞，又可作為動詞的詞，應該慎重考慮它們在本問題中的含義，以便正確地決定把它們作為類還是作為類中定義的操作。

6）實現

在分析階段不應該過早地考慮怎樣實現目標系統。因此，應該去掉僅和實現有關的候選的對象/類。在設計和實現階段，這些對象/類可能是重要的，但在分析階段過早地考慮它們反而會分散我們的注意力。

確定關聯

1）初步確定關聯

直接提取動詞短語得出的關聯

需求陳述中隱含的關聯

根據問題域知識得出的關聯

2）篩選

己刪去的類之間的關聯

與問題無關的或在實現階段考慮的關聯

瞬時事件

三元關聯

派生關聯

3）進一步完善

正名

分解

補充

標明重數

劃分主題

確定屬性

1）分析

2）選擇

識別繼承關系

反復修改

4.建立動態模型

編寫腳本

設想用戶界面

畫事件跟蹤圖

畫狀態圖

審查動態模型

各個類的狀態圖通過共享事件合并起來，構成了系統的動態模型。

5.建立功能模型

功能模型表明了系統中數據之間的依賴關系，以及有關的數據處理功能，它由一組數據流圖組成。其中的處理功能可以用IPO圖、偽碼等多種方式進一步描述。

通常在建立了對象模型和動態模型之后再建立功能模型。

畫出基本系統模型圖

基本系統模型由若干個數據源點/終點，及一個處理框組成，這個處理框代表了系統加工、變換數據的整體功能。

畫出功能級數據流圖

把基本系統模型中的單一的處理框分解成若干個處理框，以描述系統加工、變換數據的基本功能，就得到功能級數據流圖。

描述處理框功能

把數據流圖分解細化到一定程度后，應該描述圖中各個處理框的功能。注意，應該著重描述每個處理框所代表的功能，而不是實現功能的具體算法。

6.定義服務

常規行為

從事件導出的操作

狀態圖中發往對象的事件也就是該對象接收到的消息，因此該對象必須提供由消息選擇符指定的操作，這個操作修改對象狀態并啟動相應的服務。

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

數據流圖中每個處理框都與一個對象上的操作相應。應該仔細對照狀態圖和數據流圖，以便更正確地確定對象應該提供的服務。

利用繼承減少冗余操作

應該盡量利用繼承機制以減少所需定義的服務數目.

面向對象設計

1.面向對象設計的準則

模塊化

抽象

信息隱藏

弱耦合

1）交互耦合：對象之間的耦合通過消息來實現

2）繼承耦合：應該提高繼承耦合。

強內聚：衡量一個模塊內各個元素彼此結合的緊密程度

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

2）類內聚

3）一般特殊內聚

可重用

2.啟發規則

設計結果應該清晰易懂

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

設計簡單的類

使用簡單的協議

使用簡單的服務

把設計變動減至最小

3.軟件重用

概述

1）重用：也叫再用或復用，是指同一事物不作修改或稍加改動就多次重及使用。

2）軟件成分的重用級別

代碼重用、設計結果重用、分析結果重用

3）典型的可重用軟件成分

類構件：比較理想的可重用軟構件

1）可重用軟構件應具備的特點

模塊獨立性強、具有高度可塑性、接口清晰、簡明、可靠

2）類構件的重用方式

實例重用、繼承重用、多態重用

軟件重用的效益

1）質量

2）生產率

3）成本

4.系統分解

典型的面向對象設計模型，邏輯上由4部分組成:人機交互部分，問題域部分，任務管理部分,數據管理部分.

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

1）客戶-供應商關系

2）平等伙伴關系

組織系統的兩種方案

1）層次組織

2）塊狀組織

設計系統拓撲結構

5.設計問題域子系統

在面向對象設計過程中，可能面向對象分析所得出的問題域模型做的補充或修改:

調整需求

重用已有的類

把問題域類組合在一起

增添一般化類以建立協議

調整繼承層次

6.設計人機交互子系統

分類用戶

描述用戶

設計命令層次

設計人機交互類

7.設計任務管理子系統

分析并發性

設計任務管理子系統

8.設計數據管理子系統

選擇數據存儲管理模式

1）文件管理系統

2）關系數據庫管理系統

3）面向對象數據庫管理系統

設計數據管理子系統

1）設計數據格式

2）設計相應的服務

9.設計類中的服務

確定類中應有的服務

設計實現服務的方法

1）設計實現服務的算法

2）選擇數據結構

3）定義內部類和內部操作

10.設計關聯

關聯的遍歷

實現單向關聯

實現雙向關聯

關聯對象的實現

11.設計優化

確定優先級

提高效率的幾項技術

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

2）調整查詢次序

3）保留派生屬性

調整繼承關系

1）抽象與具體

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

3）利用委托實現行為共享

面向對象實現

面向對象實現包括：把面向對象設計結果翻譯成用某種程序語言書寫的面向對象程序；測試并調試面向對象的程序。

1.程序設計語言

面向對象設計的結果既可以用面向對象語言、也可以用非面向對象語言實現。使用面向對象語言時，由于語言本身充分支持面向對象概念的實現，因此，編譯程序可以自動把面向對象概念映射到目標程序中。使用非面向對象語言編寫面向對象程序，則必須由程序員自己把面向對象概念映射到目標程序中。

面向對象語言的優點

從原理上說，使用任何一種通用語言都可以實現面向對象概念。當然，使用面向對象語言，實現面向對象概念，遠比使用非面向對象語言方便，但是，方便性也并不是決定選擇何種語言的關鍵因素。選擇編程語言的關鍵因素，是語言的一致的表達能力、可重用性及可維護性。從面向對象觀點看來，能夠更完整、更準確地表達問題域語義的面向對象語言的語法是非常重要的，因為這會帶來

下述幾個重要優點：

1）一致的表示方法

2）可重用性

3）可維護性

面向對象語言的技術特點

1）支持類與對象概念的機制

2）實現整體-部分結構的機制

3）實現一般-特殊結構的機制

4）實現屬性和服務的機制

5）類型檢查

6）類庫

7）效率

8）持久保存對象

9）參數化類

10）開發環境

選擇面向對象語言

1）將來能否占主導地位

2）可重用性

3）類庫和開發環境

4）其他因素

2.程序設計風格

提高可重用性

1）提高方法的內聚

2）減小方法的規模

3）保持方法的一致性

4）把策略與現實分開

5）全面覆蓋

6）盡量不使用全局信息

7）利用繼承機制

提高可擴充性

1）封裝實現策略

2）不要用一個方法遍歷多條聯鏈

3）避免使用多分支語句

4）精心確定公有方法

提高健壯性

1）預防用戶的操作錯誤

2）檢查參數的合法性

3）不要預先確定限制條件

4）先測試后優化

3.測試策略

面向對象的單元測試

當考慮面向對象的軟件時，單元的概念改變了。“封裝”導致了類和對象的定義,這意味著類和類的實例包裝了屬性和處理這些數據的操作。現在，最小的可測試單元是封裝起來的類和對象。一個類可以包含一組不同的操作，而一個特定的操作也可能存在于一組不同的類中。因此，對于面向對象的軟件來說，單元測試的含義發生了很大變化。在測試面向對象軟件時，不再孤立地測試單個操作，而應該把操作為類的一部分來測試。

面向對象的集成測試

因為在面向對象的軟件中不存在層次的控制結構，傳統的自頂向下或自底向上的集成策略就沒有意義了。此外，由于構成類的各個成分彼此間存在直接或間接的交互，一次集成一個操作到類中通常是不現實的。

基于線程的測試和基于使用的測試兩種

面向對象的確認測試：和傳統的確認測試一樣，面向對象的確認測試也集中檢查用戶可見的動作和用戶可識別的輸出。對于面向對象的軟件來說，主要還是根據動態模型和描述系統行為的腳本來設計確認測試用例。在確認測試或系統測試層次，不再考慮類之間相互連接的細節。和傳統的確認測試一樣，面向對象軟件的確認測試也集中檢查用戶可見的動作和用戶可識別的輸出。為了導出確認測試用例，測試人員應該認真研究動態模型和描述系統行為的腳本，以確定最可能發現用戶交互需求錯誤的情景。

4.設計測試用例

測試類的方法

1）隨機測試

2）劃分測試

1）基于狀態的劃分

2）基于屬性的劃分

3）基于功能的劃分

3）基于故障的測試

集成測試方法

可采用基于線程或基于使用的策略完成集成測試，也可以采用隨機測試和劃分測試方法，從動態模型導出的測試用例，可以測試指定的類及其協作者。測試類協作可以使用隨機測試方法和劃分測試方法，以及基于情景的測試和行為測試來完成。

1）多類測試

2）從動態模型導出測試用例

確認測試

可以采用傳統的黑盒方法完成測試工作，基于情景的測試是面向對象系統確認測試的主要方法。

軟件項目管理

1.估算軟件規模

代碼行技術

功能點技術

2.工作量估算

軟件估算模型使用由經驗導出的公式來預測軟件開發工作量，工作量是軟件規模的函數，工作量的單位通常是人月。靜態單變量模型

動態多變量模型

C0C0M02模型

3.進度計劃

估算開發時間

Gantt圖工程網絡

估算工程進度

關鍵路徑

機動時間

4.人員組織

民主制程序員組：小組成員完全平等,充分享有民主通過協商做出決策。

主程序員組

現代程序員組

5.質量保證

軟件質量

軟件與明確地和隱含地定義的需求相一致的程度。具體的說。軟件質量是軟件與明確地敘述的功能和性能需求、文檔中明確描述的開發標準以及任何專業開發的軟件產品都應該具有的隱含特征相一致的程度

軟件需求是度量軟件質量的基礎。

有沒有顯式描述的隱含需求。

不遵守一組指導軟件開發的準則，會導致軟件質量不高。

軟件質量保證措施

基于非執行的測試、基于執行的測試、程序正確性證明

1）技術復審的必要性

2）走查

3）審查

4）程序正確性證明：使用數學方法嚴格驗證程序是否與它的說明完全一致。

6.軟件配置管理

軟件的整個生命期內管理變化的一組活動，目標是使變化更正確且更容易被適應，在必須變化時減少所需花費的工作量。

軟件配置

1）軟件配置項

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

軟件配置管理過程

1）標識軟件配置中的對象

2）版本控制

3）變化控制

4）配置審計

正式的技術復審:關注被修改后的配置對象的技術正確性。軟件配置審計:通過評估配置對象那些通常不在復審過程中考慮的特征，是

對正式技術復審的補充。

7.能力成熟度模型CMM

基本思想：由于問題是由人們管理軟件過程的方法不正當引起的，所以新軟件技術的運用并不會自動提高軟件的生產率和質量。能力成熟度模型有助于軟件開發機構建立一個有規律、成熟的軟件過程。

1）初始級

2）可重復級

3）已定義級

4）已管理級

5）優化級

Tags：DFDSLPCMMDFD價格DFD幣SLP價格SLP幣CMM價格CMM幣

幣安app下載