軟體工程---常用總結
- 軟體工程的框架可概括為：目標、過程和原則。
開發模型
瀑布模型
瀑布模型產生的歷史背景是20世界70年代出現的軟體危機，該模型將軟體開發分為若干階段，由於其類似於瀑布從上到下的過程，故稱其為“瀑布模型”。
- 特點：
- 階段間具有順序性和依賴性:
- 前一階段完成後,才能開始後一階段
- 前一階段的輸出文字為後一階段的輸入文字
- 推遲實現的觀點
- 質量保證： - 每個階段必須交付出合格的文件
- 對文件進行稽核
- 階段間具有順序性和依賴性:
- 缺點：
開始需要把需求做到最全，懼怕使用者測試中的反饋,懼怕需求變更。
V模型
V模型是在瀑布模型的基礎上發展而來的。
RAD(Rap Application Development，快速應用開發)模型是軟體開發過程中的一個重
要模型，由於其模型構圖形似字母V，所以又稱軟體測試的 V模型。它通過開發和測試同時進行的方式來縮短開發週期，提高開發效率。
階段步驟
V模型大體可以劃分為以下幾個不同的階段步驟：需求分析、概要設計、詳細設計、軟體編碼、單元測試、整合測試、系統測試、驗收測試。
- 需求分析：
首先要明確客戶需要的是什麼，需要軟體作成什麼樣子，需要有哪幾項功能，這一點上比較關鍵的是分析師和客戶溝通時的理解能力與互動性。要求分析師能準確地把客戶所需要達到的功能、實現方式等表述出來，給出分析結果，寫出需求規格說明書。 - 概要設計：
主要是架構的實現，指搭建架構、表述各模組功能、模組介面連線和資料傳遞的實現等多項事務。 - 詳細設計：
對概要設計中表述的各模組進行深入分析、對各模組組合進行分析等，這一階段要求達到虛擬碼級別，已經把程式的具體實現的功能、現象等表述出來。其中需要包含資料庫設計說明。 - 軟體編碼：
按照詳細設計好的模組功能表，程式設計人員編寫出實際的程式碼。 - 單元測試：
按照設定好的最小測試單元進行按單元測試，主要是測試程式程式碼，為的是確保各單元模組被正確的編譯。
單元的具體劃分，依據不同的單位、不同的軟體而有所不同，比如有具體到模組的測試，也有具體到類、函式的測試等。 - 整合測試：
經過了單元測試後，將各單元組合成完整的體系，主要測試各模組間組合後的功能實現情況，以及模組介面連線的成功與否，資料傳遞的正確性等。其主要目的是檢查軟體單位之間的介面是否正確。
根據整合測試計劃，一邊將模組或其他軟體單位組合成系統，一邊執行該系統，以分析所組成的系統是否正確，各組成部分是否合拍。 - 系統測試：
經過了單元測試和整合測試以後，我們要把軟體系統搭建起來，按照軟體規格說明書中所要求，測試軟體其效能、功能等是否和使用者需求相符合，在系統中執行是否存在漏洞，等。 - 驗收測試：
主要就是使用者在拿到軟體的時候，在使用現場，會根據前邊所提到的需求，以及規格說明書來做相應測試，以確定軟體達到符合效果的。
缺陷及解決思路
缺陷：
V模型僅僅把測試過程作為在需求分析、系統設計及編碼之後的一個階段，忽視了測試對需求分析,系統設計的驗證，需求的滿足情況一直到後期的驗收測試才被驗證。解決思路：
當一個軟體開發的時候，研發人員和測試人員需要同時工作，測試在軟體做需求分析的同時就會有測試用例的跟蹤，這樣，可以儘快找出程式錯誤和需求偏離，從而更高效的提高程式質量，最大可能的減少成本，同時滿足使用者的實際軟體需求。
適用範圍
V模式是一種傳統軟體開發模型，一般適用於一些傳統資訊系統應用的開發；而一些高效能高風險的系統、網際網路軟體，或一個系統難以被具體模組化的時候，就比較難做成V模式所需的各種構件，需要更強調迭代的開發模型或者敏捷開發模型。
W模型
W模型：由Evolutif公司提出，相對於V模型，W模型增加了軟體開發各階段中同步進行的驗證和確認活動。
如圖所示，由兩個V字型模型組成，分別代表測試與開發過程，圖中明確表示出了測試與開發的並行關係。
- 優點：
- 開發伴隨著整個開發週期，需求和設計同樣要測試；
- 更早的介入測試，可以發現初期的缺陷，修復成本低； - 分階段工作，方便專案整體管理。
- 開發伴隨著整個開發週期，需求和設計同樣要測試；
- 缺點：
- 開發和測試依然是線性的關係，需求的變更和調整，依然不方便；
- 如果沒有文件，根本無法執行w模型；對於專案組成員的技術要求更高！
軟體生命週期
瀑布型生命週期
瀑布型生命週期包括可行性分析與開發項計劃、需求分析、設計（概要設計和詳細設計）、編碼、測試、維護等階段。
階段步驟
- 問題的定義及規劃：
此階段是軟體開發方與需求方共同討論，主要確定軟體的開發目標及其可行性。 - 需求分析：
在確定軟體開發可行的情況下，對軟體需要實現的各個功能進行詳細分析。需求分析階段是一個很重要的階段，這一階段做得好，將為整個軟體開發專案的成功打下良好的基礎。"唯一不變的是變化本身。"，同樣需求也是在整個軟體開發過程中不斷變化和深入的，因此我們必須制定需求變更計劃來應付這種變化，以保護整個專案的順利進行。 - 軟體設計：
此階段主要根據需求分析的結果，對整個軟體系統進行設計，如系統框架設計，資料庫設計等等。軟體設計一般分為總體設計和詳細設計。好的軟體設計將為軟體程式編寫打下良好的基礎。 - 程式編碼：
此階段是將軟體設計的結果轉換成計算機可執行的程式程式碼。在程式編碼中必須要制定統一，符合標準的編寫規範。以保證程式的可讀性，易維護性，提高程式的執行效率。 - 軟體測試：
在軟體設計完成後要經過嚴密的測試，以發現軟體在整個設計過程中存在的問題並加以糾正。整個測試過程分單元測試、組裝測試以及系統測試三個階段進行。測試的方法主要有白盒測試和黑盒測試兩種。在測試過程中需要建立詳細的測試計劃並嚴格按照測試計劃進行測試，以減少測試的隨意性。 - 執行維護：
軟體維護是軟體生命週期中持續時間最長的階段。在軟體開發完成並投入使用後，由於多方面的原因，軟體不能繼續適應使用者的要求。要延續軟體的使用壽命，就必須對軟體進行維護。軟體的維護包括糾錯性維護和改進性維護兩個方面。
高內聚低耦合
- 內聚：是從功能角度來度量模組內的聯絡，一個好的內聚模組應當恰好做一件事。它描述的是模組內的功能聯絡；
- 耦合：是軟體結構中各模組之間相互連線的一種度量，耦合強弱取決於模組間介面的複雜程度、進入或訪問一個模組的點以及通過介面的資料。
- 耦合性：也稱塊間聯絡。指軟體系統結構中各模組間相互聯絡緊密程度的一種度量。模組之間聯絡越緊密，其耦合性就越強，模組的獨立性則越差。模組間耦合高低取決於模組間介面的複雜性、呼叫的方式及傳遞的資訊。
內聚性：又稱塊內聯絡。指模組的功能強度的度量，即一個模組內部各個元素彼此結合的緊密程度的度量。若一個模組內各元素（語名之間、程式段之間）聯絡的越緊密，則它的內聚性就越高。
- 所謂高內聚是指一個軟體模組是由相關性很強的程式碼組成，只負責一項任務，也就是常說的單一責任原則。
對於低耦合，粗淺的理解是：一個完整的系統，模組與模組之間，儘可能的使其獨立存在。也就是說，讓每個模組，儘可能的獨立完成某個特定的子功能。模組與模組之間的介面，儘量的少而簡單。如果某兩個模組間的關係比較複雜的話，最好首先考慮進一步的模組劃分。這樣有利於修改和組合。
耦合
耦合可以分為以下幾種，它們之間的耦合度由高到低排列如下：
- 內容耦合：一個模組直接訪問另一模組的內容，則稱這兩個模組為內容耦合。
內容耦合可能在組合語言中出現。大多數高階語言都已設計成不允許出現內容耦合。
這種耦合的耦合性最強，模組獨立性最弱。 - 公共耦合：一組模組都訪問同一個全域性資料結構，則稱之為公共耦合。
公共資料環境可以是全域性資料結構、共享的通訊區、記憶體的公共覆蓋區等。
如果模組只是向公共資料環境輸入資料，或是隻從公共資料環境取出資料，這屬於比較鬆散的公共耦合；
如果模組既向公共資料環境輸入資料又從公共資料環境取出資料，這屬於較緊密的公共耦合。 - 外部耦合：一組模組都訪問同一全域性簡單變數，而且不通過引數表傳遞該全域性變數的資訊，則稱之為外部耦合。
- 控制耦合：模組之間傳遞的不是資料資訊，而是控制資訊例如標誌、開關量等，一個模組控制了另一個模組的功能。
- 標記耦合：呼叫模組和被呼叫模組之間傳遞資料結構，而不是簡單資料，同時也稱作特徵耦合。
標記耦合的模組間傳遞的不是簡單變數，而是像高階語言中的資料名、記錄名和檔名等資料結果，這些名字即為標記，其實傳遞的是地址。 - 資料耦合：呼叫模組和被呼叫模組之間只傳遞簡單的資料項引數。相當於高階語言中的值傳遞。
- 非直接耦合：兩個模組之間沒有直接關係，它們之間的聯絡完全是通過主模組的控制和呼叫來實現的。
耦合度最弱，模組獨立性最強。
總結：耦合是影響軟體複雜程度和設計質量的一個重要因素，為提高模組的獨立性，應建立模組間儘可能鬆散的系統，在設計上我們應採用以下原則：若模組間必須存在耦合，應儘量使用資料耦合，少用控制耦合，慎用或有控制地使用公共耦合，並限制公共耦合的範圍，儘量避免內容耦合。
內聚
內聚有如下的種類，它們之間的內聚度由弱到強排列如下：
- 偶然內聚：一個模組內的各處理元素之間沒有任何聯絡，只是偶然地被湊到一起。
這種模組也稱為巧合內聚，內聚程度最低。 - 邏輯內聚：這種模組把幾種相關的功能組合在一起，每次被呼叫時，由傳送給模組引數來確定該模組應完成哪一種功能。
- 時間內聚：把需要同時執行的動作組合在一起，形成的模組稱為時間內聚模組。
- 過程內聚：構件或者操作的組合方式是，允許在呼叫前面的構件或操作之後，馬上呼叫後面的構件或操作，即 使兩者之間沒有資料進行傳遞。
簡單的說就是如果一個模組內的處理元素是相關的，而且必須以特定次序執行，則稱為過程內聚。 - 通訊內聚（資訊內聚）：指模組內所有處理元素都在同一個資料結構上操作或所有處理功能都通過公用資料而發生關聯（有時稱之為資訊內聚）。
即 指模組內各個組成部分都使用相同的資料資料或產生相同的資料結構。 - 順序內聚：一個模組中各個處理元素和同一個功能密切相關，而且這些處理必須順序執行，通常前一個處理元素的輸出是後一個處理元素的輸入。
例如，某模組完成工業產值求值的功能，前一個功能元素求總產值，後一個功能元素求平均產值，顯然該模組內兩部分緊密關聯。
順序內聚的內聚度比較高，但缺點是不如功能內聚易於維護。 - 功能內聚：模組內所有元素的各個組成部分全部都為完成同一個功能而存在，共同完成一個單一的功能，模組已不可再分。即 模組僅包括為完成某個功能所必須的所有成分，這些成分緊密聯絡、缺一不可。
功能內聚是最強的內聚，其優點是它的功能明確。判斷一個模組是否功能內聚，一般從模組名稱就能看出。
如果模組名稱只有一個動詞和一個特定的目標（單數名詞），一般來說就是功能內聚，如：“計算水費”、“計算產值”等模組。功能內聚一般出現在軟體結構圖的較低層次上。
功能內聚模組的一個重要特點是：他是一個“暗盒”，對於該模組的呼叫者來說，只需要知道這個模組能做什麼，而不需要知道這個模組是如何做的。
總結：在模組劃分時，要遵循“一個模組，一個功能”的原則，儘可能使模組達到功能內聚。
高內聚，低耦合的系統有什麼好處呢？
事實上，短期來看，並沒有很明顯的好處，甚至短期內會影響系統的開發進度，因為高內聚，低耦合的系統對開發設計人員提出了更高的要求。
高內聚，低耦合的好處體現在系統持續發展的過程中，高內聚，低耦合的系統具有更好的重用性，維護性，擴充套件性，可以更高效的完成系統的維護開發，持續的支援業務的發展，而不會成為業務發展的障礙。