285.軟件體系結構評估概述

7.1.1 評估關注的質量屬性
　　軟件體系結構的設計是整個軟件開發過程當中關鍵的一步。對於當今世界上龐大而複雜的系統來講，若是沒有一個合適的體系結構而要有一個成功的軟件設計幾乎是不可想象的。
　　不一樣類型的系統須要不一樣的體系結構，甚至一個系統的不一樣子系統也須要不一樣的體系結構。體系結構的選擇是一個軟件系統設計成敗的關鍵。可是，怎樣才能知道爲軟件系統所選用的體系結構是否恰當？如何確保按照所選用的體系結構能順利地開發出成功的軟件產品呢？要回答這些問題，須要使用專門的方法對軟件體系結構進行分析和評估。
　　體系結構評估能夠只針對一個體繫結構，也能夠針對一組體系結構。在體系結構評估過程當中，評估人員所關注的是系統的質量屬性，全部評估方法所廣泛關注的質量屬性有如下幾個。
　　1．性能
　　性能是指系統的響應能力，即要通過多長時間才能對某個事件做出響應，或者在某段時間內系統所能處理的事件的個數。常常用單位時間內所處理事務的數量或系統完成某個事務處理所需的時間來對性能進行定量的表示。性能測試常常要使用基準測試程序(用以測量性能指標的特定事務集或工做量環境)。
　　2．可靠性
　　可靠性是軟件系統在應用或系統錯誤面前、在乎外或錯誤使用的狀況下維持軟件系統的功能特性的基本能力。可靠性是最重要的軟件特性，一般用它衡量在規定的條件和時間內，軟件完成規定功能的能力。可靠性一般用平均失效等待時間(Mean Time To Failure，MTTF)(指軟件在失效前正常工做的平均統計時間 )和平均失效間隔時間(Mean Time Between Failure，MTBF)來衡量。在失效率爲常數和修復時間很短的狀況下，MTTF和MTBF幾乎相等。MTBF可用下式表示：
　　　　　MTBF  TTF  TTR(平均修復時間)
　　可靠性能夠分爲兩個方面：
　　(1) 容錯。其目的是在錯誤發生時確保系統正確的行爲，並進行內部「修復」。例如在一個分佈式軟件系統中失去了一個與遠程構件的鏈接，接下來恢復了鏈接。在修復這樣的錯誤以後，軟件系統能夠從新或重複執行進程間的操做直到錯誤再次發生。
　　(2) 健壯性。其能保護應用程序不受錯誤使用和錯誤輸入的影響，在遇到意外錯誤事件時確保應用系統處於已經定義好的狀態。和容錯相比，健壯性並非在錯誤發生時軟件能夠繼續運行，它只能保證軟件按照某種已經定義好的方式終止執行。軟件體系結構對軟件系統的可靠性有巨大的影響。例如，軟件體系結構經過在應用程序內部包含冗餘、集成監控控件和異常處理來支持可靠性。
　　3．可用性
　　可用性是系統可以正常運行的時間比例。常常用兩次故障之間的時間長度或在出現故障時系統可以恢復正常的速度來表示。
　　4．安全性
　　安全性是指系統在向合法用戶提供服務的同時可以阻止非受權用戶使用的企圖或拒絕服務的能力。安全性是根據系統可能受到的安全威脅的類型來分類的。
　　安全性又可劃分爲機密性、完整性、不能否認性及可控性等特性。其中，機密性保證信息不泄露給未受權的用戶、實體或過程；完整性保證信息的完整和準確，防止信息被非法修改；不能否認性是指正確認定發送者，使之不可否認已發送過的數據的過程；可控性保證對信息的傳播及內容具備控制的能力，防止爲非法者所用。
　　5．可修改性
　　可修改性是指可以快速地以較高的性能代價比對系統進行變動的能力。一般以某些具體的變動爲基準，經過考察這些變動的代價衡量可修改性。可修改性包含四個方面：
　　(1) 可維護性。這主要體如今問題的修復上；在錯誤發生後「修復」軟件系統。作好爲可維護性準備的軟件體系結構每每能作局部性的修改並能使對其餘構件的負面影響最小化。
　　(2) 可擴展性。這一點關注的是使用新特性來擴展軟件系統，以及使用改進版原本替換構件並刪除不須要或沒必要要的特性和構件。爲了實現可擴展性，軟件系統須要鬆散耦合的構件。其目標是實現一種體系結構，它能使開發人員在不影響構件客戶的狀況下替換構件。支持把新構件集成到現有的體系結構中也是必要的。
　　(3) 結構重組。這一點處理的是從新組織軟件系統的構件及構件間的關係，例如經過將構件移動到一個不一樣的子系統而改變它的位置。爲了支持結構重組，軟件系統須要精心設計構件之間的關係。理想狀況下，它們容許開發人員在不影響實現的主體部分的狀況下靈活地配置構件。
　　(4) 可移植性。可移植性使軟件系統適用於多種硬件平臺、用戶界面、操做系統、編程語言或編譯器。爲了實現可移植，須要按照硬件無關的方式組織軟件系統，其餘軟件系統和環境被提取出。可移植性是系統可以在不一樣計算環境下運行的能力。這些環境多是硬件、軟件，也多是二者的結合。在關於某個特定計算環境的全部假設都集中在一個構件中時，系統是可移植的。若是移植到新的系統須要做些更改，則可移植性就是一種特殊的可修改性。
　　6．功能性
　　功能性是系統能完成所指望的工做的能力。一項任務的完成須要系統中許多或大多數構件的相互協做。
　　7．可變性
　　可變性是指體系結構經擴充或變動而成爲新體系結構的能力。這種新體系結構應該符合預先定義的規則，在某些具體方面不一樣於原有的體系結構。當要將某個體系結構做爲一系列相關產品(例如，軟件產品線)的基礎時，可變性是很重要的。
　　8．可集成性
　　可集成性是指系統能與其餘系統協做的程度。
　　9．互操做性
　　做爲系統組成部分的軟件不是獨立存在的，常常與其餘系統或自身環境相互做用。爲了支持互操做性，軟件體系結構必須爲外部可視的功能特性和數據結構提供精心設計的軟件入口。程序和用其餘編程語言編寫的軟件系統的交互做用就是互操做性的問題，這種互操做性也影響應用的軟件體系結構。
7.1.2 評估的必要性
　　Barry Boehm說過，「匆忙之中選擇某個體系結構，閒暇之時就會深深懊悔」。糟糕的體系結構實際上宣判了項目的死刑。關於評估的必要性有如下三點：
　　(1) 軟件體系結構反映了系統最初始的設計決策，對一樣一個問題，在初始階段糾正所帶來的花費和在測試或部署階段糾正致使的開銷不在一個數量級。畢竟在體系結構視圖上一個符號改動比後期大規模的代碼改動工做量要少得多，這樣，巨大的額外開銷就避免了。
　　有了對體系結構的完整描述，退一步講即便是部分描述，也能模擬系統運行時的行爲，對一些設計思想進行探討，並推斷體系結構應用於系統時的潛在影響。而全部這些工做只不過須要整個項目週期中的幾天時間。
　　(2) 評估是挖掘隱性需求並將其補充到設計中的最後機會。因爲缺少充分的交流和不能對軟件項目透徹理解，許多涉衆並不知道本身到底想要什麼。在需求獲取階段，他們會列出自認爲最重要的幾項要求。可是評估以後，這些觀點可能會變更很大。有些起初重視的方面可能並非那麼重要，而另外一些原本看上去可有可無的東西卻被發現須要花更多精力來處理。
　　在評估過程當中，涉衆會感覺到羣體力量的強大，同時對本身的參與帶來的正面影響也很振奮。而架構師會在此階段的活動中瞭解涉衆的各類想法，調整初始設計以作出權衡(也多是對候選體系結構的對比和選擇)。對架構師來說，這也是加深對待建系統理解的好機會。總之，體系結構評估清除了涉衆的溝通障礙。其最直接的結果就是獲得各方滿意的系統藍圖，而這至少意味着項目成功了一半。
　　(3) 體系結構是開發過程的中心，它決定了團隊組織、任務分配、配置管理、文檔組織、管理策略，固然還有開發進程安排。不良體系結構每每帶來一塌糊塗的效果，由於它在被使用過程當中必須被修改以適應新的考量，或者去彌補那些在開發早期階段沒有考慮到的缺陷，在這些方面進行修改須要花費大量成本。
　　更糟糕的是，團隊會面臨着項目失控的可怕境遇：改了舊錯誤帶來了更多的新錯誤；過期的體系結構會破壞現有的開發團隊結構，而這又進一步干擾了開發工做；客戶、管理層和開發者都急切地盼望者噩夢結束，但誰都不知道這樣的日子什麼時候到來。若是在這些發生以前充分分析一下體系結構就能夠部分避免這些問題的發生。
　　所以，體系結構想要付諸實踐的話，就必須被評估。
　　7.2 軟件體系結構評估的主要方式

