第7章軟件體系結(jié)構(gòu)評估7.1軟件體系結(jié)構(gòu)評估概述7.2軟件體系結(jié)構(gòu)評估的主要方式7.3SAAM軟件體系結(jié)構(gòu)分析方法7.4ATAM體系結(jié)構(gòu)權(quán)衡分析方法7.5SAAM方法評估實例7.6本章小結(jié)習題

7.1軟件體系結(jié)構(gòu)評估概述

7.1.1評估關(guān)注的質(zhì)量屬性

軟件體系結(jié)構(gòu)的設(shè)計是整個軟件開發(fā)過程中關(guān)鍵的一步。對于當今世界上龐大而復(fù)雜的系統(tǒng)來說，如果沒有一個合適的體系結(jié)構(gòu)而要有一個成功的軟件設(shè)計幾乎是不可想象的。不同類型的系統(tǒng)需要不同的體系結(jié)構(gòu)，甚至一個系統(tǒng)的不同子系統(tǒng)也需要不同的體系結(jié)構(gòu)。體系結(jié)構(gòu)的選擇是一個軟件系統(tǒng)設(shè)計成敗的關(guān)鍵。但是，怎樣才能知道為軟件系統(tǒng)所選用的體系結(jié)構(gòu)是否恰當？如何確保按照所選用的體系結(jié)構(gòu)能順利地開發(fā)出成功的軟件產(chǎn)品呢？要回答這些問題，需要使用專門的方法對軟件體系結(jié)構(gòu)進行分析和評估。

體系結(jié)構(gòu)評估可以只針對一個體系結(jié)構(gòu)，也可以針對一組體系結(jié)構(gòu)。在體系結(jié)構(gòu)評估過程中，評估人員所關(guān)注的是系統(tǒng)的質(zhì)量屬性，所有評估方法所普遍關(guān)注的質(zhì)量屬性有以下幾個。

1．性能

性能是指系統(tǒng)的響應(yīng)能力，即要經(jīng)過多長時間才能對某個事件作出響應(yīng)，或者在某段時間內(nèi)系統(tǒng)所能處理的事件的個數(shù)。經(jīng)常用單位時間內(nèi)所處理事務(wù)的數(shù)量或系統(tǒng)完成某個事務(wù)處理所需的時間來對性能進行定量的表示。性能測試經(jīng)常要使用基準測試程序(用以測量性能指標的特定事務(wù)集或工作量環(huán)境)。

2．可靠性

可靠性是軟件系統(tǒng)在應(yīng)用或系統(tǒng)錯誤面前、在意外或錯誤使用的情況下維持軟件系統(tǒng)的功能特性的基本能力?？煽啃允亲钪匾能浖匦?，通常用它衡量在規(guī)定的條件和時間內(nèi)，軟件完成規(guī)定功能的能力。可靠性通常用平均失效等待時間(MeanTimeToFailure，MTTF)(指軟件在失效前正常工作的平均統(tǒng)計時間)和平均失效間隔時間(MeanTimeBetweenFailure，MTBF)來衡量。在失效率為常數(shù)和修復(fù)時間很短的情況下，MTTF和MTBF幾乎相等。MTBF可用下式表示：

MTBF?=?MTTF?+?MTTR(平均修復(fù)時間)可靠性可以分為兩個方面：

(1)容錯。其目的是在錯誤發(fā)生時確保系統(tǒng)正確的行為，并進行內(nèi)部“修復(fù)”。例如在一個分布式軟件系統(tǒng)中失去了一個與遠程構(gòu)件的連接，接下來恢復(fù)了連接。在修復(fù)這樣的錯誤之后，軟件系統(tǒng)可以重新或重復(fù)執(zhí)行進程間的操作直到錯誤再次發(fā)生。

(2)健壯性。其能保護應(yīng)用程序不受錯誤使用和錯誤輸入的影響，在遇到意外錯誤事件時確保應(yīng)用系統(tǒng)處于已經(jīng)定義好的狀態(tài)。和容錯相比，健壯性并不是在錯誤發(fā)生時軟件可以繼續(xù)運行，它只能保證軟件按照某種已經(jīng)定義好的方式終止執(zhí)行。軟件體系結(jié)構(gòu)對軟件系統(tǒng)的可靠性有巨大的影響。例如，軟件體系結(jié)構(gòu)通過在應(yīng)用程序內(nèi)部包含冗余、集成監(jiān)控控件和異常處理來支持可靠性。

3．可用性

可用性是系統(tǒng)能夠正常運行的時間比例。經(jīng)常用兩次故障之間的時間長度或在出現(xiàn)故障時系統(tǒng)能夠恢復(fù)正常的速度來表示。

4．安全性

安全性是指系統(tǒng)在向合法用戶提供服務(wù)的同時能夠阻止非授權(quán)用戶使用的企圖或拒絕服務(wù)的能力。安全性是根據(jù)系統(tǒng)可能受到的安全威脅的類型來分類的。

安全性又可劃分為機密性、完整性、不可否認性及可控性等特性。其中，機密性保證信息不泄露給未授權(quán)的用戶、實體或過程；完整性保證信息的完整和準確，防止信息被非法修改；不可否認性是指正確認定發(fā)送者，使之不能否認已發(fā)送過的數(shù)據(jù)的過程；可控性保證對信息的傳播及內(nèi)容具有控制的能力，防止為非法者所用。

5．可修改性

可修改性是指能夠快速地以較高的性能代價比對系統(tǒng)進行變更的能力。通常以某些具體的變更為基準，通過考察這些變更的代價衡量可修改性。可修改性包含四個方面：

(1)可維護性。這主要體現(xiàn)在問題的修復(fù)上；在錯誤發(fā)生后“修復(fù)”軟件系統(tǒng)。做好為可維護性準備的軟件體系結(jié)構(gòu)往往能做局部性的修改并能使對其他構(gòu)件的負面影響最小化。

(2)可擴展性。這一點關(guān)注的是使用新特性來擴展軟件系統(tǒng)，以及使用改進版本來替換構(gòu)件并刪除不需要或不必要的特性和構(gòu)件。為了實現(xiàn)可擴展性，軟件系統(tǒng)需要松散耦合的構(gòu)件。其目標是實現(xiàn)一種體系結(jié)構(gòu)，它能使開發(fā)人員在不影響構(gòu)件客戶的情況下替換構(gòu)件。支持把新構(gòu)件集成到現(xiàn)有的體系結(jié)構(gòu)中也是必要的。

(3)結(jié)構(gòu)重組。這一點處理的是重新組織軟件系統(tǒng)的構(gòu)件及構(gòu)件間的關(guān)系，例如通過將構(gòu)件移動到一個不同的子系統(tǒng)而改變它的位置。為了支持結(jié)構(gòu)重組，軟件系統(tǒng)需要精心設(shè)計構(gòu)件之間的關(guān)系。理想情況下，它們允許開發(fā)人員在不影響實現(xiàn)的主體部分的情況下靈活地配置構(gòu)件。

(4)可移植性。可移植性使軟件系統(tǒng)適用于多種硬件平臺、用戶界面、操作系統(tǒng)、編程語言或編譯器。為了實現(xiàn)可移植，需要按照硬件無關(guān)的方式組織軟件系統(tǒng)，其他軟件系統(tǒng)和環(huán)境被提取出。可移植性是系統(tǒng)能夠在不同計算環(huán)境下運行的能力。這些環(huán)境可能是硬件、軟件，也可能是兩者的結(jié)合。在關(guān)于某個特定計算環(huán)境的所有假設(shè)都集中在一個構(gòu)件中時，系統(tǒng)是可移植的。如果移植到新的系統(tǒng)需要作些更改，則可移植性就是一種特殊的可修改性。

6．功能性

功能性是系統(tǒng)能完成所期望的工作的能力。一項任務(wù)的完成需要系統(tǒng)中許多或大多數(shù)構(gòu)件的相互協(xié)作。

7．可變性

可變性是指體系結(jié)構(gòu)經(jīng)擴充或變更而成為新體系結(jié)構(gòu)的能力。這種新體系結(jié)構(gòu)應(yīng)該符合預(yù)先定義的規(guī)則，在某些具體方面不同于原有的體系結(jié)構(gòu)。當要將某個體系結(jié)構(gòu)作為一系列相關(guān)產(chǎn)品(例如，軟件產(chǎn)品線)的基礎(chǔ)時，可變性是很重要的。

