第10章軟件架構的演化和維護

軟件架構周期：初始設計、實際使用、修改完善(這就是演化)、退化棄用。

演化和維護的目的：為了使軟件能夠適應環境的變化而進行的糾錯性修改和完善性修改等，而且這個過程是一個不斷迭代的過程。

架構演化的重要性、演化過程、演化分類、演化原則、演化評估(完成后也需要評估的)

10.1軟件架構演化和定義的關系

10.1.1演化的重要性

為了適應用戶的新需求、業務環境和運行環境的變化等，軟件架構需要不斷地進行自身的

演化，也就是說軟件架構的演化就是為了維持軟件架構自身的有用性。

演化是軟件整體結構的演化，涵蓋整個軟件架構的全生命周期，包含需求獲取、架構文檔、架構建模、實現、維護等等

演化的重要意義：

1.軟件架構作為軟件系統的骨架支撐著整個軟件系統，是軟件系統具備諸多好的特性的重要保障。

2.其次，軟件架構作為軟件藍圖為人們宏觀管控軟件系統的整體復雜性和變化性提供了一條

有效途徑，而且基于軟件架構進行的軟件檢測和修改成本相對較低，所以要刻畫復雜的軟件演

化，并對演化中的影響效應進行觀察和控制，從軟件架構演化出發更加合理。

3.軟件架構的演化可以更好地保證軟件演化的一致性和正確性，而且明顯降低軟件演化的成本，并且軟件架構演化使得軟件系統演化更加便捷

10.1.2演化和定義的關系

根據具體定義具體說明。

舉例：軟件架構定義為SA，組件(Components)、連接件(Connectors)和約束(Constraints)三大要素，這類軟件架構演化主要關注的就是組件、連接件和約束的添加、修改與刪除等。

10.2面向對象軟件架構演化過程

假設軟件架構對應到具體的架構風格或模式，以面向對象軟件架構為例。

10.2.1對象演化

順序圖中，組件的實體為對象。組件本身包含了眾多屬性，如接口、類型、語義等，這些屬性的演化是對象自身的演化，對于描述對象間的交互并無影響。因此，會對架構設計的動態行為產生影響的演化只有括AddObject(AO)和DeleteObject(DO)兩種。

10.2.2消息演化

消息是順序圖中的核心元素，包含了名稱、源對象、目標對象、時序等信息。

消息自身的屬性如接口、類型等變化不會影響到對象間交互，但是包含的信息發生變化將會影響與之交互的其他對象或消息，從而對架構正確性或時態屬性產生影響。

消息演化分類：AddMessage (AM)、DeleteMessage(DM)、SwapMessageOrder(SMO)、OverturnMessage(OM)、 ChangeMessageModule(CMM)5種。

objl和obj2分別為產生變化的兩個對象，用ml、m2來表示消息的一一對應關系。

AM增添一條新的消息，產生在對象之間需要增加新的交互行為的時候。DM刪除當前的一條消息，產生在需要移除某個交互行為的時候，是AM的逆向演化。SMO交換兩條消息的時間順序，發生在需要改變兩個交互行為之間關系的時候。OM反轉消息的發送對象與接收對象，發生在需要修改某個交互行為本身的時候。CMM改變消息的發送或接收對象，發生在需要修改某個交互行為本身的時候。

消息與約束關聯：

消息與約束直接相關，消息的演化會直接影響到對象之間的交互行為，但不一定會違背約束。

我們可以將這種演化分為3類。第1類演化與當前約束無關，如AddMessage在大多數情況下與當前的約束無關，這些演化不會對架構設計的正確性或時態屬性產生影響。
第2類演化與約束直接關聯但不會違背約束，如ChangeMessageModule后的消息不會違背“在某處產生”的約束，這些演化同樣不會對架構設計的正確性或時態屬性產生影響。
第3類演化與約束直接關聯并會違背約束，如DeleteMessage刪除的某條消息是某條約束的內容之一，這種演化后的架構違背了約束，其是不正確的演化。

消息是順序圖的核心內容，消息演化是順序圖演化的核心。對象的演化會伴隨著消息演化，否則沒有意義。

復合片段和約束均基于消息存在，二者的演化也直接受到消息演化的影響。因此，對其他演化進行分析研究的同時，也要對相關聯的消息演化進行分析。