7.2.1 主要評估方式簡介和比較
　　從目前已有的軟件體系結構評估技術來看，某些技術經過與經驗豐富的設計人員交流獲取他們對待評估軟件體系結構的意見；某些技術對針對代碼質量度量進行擴展以自底向上地推測軟件體系結構的質量；某些技術分析把對系統的質量的需求轉換爲一系列與系統的交互活動，分析軟件體系結構對這一系列活動的支持程度等。
　　儘管看起來它們採用的評估方式都各不相同，但基本能夠概括爲三類主要的評估方式：基於調查問卷或檢查表的方式、基於場景的方式和基於度量的方式。
　　1．基於調查問卷或檢查表的評估方式
　　卡耐基梅隆大學的軟件工程研究所(CMU/SEI)的軟件風險評估過程採用了這一方法。調查問卷是一系列能夠應用到各類體系結構評估的相關問題，其中有些問題可能涉及到體系結構的設計決策；有些問題涉及到體系結構的文檔，例如體系結構的表示用的是何種ADL；有的問題針對體系結構描述自己的細節問題，如系統的核心功能是否與界面分開。檢查表中也包含一系列比調查問卷更細節和具體的問題，它們更趨向於考察某些關心的質量屬性。例如，對實時信息系統的性能進行考察時，極可能問到系統是否反覆屢次地將一樣的數據寫入磁盤等。
　　這一評估方式比較自由靈活，可評估多種質量屬性，也能夠在軟件體系結構設計的多個階段進行。可是因爲評估的結果很大程度上來自評估人員的主觀推斷，所以不一樣的評估人員可能會產生不一樣甚至截然相反的結果，並且評估人員對領域的熟悉程度、是否具備豐富的相關經驗也成爲評估結果是否正確的重要因素。
　　儘管基於調查問卷與檢查表的評估方式相對比較主觀，但因爲系統相關人員的經驗和知識是評估軟件體系結構的重要信息來源，於是它仍然是進行軟件體系結構評估的重要途徑之一。
　　2．基於場景的評估方式
　　場景是一系列有序的使用或修改系統的步驟。基於場景的方式由SEI首先提出並應用在體系結構權衡分析方法(Architecture Tradeoff Analysis Method，ATAM)和軟件體系結構分析方法(Software Architecture Analysis Method，SAAM)中。這種軟件體系結構評估方式分析軟件體系結構對場景，也就是對系統的使用或修改活動的支持程度，從而判斷該體系結構對這一場景所表明的質量需求的知足程度。例如，用一系列對軟件的修改來反映易修改性方面的需求，用一系列攻擊性操做來表明安全性方面的需求等。
　　這一評估方式考慮到了包括系統的開發人員、維護人員、最終用戶、管理人員、測試人員等在內的全部與系統相關的人員對質量的要求。基於場景的評估方式涉及到的基本活動包括肯定應用領域的功能和軟件體系結構的結構之間的映射，設計用於體現待評估質量屬性的場景以及分析軟件體系結構對場景的支持程度。
　　不一樣的應用系統對同一質量屬性的理解可能不一樣，例如，對操做系統來講，可移植性被理解爲系統可在不一樣的硬件平臺上運行，而對於普通的應用系統而言，可移植性每每是指該系統可在不一樣的操做系統上運行。因爲存在這種不一致性，對一個領域適合的場景設計在另外一個領域內未必合適，所以基於場景的評估方式是特定於領域的。這一評估方式的實施者一方面須要有豐富的領域知識以對某一質量需求設計出合理的場景，另外一方面，必須對待評估的軟件體系結構有必定的瞭解以準確判斷它是否支持場景描述的一系列活動。
　　3．基於度量的評估方式
　　度量是指爲軟件產品的某一屬性所賦予的數值，如代碼行數、方法調用層數、構件個數等。傳統的度量研究主要針對代碼，但近年來也出現了一些針對高層設計的度量，軟件體系結構度量便是其中之一。代碼度量和代碼質量之間存在着重要的聯繫，相似地，軟件體系結構度量應該也可以做爲評判質量的重要的依據。赫爾辛基大學提出的基於模式挖掘的面向對象軟件體系結構度量技術、 Karlskrona和Ronneby提出的基於面向對象度量的軟件體系結構可維護性評估、西弗吉尼亞大學提出的軟件體系結構度量方法等都在這方面進行了探索，提出了一些可操做的具體方案。咱們把這類評估方式稱作基於度量的評估方式。
　　基於度量的評估技術都涉及三個基本活動：首先須要創建質量屬性和度量之間的映射原則，即肯定怎樣從度量結果推出系統具備什麼樣的質量屬性；而後從軟件體系結構文檔中獲取度量信息；最後根據映射原則分析推導出系統的某些質量屬性。所以，這些評估技術被認爲都採用了基於度量的評估方式。
　　基於度量的評估方式提供更爲客觀和量化的質量評估。這一評估方式須要在軟件體系結構的設計基本完成之後才能進行，並且須要評估人員對待評估的體系結構十分了解，不然不能獲取準確的度量。自動的軟件體系結構度量獲取工具能在必定程度上簡化評估的難度，例如MAISA可從文本格式的UML圖中抽取面向對象體系結構的度量。
　　4．三種評估方式比較
　　通過對三類主要的軟件體系結構質量評估方式的分析，表7-1從通用性、評估者對體系結構的瞭解程度、評估實施階段、評估方式的客觀程度等方面對這三種方式進行簡單的
比較。

