軟件工程---經常使用總結

• 軟件工程的框架可歸納爲：目標、過程和原則。

開發模型

瀑布模型

瀑布模型產生的歷史背景是20世界70年代出現的軟件危機，該模型將軟件開發分爲若干階段，因爲其相似於瀑布從上到下的過程，故稱其爲「瀑布模型」。

• 特色：
  • 階段間具備順序性和依賴性:
    • 前一階段完成後,才能開始後一階段
    • 前一階段的輸出文本爲後一階段的輸入文本
       - 推遲實現的觀點
       - 質量保證：
    • 每一個階段必須交付出合格的文檔
       - 對文檔進行審覈
• 缺點：
  開始須要把需求作到最全，害怕用戶測試中的反饋,害怕需求變動。

V模型

V模型是在瀑布模型的基礎上發展而來的。

RAD(Rap Application Development，快速應用開發)模型是軟件開發過程當中的一個重
要模型，因爲其模型構圖形似字母V，因此又稱軟件測試的 V模型。它經過開發和測試同時進行的方式來縮短開發週期，提升開發效率。

階段步驟

V模型大致能夠劃分爲如下幾個不一樣的階段步驟：需求分析、概要設計、詳細設計、軟件編碼、單元測試、集成測試、系統測試、驗收測試。

• 需求分析：
  首先要明確客戶須要的是什麼，須要軟件做成什麼樣子，須要有哪幾項功能，這一點上比較關鍵的是分析師和客戶溝通時的理解能力與交互性。要求分析師能準確地把客戶所須要達到的功能、實現方式等表述出來，給出分析結果，寫出需求規格說明書。
• 概要設計：
  主要是架構的實現，指搭建架構、表述各模塊功能、模塊接口鏈接和數據傳遞的實現等多項事務。
• 詳細設計：
  對概要設計中表述的各模塊進行深刻分析、對各模塊組合進行分析等，這一階段要求達到僞代碼級別，已經把程序的具體實現的功能、現象等表述出來。其中須要包含數據庫設計說明。
• 軟件編碼：
  按照詳細設計好的模塊功能表，編程人員編寫出實際的代碼。
• 單元測試：
  按照設定好的最小測試單元進行按單元測試，主要是測試程序代碼，爲的是確保各單元模塊被正確的編譯。
  單元的具體劃分，依據不一樣的單位、不一樣的軟件而有所不一樣，好比有具體到模塊的測試，也有具體到類、函數的測試等。
• 集成測試：
  通過了單元測試後，將各單元組合成完整的體系，主要測試各模塊間組合後的功能實現狀況，以及模塊接口鏈接的成功與否，數據傳遞的正確性等。
  其主要目的是檢查軟件單位之間的接口是否正確。
  根據集成測試計劃，一邊將模塊或其餘軟件單位組合成系統，一邊運行該系統，以分析所組成的系統是否正確，各組成部分是否合拍。
• 系統測試：
  通過了單元測試和集成測試之後，咱們要把軟件系統搭建起來，按照軟件規格說明書中所要求，測試軟件其性能、功能等是否和用戶需求相符合，在系統中運行是否存在漏洞，等。
• 驗收測試：
  主要就是用戶在拿到軟件的時候，在使用現場，會根據前邊所提到的需求，以及規格說明書來作相應測試，以肯定軟件達到符合效果的。

缺陷及解決思路

• 缺陷：
  V模型僅僅把測試過程做爲在需求分析、系統設計及編碼以後的一個階段，忽視了測試對需求分析,系統設計的驗證，需求的知足狀況一直到後期的驗收測試才被驗證。

• 解決思路：
  當一個軟件開發的時候，研發人員和測試人員須要同時工做，測試在軟件作需求分析的同時就會有測試用例的跟蹤，這樣，能夠儘快找出程序錯誤和需求偏離，從而更高效的提升程序質量，最大可能的減小成本，同時知足用戶的實際軟件需求。

適用範圍

V模式是一種傳統軟件開發模型，通常適用於一些傳統信息系統應用的開發；而一些高性能高風險的系統、互聯網軟件，或一個系統難以被具體模塊化的時候，就比較難作成V模式所需的各類構件，須要更強調迭代的開發模型或者敏捷開發模型。

W模型

W模型：由Evolutif公司提出，相對於V模型，W模型增長了軟件開發各階段中同步進行的驗證和確認活動。

如圖所示，由兩個V字型模型組成，分別表明測試與開發過程，圖中明確表示出了測試與開發的並行關係。