8．可集成性

可集成性是指系統(tǒng)能與其他系統(tǒng)協(xié)作的程度。

9．互操作性

作為系統(tǒng)組成部分的軟件不是獨立存在的，經(jīng)常與其他系統(tǒng)或自身環(huán)境相互作用。為了支持互操作性，軟件體系結(jié)構(gòu)必須為外部可視的功能特性和數(shù)據(jù)結(jié)構(gòu)提供精心設(shè)計的軟件入口。程序和用其他編程語言編寫的軟件系統(tǒng)的交互作用就是互操作性的問題，這種互操作性也影響應(yīng)用的軟件體系結(jié)構(gòu)。7.1.2評估的必要性

BarryBoehm說過，“匆忙之中選擇某個體系結(jié)構(gòu)，閑暇之時就會深深懊悔”。糟糕的體系結(jié)構(gòu)實際上宣判了項目的死刑。關(guān)于評估的必要性有以下三點：

(1)軟件體系結(jié)構(gòu)反映了系統(tǒng)最初始的設(shè)計決策，對同樣一個問題，在初始階段糾正所帶來的花費和在測試或部署階段糾正導(dǎo)致的開銷不在一個數(shù)量級。畢竟在體系結(jié)構(gòu)視圖上一個符號改動比后期大規(guī)模的代碼改動工作量要少得多，這樣，巨大的額外開銷就避免了。有了對體系結(jié)構(gòu)的完整描述，退一步講即使是部分描述，也能模擬系統(tǒng)運行時的行為，對一些設(shè)計思想進行探討，并推斷體系結(jié)構(gòu)應(yīng)用于系統(tǒng)時的潛在影響。而所有這些工作只不過需要整個項目周期中的幾天時間。

(2)評估是挖掘隱性需求并將其補充到設(shè)計中的最后機會。由于缺乏充分的交流和不能對軟件項目透徹理解，許多涉眾并不知道自己到底想要什么。在需求獲取階段，他們會列出自認為最重要的幾項要求。但是評估之后，這些觀點可能會變動很大。有些起初重視的方面可能并不是那么重要，而另一些本來看上去無關(guān)緊要的東西卻被發(fā)現(xiàn)需要花更多精力來處理。在評估過程中，涉眾會感受到群體力量的強大，同時對自己的參與帶來的正面影響也很振奮。而架構(gòu)師會在此階段的活動中了解涉眾的各種想法，調(diào)整初始設(shè)計以做出權(quán)衡(也可能是對候選體系結(jié)構(gòu)的對比和選擇)。對架構(gòu)師來講，這也是加深對待建系統(tǒng)理解的好機會?？傊?，體系結(jié)構(gòu)評估清除了涉眾的溝通障礙。其最直接的結(jié)果就是得到各方滿意的系統(tǒng)藍圖，而這至少意味著項目成功了一半。

(3)體系結(jié)構(gòu)是開發(fā)過程的中心，它決定了團隊組織、任務(wù)分配、配置管理、文檔組織、管理策略，當然還有開發(fā)進程安排。不良體系結(jié)構(gòu)往往帶來一塌糊涂的效果，因為它在被使用過程中必須被修改以適應(yīng)新的考量，或者去彌補那些在開發(fā)早期階段沒有考慮到的缺陷，在這些方面進行修改需要花費大量成本。更糟糕的是，團隊會面臨著項目失控的可怕境遇：改了舊錯誤帶來了更多的新錯誤；過時的體系結(jié)構(gòu)會破壞現(xiàn)有的開發(fā)團隊結(jié)構(gòu)，而這又進一步干擾了開發(fā)工作；客戶、管理層和開發(fā)者都急切地盼望者噩夢結(jié)束，但誰都不知道這樣的日子何時到來。如果在這些發(fā)生之前充分分析一下體系結(jié)構(gòu)就可以部分避免這些問題的發(fā)生。

因此，體系結(jié)構(gòu)想要付諸實踐的話，就必須被評估。

7.2軟件體系結(jié)構(gòu)評估的主要方式

7.2.1主要評估方式簡介和比較

從目前已有的軟件體系結(jié)構(gòu)評估技術(shù)來看，某些技術(shù)通過與經(jīng)驗豐富的設(shè)計人員交流獲取他們對待評估軟件體系結(jié)構(gòu)的意見；某些技術(shù)對針對代碼質(zhì)量度量進行擴展以自底向上地推測軟件體系結(jié)構(gòu)的質(zhì)量；某些技術(shù)分析把對系統(tǒng)的質(zhì)量的需求轉(zhuǎn)換為一系列與系統(tǒng)的交互活動，分析軟件體系結(jié)構(gòu)對這一系列活動的支持程度等。盡管看起來它們采用的評估方式都各不相同，但基本可以歸納為三類主要的評估方式：基于調(diào)查問卷或檢查表的方式、基于場景的方式和基于度量的方式。

1．基于調(diào)查問卷或檢查表的評估方式

卡耐基梅隆大學的軟件工程研究所(CMU/SEI)的軟件風險評估過程采用了這一方法。調(diào)查問卷是一系列可以應(yīng)用到各種體系結(jié)構(gòu)評估的相關(guān)問題，其中有些問題可能涉及到體系結(jié)構(gòu)的設(shè)計決策；有些問題涉及到體系結(jié)構(gòu)的文檔，例如體系結(jié)構(gòu)的表示用的是何種ADL；有的問題針對體系結(jié)構(gòu)描述本身的細節(jié)問題，如系統(tǒng)的核心功能是否與界面分開。檢查表中也包含一系列比調(diào)查問卷更細節(jié)和具體的問題，它們更趨向于考察某些關(guān)心的質(zhì)量屬性。例如，對實時信息系統(tǒng)的性能進行考察時，很可能問到系統(tǒng)是否反復(fù)多次地將同樣的數(shù)據(jù)寫入磁盤等。這一評估方式比較自由靈活，可評估多種質(zhì)量屬性，也可以在軟件體系結(jié)構(gòu)設(shè)計的多個階段進行。但是由于評估的結(jié)果很大程度上來自評估人員的主觀推斷，因此不同的評估人員可能會產(chǎn)生不同甚至截然相反的結(jié)果，而且評估人員對領(lǐng)域的熟悉程度、是否具有豐富的相關(guān)經(jīng)驗也成為評估結(jié)果是否正確的重要因素。

盡管基于調(diào)查問卷與檢查表的評估方式相對比較主觀，但由于系統(tǒng)相關(guān)人員的經(jīng)驗和知識是評估軟件體系結(jié)構(gòu)的重要信息來源，因而它仍然是進行軟件體系結(jié)構(gòu)評估的重要途徑之一。

2．基于場景的評估方式

場景是一系列有序的使用或修改系統(tǒng)的步驟。基于場景的方式由SEI首先提出并應(yīng)用在體系結(jié)構(gòu)權(quán)衡分析方法(ArchitectureTradeoffAnalysisMethod，ATAM)和軟件體系結(jié)構(gòu)分析方法(SoftwareArchitectureAnalysisMethod，SAAM)中。這種軟件體系結(jié)構(gòu)評估方式分析軟件體系結(jié)構(gòu)對場景，也就是對系統(tǒng)的使用或修改活動的支持程度，從而判斷該體系結(jié)構(gòu)對這一場景所代表的質(zhì)量需求的滿足程度。例如，用一系列對軟件的修改來反映易修改性方面的需求，用一系列攻擊性操作來代表安全性方面的需求等。這一評估方式考慮到了包括系統(tǒng)的開發(fā)人員、維護人員、最終用戶、管理人員、測試人員等在內(nèi)的所有與系統(tǒng)相關(guān)的人員對質(zhì)量的要求?；趫鼍暗脑u估方式涉及到的基本活動包括確定應(yīng)用領(lǐng)域的功能和軟件體系結(jié)構(gòu)的結(jié)構(gòu)之間的映射，設(shè)計用于體現(xiàn)待評估質(zhì)量屬性的場景以及分析軟件體系結(jié)構(gòu)對場景的支持程度。不同的應(yīng)用系統(tǒng)對同一質(zhì)量屬性的理解可能不同，例如，對操作系統(tǒng)來說，可移植性被理解為系統(tǒng)可在不同的硬件平臺上運行，而對于普通的應(yīng)用系統(tǒng)而言，可移植性往往是指該系統(tǒng)可在不同的操作系統(tǒng)上運行。由于存在這種不一致性，對一個領(lǐng)域適合的場景設(shè)計在另一個領(lǐng)域內(nèi)未必合適，因此基于場景的評估方式是特定于領(lǐng)域的。這一評估方式的實施者一方面需要有豐富的領(lǐng)域知識以對某一質(zhì)量需求設(shè)計出合理的場景，另一方面，必須對待評估的軟件體系結(jié)構(gòu)有一定的了解以準確判斷它是否支持場景描述的一系列活動。