7.2.2 基於場景的評估方法概念介紹
　　最著名的體系結構評估方法均是基於場景的。場景是系統使用或改動的假定狀況集合。各類場景能夠抽象成包含6個部分的通常形式，以方便後期的評估。
　　(1) 刺激源：這是某個生成該刺激的實體(人、計算機系統或任何其餘能夠起到刺激做用的實體)。
　　(2) 刺激：刺激源對系統的影響。
　　(3) 環境：與刺激相關的上下文條件。當刺激發生時，系統可能處於過載，或者正在運行，也多是其餘狀況。
　　(4) 製品：接收刺激的實體。多是整個系統，也多是系統的一部分。
　　(5) 響應：是在刺激到達後所採起的行動。
　　(6) 響應度量：當響應發生時，應該可以以某種方式對其進行度量，以對需求進行測試來肯定其是否能被知足。
　　場景的一個優勢就在於它是針對特定系統的，也就是說它不會被領域所限。場景能夠充分自由地表達刺激源致使的系統響應。更重要的是場景能夠將多個涉衆的建議統一塊兒來。不一樣的涉衆能夠對類似的狀況從各自的角度做出解釋，而後這些解釋就能夠在刪除冗餘信息後整合到一個場景裏。
　　若干知名的評估方法均使用場景，例如SAAM、ATAM、SAEM等。下面對其中的SAAM和ATAM方法進行較詳細的介紹。
　　　7.3 SAAM軟件體系結構分析方法

　　SAAM是最先精心設計並造成文檔的分析方法。它出現於1993年，發表於1994年(Kazman，1994)。後來Kazman對其進行改進，在參考文獻[72]中對其提供了幾個深刻的案例研究。
　　SAAM是一種直觀的方法，它試圖經過場景來測量軟件的質量，而不是泛泛的不精確的質量屬性描述。SAAM也比較簡單，僅僅考慮場景和體系結構的關係，也不涉及太多的步驟和獨特的技術。
　　因而，它成爲體系結構評估初學者的理想入門方法。SAAM最初是爲了評估體系結構的可修改性而設計，不過通過演化和實際應用，在許多其餘常見的質量屬性評估方面也展示了威力，併成爲其餘一些評估方法的基礎，好比ATAM。利用預先定義的場景，SAAM能夠檢查出被評估體系結構的潛在風險，並對幾個候選體系結構進行比較。
　　另外，SAAM能夠爲不少涉衆進行(多是項目啓動後的第一次)討論提供平臺。這樣你們就有機會用人人都懂的語言來講出各自關心的問題，瞭解別人所關心的，並看到這些問題又是如何在藍圖中處理的。在此過程當中，理解上的誤差和不正確的設計都將被發現。
7.3.1 SAAM的通常步驟
　　SAAM的通常步驟看上去很是簡單直觀，圖7-1揭示了評估的通常步驟，每一個階段能獲得什麼，各個階段的關係如何。
　　從圖7-1能夠清楚地看到SAAM的輸入、輸出。爲了開始評估，必須提供一個體繫結構描述，該描述能夠是全部參與者能接受並理解的任何形式。根據特定評估的對象和關注點，描述的詳細程度和範圍可能不一樣，有時也須要進行更新或補充。多種不一樣的候選體系結構的描述均可以拿來評估以便對比和選擇。

圖7-1 SAAM的活動和依賴
　　場景是體系結構描述以外的另外一個關鍵輸入。基於場景的評估方法的基本要點就是檢查當前的體系結構可否直接知足指望的質量需求，並在不能知足時看看能夠怎樣改動。咱們幾乎不可能對質量屬性進行精確測量，可又但願質量屬性對評估有意義，因此必須以一種更實在的形式來表述它。這就是場景爲何這麼重要的緣由。有些場景可能能夠在功能性需求中提取出來，不過大多數都是源自涉衆的討論和頭腦風暴。固然，待評估的體系結構起碼得支持需求說明中的全部功能。而評估過程的關鍵是搞清楚體系結構是否能在知足需求的狀況下擁有良好的質量屬性。
　　SAAM主要是以評估報告的形式輸出。若是是評估單個體繫結構，那麼報告的內容將包括該體系結構設計不能知足質量需求的缺陷；多個體繫結構狀況下將報告哪一個候選體系結構能最好地知足場景。由不適當分解或過度複雜致使的不良設計也會在報告中被指出。最後，SAAM能夠估計修改致使的費用和範圍，以免盲目的修改。
　　除此以外，SAAM還有一些優勢。它加強了涉衆對體系結構的理解，強制對體系結構更好的編檔，澄清系統未來演化最可能的方向。經過涉衆普遍的討論，業務目標的優先級和潛在的場景也得以澄清。
　　下面詳細介紹SAAM每一個階段的活動和技術。
7.3.2 場景生成
　　場景生成是各類涉衆參與討論和頭腦風暴的過程。每一個參與者都有本身的視角，並提供基於此的場景。對於某個修改，項目投資方關注其致使的費用，程序員在乎哪些模塊將受到影響，買主關心價格，最終用戶關心由修改帶來的好處。有關聯的，甚至是相互矛盾的場景可能在這個過程當中出現並被編檔。評估過程當中最重要的是保證一個能夠自由進行評論的氛圍。生成的全部場景都應該認真記錄到列表中以便涉衆以後審查。對那些缺少評估經驗的人，可能須要一個指導教程，這樣才能保證「好」的場景生成。所謂「好」場景，是指這些場景反映了系統主要用例、潛在修改或更新，或系統行爲必須符合的其餘質量指標。
　　此階段可能會迭代進行幾回。收集場景的時候，參與者可能會在當時的文檔中找不到須要的體系結構信息。而補充的體系結構描述反過來又會觸發更多的場景。場景開發和體系結構描述是互相關聯、互相驅動的。
7.3.3 體系結構描述
　　體系結構文檔包括了須要評估的信息，固然大多數信息都是在評估前就必須準備好的。爲了更好地進行評估，體系結構描述應該以一種參與者都能接受的形式表達，對構件、鏈接件、模塊、配置、依賴、部署等概念要區分清楚。只要能清晰無歧義，天然語言、框圖、數據表或者形式化模型等任何形式均可以用來表達體系結構。如上節所述，場景生成和體系結構描述階段可能會迭代進行幾回，它們互相關聯、互相驅動。
7.3.4 場景的分類和優先級肯定
　　SAAM中的場景分爲兩類：直接場景和間接場景。直接場景指當前體系結構不經修改便可支持的場景。若是一個場景能在原始需求(該需求在設計當前體系結構時已經被考慮)找到相似的內容，那麼顯然該場景很容易被知足。架構師能夠引入一系列的響應行爲來證實這些場景確實獲得知足。一般，直接場景雖然對揭示體系結構缺陷沒有幫助，卻能夠提升涉衆對體系結構的理解程度，有助於對其餘場景的評估。
　　間接場景不能直接被當前體系結構支持。爲了知足間接場景，就須要對體系結構進行某種修改，好比添加一個或多個構件、取出間接層、用更合適的模塊替代、改變或加強接口、重定義元素間關係或者上述狀況組合。間接場景是SAAM後續活動最關鍵的驅動器。經過充分考慮各類間接場景，能夠在很大程度上預測系統未來的演化，儘管這種預測可能很模糊。
　　有了架構師的幫助，對場景分類就很容易了。縱然如此，場景仍是可能會多到沒法一一仔細評估。因爲時間和資源有限，就須要經過設置優先級的方法來選擇最關鍵的場景。CMU SEI建議以涉衆範圍內投票的方式決定哪些是「關鍵」的。每一個人都拿到固定數量的選票，大概是場景總數的30%。投票策略是隻要每一個人投票總數不超過手中的選票總數，他能夠爲任何場景投任何數目的票。而後按照獲得選票數目的順序對全部場景進行排序，並根據具體狀況選擇必定數目的排序靠前的場景。有時候，排序後的列表可能會有一個涇渭分明的分界，一邊是得票數不少的場景，另外一邊得票數不多(如圖7-2所示)的場景，那麼直接選擇得票多的場景便可。
　　其餘時候，能夠計算一下評估多少場景比較適合，或者估計一下評估時間內能完成多少。典型的好比說，一成天能夠評估完8個場景而計劃兩天的時間進行場景的單個評估，那麼選擇15或16個比較合適。要注意的是即便根據預先定好的規則某些場景是應該放棄的，但若是它們的提出者仍然堅持而其餘人又不反對的話，那麼也能夠添加到「關鍵」列表中。