10.2.3復合片段演化

復合片段是對象交互關系的控制流描述，表示可能發生在不同場合的交互，與消息同屬于連接件范疇。

復合片段本身的信息包括類型、成立條件和內部執行序列，其中內部執行序列的演化等價于消息序列演化。

復合片段的演化分為AddFragment(AF)、DeleteFragment(DF)、FragmentTypeChange(FTC)

和FragmentConditionChange(FCC)。

FCC改變復合片段內部執行的條件，發生在改變當前控制流的執行條件時。
AF在某幾條消息上新增復合片段，發生在需要增添新的控制流時。
DF刪除某個現有的復合片段，發生在需要移除當前某段控制流時。
FTC改變復合片段的類型，發生在需要改變某段控制流時。

復合片段的演化對應著對象之間交互流程的變化，因此會對架構設計的正確性及其他時態

屬性產生影響。需要驗證演化是否會違背約束。

10.2.4約束演化

順序圖中的約束信息以文字描述的方式存儲于對象或消息中，如通常可以用LTL來描述時態屬性約束。

約束演化即直接對約束信息進行添加和刪除。

AC(Add Constraint)直接添加新的約束信息，會對架構設計產生直接的影響，需要判斷當前設計是否滿足新添加的約束要求。
DC(Delete Constraint)直接移除某條約束信息，發生在去除某些不必要條件的時候，一般而言架構設計均會滿足演化后的約束。

10.3軟件架構演化方式的分類

沒有標準的演化分類，有三種較典型的分類：

(1)按照軟件架構的實現方式和實施粒度分類：

基于過程和函數的演化、面向對象的演化、基于組件的演化和基于架構的演化。

(2)按照研究方法將軟件架構演化方式分為4類(Jeffrey M.Barnes等人的分類方法):

第1類是對演化的支持，如代碼模塊化的準則、可維護性的指示(如內聚和耦合)、代碼重構等； ?

第2類是版本和工程的管理工具，如CVS和COCOMO;

第3類是架構變換的形式方法，包括系統結構和行為變換的模型，以及架構演化的重現風格等；

第4類是架構演化的成本收益分析，決定如何增加系統的彈性。

(3)針對軟件架構的演化過程是否處于系統運行時期

可以將軟件架構演化分為靜態演化(Static Evolution)和動態演化(Dynamic Evolution),前者發生在軟件架構的設計、實現和維護過程中，軟件系統還未運行或者處在運行停止狀態；后者發生在軟件系統運行過程中。

重點介紹靜態演化和動態演化。

10.3.1軟件架構演化時期

1.設計時演化

設計時演化(Design-Time Evolution)是指發生在體系結構模型和與之相關的代碼編譯之前

的軟件架構演化。

2.運行前演化

運行前演化(Pre-Execution Evolution)是指發生在執行之前、編譯之后的軟件架構演化，這時由于應用程序并未執行，修改時可以不考慮應用程序的狀態，但需要考慮系統的體系結構，且系統需要具有添加和刪除組件的機制。

3.有限制運行時演化

有限制運行時演化(Constrained Runtime Evolution)是指系統在設計時就規定了演化的具體條件，將系統置于“安全”模式下，演化只發生在某些特定約束滿足時，可以進行一些規定好的演化操作。

4.運行時演化

運行時演化(Runtime Evolution)是指系統的體系結構在運行時不能滿足要求時發生的軟件架構演化，包括添加組件、刪除組件、升級替換組件、改變體系結構的拓撲結構等。此時的演化是最難實現的。

10.3.2軟件架構靜態演化

1.靜態演化需求

靜態演化廣泛存在，主要2個方面：

(1)設計時演化需求。在架構開發和實現過程中對原有架構進行調整，保證軟件實現與架

構的一致性以及軟件開發過程的順利進行。

(2)運行前演化需求。軟件發布之后由于運行環境的變化，需要對軟件進行修改升級，在

此期間軟件的架構同樣要進行演化。

架構靜態演化和適應該靜態演化的應用實例——正交軟件架構，以及軟件開發過程中的架構靜態演化。

2.靜態演化的一般過程

靜態就是系統停止運行期間的修改和更新，一般意義上的軟件修復和升級。

三類維護方法：更正性維護、適應性維護、完善性維護。