3．基于度量的評估方式

度量是指為軟件產(chǎn)品的某一屬性所賦予的數(shù)值，如代碼行數(shù)、方法調(diào)用層數(shù)、構(gòu)件個數(shù)等。傳統(tǒng)的度量研究主要針對代碼，但近年來也出現(xiàn)了一些針對高層設(shè)計的度量，軟件體系結(jié)構(gòu)度量即是其中之一。代碼度量和代碼質(zhì)量之間存在著重要的聯(lián)系，類似地，軟件體系結(jié)構(gòu)度量應(yīng)該也能夠作為評判質(zhì)量的重要的依據(jù)。赫爾辛基大學提出的基于模式挖掘的面向?qū)ο筌浖w系結(jié)構(gòu)度量技術(shù)、?Karlskrona和Ronneby提出的基于面向?qū)ο蠖攘康能浖w系結(jié)構(gòu)可維護性評估、西弗吉尼亞大學提出的軟件體系結(jié)構(gòu)度量方法等都在這方面進行了探索，提出了一些可操作的具體方案。我們把這類評估方式稱做基于度量的評估方式?；诙攘康脑u估技術(shù)都涉及三個基本活動：首先需要建立質(zhì)量屬性和度量之間的映射原則，即確定怎樣從度量結(jié)果推出系統(tǒng)具有什么樣的質(zhì)量屬性；然后從軟件體系結(jié)構(gòu)文檔中獲取度量信息；最后根據(jù)映射原則分析推導(dǎo)出系統(tǒng)的某些質(zhì)量屬性。因此，這些評估技術(shù)被認為都采用了基于度量的評估方式。

基于度量的評估方式提供更為客觀和量化的質(zhì)量評估。這一評估方式需要在軟件體系結(jié)構(gòu)的設(shè)計基本完成以后才能進行，而且需要評估人員對待評估的體系結(jié)構(gòu)十分了解，否則不能獲取準確的度量。自動的軟件體系結(jié)構(gòu)度量獲取工具能在一定程度上簡化評估的難度，例如MAISA可從文本格式的UML圖中抽取面向?qū)ο篌w系結(jié)構(gòu)的度量。

4．三種評估方式比較

經(jīng)過對三類主要的軟件體系結(jié)構(gòu)質(zhì)量評估方式的分析，表7-1從通用性、評估者對體系結(jié)構(gòu)的了解程度、評估實施階段、評估方式的客觀程度等方面對這三種方式進行簡單的

比較。7.2.2基于場景的評估方法概念介紹

最著名的體系結(jié)構(gòu)評估方法均是基于場景的。場景是系統(tǒng)使用或改動的假定情況集合。各種場景可以抽象成包含6個部分的一般形式，以方便后期的評估。

(1)刺激源：這是某個生成該刺激的實體(人、計算機系統(tǒng)或任何其他可以起到刺激作用的實體)。

(2)刺激：刺激源對系統(tǒng)的影響。

(3)環(huán)境：與刺激相關(guān)的上下文條件。當刺激發(fā)生時，系統(tǒng)可能處于過載，或者正在運行，也可能是其他情況。

(4)制品：接收刺激的實體。可能是整個系統(tǒng)，也可能是系統(tǒng)的一部分。

(5)響應(yīng)：是在刺激到達后所采取的行動。

(6)響應(yīng)度量：當響應(yīng)發(fā)生時，應(yīng)該能夠以某種方式對其進行度量，以對需求進行測試來確定其是否能被滿足。場景的一個優(yōu)點就在于它是針對特定系統(tǒng)的，也就是說它不會被領(lǐng)域所限。場景可以充分自由地表達刺激源導(dǎo)致的系統(tǒng)響應(yīng)。更重要的是場景可以將多個涉眾的建議統(tǒng)一起來。不同的涉眾可以對相似的情況從各自的角度作出解釋，然后這些解釋就可以在刪除冗余信息后整合到一個場景里。

若干知名的評估方法均使用場景，例如SAAM、ATAM、SAEM等。下面對其中的SAAM和ATAM方法進行較詳細的介紹。

7.3SAAM軟件體系結(jié)構(gòu)分析方法

SAAM是最早精心設(shè)計并形成文檔的分析方法。它出現(xiàn)于1993年，發(fā)表于1994年(Kazman，1994)。后來Kazman對其進行改進，在參考文獻[72]中對其提供了幾個深入的案例研究。

SAAM是一種直觀的方法，它試圖通過場景來測量軟件的質(zhì)量，而不是泛泛的不精確的質(zhì)量屬性描述。SAAM也比較簡單，僅僅考慮場景和體系結(jié)構(gòu)的關(guān)系，也不涉及太多的步驟和獨特的技術(shù)。于是，它成為體系結(jié)構(gòu)評估初學者的理想入門方法。SAAM最初是為了評估體系結(jié)構(gòu)的可修改性而設(shè)計，不過經(jīng)過演化和實際應(yīng)用，在許多其他常見的質(zhì)量屬性評估方面也展現(xiàn)了威力，并成為其他一些評估方法的基礎(chǔ)，比如ATAM。利用預(yù)先定義的場景，SAAM可以檢查出被評估體系結(jié)構(gòu)的潛在風險，并對幾個候選體系結(jié)構(gòu)進行比較。

另外，SAAM可以為很多涉眾進行(可能是項目啟動后的第一次)討論提供平臺。這樣大家就有機會用人人都懂的語言來說出各自關(guān)心的問題，了解別人所關(guān)心的，并看到這些問題又是如何在藍圖中處理的。在此過程中，理解上的偏差和不正確的設(shè)計都將被發(fā)現(xiàn)。7.3.1SAAM的一般步驟

SAAM的一般步驟看上去非常簡單直觀，圖7-1揭示了評估的一般步驟，每個階段能得到什么，各個階段的關(guān)系如何。

從圖7-1可以清楚地看到SAAM的輸入、輸出。為了開始評估，必須提供一個體系結(jié)構(gòu)描述，該描述可以是所有參與者能接受并理解的任何形式。根據(jù)特定評估的對象和關(guān)注點，描述的詳細程度和范圍可能不同，有時也需要進行更新或補充。多種不同的候選體系結(jié)構(gòu)的描述都可以拿來評估以便對比和選擇。

圖7-1SAAM的活動和依賴場景是體系結(jié)構(gòu)描述之外的另一個關(guān)鍵輸入?；趫鼍暗脑u估方法的基本要點就是檢查當前的體系結(jié)構(gòu)能否直接滿足期望的質(zhì)量需求，并在不能滿足時看看可以怎樣改動。我們幾乎不可能對質(zhì)量屬性進行精確測量，可又希望質(zhì)量屬性對評估有意義，所以必須以一種更實在的形式來表述它。這就是場景為什么這么重要的原因。有些場景可能可以在功能性需求中提取出來，不過大多數(shù)都是源自涉眾的討論和頭腦風暴。當然，待評估的體系結(jié)構(gòu)起碼得支持需求說明中的所有功能。而評估過程的關(guān)鍵是搞清楚體系結(jié)構(gòu)是否能在滿足需求的情況下?lián)碛辛己玫馁|(zhì)量屬性。

SAAM主要是以評估報告的形式輸出。如果是評估單個體系結(jié)構(gòu)，那么報告的內(nèi)容將包括該體系結(jié)構(gòu)設(shè)計不能滿足質(zhì)量需求的缺陷；多個體系結(jié)構(gòu)情況下將報告哪個候選體系結(jié)構(gòu)能最好地滿足場景。由不適當分解或過分復(fù)雜導(dǎo)致的不良設(shè)計也會在報告中被指出。最后，SAAM可以估計修改導(dǎo)致的費用和范圍，以避免盲目的修改。