圖7-2 選擇關鍵場景
7.3.5 間接場景的單獨評估
　　涉衆最關心的信息莫過於間接場景會怎麼影響當前的候選體系結構。須要作什麼修改？修改是否在項目預期的費用、時限和範圍內？若是是，那麼到底須要多少額外的工做？若是不是，有沒有替代方案？這些問題在評估的這個階段都須要回答。對於每一個候選體系結構，都要評估一下在每一個間接場景下的表現。在此，體系結構的元素被映射到具體的質量屬性。
　　間接場景都要求改動當前體系結構。大多數時候，架構師負責解釋須要的變動。若是連他們都無法說清楚該如何處理這些變動，評估前體系結構描述的完整性就值得懷疑了。具體來講，這種解釋包括改動涉及的範圍、該範圍內具體的元素和估計的工做量。通常這些信息都要以表7-2的形式進行總結。

　　表7-2給出了後續變動工做的啓動基礎。涉衆根據此表就能夠決定哪些工做是最緊急並須要儘快進行，哪些工做應該延遲一段時間，還有哪些工做因其完成的可能性不高不該該在當前項目中實施。若是一個場景須要過多修改，能夠認爲有設計缺陷，可能須要在修改發生處作從新設計。
7.3.6 對場景關聯的評估
　　若是不一樣的場景都要求對同一個體系結構元素進行修改，則稱這些場景關聯於此元素。場景關聯意味着原始設計的潛在風險。這裏須要強調的一點是，所謂場景「不一樣」是指場景的語義有差別，該語義由涉衆決定。在分類和設置優先級處理以前，有共同點的場景能夠被歸爲一組或合併以免評估冗餘，最終保留那些反映典型用例、典型修改或其餘質量屬性而又不多重疊的場景。語義不一樣的場景影響同一體系結構元素(好比，同一個構件)的狀況代表設計不良。
　　場景關聯的程度高意味着功能分解不良，固然若是某些經典體系結構模式的工做方式就是如此，就能夠當例外來處理。通常說來，場景關聯多是災難的種子，由於未來系統演化的時候該關聯會致使混亂的修改。雖然無需認定全部的場景都是災難之源，但它們必須獲得足夠的重視。
　　不過在識別場景關聯時要當心一些僞關聯。有時體系結構文檔代表某個構件參與了某個關聯，可是其實是該構件內部分解良好的子構件獨立處理了不一樣的「關聯」場景。這時能夠返回到步驟2——體系結構描述，檢查一下文檔的詳細程度是否知足關聯識別所需。
7.3.7 造成整體評估
　　SAAM的最後一步是造成總結報告。若是候選體系結構只有一個，那麼整體評估要作的就是審查前面步驟的結果並總結成報告。修改計劃將基於此報告。
　　若是有多個候選體系結構，就須要進行一番比較。爲此須要根據各個關鍵場景和商務目標的關係來決定每一個關鍵場景的權重。比較體系結構時會發現，某個體系結構在某些場景下表現突出，而另外一個體繫結構在另外一些場景下最好。有時簡單的根據候選體系結構在哪些場景下具備優點很難作出最好的選擇。
　　而事實上，即便一樣叫作關鍵場景，場景的重要性也是不一樣的。這能夠經過設置權重來體現。多年來，出現了幾種決定權重的策略。其中一種方式是利用涉衆的討論，有時是爭論來獲得相對權重。或者，若是有歷史記錄，則是很好的參考資料。
　　直接場景也影響整體評估結果。不一樣的候選體系結構幾乎老是有各自不一樣的直接場景。回憶一下，直接場景是不經修改就被體系結構支持的那些場景。因此支持更多直接場景的體系結構也暗示着這是一個更好的候選。有時，也會把直接場景的重要性放到整體評估這裏一塊兒考慮。
　　最後，架構師對每一個關鍵場景下各個候選體系結構打分。通常來講，打分採用相對值的方法，好比「1，0，-1」(或「2，1，0」、「+，0，-」等)。1表示體系結構在該場景下表現很好；-1相反；0則表示體系結構對該場景可有可無。根據須要把範圍定到5或者10也沒問題。有了場景權重和體系結構的得分，就能夠畫一個相似表7-3的表格。而後把該表格和獨立場景評估、場景關聯評估和直接場景分析的結果結合起來，選擇一個最好的體系結構做爲下一步開發的基礎。

　　　7.4 ATAM體系結構權衡分析方法

　　ATAM方法可看作SAAM方法的加強版。從名字能夠看出，ATAM方法除了能暴露被評估體系結構的潛在缺陷和風險外，還能使咱們更好地理解和權衡多個相關的，甚至是不一致的質量需求或目標。
　　ATAM的基礎來自3個領域：體系結構風格、質量屬性分析組(包含豐富的質量屬性和體系結構對應關係的庫)和SAAM。
　　下面首先按照歷史順序回顧一下ATAM在各個發展階段的大概步驟，而後介紹ATAM主要步驟要作的工做以及在這些步驟中採起的技術。
7.4.1 最初的ATAM
　　大多數設計都是對目標進行權衡。若是不須要權衡，那麼實際上也不必作設計，由於只要根據需求作些固定的計算就好了。大多數的權衡源自非技術的緣由。好比說，爲了保證系統的可伸縮性，可能須要更多的間接層，從而致使更多的編程和測試工做，也意味着整個項目須要更多的花費，可能也須要更多的時間。再好比，兩個涉衆持有截然相反的需求，結果開發進程受阻。
　　架構師的職責是進行設計，方式是採集需求並把需求映射到軟件的結構和行爲描述中去。不過除此以外，他們更重要的責任是從技術和社會學的視角作權衡。ATAM就是作此類權衡的合適工具。ATAM和其餘評估方法或技術有着根本的不一樣，它明確考慮多個質量屬性之間的關聯，並能夠對這些關聯必然致使的權衡進行原則上的推理。爲了達到這個目標，最初的ATAM分紅4個階段內的6個步驟，如圖7-3所示。