• 優勢：
  • 開發伴隨着整個開發週期，需求和設計一樣要測試；
    　 - 更早的介入測試，能夠發現初期的缺陷，修復成本低；
  • 分階段工做，方便項目總體管理。
• 缺點：
  • 開發和測試依然是線性的關係，需求的變動和調整，依然不方便；
  • 若是沒有文檔，根本沒法執行w模型；對於項目組成員的技術要求更高！

軟件生命週期

瀑布型生命週期

瀑布型生命週期包括可行性分析與開發項計劃、需求分析、設計（概要設計和詳細設計）、編碼、測試、維護等階段。

階段步驟

• 問題的定義及規劃：
  此階段是軟件開發方與需求方共同討論，主要肯定軟件的開發目標及其可行性。
• 需求分析：
  在肯定軟件開發可行的狀況下，對軟件須要實現的各個功能進行詳細分析。需求分析階段是一個很重要的階段，這一階段作得好，將爲整個軟件開發項目的成功打下良好的基礎。"惟一不變的是變化自己。"，一樣需求也是在整個軟件開發過程當中不斷變化和深刻的，所以咱們必須制定需求變動計劃來應付這種變化，以保護整個項目的順利進行。
• 軟件設計：
  此階段主要根據需求分析的結果，對整個軟件系統進行設計，如系統框架設計，數據庫設計等等。軟件設計通常分爲整體設計和詳細設計。好的軟件設計將爲軟件程序編寫打下良好的基礎。
• 程序編碼：
  此階段是將軟件設計的結果轉換成計算機可運行的程序代碼。在程序編碼中必需要制定統一，符合標準的編寫規範。以保證程序的可讀性，易維護性，提升程序的運行效率。
• 軟件測試：
  在軟件設計完成後要通過嚴密的測試，以發現軟件在整個設計過程當中存在的問題並加以糾正。整個測試過程分單元測試、組裝測試以及系統測試三個階段進行。測試的方法主要有白盒測試和黑盒測試兩種。在測試過程當中須要創建詳細的測試計劃並嚴格按照測試計劃進行測試，以減小測試的隨意性。
• 運行維護：
  軟件維護是軟件生命週期中持續時間最長的階段。在軟件開發完成並投入使用後，因爲多方面的緣由，軟件不能繼續適應用戶的要求。要延續軟件的使用壽命，就必須對軟件進行維護。軟件的維護包括糾錯性維護和改進性維護兩個方面。

高內聚低耦合

• 內聚：是從功能角度來度量模塊內的聯繫，一個好的內聚模塊應當剛好作一件事。它描述的是模塊內的功能聯繫；
• 耦合：是軟件結構中各模塊之間相互鏈接的一種度量，耦合強弱取決於模塊間接口的複雜程度、進入或訪問一個模塊的點以及經過接口的數據。
• 耦合性：也稱塊間聯繫。指軟件系統結構中各模塊間相互聯繫緊密程度的一種度量。模塊之間聯繫越緊密，其耦合性就越強，模塊的獨立性則越差。模塊間耦合高低取決於模塊間接口的複雜性、調用的方式及傳遞的信息。

• 內聚性：又稱塊內聯繫。指模塊的功能強度的度量，即一個模塊內部各個元素彼此結合的緊密程度的度量。若一個模塊內各元素（語名之間、程序段之間）聯繫的越緊密，則它的內聚性就越高。

• 所謂高內聚是指一個軟件模塊是由相關性很強的代碼組成，只負責一項任務，也就是常說的單一責任原則。

• 對於低耦合，粗淺的理解是：一個完整的系統，模塊與模塊之間，儘量的使其獨立存在。也就是說，讓每一個模塊，儘量的獨立完成某個特定的子功能。模塊與模塊之間的接口，儘可能的少而簡單。若是某兩個模塊間的關係比較複雜的話，最好首先考慮進一步的模塊劃分。這樣有利於修改和組合。

耦合

耦合能夠分爲如下幾種，它們之間的耦合度由高到低排列以下：

• 內容耦合：一個模塊直接訪問另外一模塊的內容，則稱這兩個模塊爲內容耦合。
  內容耦合可能在彙編語言中出現。大多數高級語言都已設計成不容許出現內容耦合。
  這種耦合的耦合性最強，模塊獨立性最弱。
• 公共耦合：一組模塊都訪問同一個全局數據結構，則稱之爲公共耦合。
  公共數據環境能夠是全局數據結構、共享的通訊區、內存的公共覆蓋區等。
  若是模塊只是向公共數據環境輸入數據，或是隻從公共數據環境取出數據，這屬於比較鬆散的公共耦合；
  若是模塊既向公共數據環境輸入數據又從公共數據環境取出數據，這屬於較緊密的公共耦合。