除此之外，SAAM還有一些優(yōu)點。它增強了涉眾對體系結(jié)構(gòu)的理解，強制對體系結(jié)構(gòu)更好的編檔，澄清系統(tǒng)將來演化最可能的方向。通過涉眾廣泛的討論，業(yè)務(wù)目標的優(yōu)先級和潛在的場景也得以澄清。

下面詳細介紹SAAM每個階段的活動和技術(shù)。7.3.2場景生成

場景生成是各種涉眾參與討論和頭腦風暴的過程。每個參與者都有自己的視角，并提供基于此的場景。對于某個修改，項目投資方關(guān)注其導(dǎo)致的費用，程序員在意哪些模塊將受到影響，買主關(guān)心價格，最終用戶關(guān)心由修改帶來的好處。有關(guān)聯(lián)的，甚至是相互矛盾的場景可能在這個過程中出現(xiàn)并被編檔。評估過程中最重要的是保證一個可以自由進行評論的氛圍。生成的所有場景都應(yīng)該認真記錄到列表中以便涉眾之后審查。對那些缺乏評估經(jīng)驗的人，可能需要一個指導(dǎo)教程，這樣才能保證“好”的場景生成。所謂“好”場景，是指這些場景反映了系統(tǒng)主要用例、潛在修改或更新，或系統(tǒng)行為必須符合的其他質(zhì)量指標。此階段可能會迭代進行幾次。收集場景的時候，參與者可能會在當時的文檔中找不到需要的體系結(jié)構(gòu)信息。而補充的體系結(jié)構(gòu)描述反過來又會觸發(fā)更多的場景。場景開發(fā)和體系結(jié)構(gòu)描述是互相關(guān)聯(lián)、互相驅(qū)動的。7.3.3體系結(jié)構(gòu)描述

體系結(jié)構(gòu)文檔包括了需要評估的信息，當然大多數(shù)信息都是在評估前就必須準備好的。為了更好地進行評估，體系結(jié)構(gòu)描述應(yīng)該以一種參與者都能接受的形式表達，對構(gòu)件、連接件、模塊、配置、依賴、部署等概念要區(qū)分清楚。只要能清晰無歧義，自然語言、框圖、數(shù)據(jù)表或者形式化模型等任何形式都可以用來表達體系結(jié)構(gòu)。如上節(jié)所述，場景生成和體系結(jié)構(gòu)描述階段可能會迭代進行幾次，它們互相關(guān)聯(lián)、互相驅(qū)動。7.3.4場景的分類和優(yōu)先級確定

SAAM中的場景分為兩類：直接場景和間接場景。直接場景指當前體系結(jié)構(gòu)不經(jīng)修改即可支持的場景。如果一個場景能在原始需求(該需求在設(shè)計當前體系結(jié)構(gòu)時已經(jīng)被考慮)找到類似的內(nèi)容，那么顯然該場景很容易被滿足。架構(gòu)師可以引入一系列的響應(yīng)行為來證明這些場景確實得到滿足。通常，直接場景雖然對揭示體系結(jié)構(gòu)缺陷沒有幫助，卻可以提高涉眾對體系結(jié)構(gòu)的理解程度，有助于對其他場景的評估。間接場景不能直接被當前體系結(jié)構(gòu)支持。為了滿足間接場景，就需要對體系結(jié)構(gòu)進行某種修改，比如添加一個或多個構(gòu)件、取出間接層、用更合適的模塊替代、改變或增強接口、重定義元素間關(guān)系或者上述情況組合。間接場景是SAAM后續(xù)活動最關(guān)鍵的驅(qū)動器。通過充分考慮各種間接場景，可以在很大程度上預(yù)測系統(tǒng)將來的演化，盡管這種預(yù)測可能很模糊。有了架構(gòu)師的幫助，對場景分類就很容易了?？v然如此，場景還是可能會多到無法一一仔細評估。由于時間和資源有限，就需要通過設(shè)置優(yōu)先級的方法來選擇最關(guān)鍵的場景。CMUSEI建議以涉眾范圍內(nèi)投票的方式?jīng)Q定哪些是“關(guān)鍵”的。每個人都拿到固定數(shù)量的選票，大概是場景總數(shù)的30%。投票策略是只要每個人投票總數(shù)不超過手中的選票總數(shù)，他可以為任何場景投任何數(shù)目的票。然后按照得到選票數(shù)目的順序?qū)λ袌鼍斑M行排序，并根據(jù)具體情況選擇一定數(shù)目的排序靠前的場景。有時候，排序后的列表可能會有一個涇渭分明的分界，一邊是得票數(shù)很多的場景，另一邊得票數(shù)很少(如圖7-2所示)的場景，那么直接選擇得票多的場景即可。其他時候，可以計算一下評估多少場景比較適合，或者估計一下評估時間內(nèi)能完成多少。典型的比如說，一整天可以評估完8個場景而計劃兩天的時間進行場景的單個評估，那么選擇15或16個比較合適。要注意的是即使根據(jù)預(yù)先定好的規(guī)則某些場景是應(yīng)該放棄的，但如果它們的提出者仍然堅持而其他人又不反對的話，那么也可以添加到“關(guān)鍵”列表中。圖7-2選擇關(guān)鍵場景7.3.5間接場景的單獨評估

涉眾最關(guān)心的信息莫過于間接場景會怎么影響當前的候選體系結(jié)構(gòu)。需要做什么修改？修改是否在項目預(yù)期的費用、時限和范圍內(nèi)？如果是，那么到底需要多少額外的工作？如果不是，有沒有替代方案？這些問題在評估的這個階段都需要回答。對于每個候選體系結(jié)構(gòu)，都要評估一下在每個間接場景下的表現(xiàn)。在此，體系結(jié)構(gòu)的元素被映射到具體的質(zhì)量屬性。間接場景都要求改動當前體系結(jié)構(gòu)。大多數(shù)時候，架構(gòu)師負責解釋需要的變更。如果連他們都沒法說清楚該如何處理這些變更，評估前體系結(jié)構(gòu)描述的完整性就值得懷疑了。具體來說，這種解釋包括改動涉及的范圍、該范圍內(nèi)具體的元素和估計的工作量。一般這些信息都要以表7-2的形式進行總結(jié)。表7-2給出了后續(xù)變更工作的啟動基礎(chǔ)。涉眾根據(jù)此表就可以決定哪些工作是最緊急并需要盡快進行，哪些工作應(yīng)該延遲一段時間，還有哪些工作因其完成的可能性不高不應(yīng)該在當前項目中實施。如果一個場景需要過多修改，可以認為有設(shè)計缺陷，可能需要在修改發(fā)生處做重新設(shè)計。7.3.6對場景關(guān)聯(lián)的評估

如果不同的場景都要求對同一個體系結(jié)構(gòu)元素進行修改，則稱這些場景關(guān)聯(lián)于此元素。場景關(guān)聯(lián)意味著原始設(shè)計的潛在風險。這里需要強調(diào)的一點是，所謂場景“不同”是指場景的語義有差異，該語義由涉眾決定。在分類和設(shè)置優(yōu)先級處理之前，有共同點的場景可以被歸為一組或合并以避免評估冗余，最終保留那些反映典型用例、典型修改或其他質(zhì)量屬性而又很少重疊的場景。語義不同的場景影響同一體系結(jié)構(gòu)元素(比如，同一個構(gòu)件)的情況表明設(shè)計不良。場景關(guān)聯(lián)的程度高意味著功能分解不良，當然如果某些經(jīng)典體系結(jié)構(gòu)模式的工作方式就是如此，就可以當例外來處理。一般說來，場景關(guān)聯(lián)可能是災(zāi)難的種子，因為將來系統(tǒng)演化的時候該關(guān)聯(lián)會導(dǎo)致混亂的修改。雖然無需認定所有的場景都是災(zāi)難之源，但它們必須得到足夠的重視。

不過在識別場景關(guān)聯(lián)時要小心一些偽關(guān)聯(lián)。有時體系結(jié)構(gòu)文檔表明某個構(gòu)件參與了某個關(guān)聯(lián)，但是實際上是該構(gòu)件內(nèi)部分解良好的子構(gòu)件獨立處理了不同的“關(guān)聯(lián)”場景。這時可以返回到步驟2——體系結(jié)構(gòu)描述，檢查一下文檔的詳細程度是否滿足關(guān)聯(lián)識別所需。7.3.7形成總體評估

SAAM的最后一步是形成總結(jié)報告。如果候選體系結(jié)構(gòu)只有一個，那么總體評估要做的就是審查前面步驟的結(jié)果并總結(jié)成報告。修改計劃將基于此報告。