圖7-3 ATAM的步驟
　　螺旋模型源自Boehm(1986)，該文引入了一個描述軟件開發的相似的螺旋模型。圖7-3把評估集成到了整個設計過程當中。6個步驟，即收集場景，收集需求、限制和環境，描述體系結構視圖，屬性特定分析，識別敏感度和識別權衡，構成了一輪迭代。完成上述步驟後若是評估結果代表當前體系結構能知足指望的質量需求，就能夠進行詳細設計或實現了。不然，能夠制定修改計劃更新已有設計，新的設計將進入第二輪ATAM的迭代。值得注意的是，這些步驟並不須要按照線性順序操做。每一個步驟均可能會觸發任何其餘步驟的改進，正如圖7-3所示。又如，屬性特定分析可能須要收集更多的場景來保持各個屬性的均衡。
　　在進行一次迭代時，第一階段關注場景輸入。第一步僅僅關注「使用場景」，儘可能增進參與者對體系結構的理解。這樣溝通的基礎就創建了。第二步是收集質量相關信息，也是以場景的形式表達。這些場景能夠被看作是質量需求假設，是後續步驟的基礎。獲得需求以後，就能夠利用需求的限制開始第一階段的設計。設計出來的體系結構被編檔以備評估。
　　接下來評估就開始了。首先獨立分析每一個質量屬性，這時候沒必要考慮場景關聯。單獨評估能夠使得各個質量屬性方面的專家最大程度地利用屬性特定的技術或模型進行分析。好比，馬爾科夫模型擅長可用性分析，而SPE(即軟件性能工程)分析性能特別方便。屬性特定分析的結果以特定模型中數據的測量值來表述，例如「最壞狀況下請求必須在500 ms內獲得響應」，或者「在理想環境下系統的可用性爲99.99%」。
　　最後要作的是識別敏感度和權衡。在解釋這兩個步驟以前，先定義一下「體系結構元素」。體系結構元素是指任何構件、構件屬性或構件關係的屬性，只要它們對質量屬性有影響。敏感點是指會因爲體系結構元素的修改而發生顯著變化的系統模型參數。例如，基於C/S的系統，服務器的冗餘度影響整個系統的可用性。增長一個後備服務器會把平均每一年的系統崩潰時間下降一個數量級。這裏系統平均崩潰時間就是一個敏感點。一個權衡點是指與多個敏感點有關的體系結構元素。
　　就是說，若是一個構件、構件屬性或關係屬性變化了，若干質量屬性會大幅度地變得更好或更壞。 例如，C/S系統中服務器冗餘度就是一個權衡點，由於它的改動將致使可用性、費用、安全性等屬性的顯著變化，這些特性有些是互相沖突的。權衡點揭示了架構師須要密切關注的問題。
7.4.2 改進版ATAM
　　1999年，ATAM在幾個實際項目中應用後，有了升級和加強。ATAM的原有步驟有的進行了合併，另外又補充了幾個其餘的步驟(如圖7-4所示)。好比，增長了「場景分組和設置優先級」，這個步驟和SAAM中相似。有幾個步驟被濃縮成一個，如「體系結構介紹」。

圖7-4 改進版ATAM的步驟
　　對改進版ATAM主要有兩點值得注意。第一點是怎樣才知道何時中止場景生成比較合適。從圖7-4能夠看到第3步進行場景覆蓋檢查。CMU SEI專門爲此步驟定義了一套針對特定質量屬性的問題，回答這些問題能夠幫助評估者找到遺漏的有用場景並補充進來。
　　另一點就是引入了不少ABAS(基於屬性的體系結構風格)。ABAS是一種分析輔助工具，能夠幫助涉衆識別體系結構風格的質量屬性，好比性能、可用性、安全性、可測試性、可修改性等。簡言之，ABAS就是帶有屬性值以反映質量信息的體系結構風格。ABAS的著名例子是用於多個併發進程的性能分析。若是軟件系統使用多個進程，每一個進程都競爭有限的計算資源，該系統就能夠稱作性能ABAS。對此ABAS應當進行如下相關參數信息的質詢，好比進程優先級、同步位置、排隊策略和估計執行時間。可是，僅僅知道性能相關的信息並不足夠，還須要把這些信息輸入到分析框架以便分析。例如，單調速率分析是實時系統的一個有效分析框架。
　　對比兩個版本的ATAM，能夠看到一個趨勢，就是更多實際的技術和關注點被加入進來。初版創建在螺旋開發模型之上，理論的味道很濃。在第二版，步驟進行了從新調整以更好地符合實際須要。除此以外，也引入了一些須要的輔助技術，儘管其中有些從評估的角度看並不能算是核心技術。
　　簡單地說，這些變化試圖爲以下問題提供答案：怎樣幫助涉衆知道作什麼和怎麼作從而爲評估過程作貢獻？怎樣引導涉衆精確清晰地理解待評估的體系結構？怎樣生成對評估有益的場景，同時避免忽略某些必需的場景，並從全部場景中選出最重要的？怎麼把場景映射到體系結構，以便識別敏感點和權衡點？最後，怎樣對特定的質量屬性進行具體的評估並生成負責規劃後續活動的評估報告？這些問題是大多數評估方法的共同問題。儘管經歷了衆多項目的實際應用和數以千計的架構師、設計人員和軟件工程師的改進，ATAM仍在不斷調整以追求更好的評估效果。
　　下一節咱們將介紹ATAM如今的狀況，看看又有什麼新技術被引入進來。
7.4.3 ATAM的通常過程
　　當前ATAM的完整過程包括4個階段，共9個主要步驟。在此，步驟仍然沒必要是線性執行的。實踐上，評估負責人能夠決定應該執行哪些步驟，或者直接跳到本應在若干步以後才實施的步驟。這些都視狀況而定。步驟僅僅代表評估中間製品的生成順序。順序靠後的步驟總須要靠前步驟的製品做爲輸入。所以，若是評估團隊已經有了某一步驟生成的信息，或者這些信息對這次評估沒有用處，就能夠跳過這一步。
　　ATAM的通常過程如圖7-5所示。階段Ⅰ和Ⅱ是評估的核心。