靜態演化5步驟：

軟件理解：查閱文檔、分析架構、識別系統組成及元素間相互關系，提取系統的抽象表示形式。
需求變更分析：靜態演化往往是由于用戶需求變化、系統運行出錯和運行環境發生改變等原因所引起的，需要找出新的軟件需求與原有的差異。
演化計劃：分析原系統，確定演化范圍和成本，選擇合適的演化計劃。
系統重構：根據演化計劃對系統進行重構，使之適應當前的需求。
系統測試：對演化后的系統進行測試，查找其中的錯誤和不足之處。

軟件功能的變更和環境變化帶來元素的增刪改替換拆分操作，需要對這些操作對其他組件和系統本身帶來的影響進行分析。通過對組件間的影響關系進行建模，按照可達矩陣的方式即可計算出每種組件變更操作所影響的范圍。

3.靜態演化的原子演化操作

一次完整的架構演化可看作一系列的原子演化操作組合而成。啥叫原子演化操作？基于UML模型標識的軟件架構，在邏輯語義上粒度最小的架構修改操作。

原子演化操作理解：并非是物理上不可分割，模塊的增加認為是原子粒度。架構每經過一次原子演化操作，架構會產生一個中間版本Ai，對于不同的質量屬性度量和評估，影響該質量屬性變化的原子演化操作類型不同，形成軟件架構的中間版本序列A0,Al,A2,…,An也不同。

例如，假設我們需要度量軟件架構的可維護性和可靠性，就應該討論影響可維護性和可靠性的度量結果的各種原子演化操作。

1)與可維護性相關的架構演化操作

架構演化的可維護性度量基于組件圖表示的軟件架構，在較高層次上評估架構的某個原子修改操作對整個架構所產生的影響

?AMD/RMD:模塊間的依賴關系體現了模塊邏輯組織結構和控制關系，包含模塊對其他模塊的直接依賴和間接依賴，對模塊依賴關系的修改改變了模塊的控制關系以及邏輯響應，從整體上影響了架構的組織結構，可能導致架構的外部質量屬性發生變化。

?AM/RMI:模塊間的接口表示模塊間的調用方式，模塊通過接口直接提供相應可執行功能，對接口的修改可直接改變模塊間的調用關系和調用方式，并可能導致具體的執行事件的順序和方式發生更改。
?AMRM:在架構中，模塊封裝了一系列邏輯耦合度高或部署緊密的子模塊，用來表達完整的功能。模塊的增加、刪除不僅僅表示軟件功能的更改，該模塊與其他模塊的耦合方式可能使得架構整體組織結構的變化，從而引入AMD和RMD操作。過多的耦合會造成修改影響范圍增大，不利于軟件的維護以及持續演化。另外模塊本身內部設計的正確性、合理性等問題將會影響軟件潛在風險。
SM/AGM:拆分和聚合模塊通常發生在軟件調整過程中，對模塊的拆分和聚合可直接影響軟件的內聚度和耦合度，從而影響軟件整體復雜性。

2)與可靠性相關的架構演化操作

架構演化的可靠性評估基于用例圖、部署圖和順序圖，分析在架構模塊的交互過程中某個原子演化操作對交互場景的可靠程度的影響

AMS/RMS:模塊間的消息交互體現在UML順序圖中。消息變化包含增加消息、刪除消息和修改消息。消息的修改可能為順序更改、交互對象更改等，該變化可通過刪除原消息和增加新的消息等操作組合而成，因而這里只討論原子粒度的增加消息和刪除消息兩種操作。消息的刪減導致交互過程中時序復雜度的變化，可能引入運行時風險。

AO/RO:在順序圖中增加或刪除交互對象將引入AMS/DMS操作，即與該對象相關的消息將同時被增加或刪除，同時，在部署圖中還須將該模塊添加到相關站點或從相關站點刪除該模塊。由于一個執行場景的可靠性直接取決于組件和連接件的可靠性，交互對象的增減將直接影響一個或多個包含該模塊的場景的交互復雜性。
AF/RF/CF:消息片段為順序圖中一組交互消息的循環調用，消息片段的增加、刪除或者調用次數的修改將影響交互過程的復雜度，從而影響該場景的執行風險。
AU/RU:為參與者增加或刪除可執行用例，表示參與者執行權限的變化，一般來說可執行用例越多的參與者其權限越高。用戶在運行系統時以某一參與者的身份執行用例，由于其參與的執行事件的增加或者事件執行方式的多樣化，將導致系統運行更為復雜，運行時風險增加。
AA/RA:增加或刪除某一參與者意味著執行權限的增加或減少，該操作將引入AU/RU操作。參與者的增減雖然不會導致軟件結構上的變化，然而不同的參與者有不同的執行方式，因而會導致系統動態交互上的變化，對程序運行時的風險有影響。