如果有多個候選體系結(jié)構(gòu)，就需要進行一番比較。為此需要根據(jù)各個關(guān)鍵場景和商務(wù)目標的關(guān)系來決定每個關(guān)鍵場景的權(quán)重。比較體系結(jié)構(gòu)時會發(fā)現(xiàn)，某個體系結(jié)構(gòu)在某些場景下表現(xiàn)突出，而另一個體系結(jié)構(gòu)在另一些場景下最好。有時簡單的根據(jù)候選體系結(jié)構(gòu)在哪些場景下具有優(yōu)勢很難做出最好的選擇。而事實上，即使同樣叫做關(guān)鍵場景，場景的重要性也是不同的。這可以通過設(shè)置權(quán)重來體現(xiàn)。多年來，出現(xiàn)了幾種決定權(quán)重的策略。其中一種方式是利用涉眾的討論，有時是爭論來得到相對權(quán)重?；蛘撸绻袣v史記錄，則是很好的參考資料。

直接場景也影響總體評估結(jié)果。不同的候選體系結(jié)構(gòu)幾乎總是有各自不同的直接場景?；貞浺幌?，直接場景是不經(jīng)修改就被體系結(jié)構(gòu)支持的那些場景。所以支持更多直接場景的體系結(jié)構(gòu)也暗示著這是一個更好的候選。有時，也會把直接場景的重要性放到總體評估這里一起考慮。最后，架構(gòu)師對每個關(guān)鍵場景下各個候選體系結(jié)構(gòu)打分。一般來說，打分采用相對值的方法，比如“1，0，-1”(或“2，1，0”、“+，0，-”等)。1表示體系結(jié)構(gòu)在該場景下表現(xiàn)很好；-1相反；0則表示體系結(jié)構(gòu)對該場景無關(guān)緊要。根據(jù)需要把范圍定到5或者10也沒問題。有了場景權(quán)重和體系結(jié)構(gòu)的得分，就可以畫一個類似表7-3的表格。然后把該表格和獨立場景評估、場景關(guān)聯(lián)評估和直接場景分析的結(jié)果結(jié)合起來，選擇一個最好的體系結(jié)構(gòu)作為下一步開發(fā)的基礎(chǔ)。

7.4ATAM體系結(jié)構(gòu)權(quán)衡分析方法

ATAM方法可看做SAAM方法的增強版。從名字可以看出，ATAM方法除了能暴露被評估體系結(jié)構(gòu)的潛在缺陷和風險外，還能使我們更好地理解和權(quán)衡多個相關(guān)的，甚至是不一致的質(zhì)量需求或目標。

ATAM的基礎(chǔ)來自3個領(lǐng)域：體系結(jié)構(gòu)風格、質(zhì)量屬性分析組(包含豐富的質(zhì)量屬性和體系結(jié)構(gòu)對應(yīng)關(guān)系的庫)和SAAM。

下面首先按照歷史順序回顧一下ATAM在各個發(fā)展階段的大概步驟，然后介紹ATAM主要步驟要做的工作以及在這些步驟中采取的技術(shù)。7.4.1最初的ATAM

大多數(shù)設(shè)計都是對目標進行權(quán)衡。如果不需要權(quán)衡，那么實際上也沒必要做設(shè)計，因為只要根據(jù)需求做些固定的計算就行了。大多數(shù)的權(quán)衡源自非技術(shù)的原因。比如說，為了保證系統(tǒng)的可伸縮性，可能需要更多的間接層，從而導(dǎo)致更多的編程和測試工作，也意味著整個項目需要更多的花費，可能也需要更多的時間。再比如，兩個涉眾持有截然相反的需求，結(jié)果開發(fā)進程受阻。架構(gòu)師的職責是進行設(shè)計，方式是采集需求并把需求映射到軟件的結(jié)構(gòu)和行為描述中去。不過除此之外，他們更重要的責任是從技術(shù)和社會學的視角做權(quán)衡。ATAM就是做此類權(quán)衡的合適工具。ATAM和其他評估方法或技術(shù)有著根本的不同，它明確考慮多個質(zhì)量屬性之間的關(guān)聯(lián)，并可以對這些關(guān)聯(lián)必然導(dǎo)致的權(quán)衡進行原則上的推理。為了達到這個目標，最初的ATAM分成4個階段內(nèi)的6個步驟，如圖7-3所示。圖7-3ATAM的步驟螺旋模型源自Boehm(1986)，該文引入了一個描述軟件開發(fā)的類似的螺旋模型。圖7-3把評估集成到了整個設(shè)計過程中。6個步驟，即收集場景，收集需求、限制和環(huán)境，描述體系結(jié)構(gòu)視圖，屬性特定分析，識別敏感度和識別權(quán)衡，構(gòu)成了一輪迭代。完成上述步驟后如果評估結(jié)果表明當前體系結(jié)構(gòu)能滿足期望的質(zhì)量需求，就可以進行詳細設(shè)計或?qū)崿F(xiàn)了。否則，可以制定修改計劃更新已有設(shè)計，新的設(shè)計將進入第二輪ATAM的迭代。值得注意的是，這些步驟并不需要按照線性順序操作。每個步驟都可能會觸發(fā)任何其他步驟的改進，正如圖7-3所示。又如，屬性特定分析可能需要收集更多的場景來保持各個屬性的均衡。在進行一次迭代時，第一階段關(guān)注場景輸入。第一步僅僅關(guān)注“使用場景”，盡量增進參與者對體系結(jié)構(gòu)的理解。這樣溝通的基礎(chǔ)就建立了。第二步是收集質(zhì)量相關(guān)信息，也是以場景的形式表達。這些場景可以被看做是質(zhì)量需求假設(shè)，是后續(xù)步驟的基礎(chǔ)。得到需求之后，就可以利用需求的限制開始第一階段的設(shè)計。設(shè)計出來的體系結(jié)構(gòu)被編檔以備評估。接下來評估就開始了。首先獨立分析每個質(zhì)量屬性，這時候不必考慮場景關(guān)聯(lián)。單獨評估可以使得各個質(zhì)量屬性方面的專家最大程度地利用屬性特定的技術(shù)或模型進行分析。比如，馬爾科夫模型擅長可用性分析，而SPE(即軟件性能工程)分析性能特別方便。屬性特定分析的結(jié)果以特定模型中數(shù)據(jù)的測量值來表述，例如“最壞情況下請求必須在500ms內(nèi)得到響應(yīng)”，或者“在理想環(huán)境下系統(tǒng)的可用性為99.99%”。最后要做的是識別敏感度和權(quán)衡。在解釋這兩個步驟之前，先定義一下“體系結(jié)構(gòu)元素”。體系結(jié)構(gòu)元素是指任何構(gòu)件、構(gòu)件屬性或構(gòu)件關(guān)系的屬性，只要它們對質(zhì)量屬性有影響。敏感點是指會由于體系結(jié)構(gòu)元素的修改而發(fā)生顯著變化的系統(tǒng)模型參數(shù)。例如，基于C/S的系統(tǒng)，服務(wù)器的冗余度影響整個系統(tǒng)的可用性。增加一個后備服務(wù)器會把平均每年的系統(tǒng)崩潰時間降低一個數(shù)量級。這里系統(tǒng)平均崩潰時間就是一個敏感點。一個權(quán)衡點是指與多個敏感點有關(guān)的體系結(jié)構(gòu)元素。就是說，如果一個構(gòu)件、構(gòu)件屬性或關(guān)系屬性變化了，若干質(zhì)量屬性會大幅度地變得更好或更壞。?例如，C/S系統(tǒng)中服務(wù)器冗余度就是一個權(quán)衡點，因為它的改動將導(dǎo)致可用性、費用、安全性等屬性的顯著變化，這些特性有些是互相沖突的。權(quán)衡點揭示了架構(gòu)師需要密切關(guān)注的問題。7.4.2改進版ATAM