圖7-5 ATAM的通常過程
　　階段0是準備階段。考慮到ATAM評估的範圍、時間和費用，有必要就評估時間表、費用計劃、參與者組織等問題進行討論甚至簽署嚴格的合同協定。評估前首先應該搞清楚進行評估是否可行、誰參與評估、評估的對象是什麼、評估結果提交給誰、評估後又該作什麼。爲了不核心評估階段中斷，上面提到的每一個問題都須要仔細考慮和計劃。而後，須要創建一個評估團隊(若是準備評估的組織沒有專職評估團隊的話)，負責接下來的工做。該團隊中須要定義幾個角色，包括團隊領導、評估領導、書記員、計時者、提問者、監督員等。同一我的能夠扮演多個角色。一般，在階段0會開一個評估團隊會議以明確責任併爲下一階段作好準備。
　　階段Ⅲ是評估收尾階段。這時有兩項任務必需要作。首先是要產生最終報告，記錄核心評估階段的過程、信息和基於此的結論。另外一項任務是進行總結以便改進從此的評估。一方面，能夠詢問評估成員或者其餘參與者感受哪些活動好，哪些很差，爲何。能夠收集關於本次評估的花費和收益的信息。這種數據挖掘可能會有利於找到各類活動的可改進之處。另外一方面，能夠整理本次的場景和相關的問題，以備下次評估相似項目。在領域特定的開發中，這項活動因其強大的可重用性而很是有效。
　　階段Ⅰ和階段Ⅱ是核心評估階段，共有9個步驟，和前面小節曾講的步驟相似。這些步驟又進一步分爲以下4個子階段：
　　1．介紹
　　(1) 介紹ATAM：介紹ATAM的步驟、活動和技術。
　　(2) 介紹商業動機：介紹商業目標以識別主要質量需求。
　　(3) 介紹體系結構：解釋當前體系結構如何知足商業動機。
　　2．研究和分析
　　(4) 識別體系結構方法：找到創建體系結構所用的方法。
　　(5) 生成質量屬性效用樹：以樹的形式產生反映系統效用的帶有優先級的場景。
　　(6) 分析體系結構方法：對支持關鍵場景的體系結構方法進行分析，並識別風險、非風險、敏感點和權衡點。
　　3．測試
　　(7) 頭腦風暴和給場景指定優先級：由更多的涉衆生成更多的場景。
　　(8) 分析體系結構方法：同步驟(6)，不過採用的場景來自步驟(7)。
　　4．報告
　　(9) 報告結果：產生評估報告。
　　實際上，主要階段Ⅰ和Ⅱ分別是上述步驟的一次迭代，固然包括的具體步驟和參與者範圍有所不一樣，如表7-4所示。主要階段Ⅱ須要更多類型的涉衆參與場景生成和分析討論。主要階段Ⅰ則試圖利用幾個原則識別主要的質量屬性，爲後續評估打好基礎。主要階段Ⅰ只包含步驟(1)～(6)。固然，沒必要機械式地執行這兩次迭代。實際應用時評估團隊能夠調整迭代這些步驟的時間計劃，並能夠自行決定每次迭代的參與者。

　　讀者可能會看到一些不熟悉的概念，如「效用樹」、「風險」或者「非風險」，也可能會問爲何步驟(6)看上去和步驟(8)同樣。這些問題在後面的小節中將有詳細介紹。
7.4.4 介紹
　　這個子階段的目標是界定哪些行動是有益的，而哪些不是。該階段引導參與者致力於系統設計並能作出貢獻。同時，後續步驟所需的輸入也由此階段提供。
　　步驟(1)——介紹ATAM。
　　這一步回答了「什麼是ATAM？」和「ATAM參與者都作些什麼？」的問題。這是由於除了專業的評估團隊，其餘涉衆多是第一次參與評估。評估負責人須要向參與者介紹ATAM，回答他們的相關問題。在此過程當中，評估負責人的工做集中在場景肯定優先級、效用樹構建等操做的步驟、概念和技術，評估的輸入輸出及其餘有關信息。
　　步驟(2)——介紹商業動機。
　　項目領導人(項目主要管理者或相似人員)須要向全部參與者解釋主要的商業動機。畢竟，場景開發和特定的評估須要此類信息。這項介紹的主題應該包括：主要商業目標，需求說明中已文檔化的主要功能，來自技術、管理、經濟、政策方面的有關限制，還有涉衆的重要質量需求。注意「涉衆」這個概念，在不一樣主要階段，涉衆的範圍不一樣，這就使得關注點會有所偏重。這種差別也能做爲一個參照，以便暴露那些沒被考慮的問題。
　　步驟(3)——介紹體系結構。
　　首席架構師介紹已有的體系結構，一般採用多視圖的形式。大多數項目須要展現靜態邏輯結構的分解視圖、運行時結構的構件-鏈接件視圖、邏輯結構和物理實體之間映射的分佈視圖和描述指望行爲的行爲視圖。不過特定狀況下，架構師有權決定使用其餘視圖展現系統某個特定區域，以此提供與關鍵質量屬性對應的體系結構信息。
　　體系結構介紹的詳細程度直接影響後續的分析。根據在準備階段設定的評估的指望效果，架構師有義務選擇一個對評估比較合適的詳細程度。固然在評估時，若是須要的體系結構信息未被提供，涉衆能夠向架構師詢問。最後，一個重要任務就是列出明確使用的體系結構方法，爲下一步作準備。
7.4.5 研究和分析
　　在這個子階段，涉衆開始將體系結構與質量屬性對應起來。不過和前述ATAM的其餘版本相比，在此使用的具體方法更加出色。這裏捕獲分析的不是體系結構元素，而是體系結構方法；用於場景生成的不是頭腦風暴一類的辦法，而是採用效用樹。在效用樹中，每一個場景的優先級由二維估計值來測量。評估中，要識別風險、非風險、敏感點和權衡點，不過這些識別是分析的開始而非結束。
　　步驟(4)——識別體系結構方法。
　　識別體系結構方法的緣由是這些信息提供了體系結構構建背後的基本原則。簡言之，一個體繫結構方法是指根據功能或質量需求而作的設計決定。
　　衆所周知，軟件體系結構風格和模式包含了大量的有用信息，這些信息與進行特定設計的原理緊密相關。體系結構模式描述了必要的抽象元素、這些元素的結構和相關的一些約束。每一個體繫結構模式的優缺點和基本原理都有成千上萬次的使用做基礎。ATAM第二版中提到的ABAS尤爲有用。和ABAS相聯繫的屬性值暴露了主要的質量屬性目標，也能用來分析可否知足這些目標。
　　可是並非全部的體系結構方法均可以用體系結構風格或模式的形式表達。若是是這樣，架構師就須要用天然語言解釋爲何作出這樣的設計，或爲何設計會以指望的方式運行。架構師應該能講清楚使用的每一個體繫結構方法。這樣，對於那些架構師以爲很基礎，可是對評估很是重要的體系結構方法(因而若是不是被明確的問到，架構師不會作特別說明)，其餘評估參與者也有機會理解。
　　儘管這一步驟須要清晰的解釋，可是不須要對方法的分析，那是步驟(6)中的任務。
　　步驟(5)——生成質量屬性效用樹。
　　本步驟將識別關鍵質量屬性目標，參與者是評估團隊和核心項目成員，如管理者、客戶表明和首席架構師。這裏主要的目標是避免在評估上時間和費用的浪費。若是參與者不能決定出關鍵的質量屬性目標或就此達成一致，評估就沒法獲得應有的效果。質量屬性效用樹是達到此目標的強大工具。
　　質量屬性效用樹(Quality Attribute Utility Tree，QAUT)以樹的形式表現質量屬性的細化。QAUT的根是效用，接下來是質量屬性層，典型的有可用性、可修改型和安全性等。再接着下一層是質量屬性具體描述分類，也就是把某個質量屬性分紅幾個主題。第四層也是最後一層，是具體的場景，精肯定義了質量需求以容許後續分析。通常來講，QAUT把系統的指望效用翻譯成了場景。
　　每一個場景有兩維度量：
　　(1) 此場景對系統成功的重要程度。
　　(2) 架構師所估計的支持此場景的開發難度。測量所用的標度能夠定爲相似高、中、低這樣範圍爲3的序數尺度，範圍爲5或者10等也能夠。標記好度量後，場景就能夠排出優先級了，最上面的是參與者但願獲得的最關鍵的質量屬性目標。
　　圖7-6是QAUT的一個例子。實際上，真實項目中生成的場景比此例複雜得多。最終QUAT生成了帶有優先級的場景列表，順序應該是(H，H)、(H，M)、(M，H)……(L，L)。這個優先級清楚地揭示了各類涉衆的全面關注。也許有人認爲性能是關鍵需求，而另外一些人堅持可用性須要更多的關注。可是在創建QAUT以前，每一個人的想法可能都是凌亂的。QAUT引導並澄清系統的質量需求及其相對重要性。因而，評估的時間和成本不夠時就能夠省略優先級低的場景。由於分析不重要或者很簡單的場景沒什麼意義。
　　步驟(6)——分析體系結構方法。
　　QAUT指明瞭評估的方向，以後就該分析體系結構方法處理高優先級場景的機制了。在這一步驟，評估團隊和架構師一道識別在那些和重要場景相關的方法中存在的風險、非風險、敏感點和權衡點。