4.靜態演化實例：正交軟件架構(Orthogonal Software Architecture)

通過對功能進行分層和線索化，可以形成正交體系結構，同一層次中的組件不允許相互調用，故每個變動僅影響一條線索，如圖10-5所示。

正交體系的演化過程概括如下：

①需求變動歸類，使需求的變化和現有組件及線索相對應，判斷重用情況；

②制訂架構演化計劃；

③修改、增加或刪除組件；

④更新組件之間的相互作用；

⑤產生演化后的軟件架構，作為系統更新的詳細設計方案和實現基礎。

10.3.3軟件架構動態演化

動態演化是在系統運行期間的演化，需要在不停止系統功能的情況下完成演化，較之靜態演化更加困難。具體發生在有限制的運行時演化和運行時演化階段。

一些長期運行，不能停機或者停機代價太高的系統，為適應系統需求變化或環境變化，因靜態體系結構缺乏表示動態更新的機制，很難用其分析、描述這樣的系統，更不能用它來指導系統進行動態演化，所以動態演化架構誕生。

1.動態演化的需求

架構的動態演化主來2類需求：

1).軟件內部執行所導致的體系結構的改變。如許多服務器端軟件會在客戶請求到達時創建新的組件來響應用戶需求。

2).軟件系統外部的請求對軟件進行的重配置。如OS升級無需重啟。

2.動態演化的類型

1)軟件動態性的等級

交互動態性(Interactive Dynamism),要求數據在固定的結構下動態交互；
結構動態性(Structural Dynamism),允許對結構進行修改，通常的形式是組件和連接件實例的添加和刪除，這種動態性是研究和應用的主流；
架構動態性(Architectural Dynamism),允許軟件架構的基本構造的變動，即結構可以被重定義，如新的組件類型的定義。

目前多在1、2級別，3很少。

2)動態演化的內容 (根據所修改的內容)??

●屬性改名：目前所有的ADL都支持對非功能屬性的分析和規約，而在運行過程中，用戶可能會對這些指標進行重新定義(如服務響應時間)。

●行為變化：在運行過程中，用戶需求變化或系統自身服務質量的調節都將引發軟件行為的變化。諸如，為了提高安全級別而更換加密算法；將HTTP協議改為HTTPS協議；組件和連接件的替換和重新配置。

●拓撲結構改變：如增刪組件，增刪連接件，改變組件與連接件之間的關聯關系等。

●風格變化：一般軟件演化后其架構風格應當保持不變，如果非要改變軟件的架構風格，也只能將 架構風格變為其衍生風格，如將兩層C/S結構調整為三層C/S結構或C/S與B/S的混合結構，將“1對1”的請求響應結構改為“1對N”的請求響應結構，以實現負載的平衡。

實現軟件架構動態演化的技術主要有兩種：

采用動態軟件架構(Dynamic Soffware Architecture,DSA)：DSA是指在運行時刻會發生變化的系統框架結構，允許在運行過程中通過框架結構的動態演化實現對架構的修改。

進行動態重配置(Dynamic? Reconfiguration,DR)：DR從組件和連接件的配置入手，允許在運行過程中增刪組件，增刪連接件，修改連接關系等操作。

我們將DSA歸結為架構動態性，將DR歸結為結構動態性。

3.動態軟件架構

軟件架構的3個方向：軟件架構風格、軟件架構連接件、DSA。

DSA定義：可修改自身的架構，并在系統執行期間進行修改。

DSA意義：減少系統開發的費用和風險；增強用戶自定義性和可擴展性，并可為用戶提供更新系統屬性的服務。

1)基于DSA實現動態演化的基本原理

基本原理：