1999年，ATAM在幾個實際項目中應(yīng)用后，有了升級和增強。ATAM的原有步驟有的進行了合并，另外又補充了幾個其他的步驟(如圖7-4所示)。比如，增加了“場景分組和設(shè)置優(yōu)先級”，這個步驟和SAAM中類似。有幾個步驟被濃縮成一個，如“體系結(jié)構(gòu)介紹”。圖7-4改進版ATAM的步驟對改進版ATAM主要有兩點值得注意。第一點是怎樣才知道什么時候停止場景生成比較合適。從圖7-4可以看到第3步進行場景覆蓋檢查。CMUSEI專門為此步驟定義了一套針對特定質(zhì)量屬性的問題，回答這些問題可以幫助評估者找到遺漏的有用場景并補充進來。另外一點就是引入了很多ABAS(基于屬性的體系結(jié)構(gòu)風格)。ABAS是一種分析輔助工具，可以幫助涉眾識別體系結(jié)構(gòu)風格的質(zhì)量屬性，比如性能、可用性、安全性、可測試性、可修改性等。簡言之，ABAS就是帶有屬性值以反映質(zhì)量信息的體系結(jié)構(gòu)風格。ABAS的著名例子是用于多個并發(fā)進程的性能分析。如果軟件系統(tǒng)使用多個進程，每個進程都競爭有限的計算資源，該系統(tǒng)就可以稱做性能ABAS。對此ABAS應(yīng)當進行以下相關(guān)參數(shù)信息的質(zhì)詢，比如進程優(yōu)先級、同步位置、排隊策略和估計執(zhí)行時間。但是，僅僅知道性能相關(guān)的信息并不足夠，還需要把這些信息輸入到分析框架以便分析。例如，單調(diào)速率分析是實時系統(tǒng)的一個有效分析框架。對比兩個版本的ATAM，可以看到一個趨勢，就是更多實際的技術(shù)和關(guān)注點被加入進來。第一版建立在螺旋開發(fā)模型之上，理論的味道很濃。在第二版，步驟進行了重新調(diào)整以更好地符合實際需要。除此之外，也引入了一些需要的輔助技術(shù)，盡管其中有些從評估的角度看并不能算是核心技術(shù)。簡單地說，這些變化試圖為如下問題提供答案：怎樣幫助涉眾知道做什么和怎么做從而為評估過程做貢獻？怎樣引導(dǎo)涉眾精確清晰地理解待評估的體系結(jié)構(gòu)？怎樣生成對評估有益的場景，同時避免忽略某些必需的場景，并從所有場景中選出最重要的？怎么把場景映射到體系結(jié)構(gòu)，以便識別敏感點和權(quán)衡點？最后，怎樣對特定的質(zhì)量屬性進行具體的評估并生成負責規(guī)劃后續(xù)活動的評估報告？這些問題是大多數(shù)評估方法的共同問題。盡管經(jīng)歷了眾多項目的實際應(yīng)用和數(shù)以千計的架構(gòu)師、設(shè)計人員和軟件工程師的改進，ATAM仍在不斷調(diào)整以追求更好的評估效果。

下一節(jié)我們將介紹ATAM現(xiàn)在的情況，看看又有什么新技術(shù)被引入進來。7.4.3ATAM的一般過程

當前ATAM的完整過程包括4個階段，共9個主要步驟。在此，步驟仍然不必是線性執(zhí)行的。實踐上，評估負責人可以決定應(yīng)該執(zhí)行哪些步驟，或者直接跳到本應(yīng)在若干步之后才實施的步驟。這些都視情況而定。步驟僅僅表明評估中間制品的生成順序。順序靠后的步驟總需要靠前步驟的制品作為輸入。因此，如果評估團隊已經(jīng)有了某一步驟生成的信息，或者這些信息對此次評估沒有用處，就可以跳過這一步。

ATAM的一般過程如圖7-5所示。階段Ⅰ和Ⅱ是評估的核心。圖7-5ATAM的一般過程階段0是準備階段。考慮到ATAM評估的范圍、時間和費用，有必要就評估時間表、費用計劃、參與者組織等問題進行討論甚至簽署嚴格的合同協(xié)定。評估前首先應(yīng)該搞清楚進行評估是否可行、誰參與評估、評估的對象是什么、評估結(jié)果提交給誰、評估后又該做什么。為了避免核心評估階段中斷，上面提到的每個問題都需要仔細考慮和計劃。然后，需要建立一個評估團隊(如果準備評估的組織沒有專職評估團隊的話)，負責接下來的工作。該團隊中需要定義幾個角色，包括團隊領(lǐng)導(dǎo)、評估領(lǐng)導(dǎo)、書記員、計時者、提問者、監(jiān)督員等。同一個人可以扮演多個角色。通常，在階段0會開一個評估團隊會議以明確責任并為下一階段做好準備。階段Ⅲ是評估收尾階段。這時有兩項任務(wù)必須要做。首先是要產(chǎn)生最終報告，記錄核心評估階段的過程、信息和基于此的結(jié)論。另一項任務(wù)是進行總結(jié)以便改進今后的評估。一方面，可以詢問評估成員或者其他參與者感覺哪些活動好，哪些不好，為什么。可以收集關(guān)于本次評估的花費和收益的信息。這種數(shù)據(jù)挖掘可能會有利于找到各種活動的可改進之處。另一方面，可以整理本次的場景和相關(guān)的問題，以備下次評估類似項目。在領(lǐng)域特定的開發(fā)中，這項活動因其強大的可重用性而非常有效。階段Ⅰ和階段Ⅱ是核心評估階段，共有9個步驟，和前面小節(jié)曾講的步驟類似。這些步驟又進一步分為如下4個子階段：

1．介紹

(1)介紹ATAM：介紹ATAM的步驟、活動和技術(shù)。

(2)介紹商業(yè)動機：介紹商業(yè)目標以識別主要質(zhì)量需求。

(3)介紹體系結(jié)構(gòu)：解釋當前體系結(jié)構(gòu)如何滿足商業(yè)動機。

2．研究和分析

(4)識別體系結(jié)構(gòu)方法：找到建立體系結(jié)構(gòu)所用的方法。

(5)生成質(zhì)量屬性效用樹：以樹的形式產(chǎn)生反映系統(tǒng)效用的帶有優(yōu)先級的場景。

(6)分析體系結(jié)構(gòu)方法：對支持關(guān)鍵場景的體系結(jié)構(gòu)方法進行分析，并識別風險、非風險、敏感點和權(quán)衡點。

3．測試

(7)頭腦風暴和給場景指定優(yōu)先級：由更多的涉眾生成更多的場景。

(8)分析體系結(jié)構(gòu)方法：同步驟(6)，不過采用的場景來自步驟(7)。

4．報告

(9)報告結(jié)果：產(chǎn)生評估報告。

實際上，主要階段Ⅰ和Ⅱ分別是上述步驟的一次迭代，當然包括的具體步驟和參與者范圍有所不同，如表7-4所示。主要階段Ⅱ需要更多類型的涉眾參與場景生成和分析討論。主要階段Ⅰ則試圖利用幾個原則識別主要的質(zhì)量屬性，為后續(xù)評估打好基礎(chǔ)。主要階段Ⅰ只包含步驟(1)～(6)。當然，不必機械式地執(zhí)行這兩次迭代。實際應(yīng)用時評估團隊可以調(diào)整迭代這些步驟的時間計劃，并可以自行決定每次迭代的參與者。讀者可能會看到一些不熟悉的概念，如“效用樹”、“風險”或者“非風險”，也可能會問為什么步驟(6)看上去和步驟(8)一樣。這些問題在后面的小節(jié)中將有詳細介紹。7.4.4介紹

這個子階段的目標是界定哪些行動是有益的，而哪些不是。該階段引導(dǎo)參與者致力于系統(tǒng)設(shè)計并能做出貢獻。同時，后續(xù)步驟所需的輸入也由此階段提供。

步驟(1)——介紹ATAM。

這一步回答了“什么是ATAM？”和“ATAM參與者都做些什么？”的問題。這是因為除了專業(yè)的評估團隊，其他涉眾可能是第一次參與評估。評估負責人需要向參與者介紹ATAM，回答他們的相關(guān)問題。在此過程中，評估負責人的工作集中在場景確定優(yōu)先級、效用樹構(gòu)建等操作的步驟、概念和技術(shù)，評估的輸入輸出及其他有關(guān)信息。步驟(2)——介紹商業(yè)動機。