圖7-6 質量屬性效用樹示例
　　風險是已經作出的可是在特定的可能狀況下出現潛在問題的決策。而非風險正好相反。可能有人會說風險應該受到更多關注，由於它們是未來的問題之源。不過，非風險也同樣重要，由於它們暗示了哪些體系結構方法值得保留和堅持。更重要的是，當上下文變化的時候，非風險可能會轉變成風險。所以，顯式地列出非風險是有用的。
　　敏感點是指會被某些體系結構元素顯著影響的系統模型的屬性值。權衡點是系統內與幾個敏感點都相關的地方。在步驟(4)和步驟(5)中這些須要的信息應該就準備好了。不過若評估團隊感到有什麼信息缺失，能夠詢問架構師。
　　爲了識別風險、非風險、敏感點和權衡點，全體參與者都要完成下述工做：
　　(1) 識別出試圖支持重要場景的體系結構方法並弄清楚這些方法在當前體系結構中是怎麼實例化的。
　　(2) 分析每一個方法，考慮其明顯的優勢和缺點，判斷其是否對質量屬性帶來負面影響。這項工做能夠利用詢問一系列附屬於這種體系結構方法的特定問題來完成。
　　(3) 在回答這些問題的基礎上，識別風險、非風險、敏感點和權衡點並分別記錄在文檔中。
　　這一步驟結束，主要階段Ⅰ就完成了。若是一切順利，評估團隊應該對體系結構有了大體的瞭解，也清楚了其優缺點。
7.4.6 測試
　　這一階段的目的是對到目前爲止所做的分析進行測試。會有更多種類的涉衆就係統質量需求給出建議。討論的範圍被擴大了，於是會有額外的問題和關注點出現來對系統需求進行補充。
　　步驟(7)——頭腦風暴和設定場景優先級。
　　在步驟(5)中，場景表示爲QAUT，代表項目決策者心目中的體系結構該是什麼樣子。不過在這一步，評估團隊的範圍更大了。這裏獲得更多場景的有效方法是頭腦風暴，就像SAAM的場景生成採用的方式。這種環境容易激發創造性的想法和新穎的建議。按性質場景能夠分爲如下3類：
　　(1) 用例場景：描述被評估體系結構所在的系統在最終用戶的特定操做下如何動做和響應。
　　(2) 增加式場景：描述被評估體系結構所在的系統怎樣支持快速修改和演化的，好比添加構件、平臺移植或者與其餘系統集成。
　　(3) 探索式場景：探索被評估體系結構所在系統的極端增加狀況。若是說增加式場景試圖揭示指望中的和可能的修改，那麼探索式場景使評估參與者有機會知道重大變動後系統會發生什麼。好比說，性能必須提升5倍，或可用性須要提升一個數量級。根據這類場景，額外的敏感點和權衡點將會暴露，評估測試可基於此。
　　頭腦風暴後，利用投票爲場景設置優先級，這和SAAM相似。顯然步驟(5)和本步驟生成的場景有顯著差別。利用QAUT生成場景是細化的過程，看起來是自頂向下的風格。評估團隊和核心項目決策人經過QAUT找到當前體系結構的主要質量驅動。而頭腦風暴生成的場景須要幾乎全部涉衆的合做。測試時，本步驟生成的場景將和QAUT的結果比對。新的場景成爲QAUT已有分支的葉子節點，也可能原來就徹底沒有相應的質量屬性分支。評估測試的目的也正是如此，即暴露兩者之間的差別，補充未考慮到的場景。
　　步驟(8)——分析體系結構方法。
　　這一步使用的方法和技術同步驟(6)，主要差異在於，在此涉衆分析的是步驟(7)產生的體系結構方法。若是一切順利，那麼架構師只須要解釋是如何用那些被捕獲的方法來實現場景的。可是若是存在某些場景不能被直接支持，那麼評估團隊應該記錄在檔以便制定修改計劃。
7.4.7 報告
　　步驟(9)——提供評估結果。
　　這是ATAM一輪迭代的最後一步，包括已收集在原始體系結構文檔內的、涉衆生成的和分析獲得的全部信息都要體如今評估報告中。最重要的內容或者說ATAM的輸出，包括文檔化的體系結構方法(包括這些方法附屬的問題)、帶優先級的場景、QAUT、關鍵質量需求、風險、非風險、敏感點和權衡點。全部涉衆一塊兒討論來解決當前體系結構的問題，尤爲是風險和權衡點。
　　　　　7.5 SAAM方法評估實例

　　咱們在本節介紹一個使用SAAM方法的實例。 咱們使用SAAM方法對第3章介紹過的KWIC(在文章中查找和重組關鍵詞)系統中的不一樣場景進行評估。
　　1．定義角色和場景
　　KWIC系統感興趣的角色有兩個，分別是最終用戶和開發人員。使用四個場景，其中兩個場景通過了不一樣的最終用戶的討論，即
　　(1) 修改KWIC程序，使之成爲一個增量方式而不是批處理的方式。這個程序版本將能一次接受一個句子，產生一個全部置換的字母列表。
　　(2) 修改KWIC程序，使之能刪除在句子前端的噪音單詞(例如前置詞、代名詞、連詞等)。
　　使用的另外兩個場景是通過開發人員討論，但最終用戶不知道的，即
　　(1) 改變句子的內部表示(例如，壓縮和解壓縮)。
　　(2) 改變中間數據結構的內部表示(例如，可直接存儲置換後的句子，也可存儲轉換後的詞語的地址)。
　　2．描述體系結構
　　第2步就是使用通用的表示對待評估的體系結構進行描述，這種描述是爲了使評估過程更容易，使評估人員知道體系結構圖中的框或箭頭的準確含義。這裏對兩種體系結構風格進行評估。
　　1) 共享內存的解決方案
　　在第一個待評估的體系結構中，有一個全局存儲區域，被稱作Sentences，用來存儲全部輸入的句子。其執行的順序是：輸入例程讀入句子→存儲句子→循環轉換例程轉換句子→字母例程按字母順序排列句子→輸出。當須要時，主控程序傳遞控制信息給不一樣的例程。圖7-7描述了這個過程，不一樣計算構件上的數字表明場景編號，在這一步中可忽略(將在後面用到)。

圖7-7 共享內存的解決方案示例
　　2) 抽象數據類型解決方案
　　待評估的第2個體繫結構使用抽象數據類型(Abstract Data Type，ADT)，如圖7-8所示。其中每一個功能都隱藏和保護了其內部數據表示，提供專門的存取函數做爲惟一的存儲、檢索和查詢數據的方式。ADT Sentences有兩個函數，分別是set和getNext，用來增長和檢索句子；ADT Shifted Sentences提供了存取函數setup和getNext，分別用來創建句子的循環置換和檢索置換後的句子。

