本章分享的1.4節的重要考點內容相對來說還是比較多的，里面包括需求、設計、測試等軟件工程的內容，同學們學完前幾篇文章的分享會發現，第一章與計算機領域的知識的銜接程度還是非常緊密的。我經常會聽到很多面授課學員在學習第一章的時候跟我說“第一章記不住，太難了，想放棄”，其實我可以這么說第一章是比較難，就以1.4節為例，大部分同學應該都是計算機相關專業畢業的學員，大家在大學的時候一定知道軟件工程這個專業，試想一下，軟件工程專業的同學用三到四年的時間學習軟件工程的相關知識，我們的教材只是用一個小節進行講解，所有的知識點只要背下來考試就會沒問題。而且你幸運的看到了這篇文章，你會發現本篇文章對書中不考的知識點進行篩選精化，將原先要背的幾十頁甚至幾百頁的內容最終形成幾千字的文字，大家就更不應該退縮了，更應該好好學習了。下面我們繼續分享

1.4軟件工程

1.4.1需求分析

1、需求是多層次的， 包括業務需求、用戶需求和系統需求。

(1) 業務需求。業務需求是指反映企業或客戶對系統高層次的目標要求，通常來自項目投資人、購買產品的客戶、客戶單位的管理人員、市場營銷部門或產品策劃部門等。

(2) 用戶需求。用戶需求描述的是用戶的具體目標，或用戶要求系統必須能完成的任務。也就是說，用戶需求描述了用戶能使用系統來做些什么。通常采取用戶訪談和問卷調查等方式，對用戶使用的場景進行整理，從而建立用戶需求。

(3) 系統需求。系統需求是從系統的角度來說明軟件的需求，包括功能需求、非功能需求和設計約束等。

2、質量功能部署(QFD)是一種將用戶要求轉化成軟件需求的技術，其目的是最大限度地提升軟件工程過程中用戶的滿意度。QFD將軟件需求分為三類，分別是常規需求、期望需求和意外需求。

(1) 常規需求。用戶認為系統應該做到的功能或性能，實現越多用戶會越滿意。

(2) 期望需求。用戶想當然認為系統應具備的功能或性能，但并不能正確描述自己想要得到的這些功能或性能需求。如果期望需求沒有得到實現，會讓用戶感到不滿意。