項目領(lǐng)導(dǎo)人(項目主要管理者或類似人員)需要向所有參與者解釋主要的商業(yè)動機。畢竟，場景開發(fā)和特定的評估需要此類信息。這項介紹的主題應(yīng)該包括：主要商業(yè)目標，需求說明中已文檔化的主要功能，來自技術(shù)、管理、經(jīng)濟、政策方面的有關(guān)限制，還有涉眾的重要質(zhì)量需求。注意“涉眾”這個概念，在不同主要階段，涉眾的范圍不同，這就使得關(guān)注點會有所偏重。這種差異也能作為一個參照，以便暴露那些沒被考慮的問題。步驟(3)——介紹體系結(jié)構(gòu)。

首席架構(gòu)師介紹已有的體系結(jié)構(gòu)，通常采用多視圖的形式。大多數(shù)項目需要展示靜態(tài)邏輯結(jié)構(gòu)的分解視圖、運行時結(jié)構(gòu)的構(gòu)件-連接件視圖、邏輯結(jié)構(gòu)和物理實體之間映射的分布視圖和描述期望行為的行為視圖。不過特定情況下，架構(gòu)師有權(quán)決定使用其他視圖展示系統(tǒng)某個特定區(qū)域，以此提供與關(guān)鍵質(zhì)量屬性對應(yīng)的體系結(jié)構(gòu)信息。體系結(jié)構(gòu)介紹的詳細程度直接影響后續(xù)的分析。根據(jù)在準備階段設(shè)定的評估的期望效果，架構(gòu)師有義務(wù)選擇一個對評估比較合適的詳細程度。當然在評估時，如果需要的體系結(jié)構(gòu)信息未被提供，涉眾可以向架構(gòu)師詢問。最后，一個重要任務(wù)就是列出明確使用的體系結(jié)構(gòu)方法，為下一步做準備。7.4.5研究和分析

在這個子階段，涉眾開始將體系結(jié)構(gòu)與質(zhì)量屬性對應(yīng)起來。不過和前述ATAM的其他版本相比，在此使用的具體方法更加出色。這里捕獲分析的不是體系結(jié)構(gòu)元素，而是體系結(jié)構(gòu)方法；用于場景生成的不是頭腦風暴一類的辦法，而是采用效用樹。在效用樹中，每個場景的優(yōu)先級由二維估計值來測量。評估中，要識別風險、非風險、敏感點和權(quán)衡點，不過這些識別是分析的開始而非結(jié)束。步驟(4)——識別體系結(jié)構(gòu)方法。

識別體系結(jié)構(gòu)方法的原因是這些信息提供了體系結(jié)構(gòu)構(gòu)建背后的基本原則。簡言之，一個體系結(jié)構(gòu)方法是指根據(jù)功能或質(zhì)量需求而做的設(shè)計決定。

眾所周知，軟件體系結(jié)構(gòu)風格和模式包含了大量的有用信息，這些信息與進行特定設(shè)計的原理緊密相關(guān)。體系結(jié)構(gòu)模式描述了必要的抽象元素、這些元素的結(jié)構(gòu)和相關(guān)的一些約束。每個體系結(jié)構(gòu)模式的優(yōu)缺點和基本原理都有成千上萬次的使用作基礎(chǔ)。ATAM第二版中提到的ABAS尤其有用。和ABAS相聯(lián)系的屬性值暴露了主要的質(zhì)量屬性目標，也能用來分析能否滿足這些目標。但是并不是所有的體系結(jié)構(gòu)方法都可以用體系結(jié)構(gòu)風格或模式的形式表達。如果是這樣，架構(gòu)師就需要用自然語言解釋為什么做出這樣的設(shè)計，或為什么設(shè)計會以期望的方式運行。架構(gòu)師應(yīng)該能講清楚使用的每個體系結(jié)構(gòu)方法。這樣，對于那些架構(gòu)師覺得很基礎(chǔ)，但是對評估非常重要的體系結(jié)構(gòu)方法(于是如果不是被明確的問到，架構(gòu)師不會做特別說明)，其他評估參與者也有機會理解。

盡管這一步驟需要清晰的解釋，但是不需要對方法的分析，那是步驟(6)中的任務(wù)。步驟(5)——生成質(zhì)量屬性效用樹。

本步驟將識別關(guān)鍵質(zhì)量屬性目標，參與者是評估團隊和核心項目成員，如管理者、客戶代表和首席架構(gòu)師。這里主要的目標是避免在評估上時間和費用的浪費。如果參與者不能決定出關(guān)鍵的質(zhì)量屬性目標或就此達成一致，評估就無法得到應(yīng)有的效果。質(zhì)量屬性效用樹是達到此目標的強大工具。質(zhì)量屬性效用樹(QualityAttributeUtilityTree，QAUT)以樹的形式表現(xiàn)質(zhì)量屬性的細化。QAUT的根是效用，接下來是質(zhì)量屬性層，典型的有可用性、可修改型和安全性等。再接著下一層是質(zhì)量屬性具體描述分類，也就是把某個質(zhì)量屬性分成幾個主題。第四層也是最后一層，是具體的場景，精確定義了質(zhì)量需求以允許后續(xù)分析。一般來說，QAUT把系統(tǒng)的期望效用翻譯成了場景。每個場景有兩維度量：

(1)此場景對系統(tǒng)成功的重要程度。

(2)架構(gòu)師所估計的支持此場景的開發(fā)難度。測量所用的標度可以定為類似高、中、低這樣范圍為3的序數(shù)尺度，范圍為5或者10等也可以。標記好度量后，場景就可以排出優(yōu)先級了，最上面的是參與者希望得到的最關(guān)鍵的質(zhì)量屬性目標。圖7-6是QAUT的一個例子。實際上，真實項目中生成的場景比此例復(fù)雜得多。最終QUAT生成了帶有優(yōu)先級的場景列表，順序應(yīng)該是(H，H)、(H，M)、(M，H)……(L，L)。這個優(yōu)先級清楚地揭示了各種涉眾的全面關(guān)注。也許有人認為性能是關(guān)鍵需求，而另一些人堅持可用性需要更多的關(guān)注。但是在建立QAUT之前，每個人的想法可能都是凌亂的。QAUT引導(dǎo)并澄清系統(tǒng)的質(zhì)量需求及其相對重要性。于是，評估的時間和成本不夠時就可以省略優(yōu)先級低的場景。因為分析不重要或者很簡單的場景沒什么意義。步驟(6)——分析體系結(jié)構(gòu)方法。

QAUT指明了評估的方向，之后就該分析體系結(jié)構(gòu)方法處理高優(yōu)先級場景的機制了。在這一步驟，評估團隊和架構(gòu)師一道識別在那些和重要場景相關(guān)的方法中存在的風險、非風險、敏感點和權(quán)衡點。圖7-6質(zhì)量屬性效用樹示例風險是已經(jīng)做出的但是在特定的可能情況下出現(xiàn)潛在問題的決策。而非風險正好相反?？赡苡腥藭f風險應(yīng)該受到更多關(guān)注，因為它們是將來的問題之源。不過，非風險也一樣重要，因為它們暗示了哪些體系結(jié)構(gòu)方法值得保留和堅持。更重要的是，當上下文變化的時候，非風險可能會轉(zhuǎn)變成風險。因此，顯式地列出非風險是有用的。

敏感點是指會被某些體系結(jié)構(gòu)元素顯著影響的系統(tǒng)模型的屬性值。權(quán)衡點是系統(tǒng)內(nèi)與幾個敏感點都相關(guān)的地方。在步驟(4)和步驟(5)中這些需要的信息應(yīng)該就準備好了。不過若評估團隊感到有什么信息缺失，可以詢問架構(gòu)師。為了識別風險、非風險、敏感點和權(quán)衡點，全體參與者都要完成下述工作：

(1)識別出試圖支持重要場景的體系結(jié)構(gòu)方法并弄清楚這些方法在當前體系結(jié)構(gòu)中是怎么實例化的。

(2)分析每個方法，考慮其明顯的優(yōu)點和缺點，判斷其是否對質(zhì)量屬性帶來負面影響。這項工作可以利用詢問一系列附屬于這種體系結(jié)構(gòu)方法的特定問題來完成。

(3)在回答這些問題的基礎(chǔ)上，識別風險、非風險、敏感點和權(quán)衡點并分別記錄在文檔中。 這一步驟結(jié)束，主要階段Ⅰ就完成了。如果一切順利，評估團隊應(yīng)該對體系結(jié)構(gòu)有了大致的了解，也清楚了其優(yōu)缺點。7.4.6測試