• 外部耦合：一組模塊都訪問同一全局簡單變量，並且不經過參數表傳遞該全局變量的信息，則稱之爲外部耦合。
• 控制耦合：模塊之間傳遞的不是數據信息，而是控制信息例如標誌、開關量等，一個模塊控制了另外一個模塊的功能。
• 標記耦合：調用模塊和被調用模塊之間傳遞數據結構，而不是簡單數據，同時也稱做特徵耦合。
  標記耦合的模塊間傳遞的不是簡單變量，而是像高級語言中的數據名、記錄名和文件名等數據結果，這些名字即爲標記，其實傳遞的是地址。
• 數據耦合：調用模塊和被調用模塊之間只傳遞簡單的數據項參數。至關於高級語言中的值傳遞。
• 非直接耦合：兩個模塊之間沒有直接關係，它們之間的聯繫徹底是經過主模塊的控制和調用來實現的。
  耦合度最弱，模塊獨立性最強。

總結：耦合是影響軟件複雜程度和設計質量的一個重要因素，爲提升模塊的獨立性，應創建模塊間儘量鬆散的系統，在設計上咱們應採用如下原則：若模塊間必須存在耦合，應儘可能使用數據耦合，少用控制耦合，慎用或有控制地使用公共耦合，並限制公共耦合的範圍，儘可能避免內容耦合。

內聚

內聚有以下的種類，它們之間的內聚度由弱到強排列以下：

• 偶然內聚：一個模塊內的各處理元素之間沒有任何聯繫，只是偶然地被湊到一塊兒。
  這種模塊也稱爲巧合內聚，內聚程度最低。
• 邏輯內聚：這種模塊把幾種相關的功能組合在一塊兒，每次被調用時，由傳送給模塊參數來肯定該模塊應完成哪種功能。
• 時間內聚：把須要同時執行的動做組合在一塊兒，造成的模塊稱爲時間內聚模塊。
• 過程內聚：構件或者操做的組合方式是，容許在調用前面的構件或操做以後，立刻調用後面的構件或操做，即 使二者之間沒有數據進行傳遞。
  簡單的說就是若是一個模塊內的處理元素是相關的，並且必須以特定次序執行，則稱爲過程內聚。
• 通訊內聚（信息內聚）：指模塊內全部處理元素都在同一個數據結構上操做或全部處理功能都經過公用數據而發生關聯（有時稱之爲信息內聚）。
  即 指模塊內各個組成部分都使用相同的數據數據或產生相同的數據結構。
• 順序內聚：一個模塊中各個處理元素和同一個功能密切相關，並且這些處理必須順序執行，一般前一個處理元素的輸出是後一個處理元素的輸入。
  例如，某模塊完成工業產值求值的功能，前一個功能元素求總產值，後一個功能元素求平均產值，顯然該模塊內兩部分緊密關聯。
  順序內聚的內聚度比較高，但缺點是不如功能內聚易於維護。
• 功能內聚：模塊內全部元素的各個組成部分所有都爲完成同一個功能而存在，共同完成一個單一的功能，模塊已不可再分。即 模塊僅包括爲完成某個功能所必須的全部成分，這些成分緊密聯繫、缺一不可。
  功能內聚是最強的內聚，其優勢是它的功能明確。判斷一個模塊是否功能內聚，通常從模塊名稱就能看出。
  若是模塊名稱只有一個動詞和一個特定的目標（單數名詞），通常來講就是功能內聚，如：「計算水費」、「計算產值」等模塊。功能內聚通常出如今軟件結構圖的較低層次上。
  功能內聚模塊的一個重要特色是：他是一個「暗盒」，對於該模塊的調用者來講，只須要知道這個模塊能作什麼，而不須要知道這個模塊是如何作的。

總結：在模塊劃分時，要遵循「一個模塊，一個功能」的原則，儘量使模塊達到功能內聚。

高內聚，低耦合的系統有什麼好處呢？ 事實上，短時間來看，並無很明顯的好處，甚至短時間內會影響系統的開發進度，由於高內聚，低耦合的系統對開發設計人員提出了更高的要求。 高內聚，低耦合的好處體如今系統持續發展的過程當中，高內聚，低耦合的系統具備更好的重用性，維護性，擴展性，能夠更高效的完成系統的維護開發，持續的支持業務的發展，而不會成爲業務發展的障礙。