使DSA在可運行應用系統中以一類有狀態、有行為、可操作的實體顯式地表示出來，并且被整個運行環境共享，作為整個系統運行的依據。也就是說，運行時刻體系結構相關信息的改變可用來觸發、驅動系統自身的動態調整。此外，對系統自身所做的動態調整結果可反映在體系結構這一抽象層面上。

為動態演化提供相關功能：

①須提供保存當前軟件架構信息(拓撲結構、組件狀態和數目等)的功能；

②實施動態演化還須設置一個監控管理機制，對系統有無需求變化進行監視。當發現有需求變化時，應能分析并判斷可否實施演化，以及何時演化和演化范圍，并最終分析或生成演化策略。

③還應保證演化操作原子性，即在動態變化過程中，如果其中之一的操作失敗了，整個操作集都要被撤銷，從而避免系統出現不穩定的狀態。

DSA實施動態演化大體遵循以下4步：

①捕捉并分析需求變化；

②獲取或生成體系結構演化策略；

③根據步驟2得到的演化策略，選擇適當的演化策略并實施演化；

④演化后的評估與檢測。

完成這4個步驟還需要DSA描述語言和演化工具的支持。

2)DSA描述語言

①基于行為視角的π-ADL,使用進程代數來描述具有動態性的行為；

②基于反射視角的Pilar,利用反射理論顯式地為元信息建立模型；

③基于協調視角的LIME,注重計算和協調部分的分離，利用協調論的原理來解決動態性交互。

3)DSA演化工具

動態演化的工具需要支持系統在演化過程中與其軟件架構的一致性檢查，并能夠對架構演

化過程進行管理。

使用反射機制：K-Component框架元模型，

基于組件操作：SACDRE。

基于π演算：SAAM

利用外部的體系結構演化管理器；Argo

4.動態軟件架構應用實例——PKUAS

5.動態重配置

基于軟件動態重配置的軟件架構動態演化主要是指在軟件部署之后對配置信息的修改，常常被用于系統動態升級時需要進行的配置信息修改。一般來說，動態重配置可能涉及的修改有：

①簡單任務的相關實現修改；

②工作流實例任務的添加和刪除；

③組合任務流程中的個體修改；

④任務輸入來源的添加和刪除；

⑤任務輸入來源的優先級修改；

⑥組合任務輸出目標的添加和刪除；

⑦組合任務輸出目標的優先級修改等。

1)動態重配置模式

4種重配置模式：

(1)主從(Master-Slave)模式：

在主從模式中，主組件接收客戶端的服務請求，它將工作劃分給從組件，然后合并、解釋、總結或整理從組件的響應。當主組件沒有對從組件分配工作時，從組件處于空閑(Idle)狀態，并會在新的任務分配時被重新激活。主從模式由主操作重配置狀態圖描述，其中包含兩個正交的圖，即主操作狀態圖和主重配置狀態圖，主操作狀態圖定義了主組件的操作狀態，主重配置狀態圖描述了主組件如何安排重配置的過程。

(2)中央控制(Centralized Control)模式：

中央控制模式廣泛應用于實時系統之中。在該模式中，一個中央控制器會控制多個組件，其狀態圖會維持兩個狀態，分別標識中央控制器是否處于空閑狀態。

(3)客戶端/服務器(Client/Server)模式：

客戶端/服務器模式中的客戶端組件需要服務器組件所提供的服務，二者通過同步消息進行交互，在客戶端/服務器重配置模式中，當客戶端發起的事務完成之后可以添加或刪除客戶端組件；當順序服務器(Sequential Server)完成了當前的事務，或者并發服務器(Concurrent Server)完成了當前事務的集合，且將新的事務在服務器消息緩沖中排隊完畢之后，可以添加或刪除服務器組件。

(4)分布式控制(Decentralized Control)模式

分布式控制模式下系統的功能整合在多個分布式控制組件之中。該模式廣泛用于分布式應用之中，且有著多種相似的類型，如環形(Ring)模式和順序(Serial)模式。環形模式中每個組件有著相同的功能，且在其左右均有一個組件(稱為前驅和后繼)與之交互；順序模式中每個組件使用相同的連接與自己的前驅和后繼交互，每個組件向自己的前驅發送請求并獲得響應。

2)例子：可重用、可配置的產品線架構

3)動態重配置的難點