這一階段的目的是對到目前為止所作的分析進行測試。會有更多種類的涉眾就系統(tǒng)質(zhì)量需求給出建議。討論的范圍被擴大了，因而會有額外的問題和關(guān)注點出現(xiàn)來對系統(tǒng)需求進行補充。步驟(7)——頭腦風暴和設(shè)定場景優(yōu)先級。

在步驟(5)中，場景表示為QAUT，表明項目決策者心目中的體系結(jié)構(gòu)該是什么樣子。不過在這一步，評估團隊的范圍更大了。這里得到更多場景的有效方法是頭腦風暴，就像SAAM的場景生成采用的方式。這種環(huán)境容易激發(fā)創(chuàng)造性的想法和新穎的建議。按性質(zhì)場景可以分為以下3類：

(1)用例場景：描述被評估體系結(jié)構(gòu)所在的系統(tǒng)在最終用戶的特定操作下如何動作和響應(yīng)。

(2)增長式場景：描述被評估體系結(jié)構(gòu)所在的系統(tǒng)怎樣支持快速修改和演化的，比如添加構(gòu)件、平臺移植或者與其他系統(tǒng)集成。

(3)探索式場景：探索被評估體系結(jié)構(gòu)所在系統(tǒng)的極端增長情況。如果說增長式場景試圖揭示期望中的和可能的修改，那么探索式場景使評估參與者有機會知道重大變更后系統(tǒng)會發(fā)生什么。比如說，性能必須提高5倍，或可用性需要提高一個數(shù)量級。根據(jù)這類場景，額外的敏感點和權(quán)衡點將會暴露，評估測試可基于此。頭腦風暴后，利用投票為場景設(shè)置優(yōu)先級，這和SAAM類似。顯然步驟(5)和本步驟生成的場景有顯著差異。利用QAUT生成場景是細化的過程，看起來是自頂向下的風格。評估團隊和核心項目決策人通過QAUT找到當前體系結(jié)構(gòu)的主要質(zhì)量驅(qū)動。而頭腦風暴生成的場景需要幾乎所有涉眾的合作。測試時，本步驟生成的場景將和QAUT的結(jié)果比對。新的場景成為QAUT已有分支的葉子節(jié)點，也可能原來就完全沒有相應(yīng)的質(zhì)量屬性分支。評估測試的目的也正是如此，即暴露二者之間的差異，補充未考慮到的場景。步驟(8)——分析體系結(jié)構(gòu)方法。

這一步使用的方法和技術(shù)同步驟(6)，主要差別在于，在此涉眾分析的是步驟(7)產(chǎn)生的體系結(jié)構(gòu)方法。如果一切順利，那么架構(gòu)師只需要解釋是如何用那些被捕獲的方法來實現(xiàn)場景的。但是如果存在某些場景不能被直接支持，那么評估團隊應(yīng)該記錄在檔以便制定修改計劃。7.4.7報告

步驟(9)——提供評估結(jié)果。

這是ATAM一輪迭代的最后一步，包括已收集在原始體系結(jié)構(gòu)文檔內(nèi)的、涉眾生成的和分析得到的所有信息都要體現(xiàn)在評估報告中。最重要的內(nèi)容或者說ATAM的輸出，包括文檔化的體系結(jié)構(gòu)方法(包括這些方法附屬的問題)、帶優(yōu)先級的場景、QAUT、關(guān)鍵質(zhì)量需求、風險、非風險、敏感點和權(quán)衡點。所有涉眾一起討論來解決當前體系結(jié)構(gòu)的問題，尤其是風險和權(quán)衡點。

7.5SAAM方法評估實例

我們在本節(jié)介紹一個使用SAAM方法的實例。?我們使用SAAM方法對第3章介紹過的KWIC(在文章中查找和重組關(guān)鍵詞)系統(tǒng)中的不同場景進行評估。

1．定義角色和場景

KWIC系統(tǒng)感興趣的角色有兩個，分別是最終用戶和開發(fā)人員。使用四個場景，其中兩個場景經(jīng)過了不同的最終用戶的討論，即

(1)修改KWIC程序，使之成為一個增量方式而不是批處理的方式。這個程序版本將能一次接受一個句子，產(chǎn)生一個所有置換的字母列表。

(2)修改KWIC程序，使之能刪除在句子前端的噪音單詞(例如前置詞、代名詞、連詞等)。使用的另外兩個場景是經(jīng)過開發(fā)人員討論，但最終用戶不知道的，即

(1)改變句子的內(nèi)部表示(例如，壓縮和解壓縮)。

(2)改變中間數(shù)據(jù)結(jié)構(gòu)的內(nèi)部表示(例如，可直接存儲置換后的句子，也可存儲轉(zhuǎn)換后的詞語的地址)。

2．描述體系結(jié)構(gòu)

第2步就是使用通用的表示對待評估的體系結(jié)構(gòu)進行描述，這種描述是為了使評估過程更容易，使評估人員知道體系結(jié)構(gòu)圖中的框或箭頭的準確含義。這里對兩種體系結(jié)構(gòu)風格進行評估。

1)共享內(nèi)存的解決方案

在第一個待評估的體系結(jié)構(gòu)中，有一個全局存儲區(qū)域，被稱做Sentences，用來存儲所有輸入的句子。其執(zhí)行的順序是：輸入例程讀入句子→存儲句子→循環(huán)轉(zhuǎn)換例程轉(zhuǎn)換句子→字母例程按字母順序排列句子→輸出。當需要時，主控程序傳遞控制信息給不同的例程。圖7-7描述了這個過程，不同計算構(gòu)件上的數(shù)字代表場景編號，在這一步中可忽略(將在后面用到)。圖7-7共享內(nèi)存的解決方案示例

2)抽象數(shù)據(jù)類型解決方案

待評估的第2個體系結(jié)構(gòu)使用抽象數(shù)據(jù)類型(AbstractDataType，ADT)，如圖7-8所示。其中每個功能都隱藏和保護了其內(nèi)部數(shù)據(jù)表示，提供專門的存取函數(shù)作為唯一的存儲、檢索和查詢數(shù)據(jù)的方式。ADTSentences有兩個函數(shù)，分別是set和getNext，用來增加和檢索句子；ADTShiftedSentences提供了存取函數(shù)setup和getNext，分別用來建立句子的循環(huán)置換和檢索置換后的句子。圖7-8抽象數(shù)據(jù)類型解決方案示例

ADTShiftedSentences使用ADTSentences的getNext函數(shù)來重新存儲輸入的句子。ADTAlphabetizedSentences提供了一個setup函數(shù)和一個i-th函數(shù)，setup函數(shù)重復(fù)調(diào)用ShiftedSentences的getNext函數(shù)，以檢索已經(jīng)存儲的所有行并進行排序，i-th函數(shù)根據(jù)參數(shù)i，從存儲隊列中返回第i個句子。

3．評估體系結(jié)構(gòu)

既然已經(jīng)把待評估的體系結(jié)構(gòu)用通用的符號標記了出來，接下來就是評估體系結(jié)構(gòu)滿足場景的程度。通過依次考慮每個場景來進行評估。我們所選擇的用來評估的所有場景都是間接場景，也就是說，這些場景不能被待評估的體系結(jié)構(gòu)直接執(zhí)行，因此評估依賴于體系結(jié)構(gòu)的某些修改。

(1)場景1。第一個場景是從批處理模式轉(zhuǎn)移到增量模式，也就是說，不是把所有句子都輸入完后再一次性進行處理，而是一次只處理一個句子。

對共享內(nèi)存解決方案而言，這需要修改Input例程，使之在讀入一個句子后讓出控制權(quán)，同時，也要修改MasterControl主控程序，因為子例程不再是按順序一次只調(diào)用一個，而是一個迭代調(diào)用的過程。還要修改Alphabetizer例程，因為使用增量模式后，牽涉到插入排序的問題。我們假設(shè)CircularShift例程一次只處理一個句子，且輸出函數(shù)只要被調(diào)用，就可以輸出。注意，我們所作的假設(shè)只是針對共享內(nèi)存解決方案而言的，一般來說，判斷的準確性取決于不同的計算構(gòu)件的內(nèi)部工作知識。這也是為什么要期望評估人員中，既有具有計算構(gòu)件一般知識的人，也有具有特定構(gòu)件知識的人。

對抽象數(shù)據(jù)類型解決方案而言，Input函數(shù)需要修改，使之在被調(diào)用時，一次只輸入一行。假設(shè)Sentence當存儲了輸