模式與軟件架構——軟件架構的非功能特徵

軟件的非功能特徵對軟件系統的開發和維護工做、整體可操做性以及消耗的計算機資源有重大的影響。除開影響應用程序的質量和架構外，非功能性特徵還會影響系統的功能特性。軟件系統的規模越大，複雜度越高、生命週期越長、非功能特徵就越重要。

軟件架構的非功能特徵

軟件架構非功能特徵

• 可修改性
• 互操做性
• 效率
• 可靠性
• 可測試性
• 可重用性

1.可修改性

大型的工業和商業軟件系統的壽命週期一般都是很長的，有時候會長達20年甚至更長。不少這類應用程序在開發結束後都不是固定不變的，而在其整個生命週期內不斷演化。原來的需求又會變化，還會出現新的需求。爲了下降維護成本和修改工做量，應用程序的軟件必須爲修改和演化作好準備。

軟件老化的緣由

• 一成不變 (lack of mevement):軟件不更新，必然老化
• 盲動(ignorant surgery):修改軟件的人對最初的設計不瞭解，軟件架構逐漸被破壞
• 軟件一開始就缺少靈活性
• 文檔不充分，隨着時間的推移，對系統的認識愈來愈不清晰

軟件老化的後果

• 愈來愈難以經過引入新功能來跟上市場的步伐
• 性能愈來愈低
• 可靠性愈來愈差

解決方法

• 提供準確的文檔
• 修改時保留原來的結構
• 認真審覈
• 軟件最初設計就應該爲修改作好準備

可修改性包含內容

可維護性

主要是指修復問題，即出現錯誤後對軟件系統的 「修理」 。若是軟件架構爲維護作好了充分的準備，那麼這一般只須要作局部的修改，而且能夠最大限度下降修改給其餘組件帶來的反作用。

可擴展性

主要指給軟件系統添加新功能，將組件替換爲改進後的版本以及刪除多餘或沒必要要的功能和組件。爲提升可擴展性，軟件系統的組件必須鬆耦合。從而打造出讓你更換組件是不會影響其客戶端的架構，並支持在既有架構中添加新組件

重組

從新組織軟件系統的組件以及他們之間的關係，好比調整組件的位置，將其移動到另外一個子系統中，爲支持軟件系統重組，必須仔細設計組件之間的關係。理想狀況下，應該能靈活配置組件，而不影響其餘實現的主要部分

可移植性

指對軟件系統進行修改，使其支持各類硬件平臺、用戶界面、操做系統、編程語言或編譯器、爲提供可移植性，須要這樣組織軟件系統：找出依賴於硬件、其餘軟件系統和環境的部分，將其放在系統庫和永恆界面庫等特殊的組件中。

2.互操做性

系統中的軟件並不是獨立，常常須要與其餘系統或環境交互。爲了提升互操做性，設計軟件架構時，對那些外部可見的功能和數據結構，必須提供明確的訪問途徑。
互操做性的另外一方面是程序與使用其餘編程語言編寫的軟件系統的交互。

3.效率

效率與執行軟件是使用的資源及其對響應速度、吞吐量和存儲空間消耗的影響相關。
要提升應用程序的效率，不能光靠使用精巧的算法，在組件之間合理的分配職責以及組件之間的耦合度也是很重要的。
在分佈式軟件系統中，效率也扮演者重要的角色，分佈式應用程序底層的IPC（進程間通訊）必須足夠快，可以以足夠高的速度傳輸消息和數據，諸如Forwarder-Reciever 等模式致力於解決效率問題，然而，不少模式都爲解決問題增長了間接程度，這可能下降而不是提升效率

4.可靠性

可靠性是指，不管應用程序或系統發生錯誤仍是用戶以意外或錯誤的方式使用，軟件系統都能繼續運行。通常能夠將可靠性分爲兩個方面。

• 容錯： 其目標是在發生錯誤時確保行爲正確並自行修復，如分佈式軟件系統在到遠程組件的鏈接斷開時從新創建鏈接，修復這種錯誤後，軟件系統可繼續或從新執行錯誤發生時正在執行的操做。
• 健壯性：指的是對應用程序進行保護，以抵禦錯誤的使用方式和無效輸入，確保他在發生意外錯誤時處於指定的狀態。請注意，不一樣於容錯，健壯性並不必定意味着軟件可以自發成錯誤時繼續運行，也可能只保證軟件以指定的方式終止便可。

軟件架構對軟件系統的可靠性影響重大，爲提升可靠性，軟件架構可採起的方式包括

• 有意在應用程序中添加冗餘
• 集成監視組件或錯誤處理

5.可測試性

軟件系統的規模日益增大而且愈來愈複雜，工業軟件尤其如此，這致使測試更困難，更昂貴。
要簡化軟件系統正確性的評估工做，有賴於架構的支持，支持可測試性的軟件架構有助於發現並修復錯誤，臨時集成調試代碼和調試組件也更容易。

6.可重用性

可重用性是當前軟件工程討論最多的主題之一，它有望縮減軟件系統的開發時間和成本，還能夠改善軟件質量，可重用性主要包括兩個方面： 經過重用開發軟件以及開發時考慮重用。

• 經過重用開發軟件： 這意味着重用既有項目或商業庫的組件和成果、設計分析、設計規範或代碼組件。
• 開發軟件時考慮重用： 開發軟件時專一於生成在將來的項目中可重用的組件，這要求當前開發的應用程序採用的軟件架構容許哥哥部分彼此獨立，這樣無需作重大的修改就能在其餘系統使用它們

結束語

非功能特徵可能既相互矛盾有互爲補充。例如，提供重複的應用程序功能以支持容錯時，與未提供這種冗餘的結構相比，最終的結構既低效又昂貴。肯定軟件架構的非功能需求顯然須要考慮不一樣非功能需求之間的相互依賴關係，並做出必要的取捨，同時還須要肯定不一樣非功能需求的優先順序，在發生衝突時優先考慮一種需求，而捨棄另外一種需求。雖然對於軟件架構來講，非功能特徵相當重要，可是在多大程度上具有這些特徵卻難以度量，在軟件架構必須知足的詳細指標中，只包含爲數很少的幾個非功能特徵，所以，估算軟件架構在多大程度上具有給定的非功能特徵主要依賴於軟件工程師的經驗。