Tamura等人提出了在帶有服務質量(Quality of Service,QoS)約束的情況下，基于擴展圖進

行架構重配置的方法。針對此類重配置說明了動態重配置的4個難點：

①約束定義困難；

②性能約束難以靜態衡量，需要在軟件運行時進行評估；

③某些重配置方案能夠解決性能約束的某一方面，但是難以管理所有方面；?

④重配置需要同時保證兩個方面，即維持組件系統的完整性和重配置策略的正確和安全性。

10.4軟件架構演化原則

1.演化成本控制原則Evolution Cost Control,ECC

●原則解釋：演化成本要控制在預期的范圍之內，也就是演化成本要明顯小于重新開發成本。

●原則用途：用于判斷架構演化的成本是否在可控范圍內，以及用戶是否可接受。

●度量方案：CoE<<CoRD。

●方案說明：CoE為演化成本，CoRD為重新開發成本，CoE遠小于CoRD最佳。

2.進度可控原則Schedule Control

●原則解釋：架構演化要在預期時間內完成，也就是時間成本可控。

●原則用途：根據該原則可以規劃每個演化過程的任務量；體現一種迭代、遞增(持續演化)的演化思想。

●度量方案：ttask=|Ttask-Ttask|。

●方案說明：某個演化任務的實際完成時間(Ttask)和預期完成時間(T'task)的時間差，時間差ttask越小越好。

3.風險可控原則Risk Control

●原則解釋：架構演化過程中的經濟風險、時間風險、人力風險、技術風險和環境風險等必須在可控范圍內。

●原則用途：用于判斷架構演化過程中各種風險是否易于控制。

●度量方案：分別檢驗。

●方案說明：時間風險、經濟風險、人力風險、技術風險都不存在。

4.主體維持原則

●原則解釋：對稱穩定增長(the Average Incremental Growth,AIG)原則所有其他因素必須與軟件演化協調，開發人員、銷售人員、用戶必須熟悉軟件演化的內容，從而達到令人滿意的演化。因此，軟件演化的平均增量的增長須保持平穩，保證軟件系統主體行為穩定。

●原則用途：用于判斷架構演化是否導致系統主體行為不穩定。

●度量方案：計算AIG即可，AIG=主體規模的變更量/主體的規模。

●方案說明：根據度量動態變更信息(類型、總量、范圍)來計算。

5.系統總體結構優化原則Optimization of Whole Structure

●原則解釋：架構演化要遵循系統總體結構優化原則，使得演化之后的軟件系統整體結構(布局)更加合理。

●原則用途：用于判斷系統整體結構是否合理，是否最優。

●度量方案：檢查系統的整體可靠性和性能指標。

●方案說明：判斷整體結構優劣的主要指標是系統的可靠性和性能。

6.平滑演化原則Invariant Work Rate,IWR

●原則解釋：在軟件系統的生命周期里，軟件的演化速率趨于穩定，如相鄰版本的更新率相對固定。

●原則用途：用于判斷是否存在劇烈架構演化。

●度量方案：計算IWR即可，IWR=變更總量/項目規模。

●方案說明：根據度量動態變更信息(類型、總量、范圍等)來計算。

7.目標一致原則Objective Conformance

●原則解釋：架構演化的階段目標和最終目標要一致。

●原則用途：用于判斷每個演化過程是否達到階段目標，所有演化過程結束是否能達到最終目標。

●度量方案：otask=|Otask-O'task|。

●方案說明：階段目標的實際達成情況(Otask)和預期目標(O'task)的差，Otask越小越好。

8.模塊獨立演化原則/修改局部化原則(Local Change)

●原則解釋：軟件中各模塊(相同制品的模塊，如Java的某個類或包)自身的演化最好相互獨立，或者至少保證對其他模塊的影響比較小或影響范圍比較小。

●原則用途：用于判斷每個模塊自身的演化是否相互獨立。

●度量方案：檢查模塊的修改是否是局部的。

●方案說明：可以通過計算修改的影響范圍來進行度量。

9.影響可控原則Impact Limitation

●原則解釋：軟件中一個模塊如果發生變更，其給其他模塊帶來的影響要在可控范圍內，也就是影響范圍可預測。

●原則用途：用于判斷是否存在對某個模塊的修改導致大量其他修改的情況。

●度量方案：檢查影響的范圍是否可控。

●方案說明：可以通過計算修改的影響范圍來進行度量。

10.復雜性可控原則Complexity Controllability

●原則解釋：架構演化必須要控制架構的復雜性，從而進一步保障軟件的復雜性在可控范圍內。

●原則用途：用于判斷演化之后的架構是否易維護、易擴展、易分析、易測試等。

●度量方案：CC<某個閾值；方案說明：CC增長可控。

11.有利于重構原則Useful for Refactoring

●原則解釋：架構演化要遵循有利于重構原則，使得演化之后的軟件架構更便于重構。

●原則用途：用于判斷架構易重構性是否得到提高。

●度量方案：檢查系統的復雜度指標。

●方案說明：系統越復雜越不容易重構。

12.有利于重用原則Useful for Reuse

●原則解釋：架構演化最好能維持，甚至提高整體架構的可重用性。

●原則用途：用于判斷整體架構可重用性是否遭到破壞。

●度量方案：檢查模塊自身的內聚度、模塊之間的耦合度。

●方案說明：模塊的內聚度越高，該模塊與其他模塊之間的耦合度越低，越容易重用。

13.設計原則遵從性原則Design Principles Conformance

●原則解釋：架構演化最好不能與架構設計原則沖突。

●原則用途：用于判斷架構設計原則是否遭到破壞(架構設計原則是好的設計經驗總結，要保障其得到充分使用)。

●度量方案：RCP=|CDP//DP]。

●方案說明：沖突的設計原則集合(CDP)和總的設計原則集合(DP)的比較，RCP越小越好。

14.適應新技術原則Technology Independence,TI

●原則解釋：軟件要獨立于特定的技術手段，這樣才能夠讓軟件運行于不同平臺。

●原則用途：用于判斷架構演化是否存在對某種技術依賴過強的情況。

●度量方案：TI=1-DDT,其中DDT=1依賴的技術集合/用到的技術合集]。

●方案說明：根據演化系統對關鍵技術的依賴程度進行度量。

15.環境適應性原則Platform Adaptability

●原則解釋：架構演化后的軟件版本能夠比較容易適應新的硬件環境與軟件環境。

●原則用途：用于判斷架構在不同環境下是否仍然可使用，或者容易進行環境配置。

●度量方案：硬件/軟件兼容性。

●方案說明：結合軟件質量中兼容性指標進行度量。

16.標準依從性原則Standard Conformance

●原則解釋：架構演化不會違背相關質量標準(國際標準、國家標準、行業標準、企業標準等)。

●原則用途：用于判斷架構演化是否具有規范性，是否有章可循；而不是胡亂或隨意地演化。

●度量方案：需要人工判定。

17.質量向好原則Quality Improvement,QI

●原則解釋：通過演化使得所關注的某個質量指標或某些質量指標的綜合效果變得更好或者更滿意，例如可靠性提高了。

●原則用途：用于判斷架構演化是否導致某些質量指標變得很差。

●度量方案：EQI≥Q。

●方案說明：演化之后的質量(EQI)比原來的質量(SQ)要好。

18.適應新需求原則New Requirement Adaptability

●原則解釋：架構演化要很容易適應新的需求變更；架構演化不能降低原有架構適應新需求的能力；架構演化最好可以提高適應新需求的能力。

●原則用途：用于判斷演化之后的架構是否降低了架構適應新需求的能力。

●度量方案：RNR=IANR/NR|。

●方案說明：適應的新需求集合(ANR)和實際新需求集合(NR)的比較，RNR越小越好。

10.5軟件架構演化評估方法

根據演化過程是否已知可將評估過程分為：演化過程已知的評估和演化過程未知的評估。

10.5.1演化過程已知的評估

評估其目的：通過對架構演化過程進行度量，比較架構內部結構上的差異以及由此導致的外部質量屬性上的變化，對該演化過程中相關質量屬性進行評估。

1.評估流程

基本思路：是將架構度量應用到演化過程中，通過對演化前后的不同版本的架構分別進行度量，得到度量結果的差值及其變化趨勢，并計算架構間質量屬性距離，進而對相關質量屬性進行評估。

2.架構演化中間版本度量

3.架構質量屬性距離

4.架構演化評估

基于度量的架構演化評估方法，其基本思路在于通過對演化前后的軟件架構進行度量，比較架構內部結構上的差異以及由此導致的外部質量屬性上的變化。基于度量的架構演化評估，可以幫助我們分析架構內部結構的修改對外部質量屬性所產生的影響、監控演化過程中架構質量的變化、歸納架構演化趨勢，并有助于開發和維護等相關工作開展，具體包括如下幾個方面：

①架構修改影響分析：為了更好地歸納和說明架構演化的相關規律，本節對演化進行分類，比較不同類型的演化操作對架構相關質量屬性的影響。通過將演化過程拆分成粒度很細的原子演化操作序列，具體分析架構內部邏輯結構和交互過程的修改會對哪些相關外部質量屬性產生影響，并分析修改影響范圍，進一步分析架構版本距離和相關質量屬性距離的關聯。

②監控演化過程：通過對架構演化過程中的中間版本架構進行度量，我們可以得到架構相關質量屬性隨時間推移的變化曲線。通過對架構演化過程中質量屬性的監控，將有利于保持架構健康持續地演化。

③分析關鍵演化過程：架構質量屬性距離評估不同版本的架構在質量屬性上的差異。從質量屬性距離形成的曲線可以觀察到架構質量發生較大改變的時刻，在該時刻架構的邏輯依賴或交互過程可能發生重大改變，在開發和維護過程中應該予以重視，這將有利于架構維護及故障定位等。

10.5.2演化過程未知的評估

根據架構演化前后的度量結果逆向推測出架構發生架構度量架構度量了哪些改變，并分析這些改變與架構相關質量屬性的關聯關系。

10.6大型網站系統架構演化實例

10.6.1第一階段：單體架構

10.6.2第二階段：垂直架構

10.6.3第三階段：使用緩存改善網站性能

網站使用的緩存可以分為兩種：緩存在應用服務器上的本地緩存和緩存在專門的分布式緩存服

務器上的遠程緩存。

●本地緩存的訪問速度更快一些，但是受應用服務器內存限制，其緩存數據量有限，而且會出現和應用程序爭用內存的情況。

●遠程分布式緩存可以使用集群的方式，部署大內存的服務器作為專門的緩存服務器，可以在理論上做到不受內存容量限制的緩存服務。

10.6.4第四階段：使用服務集群改善網站并發處理能力

應用服務器實現集群是網站可伸縮架構設計中較為簡單成熟的一種。

通過負載均衡調度服務器，可以將來自用戶瀏覽器的訪問請求分發到應用服務器集群中的任何一臺服務器上，如果有更多用戶，就在集群中加入更多的應用服務器，使應用服務器的壓力不再成為整個網站的瓶頸。

10.6.5第五階段：數據庫讀寫分離

10.6.6第六階段：使用反向代理和CDN加速網站響應

● CDN部署在網絡提供商的機房，使用戶在請求網站服務時，可以從距離自己最近的網絡提供商機房獲取數據。

●反向代理則部署在網站的中心機房，當用戶請求到達中心機房后，首先訪問的服務器是反向代理服務器，如果反向代理服務器中緩存著用戶請求的資源，就將其直接返回給用戶。

10.6.7第七階段：使用分布式文件系統和分布式數據庫系統

任何強大的單一服務器都滿足不了大型網站持續增長的業務需求。數據庫經過讀寫分離后，從一臺服務器拆分成兩臺服務器，但是隨著網站業務的發展依然不能滿足需求，這時需要使用分布式數據庫。文件系統也一樣，需要使用分布式文件系統。分布式數據庫是網站數據庫拆分的最后手段，只有在單表數據規模非常龐大的時候才使用。不到不得已時，網站更常用的數據庫拆分手段是業務分庫，將不同業務的數據部署在不同的物理服務器上。

10.6.8第八階段：使用NoSQL和搜索引擎

隨著網站業務越來越復雜，對數據存儲和檢索的需求也越來越復雜，網站需要采用一些非關系數據庫技術如NoSQL和非數據庫查詢技術如搜索引擎。NoSQL和搜索引擎都是源自互聯網的技術手段，對可伸縮的分布式特性具有更好的支持。應用服務器則通過一個統一數據訪問模塊訪問各種數據，減輕應用程序管理諸多數據源的麻煩。