(3) 意外需求。意外需求也稱為興奮需求，是用戶要求范圍外的功能或性能(但通常是軟件開發人員很樂意賦予系統的技術特性實現這些需求用戶會更高興，但不實現也不影響其購買的決策。意外需求是控制在開發人員手中的，開發人員可以選擇實現更多的意外需求，以便得到高滿意、高忠誠度的用戶，也可以(出于成本或項目周期的考慮)選擇不實現任何意外需求。

3、常見的需求獲取方法包括用戶訪談、問卷調查、采樣、情節串聯板、聯合需求計劃等

4、一個好的需求應該具有無二義性、完整性、一致性、可測試性、確定性、可跟蹤性、正確性、必要性等特性，因此，需要分析人員把雜亂無章的用戶要求和期望轉化為用戶需求，這就是需求分析的工作。

使用SA方法進行需求分析，其建立的模型的核心是數據字典。在實際工作中，一般使用實體聯系圖(E-R圖) 表示數據模型，用數據流圖(DFD) 表示功能模型，用狀態轉換圖(STD) 表示行為模型。E-R圖主要描述實體、屬性，以及實體之間的關系;DFD從數據傳遞和加工的角度，利用圖形符號通過逐層細分描述系統內各個部件的功能和數據在它們之間傳遞的情況，來說明系統所完成的功能; STD通過描述系統的狀態和引起系統狀態轉換的事件，來表示系統的行為，指出作為特定事件的結果將執行哪些動作(例如，處理數據等)。

5、軟件需求規格說明書(SRS)是需求開發活動的產物，其中規定SRS應該包括以下內容。

(1)范圍(2)引用文件(3)需求(4)合格性規定(5)需求可追蹤性(6)尚未解決的問題(7) 注解(8)附錄

6、需求驗證也稱為需求確認，其活動是為了確定以下幾個方面的內容。

(1) SRS正確地描述了預期的、滿足項目干系人需求的系統行為和特征。

(2) SRS中的軟件需求是從系統需求、業務規格和其他來源中正確推導而來的。

(3) 需求是完整的和高質量的。

(4)需求的表示在所有地方都是一致的。

(5)需求為繼續進行系統設計、實現和測試提供了足夠的基礎。

在實際工作中，一般通過需求評審和需求測試工作來對需求進行驗證。需求評審就是對SRS進行技術評審。

7、從總體上來看，UML的結構包括構造塊、規則和公共機制三個部分。

8、UML用關系把事物結合在一起，主要有下列四種關系:

(1) 依賴: :依賴是兩個事物之間的語義關系，其中一個事物發生變化會影響另一個事物的語義。

(2) 關聯:關聯描述一組對象之間連接的結構關系。

(3) 泛化:泛化是一般化和特殊化的關系，描述特殊元素的對象可替換一般元素的對象。

(4) 實現:實現是類之間的語義關系，其中的一個類指定了由另一個類保證執行的契約。

9、UML 2. 0包括14種圖，分別列舉如下:

(1)類圖:類圖描述一組類、接口、協作和它們之間的關系。類圖給出了系統的靜態設計視圖，活動類的類圖給出了系統的靜態進程視圖。

(2)對象圖:對象圖描述一組對象及它們之間的關系。

(3) 泛化:泛化是一般化和特殊化的關系，描述特殊元素的對象可替換一般元素的對象。

(4) 實現:實現是類之間的語義關系，其中的一個類指定了由另一個類保證執行的契約。

9、UML 2. 0包括14種圖，分別列舉如下:

(1)類圖:類圖描述一組類、接口、協作和它們之間的關系。類圖給出了系統的靜態設計視圖，活動類的類圖給出了系統的靜態進程視圖。

(2)對象圖:對象圖描述一組對象及它們之間的關系。

(3) 構件圖:構件圖描述一個封裝的類和它的接口、端口， 以及由內嵌的構件和連接件構成的內部結構。

(4) 組合結構圖:組合結構圖描述結構化類(例如，構件或類)的內部結構，包括結構化類與系統其余部分的交互點。

(5)用例圖:用例圖描述一組用例、參與者及它們之間的關系。

(6)順序圖(也稱序列圖) :順序圖是一一種交互圖，交互圖展現了一種交互，它由一組對象或參與者以及它們之間可能發送的消息構成。交互圖專注于系統的動態視圖。順序圖是強調消息的時間次序的交互圖。

(7) 通信圖:通信圖也是一種交互圖，它強調收發消息的對象或參與者的結構組織。順序圖強調的是時序，通信圖強調的是對象之間的組織結構(關系)。

(8) 定時圖(也稱計時圖) :定時圖也是一種交互圖，它強調消息跨越不同對象或參與者的實際時間，而不僅僅只是關心消息的相對順序。

(9) 狀態圖:狀態圖描述一個狀態機，它由狀態、轉移、事件和活動組成。狀態圖給出了對象的動態視圖。

(10) 活動圖:活動圖將進程或其他計算結構展示為計算內部一步步的控制流和數據流?；顒訄D專注于系統的動態視圖。它強調對象間的控制流程。

(11) 部署圖:部署圖描述對運行時的處理節點及在其中生存的構件的配置。部署圖給出了架構的靜態部署視圖，通常一個節點包含一個或多個部署圖。

(12)制品圖:制品圖描述計算機中一個系統的物理結構。制品包括文件、數據庫和類似的物理比特集合。制品圖通常與部署圖一起使用。制品也給出了它們實現的類和構件。

(13) 包圖:包圖描述由模型本身分解而成的組織單元，以及它們之間的依賴關系。

(14)交互概覽圖:交互概覽圖是活動圖和順序圖的混合物。

10、UML視圖: 5個系統視圖:

(1) 邏輯視圖:邏輯視圖也稱為設計視圖，它表示了設計模型中在架構方面具有重要意義的部分，即類、子系統、包和用例實現的子集。

(2) 進程視圖:進程視圖是可執行線程和進程作為活動類的建模，它是邏輯視圖的一-次執行實例，描述了并發與同步結構。

(3)實現視圖:實現視圖對組成基于系統的物理代碼的文件和構件進行建模。

(4)部署視圖:部署視圖把構件部署到一組物理節點上，表示軟件到硬件的映射和分布結構。

(5) 用例視圖:用例視圖是最基本的需求分析模型。

11、00A模型獨立于具體實現，即不考慮與系統具體實現有關的因素，這也是00A和00D的區別之所在。00A的任務是“做什么00D的任務是“怎么做”。面向對象分析階段的核心工作是建立系統的用例模型與分析模型。

12、SA (結構化分析)方法采用功能分解的方式來描述系統功能，在這種表達方式中，系統功能被分解到各個功能模塊中，通過描述細分的系統模塊的功能來達到描述整個系統功能的目的。

13、類之間的主要關系有關聯、依賴、泛化、聚合、組合和實現等

(1) 關聯關系。關聯提供了不同類的對象之間的結構關系，它在一段時間內將多個類的實例連接在一起。關聯體現的是對象實例之間的關系，而不表示兩個類之間的關系。

(2) 依賴關系。兩個類A和B，如果B的變化可能會引起A的變化，則稱類A依賴于類B。

(3) 泛化關系。泛化關系描述了一- 般事物與該事物中的特殊種類之間的關系，也就是父類與子類之間的關系。繼承關系是泛化關系的反關系，也就是說，子類繼承了父類，而父類則是子類的泛化。

(4)共享聚集。共享聚集關系通常簡稱為聚合關系，它表示類之間的整體與部分的關系，其含義是“部分”可能同時屬于多個“整體”，“部分”與“整體”的生命周期可以不相同。

(5)組合聚集。組合聚集關系通常簡稱為組合關系，它也是表示類之間的整體與部分的關系。與聚合關系的區別在于，組合關系中的“部分”只能屬于一個“整體”，“部分”與“整體”的生命周期相同，“部分” 隨著“整體M的創建而創建，也隨著“整體”的消亡 而消亡。

(6) 實現關系。實現關系將說明和實現聯系起來。接口是對行為而非實現的說明， 而類中則包含了實現的結構。一個或多個類可以實現一個接口，而每個類分別實現接口中的操作。

1.4.2軟件架構設計

1、解決好軟件的復用、質量和維護問題，是研究軟件架構的根本目的。軟件架構設計的一個核心問題是能否達到架構級的軟件復用。

2、軟件架構分為數據流風格、調用/返回風格、獨立構件風格、虛擬機風格和倉庫風格。

(1) 數據流風格:數據流風格包括批處理序列和管道/過濾器兩種風格。

(2) 調用/返回風格:調用/返回風格包括主程序/子程序、數據抽象和面向對象，以及層次結構。

(3) 獨立構件風格:獨立構件風格包括進程通信和事件驅動的系統。

(4)虛擬機風格:虛擬機風格包括解釋器和基于規則的系統。

(5) 倉庫風格:倉庫風格包括數據庫系統、黑板系統和超文本系統。

3、軟件架構評估可以只針對一個架構，也可以針對一組架構。在架構評估過程中，評估人員所關注的是系統的質量屬性。

4、敏感點是一個或多個構件(和/或構件之間的關系)的特性，權衡點是影響多個質量屬性的特性，是多個質量屬性的敏感點。

5、從目前已有的軟件架構評估技術來看，可以歸納為三類主要的評估方式，分別是基于調查問卷(或檢查表)的方式、基于場景的方式和基于度量的方式。這三種評估方式中，基于場景的評估方式最為常用。

6、基于場景的方式主要包括:架構權衡分析法(ATAM)、 軟件架構分析法(SAAM)和成本效益分析法(CBAM)中。 在架構評估中，一般采用刺激、環境和響應三方面來對場景進行描述。刺激是場景中解釋或描述項目干系人怎樣引發與系統的交互部分，環境描述的是刺激發生時的情況，響應是指系統是如何通過架構對刺激作出反應的。

7、基于場景的方式分析軟件架構對場景的支持程度，從而判斷該架構對這一場景所代表的質量需求的滿足程度。這一評估方式考慮到了所有與系統相關的人員對質量的要求，涉及的基本活動包括確定應用領域的功能和軟件架構之間的映射，設計用于體現待評估質量屬性的場景，以及分析軟件架構對場景的支持程度。

1.4.3軟件設計

1、軟件設計分為結構化設計與面向對象設計。

2、結構化設計SD是--種面向數據流的方法，它以SRS和SA階段所產生的DFD和數據字典等文檔為基礎，是一個自頂向下、逐步求精和模塊化的過程。SD分為概要設計和詳細設計兩個階段

3、在SD中，需要遵循一個基本的原則:高內聚，低耦合

4、面向對象設計00D是00A方法的延續，其基本思想包括抽象、封裝和可擴展性，其中可擴展性主要通過繼承和多態來實現。

5、設計模式是前人經驗的總結，它使人們可以方便地復用成功的軟件設計。根據處理范圍不同，設計模式可分為類模式和對象模式。根據目的和用途不同，設計模式可分為創建型模式、結構型模式和行為型模式三種。創建型模式主要用于創建對象;結構型模式主要用于處理類或對象的組合;行為型模式主要用于描述類或對象的交互以及職責的分配。

1.4. 4軟件工程的過程管理

1、階段式模型

2、連續式模型

1.4.5軟件測試及其管理

1、每個測試用例應包括名稱和標識、測試追蹤、用例說明、測試的初始化要求、測試的輸入、期望的測試結果、評價測試結果的準則、操作過程、前提和約束、測試終止條件。期望的測試結果、評價測試結果的準則、操作過程、前提和約束、測試終止條件。

2、軟件測試方法可分為靜態測試和動態測試。靜態測試是指被測試程序不在機器上運行，而采用人工檢測和計算機輔助靜態分析的手段對程序進行檢測。靜態測試包括對文檔的靜態測試和對代碼的靜態測試。對文檔的靜態測試主要以檢查單的形式進行，而對代碼的靜態測試一般采用桌前檢查、代碼走查和代碼審查。

3、動態測試是指在計算機上實際運行程序進行軟件測試，一般采用白盒測試和黑盒測試方法。白盒測試也稱為結構測試，主要用于軟件單元測試中。它的主要思想是，將程序看作是一個透明的白盒，測試人員完全清楚程序的結構和處理算法，按照程序內部邏輯結構設計測試用例。白盒測試方法主要有控制流測試、數據流測試和程序變異測試等。另外，使用靜態測試的方法也可以實現白盒測試。例如，使用人工檢查代碼的方法來檢查代碼的邏輯問題，也屬于白盒測試的范疇。白盒測試方法中，最常用的技術是邏輯覆蓋，即使用測試數據運行被測程序，考察對程序邏輯的覆蓋程度。主要的覆蓋標準有語句覆蓋、判定覆蓋、條件覆蓋、條件/判定覆蓋、條件組合覆蓋、修正的條件/判定覆蓋和路徑覆蓋等。

4、黑盒測試也稱為功能測試，主要用于集成測試、確認測試和系統測試中。黑盒測試將程序看作是一個不透明的黑盒，完全不考慮(或不了解)程序的內部結構和處理算法。一般包括等價類劃分、邊界值分析、判定表、因果圖、狀態圖、隨機測試、猜錯法和正交試驗法等。

5、軟件測試可分為單元測試、集成測試、確認測試、系統測試、配置項測試和回歸測試等類別。

(1)單元測試。單元測試也稱為模塊測試。

(2) 集成測試。集成測試的目的是檢查模塊之間，以及模塊和已集成的軟件之間的接口關系。

(3)確認測試。確認測試主要用于驗證軟件的功能、性能和其他特性是否與用戶需求一致。根據用戶的參與程度，通常包括以下類型。

內部確認測試。內部確認測試主要由軟件開發組織內部按照SRS進行測試。

Alpha測試和Beta測試。對于通用產品型的軟件開發而言，Alpha測試是指由用戶在開發環境下進行測試，通過Alpha測試以后的產品通常稱為Alpha版;Beta測試是指由用戶在實際使用環境下進行測試，通過Beta測試的產品通常稱為Beta版。一般在通過Beta測試后，才能把產品發布或交付給用戶。

驗收測試。驗收測試是指針對SRS，在交付前以用戶為主進行的測試。其測試對象為完整的、集成的計算機系統。

(4)系統測試。系統測試的對象是完整的、集成的計算機系統，系統測試的目的是在真實系統工作環境下，驗證完整的軟件配置項能否和系統正確連接，并滿足系統/子系統設計文檔和軟件開發合同規定的要求。

(5)配置項測試。配置項測試的對象是軟件配置項，配置項測試的目的是檢驗軟件配置項與SRS的一致性。

(6) 回歸測試。回歸測試的目的是測試軟件變更之后，變更部分的正確性和對變更需求的符合性，以及軟件原有的、正確的功能、性能和其他規定的要求的不損害性?；貧w測試的對象主要包括以下四個方面。

未通過軟件單元測試的軟件，在變更之后，應對其進行單元測試。

未通過配置項測試的軟件，在變更之后，首先應對變更的軟件單元進行測試，然后再進行相關的集成測試和配置項測試。

未通過系統測試的軟件，在變更之后，首先應對變更的軟件單元進行測試，然后再進行相關的集成測試、配置項測試和系統測試。

因其他原因進行變更之后的軟件單元，也首先應對變更的軟件單元進行測試，然后再進行相關的軟件測試。

6、與傳統的結構化系統相比，00系統具有三個明顯特征，即封裝性、繼承性與多態性。正是由于這三個特征，給00系 統的測試帶來了一系列的困難。

7、常用的軟件調試策略可以分為蠻力法、回溯法和原因排除法三類。軟件調試與測試的區別主要體現在以下幾個方面。

(1) 測試的目的是找出存在的錯誤，而調試的目的是定位錯誤并修改程序以修正錯誤。

(2) 調試是測試之后的活動，測試和調試在目標、方法和思路.上都有所不同。

(3)測試從一個已知的條件開始，使用預先定義的過程，有預知的結果;調試從一-個未知的條件開始，結束的過程不可預計。

(4)測試過程可以事先設計，進度可以事先確定;調試不能描述過程或持續時間。

8、軟件測試的管理包括過程管理、配置管理和評審工作。

(1)過程管理。過程管理包括測試活動管理和測試資源管理。軟件測試應由相對獨立的人員進行。軟件測試人員應包括測試項目負責人、測試分析員、測試設計員、測試程序員、測試員、測試系統管理員和配置管理員等。

(2)配置管理。應按照軟件配置管理的要求，將測試過程中產生的各種工作產品納入配置管理。由開發組織實施的軟件測試，應將測試工作產品納入軟件項目的配置管理;由獨立測試組織實施的軟件測試，應建立配置管理庫，將被測試對象和測試工作產品納入配置管理。

(3)評審。測試過程中的評審包括測試就緒評審和測試評審。測試就緒評審是指在測試執行前對測試計劃和測試說明等進行評審，評審測試計劃的合理性和測試用例的正確性、完整性和覆蓋充分性，以及測試組織、測試環境和設備、工具是否齊全并符合技術要求等;測試評審是指在測試完成后，評審測試過程和測試結果的有效性，確定是否達到測試目的，主要對測試記錄和測試報告進行評審。

1.4.6軟件集成技術

1、企業應用集成EAI包括表示集成、數據集成、控制集成和業務流程集成等多個層次和方面。當

然，也可以在多個企業之間進行應用集成。

(1)表示集成也稱為界面集成，是黑盒集成，無須了解程序與數據庫的內部構造。常用的集成

技術主要有屏幕截取和輸入模擬技術。

(2) 數據集成是白盒集成

(3)控制集成也稱為功能集成或應用集成，是在業務邏輯層上對應用系統進行集成的。集成處可能只需簡單使用公開的API (應 用程序編程接口)就可以訪問，當然也可能需要添加附加的代碼來實現?？刂萍墒呛诤屑?。控制集成與表示集成、數據集成相比，靈活性更高。表示集成和數據集成適用的環境下，都適用于控制集成。但是，由于控制集成是在業務邏輯層進行的，其復雜度更高一些。

(4) 業務流程集成

業務流程集成也稱為過程集成，這種集成超越了數據和系統，它由一系列基于標準的、統一數據格式的工作流組成。當進行業務流程集成時，企業必須對各種業務信息的交換進行定義、授權和管理，以便改進操作、減少成本、提高響應速度。

(5) 企業之間的應用集成

EAI技術可以適用于大多數要實施電子商務的企業，以及企業之間的應用集成。EAI使得應用集成架構里的客戶和業務伙伴都可以通過集成供應鏈內的所有應用和數據庫實現信息共享。也就是說，能夠使企業充分利用外部資源。

請大家認真學習1.4節的，為了能夠快速準確的找到我的文章大家可以關注我，我會每天進行更新。