圖7-8 抽象數據類型解決方案示例
　　ADT Shifted Sentences使用ADT Sentences的getNext函數來從新存儲輸入的句子。ADT Alphabetized Sentences提供了一個setup函數和一個i-th函數，setup函數重複調用Shifted Sentences的getNext函數，以檢索已經存儲的全部行並進行排序，i-th函數根據參數i，從存儲隊列中返回第i個句子。
　　3．評估體系結構
　　既然已經把待評估的體系結構用通用的符號標記了出來，接下來就是評估體系結構知足場景的程度。經過依次考慮每一個場景來進行評估。咱們所選擇的用來評估的全部場景都是間接場景，也就是說，這些場景不能被待評估的體系結構直接執行，所以評估依賴於體系結構的某些修改。
　　(1) 場景1。第一個場景是從批處理模式轉移到增量模式，也就是說，不是把全部句子都輸入完後再一次性進行處理，而是一次只處理一個句子。
　　對共享內存解決方案而言，這須要修改Input例程，使之在讀入一個句子後讓出控制權，同時，也要修改Master Control主控程序，由於子例程再也不是按順序一次只調用一個，而是一個迭代調用的過程。還要修改Alphabetizer例程，由於使用增量模式後，牽涉到插入排序的問題。咱們假設Circular Shift例程一次只處理一個句子，且輸出函數只要被調用，就能夠輸出。
　　注意，咱們所做的假設只是針對共享內存解決方案而言的，通常來講，判斷的準確性取決於不一樣的計算構件的內部工做知識。這也是爲何要指望評估人員中，既有具備計算構件通常知識的人，也有具備特定構件知識的人。
　　對抽象數據類型解決方案而言，Input函數須要修改，使之在被調用時，一次只輸入一行。假設Sentence當存儲了輸入以後放棄控制權，則無需改變。也假設當Shifted Sentences被調用時，能請求和轉換全部可得到的句子，這樣，該例程也無須改變。與在共享內存解決方案中同樣，Alphabetized Sentences也必須修改。
　　綜上所述，對第一個場景而言，兩個待評估的體系結構受到的影響是均等的，所以，咱們斷定其爲中性的。
　　(2) 場景2。第二個場景要求刪除句子中的「噪音」單詞。不管在共享內存解決方案仍是在抽象數據類型解決方案中，這種需求都可經過修改轉換函數很容易地實現(在共享內存體系結構中，修改Circular Shift函數；在抽象數據類型體系結構中，修改Shifted Sentences函數)。由於在兩種體系結構中，轉換函數都是局部的，且噪音單詞的刪除不會影響句子的內部表示，因此，對兩種體系結構而言，這種修改是等價的。
　　(3) 場景3。第三個場景要求改變句子的內部表示，例如從一個未壓縮的表示轉換到壓縮的表示。在共享內存體系結構中，全部函數共享一個公用的表示，所以，除了主控函數Master Control外，全部函數都受該場景的影響。在抽象數據類型中，輸入句子的內部表示由Sentence提供緩衝。所以，就第三個場景而言，抽象數據類型體系結構比共享內存的體系結構要好。
　　(4) 場景4。第四個場景要求改變中間數據結構的內部表示(例如，既可直接存儲置換後的句子，也可存儲轉換後的詞語的地址)。對於共享內存體系結構，須要修改Circular Shift、Alphabetize和Output三個例程。對於抽象數據類型體系結構，須要修改抽象數據類型中的Shifted Sentences和Alphabetized Sentences。所以，抽象數據類型解決方案所受影響的構件數量要比共享內存體系結構解決方案的少。
　　(5) 比較分析。圖7-7和圖7-8都標記了反映每一個場景的影響。例如，在圖7-7中，Master Control構件中的「1」反映了該構件必須修改以支持場景1。檢查待評估體系結構，看其有多少個構件受場景的影響，每一個構件最多受多少個場景的影響。從這方面來看，抽象數據類型體系結構要比共享內存體系結構好。在共享內存體系結構和抽象數據類型體系結構中，二者都有4個構件受場景的影響，可是，在共享內存體系結構中，有兩個構件(Circular Shift和Alphabetize)受三個場景的影響，而在抽象數據類型體系結構中，全部構件最多隻受兩個場景的影響。
　　(6) 評估結果。表7-5歸納了評估的結果，其中0表示對該場景而言，兩個體系結構不分好壞，在實際的評估中，還須要根據組織的偏好設置場景的優先級。例如，若是功能的增長是風險承擔者最關心的問題(就像第2個場景同樣)， 那麼這兩個體系結構是不相上下的，由於在這一點上，它們之間沒有什麼區別。

　　可是，若是句子內部表示的修改是風險承擔者最關心的問題(就像第3個場景同樣)，那麼抽象數據類型體系結構顯然是要首選的體系結構。
　　使用SAAM方法評估系統的結果一般容易理解，容易解釋，並且和不一樣組織的需求目標聯繫在一塊兒。開發人員、維護人員、用戶和管理人員會找到對他們關心的問題的直接回答，只要這些問題是以場景的方式提出的。
　　　　　　7.6 本 章 小 結

　　體系結構評估，是指對系統的某些值得關心的屬性進行評價和判斷。評估的結果可用於確認潛在的風險，並檢查設計階段所獲得的系統需求的質量。體系結構評估能夠只針對一個體繫結構，也能夠針對一組體系結構。在體系結構評估過程當中，評估人員所關注的是系統的質量屬性。本章首先介紹了幾個幾乎全部評估方法都廣泛關注的質量屬性：性能、可靠性、可用性、安全性、可修改性、功能性等，而後從三個方面討論了體系結構評估的必要性。
　　從目前已有的軟件體系結構評估技術來看，儘管它們採用的評估方式都各不相同，但基本能夠概括爲三類主要的評估方式：基於調查問卷或檢查表的方式、基於場景的方式和基於度量的方式。最著名的體系結構評估方法均是基於場景的。場景是系統使用或改動的假定狀況集合。本章詳細介紹了兩個最著名的基於場景的評估方法——SAAM 和ATAM。SAAM本質上是一個尋找受場景影響的體系結構元素的方法，而ATAM創建在SAAM基礎上，關注對風險、非風險、敏感點和權衡點的識別。
　　SAAM和ATAM表現了大多數基於場景評估方法的共同特性。它們以場景和體系結構描述做爲輸入，評估判斷當前體系結構(或候選體系結構)可否知足指望質量屬性。潛在的缺陷和風險被識別，這是修改工做啓動的基礎。最後，原始的評估獲得的數據被收集起來以備後用，例如用做進一步開發時的提示信息，或者積攢起來做爲重用時重要的歷史數據。
　　　　　　　　習 題

　　1．爲何要評估軟件體系結構？從哪些方面評估軟件體系結構？
　　2．軟件體系結構評估的主要方法有哪三種？請簡單解釋每種方法。
　　3．ATAM評估方法的基本步驟是什麼？
　　4．選擇你所熟悉的一個軟件系統，給出4～5種質量屬性。在該系統中，設計者最爲關心哪些質量屬性？這些質量屬性是如何定義的？須要實現到什麼程度？
　　5．分別使用SAAM方法和ATAM方法，對上題中的系統的體系結構進行分析和評估。