1、課 程 內 容 軟件重用與構件技術 軟件體系結構概論 軟件體系結構的風格 軟件體系結構描述 軟件體系結構設計 基于體系結構的軟件開發過程 軟件體系結構評估 Web服務體系結構 特定領域的軟件體系結構 軟件體系結構集成開發環境體系結構的選擇是一個軟件系統設計成敗的關鍵，但是，怎樣才能知道為軟件系統所選用的體系結構是否恰當？如何確保按照所選用的體系結構能順利地開發出成功的軟件產品呢？要回答這些問題，需要使用專門的方法對軟件體系結構進行評估。 體系結構評估可以只針對一個體系結構，也可以針對一組體系結構。在體系結構評估過程中，評估人員所關注的是系統的質量屬性，所有評估方法所普遍關注的質量屬性有以下幾個

2、：可用性、性能、可修改性、可靠性、安全性、可測試性、易用性、可重用性、可集成性等。第7章 軟件體系結構評估 7.1 體系結構評估概述第7章 軟件體系結構評估 7.1 體系結構評估概述 評估的必要性（1）軟件體系結構反映了系統最初始的設計決策，對同樣一個問題，在初始階段糾正所帶來的花費和在測試或部署階段糾正導致的開銷不在一個數量級。在體系結構視圖上一個符號改動比后期大規模的代碼改動工作量要少得多，這樣，巨大的額外開銷就避免了。有了對體系結構的完整描述，退一步講即使是部分描述，就能模擬系統運行時行為，對一些設計思想進行探討，并推斷體系結構應用于系統時的潛在影響。而所有這些工作只不過需要整個項目周期

3、中的幾天時間。 第7章 軟件體系結構評估 7.1 體系結構評估概述 評估的必要性（2）評估是挖掘隱性需求并將其補充到設計中的最后機會。由于缺乏充分的交流和不能對軟件項目透徹理解，許多涉眾并不知道自己到底想要什么。在需求獲取階段，他們會列出自認為最重要的幾項要求。但是評估之后，這些觀點可能會變動很大。有些起初重視的方面可能并不是那么重要，而另一些本來看上去無關緊要的東西卻被發現需要花更多精力來處理。體系結構評估清除了涉眾的溝通障礙。其最直接的結果就是得到各方滿意的系統藍圖，而這至少意味者項目成功的一半。 第7章 軟件體系結構評估 7.1 體系結構評估概述 評估的必要性（3）體系結構是開發過程的中

4、心，它決定了團隊組織，任務分配，配置管理，文檔組織，管理策略，還有開發進程安排。不良體系結構往往帶來不良的效果，因為它在被使用過程中必須被修改來適應新的考量，或者去彌補那些在開發早期階段沒考慮到的缺陷，在這些方面進行修改需要花費大量成本。如果在這些發生之前充分分析一下體系結構就可以部分避免這些問題的發生。 第7章 軟件體系結構評估 7.2 SA評估的主要方式 主要的評估方式 基于調查問卷或檢查表的評估方式 基于場景的評估方式 基于度量的評估方式 第7章 軟件體系結構評估 基于調查問卷或檢查表的評估方式(1) CMU/SEI的軟件風險評估過程采用了這一方式。 調查問卷是一系列可以應用到各種體系結

5、構評估的相關問題，其中有些問題可能涉及到體系結構的設計決策；有些問題涉及到體系結構的文檔，有的問題針對體系結構描述本身的細節問題。 檢查表中包含一系列比調查問卷更細節和具體的問題，它們更趨向于考察某些關心的質量屬性。7.2 SA評估的主要方式第7章 軟件體系結構評估 基于調查問卷或檢查表的評估方式(2) 這一評估方式比較自由靈活，可評估多種質量屬性，也可以在軟件體系結構設計的多個階段進行。但是由于評估的結果很大程度上來自評估人員的主觀推斷，因此不同的評估人員可能會產生不同甚至截然相反的結果，而且評估人員對領域的熟悉程度、是否具有豐富的相關經驗也成為評估結果是否正確的重要因素。 盡管基于調查問卷

6、與檢查表的評估方式相對比較主觀，但由于系統相關的人員的經驗和知識是評估軟件體系結構的重要信息來源，因而它仍然是進行軟件體系結構評估的重要途徑之一。7.2 SA評估的主要方式第7章 軟件體系結構評估 基于場景的評估方式(1) 場景是一系列有序的使用或修改系統的步驟。基于場景的方式由SEI首先提出并應用在體系結構權衡分析方法（ATAM）和軟件體系結構分析方法（SAAM）中。 這種軟件體系結構評估方式分析軟件體系結構對場景也就是對系統的使用或修改活動的支持程度，從而判斷該體系結構對這一場景所代表的質量需求的滿足程度。例如，用一系列對軟件的修改來反映易修改性方面的需求，用一系列攻擊性操作來代表安全性方

7、面的需求等。7.2 SA評估的主要方式第7章 軟件體系結構評估 基于場景的評估方式(2) 這一評估方式考慮到了包括系統的開發人員、維護人員、最終用戶、管理人員、測試人員等在內的所有與系統相關的人員對質量的要求。基于場景的評估方式涉及到的基本活動包括確定應用領域的功能和軟件體系結構的結構之間的映射，設計用于體現待評估質量屬性的場景以及分析軟件體系結構對場景的支持程度。 7.2 SA評估的主要方式 不同的應用系統對同一質量屬性的理解可能不同，例如，對操作系統來說，可移植性被理解為系統可在不同的硬件平臺上運行，而對于普通的應用系統而言，可移植性往往是指該系統可在不同的操作系統上運行。由于存在這種不一

8、致性，對一個領域適合的場景設計在另一個領域內未必合適，因此基于場景的評估方式是特定于領域的。這一評估方式的實施者一方面需要有豐富的領域知識以對某一質量需求設計出合理的場景，另一方面，必須對待評估的軟件體系結構有一定的了解以準確判斷它是否支持場景描述的一系列活動。第7章 軟件體系結構評估 基于場景的評估方式(3) 7.2 SA評估的主要方式第7章 軟件體系結構評估 基于度量的評估方式(1) 度量是指為軟件產品的某一屬性所賦予的數值，如代碼行數、方法調用層數、構件個數等。傳統的度量研究主要針對代碼，但近年來也出現了一些針對高層設計的度量，軟件體系結構度量即是其中之一。代碼度量和代碼質量之間存在著重

9、要的聯系，類似地，軟件體系結構度量應該也能夠作為評判質量的重要的依據。 7.2 SA評估的主要方式 赫爾辛基大學提出的基于模式挖掘的面向對象軟件體系結構度量技術、Karlskrona和Ronneby提出的基于面向對象度量的軟件體系結構可維護性評估、西弗吉尼亞大學提出的軟件體系結構度量方法等都在這方面進行了探索，提出了一些可操作的具體方案。我們把這類評估方式稱作基于度量的評估方式。第7章 軟件體系結構評估 基于度量的評估方式(2) 7.2 SA評估的主要方式第7章 軟件體系結構評估 基于度量的評估方式(3) 基于度量的評估技術都涉及三個基本活動：首先需要建立質量屬性和度量之間的映射原則，即確定怎

10、樣從度量結果推出系統具有什么樣的質量屬性；然后從軟件體系結構文檔中獲取度量信息；最后根據映射原則分析推導出系統的某些質量屬性。7.2 SA評估的主要方式 基于度量的評估方式提供更為客觀和量化的質量評估。這一評估方式需要在軟件體系結構的設計基本完成以后才能進行，而且需要評估人員對待評估的體系結構十分了解，否則不能獲取準確的度量。自動的軟件體系結構度量獲取工具能在一定程度上簡化評估的難度，例如MAISA可從文本格式的UML圖中抽取面向對象體系結構的度量。第7章 軟件體系結構評估 基于度量的評估方式(4) 7.2 SA評估的主要方式第7章 軟件體系結構評估 三種評估方式的比較 7.2 SA評估的主要

11、方式第7章 軟件體系結構評估 基本概念 （1） 敏感點和權衡點 敏感點是一個或多個構件（和/或構件之間的關系）的特性。研究敏感點可使設計人員或分析員明確在搞清楚如何實現質量目標時應注意什么。 權衡點是影響多個質量屬性的特性，是多個質量屬性的敏感點。例如，改變加密級別可能會對安全性和性能產生非常重要的影響。提高加密級別可以提高安全性，但可能要耗費更多的處理時間，影響系統性能。如果某個機密消息的處理有嚴格的時間延遲要求，則加密級別可能就會成為一個權衡點。7.2 SA評估的主要方式第7章 軟件體系結構評估 基本概念 （2）風險承擔者 系統的體系結構涉及到很多人的利益，這些人都對體系結構施加各種影響，

12、以保證自己的目標能夠實現。 7.2 SA評估的主要方式第7章 軟件體系結構評估 基本概念 （3）場景 在進行體系結構評估時，一般首先要精確地得出具體的質量目標，并以之作為判定該體系結構優劣的標準。我們把為得出這些目標而采用的機制叫做場景。場景是從風險承擔者的角度對與系統的交互的簡短描述。在體系結構評估中，一般從刺激源、刺激、環境、制品、響應和響應度量這六個方面來對場景進行描述。7.2 SA評估的主要方式第7章 軟件體系結構評估 7.3 SAAM評估方法SAAM方法是最早形成文檔并得到廣泛使用的軟件體系結構分析方法，最初是用來分析體系結構的可修改性的，但實踐證明，SAAM方法也可用于對許多質量屬

13、性（例如可移植性、可擴充性、可集成性等）及系統功能進行快速評估。SAAM比較簡單，這種方法易學易用，進行培訓和準備的工作量都比較少。第7章 軟件體系結構評估 7.3 SAAM評估方法SAAM是一種直觀的方法，它試圖通過場景來測量軟件的質量，而不是泛泛的不精確的質量屬性描述。SAAM也比較簡單，僅僅考慮場景和體系結構的關系，也不涉及太多的步驟和獨特的技術。于是，它成為體系結構評估初學者的理想入門方法。SAAM最初是為了評估體系結構的可修改性而設計，不過經過演化和實際應用，在許多其它常見的質量屬性評估方面也展現了威力，并成為其它一些評估方法的基礎，比如ATAM。利用預先定義的場景，SAAM可以檢查

14、出被評估體系結構的潛在風險，并對幾個候選體系結構進行比較。第7章 軟件體系結構評估 7.3 SAAM評估方法另外，SAAM可以為很多涉眾進行（可能是項目啟動后的第一次）討論提供平臺。這樣大家就有機會用人人都懂的語言來說出各自關心的問題，了解別人所關心的，并看到這些問題又是如何在藍圖中處理的。在此過程中，理解上的偏差和不正確的設計都將被發現。 下圖給出了SAAM評估的步驟，每個階段能得到什么，各個階段的關系如何。第7章 軟件體系結構評估 7.3 SAAM評估方法 SAAM評估的步驟 1、形成場景2、描述體系結構3、對場景進行分類和確定優先級4、對間接場景進行單個評估5、評估場景的相互作用6、形成

15、總體評估為了開始評估，必須提供一個體系結構描述，該描述可以是所有參與者能接受并理解的任何形式。根據特定評估的對象和關注點，描述的詳細程度和范圍可能不同，有時也需要進行更新或補充。多種不同的候選體系結構的描述都可以拿來評估以便對比和選擇。 第7章 軟件體系結構評估 7.3 SAAM評估方法 SAAM評估的步驟 場景是體系結構描述之外的另一個關鍵輸入。基于場景的評估方法的基本要點就是檢查當前的體系結構能否直接滿足期望的質量需求，并在不能滿足時看看可以怎樣改動。我們幾乎不可能對質量屬性進行精確測量，可又希望質量屬性對評估有意義，所以必須以一種更實在的形式來表述它。這就是場景為什么這么重要的原因。有些

16、場景可能可以在功能性需求中提取出來，不過大多數都是源自涉眾的討論和頭腦風暴。當然，待評估的體系結構起碼得支持需求說明中的所有功能。而評估過程的關鍵是搞清楚體系結構是否能在滿足需求的情況下擁有良好的質量屬性。 第7章 軟件體系結構評估 7.3 SAAM評估方法 SAAM評估的步驟 SAAM主要是以評估報告的形式輸出。如果是評估單個體系結構，那么報告的內容將包括該體系結構設計不能滿足質量需求的缺陷；多個體系結構情況下將報告哪個候選體系結構能最好地滿足場景。由不適當分解或過分復雜導致不良設計也會在報告中被指出。最后，SAAM可以估計修改導致的費用和范圍，以避免盲目的修改。第7章 軟件體系結構評估 7

17、.3 SAAM評估方法 SAAM評估的步驟 除此之外，SAAM還有一些優點。它增強了涉眾對體系結構的理解，強制對體系結構更好的編檔，澄清系統將來演化最可能的方向。通過涉眾廣泛的討論，業務目標的優先級和潛在的場景也得以澄清。 第7章 軟件體系結構評估 7.3 SAAM評估方法 SAAM評估的步驟 1、形成場景 在形成場景的過程中，要注意全面捕捉系統的主要用途、系統用戶類型、系統將來可能的變更、系統在當前及可預見的未來必須滿足的質量屬性等信息。只有這樣，形成的場景才能代表與各種風險承擔者相關的任務。第7章 軟件體系結構評估 7.3 SAAM評估方法 SAAM評估的步驟 形成場景的過程也是集中討論的

18、過程。集體討論能夠使風險承擔者在一個友好的氛圍中提出一個個場景，這些場景反映了他們的需求，也體現了他們對體系結構將如何實現他們的需求的認識。某一個場景可能只反映一個風險承擔者的需求，也可能反映多個風險承擔者的需求。例如，對于某個變更，開發人員關心的是實現該變更的難度和對性能的影響，而系統管理員則關心此變更對體系結構的可集成性的影響。在評估過程中，隨著場景的不斷提出，記錄人員要把它們都記錄在冊，形成文檔，供所有參加評估的人員查閱。第7章 軟件體系結構評估 7.3 SAAM評估方法 SAAM評估的步驟 提出和收集場景的過程經常要重復兩次或多次。形成場景和描述體系結構的工作是相關聯的，這兩個步驟可重

19、復進行，是一個迭代的過程。 第7章 軟件體系結構評估 7.3 SAAM評估方法 SAAM評估的步驟 2、描述體系結構 在這一步，體系結構設計師應該采用參加評估的所有人員都能充分理解的形式，對待評估的體系結構進行適當的描述。這種描述必須要說明系統中的運算和數據構件，也要講清它們之間的聯系。除了要描述這些靜態特性外，還要對系統在某段時間內的動態特征做出說明。描述既可采用自然語言，也可采用形式化的手段。第7章 軟件體系結構評估 7.3 SAAM評估方法 SAAM評估的步驟 場景的形成和對體系結構的描述通常是相互促進的。一方面，對體系結構的描述使風險承擔者考慮針對所評估的體系結構的某些具體特征的場景；

20、另一方面，場景也反映了對體系結構的需求，因此必須體現在體系結構的描述中。 第7章 軟件體系結構評估 7.3 SAAM評估方法 SAAM評估的步驟 3、對場景進行分類和確定優先級 在SAAM評估中，場景就是對所期望的系統中某個使用情況的簡短描述。體系結構可能直接支持該場景，即這一預計的使用情況不需要對體系結構做任何修改即可實現。這一般可以通過演示現有的體系結構在執行此場景時的表示來確定。在SAAM評估方法中稱這樣的場景為直接場景。即直接場景是按照現有體系結構開發出來的系統能夠直接實現的場景。第7章 軟件體系結構評估 7.3 SAAM評估方法 SAAM評估的步驟 如果所評估的體系結構不能直接支持某

21、一場景，就必須對所描述的體系結構做些修改。可能要對執行某一功能的一個或多個構件進行更改、為實現某一功能而增加一個構件，為已有構件建立某種新的聯系、刪除某個構件或某種聯系、更改某一接口，或者是以上多種情況的綜合，這樣的場景叫做間接場景。第7章 軟件體系結構評估 7.3 SAAM評估方法 SAAM評估的步驟 間接場景就是需要對現有體系結構做些修改才能支持的場景，間接場景對于衡量體系結構對系統在演化過程中將出現的變更的適應情況十分關鍵。通過各種間接場景對體系結構的影響，可以確定出體系結構在相關系統的生命周期內對不斷演化的使用的適應情況。第7章 軟件體系結構評估 7.3 SAAM評估方法 SAAM評估

22、的步驟 評估人員通過對場景設置優先級，可保證在評估的優先時間內考慮最重要的場景。這里的“重要”完全是由風險承擔者及其所關心的問題確定的。風險承擔者們通過投票表達出所關心的問題。每個參加評估的風險承擔者都將拿到固定數量的選票，向每個風險承擔者發放的選票數一般是待評估場景數量的30%，他們可以用自己認為合適的方式投票，可把這些票全部投給某一個場景，或者每個場景投2-3張票，還可以一個場景一張票等。第7章 軟件體系結構評估 7.3 SAAM評估方法 SAAM評估的步驟 只要每個人投票總數不超過手中的選票總數，他可以為任何場景投任何數目的票。然后按照得到選票數目的順序對所有場景進行排序，并根據具體情況

23、選擇一定數目的排序靠前的場景。有時候，排序后的列表可能會有一個涇渭分明的分界，一邊是得到很多票的場景，另一邊得票數很少（如圖7-2所示），那么直接選擇得票多的場景即可。第7章 軟件體系結構評估 7.3 SAAM評估方法 SAAM評估的步驟 第7章 軟件體系結構評估 7.3 SAAM評估方法 SAAM評估的步驟 其它時候，可以計算一下評估多少場景比較適合，或者估計一下評估時間內能完成多少。典型的比如說，一整天可以評估完8個場景而你計劃兩天的時間進行場景的單個評估，那么選擇15或16個比較合適。要注意的是即使根據預先定好的規則某些場景是應該放棄的，但如果它們的提出者仍然堅持而其它人又不反對的話，那

24、么也可以添加到“關鍵”列表中。 第7章 軟件體系結構評估 7.3 SAAM評估方法 SAAM評估的步驟 4、對間接場景進行單個評估 一旦確定了要考慮的一組場景，就要把這些場景與體系結構的描述對應起來。對于直接場景而言，體系結構設計師需要講清所評估的體系結構將如何執行這些場景；對于間接場景而言，體系結構設計師應說明需要對體系結構做哪些修改才能適應間接場景的要求。第7章 軟件體系結構評估 7.3 SAAM評估方法 SAAM評估的步驟 對每一個間接場景，必須列出為支持該場景而需要對體系結構所做的改動，并估計出這些變更的代價。對體系結構的更改意味著引入某個新構件或新聯系，或者需要對已有構件或聯系的描述

25、進行修改。在這一步快結束時，應該給出全部場景的總結性列表。對每個間接場景，都應描述出要求做的更改，并由記錄人員記錄下來，形成文檔。在描述中應包括對完全實現每個更改的代價的估計（包括測試和調試的時間）。(表7-2)第7章 軟件體系結構評估 7.3 SAAM評估方法 SAAM評估的步驟 第7章 軟件體系結構評估 7.3 SAAM評估方法 SAAM評估的步驟 表7-2 SAAM間接場景單個評估表場景編號場景描述所需改動需改動元素數估計工作量F4允許同其它系統交換數據數據序列化模塊，數據交換接口212個工作日F8加入上下文相關的幫助上下文相關的UI控制，幫助文檔230個工作日F9支持多個DBMS數據管

26、理抽象13個工作日 5、評估場景的相互作用 當兩個或多個間接場景要求更改體系結構的同一個構件時，我們就稱這些場景在這一組構件上相互作用。那么，為什么要強調場景的相互作用呢？ 首先，場景的相互作用暴露了設計方案中的功能分配。場景相互作用的多少與結構復雜性、耦合度、內聚性等有關。第7章 軟件體系結構評估 7.3 SAAM評估方法 SAAM評估的步驟 例如，如果場景1和場景2是屬于不同類別的，并且都影響構件X，那末構件X在結構劃分方面可能存在著耦合問題。這時場景1和場景2的交互體現出系統結構沒有很好地劃分構件。另一方面，如果場景1和場景2是同一類的，那么它們在構件X內部的交互反映出該模塊具有良好的內

27、聚性。第7章 軟件體系結構評估 7.3 SAAM評估方法 SAAM評估的步驟 其次，場景的相互作用能夠暴露出體系結構設計文檔未能充分說明的結構分解。如果場景在某一構件內相互作用，但該構件實際上又分解成未表現出場景相互作用的子構件，就會出現這種文檔描述不當的情況。如果真的出現了這種情況，則必須重新審核第2步（描述體系結構）的工作。 第7章 軟件體系結構評估 7.3 SAAM評估方法 SAAM評估的步驟 6、形成總體評估 SAAM的最后一步是形成總結報告。如果候選體系結構只有一個，那么總體評估要做的就是審查前面步驟的結果并總結成報告。修改計劃將基于此報告。 第7章 軟件體系結構評估 7.3 SAA

28、M評估方法 SAAM評估的步驟 如果有多個候選體系結構，就需要進行一番比較。為此需要根據各個關鍵場景和商務目標的關系來決定每個關鍵場景的權重。比較體系結構時會發現，某個體系結構在某些場景下表現突出，而另一個體系結構在另一些場景下最好。有時簡單的根據候選體系結構在哪些場景下具有優勢很難做出最好的選擇。而事實上，即使同樣叫做關鍵場景，場景的重要性也是不同的。這可以通過設置權重來體現。多年來，出現了幾種決定權重的策略。其中一種方式是利用涉眾的討論，有時是爭論來得到相對權重。或者，如果有歷史記錄，則是很好的參考資料。 第7章 軟件體系結構評估 7.3 SAAM評估方法 SAAM評估的步驟 直接場景也影

29、響總體評估結果。不同的候選體系結構幾乎總是有各自不同的直接場景。回憶一下，直接場景是不經修改就被體系結構支持的那些場景。所以支持更多直接場景的體系結構也暗示著這是一個更好的候選。有時，也會把直接場景的重要性放到總體評估這里一起考慮。 第7章 軟件體系結構評估 7.3 SAAM評估方法 SAAM評估的步驟 最后，架構師對每個關鍵場景下各個候選體系結構打分。一般來說，打分采用相對值的方法，比如“1，0，-1”（或“2，1，0”、“+，0，-”等）。1表示體系結構在該場景下表現很好；-1相反；0則表示體系結構對該場景無關緊要。根據需要把范圍定到5或者10也沒問題。有了場景權重和體系結構的得分，就可以

30、畫一個類似表7-3的表格。然后把該表格和獨立場景評估、場景關聯評估和直接場景分析的結果結合起來，選擇一個最好的體系結構作為下一步開發的基礎。 第7章 軟件體系結構評估 7.3 SAAM評估方法 SAAM評估的步驟 第7章 軟件體系結構評估 7.3 SAAM評估方法表7-3 SAAM總體評估示例場景編號權重候選1候選2F481-1F581-1F8510F107-11F131001F14601總體評估得分4567使用ATAM方法對軟件體系結構進行評估的目標是理解體系結構關于軟件系統的質量屬性需求決策的結果。ATAM方法不但揭示了體系結構如何滿足特定的質量目標（例如性能和可修改性），而且還提供了這些

31、質量目標是如何交互的，即它們之間是如何權衡的。這些設計決策很重要，一直會影響到整個軟件生命周期，并且在軟件實現后很難修改這些決策。第7章 軟件體系結構評估 7.4 ATAM評估方法最初的ATAM分成4個階段內的6個步驟，如圖7-3所示。 第7章 軟件體系結構評估 7.4 ATAM評估方法圖7-3把評估集成到了整個設計過程中。6個步驟，即收集場景，收集需求、限制和環境，描述體系結構視圖，屬性特定分析，識別敏感點和權衡點，構成了一輪迭代。完成上述步驟后如果評估結果表明當前體系結構能滿足期望的質量需求，就可以進行詳細設計或實現了。否則，可以制定修改計劃更新已有設計，新的設計將進入第二輪ATAM的迭代

32、。值得注意的是，這些步驟并不需要按照線性順序操作。每個步驟都可能會觸發任何其它步驟的改進。 第7章 軟件體系結構評估 7.4 ATAM評估方法改進版ATAM1999年，ATAM在幾個實際項目中應用后，有了升級和增強。ATAM的原有步驟有的進行了合并，另外又補充了幾個其它的步驟（如圖7-4所示）。比如，增加了“場景分組和設置優先級”，這個步驟和SAAM中類似。有幾個步驟被濃縮成一個，如“體系結構介紹”。 第7章 軟件體系結構評估 7.4 ATAM評估方法第7章 軟件體系結構評估 7.4 ATAM評估方法對比兩個版本的ATAM，可以看到一個趨勢，就是更多實際的技術和關注點被加入進來。第一版建立在螺

33、旋開發模型之上，理論的味道很濃。在第二版，步驟進行了重新調整以更好地符合實際需要。除此之外，也引入了一些需要的輔助技術。 第7章 軟件體系結構評估 7.4 ATAM評估方法當前ATAM的完整過程包括4個階段，共9個主要步驟。在此，步驟仍然不必是線性執行的。實踐中，評估負責人可以決定應該執行哪些步驟，或者直接跳到本應在若干步之后才實施的步驟。這些都視情況而定。步驟僅僅表明評估中間制品的生成順序。順序靠后的步驟總需要靠前步驟的制品作為輸入。因此，如果評估團隊已經有了某一步驟生成的信息，或者這些信息對此次評估沒有用處，就可以跳過這一步。 第7章 軟件體系結構評估 7.4 ATAM評估方法ATAM的一

34、般過程如圖7-5所示。階段I和II是評估的核心。 第7章 軟件體系結構評估 7.4 ATAM評估方法階段0是準備階段。考慮到ATAM評估的范圍、時間和費用，有必要就評估時間表、費用計劃、參與者組織等問題進行討論甚至簽署嚴格的合同協定。打算評估的人首先應該搞清楚進行評估是否可行、誰參與評估、評估的對象是什么、評估結果提交給誰、評估后又該做什么。為了避免核心評估階段中斷，上面提到的每個問題都需要仔細考慮和計劃。然后，需要建立一個評估團隊，負責接下來的工作。該團隊中需要定義幾個角色，包括團隊領導、評估領導、書記員、計時者、提問者、監督員等。同一個人可以扮演多個角色。通常，在階段0會開一個評估團隊會議

35、以明確責任并為下一階段做好準備。 第7章 軟件體系結構評估 7.4 ATAM評估方法階段III是評估收尾階段。這時有兩項任務必須要做。首先就是要產生最終報告，記錄核心評估階段的過程、信息和基于此的結論。另一項任務是進行總結以便改進今后的評估。一方面，可以問問評估成員或者其他參與者感覺哪些活動好，哪些不好，為什么。可以收集關于本次評估的花費和受益的信息。這種數據挖掘可能會有利于找到各種活動的可改進之處。另一方面，可以整理本次的場景和相關的問題，以備下次評估類似項目。在領域特定的開發中，這項活動因其強大的可重用性而非常有效。 第7章 軟件體系結構評估 7.4 ATAM評估方法第7章 軟件體系結構評

36、估 7.4 ATAM評估方法 ATAM評估的步驟 整個ATAM評估過程包括九個步驟，按其編號順序分別是描述ATAM方法、描述商業動機、描述體系結構、確定體系結構方法、生成質量屬性效用樹、分析體系結構方法、討論和分級場景、分析體系結構方法（是第六步的重復）、描述評估結果。 第7章 軟件體系結構評估 7.4 ATAM評估方法 ATAM評估的步驟 這些步驟又進一步分為如下4個子階段： 1、介紹（1）介紹ATAM：介紹ATAM的步驟、活動和技術。（2）介紹商業動機：介紹商業目標以識別主要質 量需求。（3）介紹體系結構：解釋當前體系結構如何滿足 商業動機。第7章 軟件體系結構評估 7.4 ATAM評估方

37、法 ATAM評估的步驟 2、研究和分析（4）識別體系結構方法：找到建立體系結構所用 的方法。（5）生成質量屬性效用樹：以樹的形式產生反映 系統效用的帶有優先級的場景。（6）分析體系結構方法：對支持關鍵場景的體系 結構方法進行分析，并識別風險、非風險、 敏感點和權衡點。 第7章 軟件體系結構評估 7.4 ATAM評估方法 ATAM評估的步驟 3、測試（7）頭腦風暴和給場景指定優先級：由更多的涉 眾生成更多的場景。（8）分析體系結構方法：同步驟（6），不過采用 的場景來自步驟（7）。 4、報告（9）報告結果：產生評估報告。 子階段評估步驟主要階段I主要階段II介紹（1）介紹ATAM （2）介紹商業

38、動機（3）介紹體系結構研究和分析（4）識別體系結構方法（5）生成質量屬性效用樹（6）分析體系結構方法測試（7）頭腦風暴和設定場景優先級無（8）分析體系結構方法報告（9）提供評估結果第7章 軟件體系結構評估 7.4 ATAM評估方法第7章 軟件體系結構評估 （1）描述ATAM方法(1) ATAM評估的第一步要求評估小組負責人向參加會議的風險承擔者介紹ATAM評估方法。在這一步，要解釋每個人將要參與的過程，并預留出解答疑問的時間，設置好其他活動的環境和預期結果。關鍵是要使每個人都知道要收集哪些信息，如何描述這些信息，將要向誰報告等。特別是要描述以下事項：7.4 ATAM評估方法（1）ATAM方法步

39、驟簡介；（2）獲取和分析技術：效用樹的生成，基于體系結構方法的獲取/分析，場景的映射等；（3）評估結果：所得出的場景及其優先級，用戶理解/評估體系結構的問題，描述驅動體系結構的需求并對這些需求進行分類，所確定的一組體系結構方法和風格，一組所發現的風險點和無風險點、敏感點和權衡點。第7章 軟件體系結構評估 描述ATAM方法(2) 7.4 ATAM評估方法第7章 軟件體系結構評估 （2）描述商業動機 參加評估的所有人員必須理解待評估的系統，在這一步，項目經理要從商業角度介紹系統的概況。商業環境/驅動描述（約12張幻燈片，45分鐘）（1）描述商業環境、歷史、市場劃分、驅動需求、風險承擔者、當前需要以

40、及系統如何滿足這些需要（3-4張幻燈片）。（2）描述商業方面的約束條件（例如：推向市場的時間、客戶需求、標準和成本等）（1-3張幻燈片）。（3）描述技術方面的約束條件（例如：COTS、與其他系統的互操作、所需要的軟硬件平臺、遺留代碼的重用等）（1-3張幻燈片）。（4）質量屬性需求（例如：系統平臺、可用性、安全性、可修改性、互操作性、集成性和這些需求來自的商業需要）（2-3張幻燈片）。（5）術語表（1張幻燈片）。7.4 ATAM評估方法第7章 軟件體系結構評估 （3）描述體系結構(1) 在這一步中，首席設計師或設計小組要對體系結構進行詳略適當的介紹，這里的“詳略適當”取決于多個因素，例如有多少信

41、息已經決定了下來，并形成了文檔；可用時間是多少；系統面臨的風險有哪些等。這一步很重要，將直接影響到可能要做的分析及分析的質量。在進行更詳細的分析之前，評估小組通常需要收集和記錄一些額外的體系結構信息。 7.4 ATAM評估方法第7章 軟件體系結構評估 描述體系結構(2) 體系結構描述（約20張幻燈片，60分鐘）（1）驅動體系結構的需求（例如：性能、可用性、安全性、可修改性、互操作性、集成性等），以及與這些需求相關的可度量的量和滿足這些需求的任何存在的標準、模型或方法（2-3張幻燈片）。（2）高層體系結構視圖（4-8張幻燈片）。 功能：函數、關鍵的系統抽象、領域元素及其依賴關系、數據流； 模塊/

42、層/子系統：描述系統功能組成的子系統、層、模塊，以及對象、過程、函數及它們之間的關系（例如：過程調用、方法使用、回調和包含等）； 進程/線程：進程、線程及其同步，數據流和與之相連的事件； 硬件：CPU、存儲器、外設/傳感器，以及連接這些硬件的網絡和通信設備。7.4 ATAM評估方法第7章 軟件體系結構評估 描述體系結構(3) （3）所采用的體系結構方法或風格，包括它們所強調的質量屬性和如何實現的描述（3-6張幻燈片）。（4）COTS的使用，以及如何選擇和集成（1-2張幻燈片）。（5）介紹1-3個最重要的用例場景，如果可能，應包括對每個場景的運行資源的介紹（1-3張幻燈片）。（6）介紹1-3個最

43、重要的變更場景，如果可能，應描述通過變更構件、連接件或接口所帶來的影響（1-3張幻燈片）。（7）與滿足驅動體系結構需求相關的體系結構問題或風險（2-3張幻燈片）。（8）術語表（1張幻燈片）。7.4 ATAM評估方法第7章 軟件體系結構評估 （4）確定體系結構方法 識別體系結構方法的原因是這些信息提供了體系結構構建背后的基本原則。一個體系結構方法是指根據功能或質量屬性需求而做的設計決定。軟件體系結構風格和模式包含了大量有用信息，這些信息與進行特定設計的原理緊密相關。體系結構模式描述了必要的抽象元素、這些元素的結構和相關的一些約束。但并不是所有的體系結構方法都可以用體系結構風格或模式的形式表達。架

44、構師應該能講清楚使用的每個體系結構方法，這樣其他評估參與者也有機會理解。7.4 ATAM評估方法第7章 軟件體系結構評估 （5）生成質量屬性效用樹(1) 評估小組、設計小組、管理人員和客戶代表一起確定系統最重要的質量屬性目標，并對這些質量目標設置優先級和細化。這一步很關鍵，它對以后的分析工作起指導作用。即使是體系結構級的分析，也并不一定是全局的，所以，評估人員需要集中所有相關人員的精力，注意體系結構的各個方面，這對系統的成敗起關鍵作用。這通常是通過構建效用樹的方式來實現的。 7.4 ATAM評估方法 效用樹的輸出結果是對具體質量屬性需求（以場景形式出現）的優先級的確定，這種優先級列表為ATAM

45、評估方法的后面幾步提供了指導，它告訴了評估小組該把有限的時間花在哪里，特別是該在哪里去考察體系結構方法與相應的風險、敏感點和權衡。 第7章 軟件體系結構評估 生成質量屬性效用樹(2) 7.4 ATAM評估方法 質量屬性效用樹（Quality Attribute Utility Tree，QAUT）以樹的形式表現質量屬性的細化。QAUT的根是效用，接下來是質量屬性層，典型的有可用性、可修改型和安全性等。再接著下一層是質量屬性具體描述分類，也就是把某個質量屬性分成幾個主題。第四層也是最后一層，是具體的場景，精確定義了質量需求以允許后續分析。一般來說，QAUT把系統的期望效用翻譯成了場景。 第7章

46、軟件體系結構評估 生成質量屬性效用樹(3) 7.4 ATAM評估方法每個場景有兩維度量： （1）此場景對系統成功的重要程度。 （2）架構師所估計的支持此場景的開發難度。測量所用的標度可以定為類似高、中、低這樣范圍為3的序數尺度，范圍為5或者10等也可以。標記好度量后，場景就可以排出優先級了，最上面的是參與者希望得到的最關鍵的質量屬性目標。 第7章 軟件體系結構評估 生成質量屬性效用樹(4) 7.4 ATAM評估方法第7章 軟件體系結構評估 生成質量屬性效用樹(5) 7.4 ATAM評估方法第7章 軟件體系結構評估 （6）分析體系結構方法(1) 一旦有了效用樹的結果，評估小組可以對實現重要質量屬

47、性的體系結構方法進行考察。這是通過注意文檔化這些體系結構決策和確定它們的風險、敏感點和權衡點等來實現的。在這一步中，評估小組要對每一種體系結構方法都考察足夠的信息，完成與該方法有關的質量屬性的初步分析。這一步的主要結果是一個體系結構方法或風格的列表，與之相關的一些問題，以及設計師對這些問題的回答。通常產生一個風險列表、敏感點和權衡點列表。7.4 ATAM評估方法第7章 軟件體系結構評估 分析體系結構方法(2) 風險是已經做出的但是在特定可能情況下會出現潛在問題的決策。而非風險正相反。可能有人會說風險應該受到更多關注，因為它們是將來的問題之源。不過，非風險一樣重要，因為它們暗示了哪些體系結構方法

48、值得保留和堅持。更重要的是，當上下文變化的時候，非風險可能會轉變成風險。因此，顯式地列出非風險是有用的。 7.4 ATAM評估方法第7章 軟件體系結構評估 分析體系結構方法(3) 敏感點是指會被某些體系結構元素顯著影響的系統模型的屬性值。研究敏感點可使設計人員或分析員明確在搞清楚如何實現質量目標時應注意什么。權衡點是系統內與幾個敏感點都相關的地方。權衡點是影響多個質量屬性的特性，是多個質量屬性的敏感點。例如，改變加密級別可能會對安全性和性能產生非常重要的影響。提高加密級別可以提高安全性，但可能要耗費更多的處理時間，影響系統性能。如果某個機密消息的處理有嚴格的時間延遲要求，則加密級別可能就會成為

49、一個權衡點。7.4 ATAM評估方法第7章 軟件體系結構評估 分析體系結構方法(4) 7.4 ATAM評估方法第7章 軟件體系結構評估 分析體系結構方法(5) 7.4 ATAM評估方法看門狗：采用一個獨立于CPU的定時器周期性地產生復位脈沖，而CPU則必須在這個周期內對這個定時器進行清零處理（所謂的“喂狗”），讓其重新計時。如果CPU不能在規定的時間內去喂狗，有可能是死機，則定時器可以讓CPU重新復位回到正常程序中來。 心跳：是雙機容錯系統的一種故障診測方法，使用備用機對主用機進行診測，通過主用機按一定的間隔通過監控線往備用機發送心跳信息，以備用機收不到主機的信息為診測失敗的依據。 第7章 軟

50、件體系結構評估 （7）討論和分級場景(1) 風險承擔者需進行兩項相關的活動：集體討論用例場景（描述風險承擔者期望使用系統的方式）和改變場景（描述風險承擔者所期望的系統在將來變更的方式）。用例場景是場景的一種，在用例場景中，風險承擔者是一個終端用戶，使用系統執行一些功能。改變場景代表系統的變更，可分為成長場景和考察場景兩類。 7.4 ATAM評估方法 成長場景描述的是體系結構在中短期的改變，包括期望的修改、性能或可用性的變更、移植性、與其他軟件系統的集成等。考察場景描述的是系統成長的一個極端情形，即體系結構由下列情況所引起的改變：根本性的性能或可用性需求（例如數量級的改變）、系統基礎結構或任務的

51、重大變更等。成長場景能夠使評估人員看清在預期因素影響系統時，體系結構所表現出來的優缺點，而考察場景則試圖找出敏感點和權衡點，這些點的確定有助于評估者評估系統質量屬性的限制。 第7章 軟件體系結構評估 討論和分級場景(2) 7.4 ATAM評估方法第7章 軟件體系結構評估 討論和分級場景(3) 一旦收集了若干個場景后，必須要設置優先級。評估人員可通過投票表決的方式來完成，每個風險承擔者分配相當于總場景數的30%的選票，且此數值只入不舍。例如，如果共有17個場景，則每個風險承擔者將拿到6張選票，這6張選票的具體使用則取決于風險承擔者，他可以把這6張票全部投給某一個場景，或者每個場景投2-3張票，還

52、可以一個場景一張票等。一旦投票結果確定，所有場景就可設置優先級。設置優先級和投票的過程既可公開也可保密。7.4 ATAM評估方法第7章 軟件體系結構評估 討論和分級場景(4) 7.4 ATAM評估方法第7章 軟件體系結構評估 討論和分級場景(5) 7.4 ATAM評估方法最初的效用樹是由架構設計師和關鍵開發人員創建的。在對場景進行集體討論的過程和設置優先級的過程中，有很多風險承擔者參與其中，與最初的效用樹相比，兩者之間的不匹配可以揭露架構設計師未曾注意到的方面，從而使得我們發現架構中的重大風險。第7章 軟件體系結構評估 討論和分級場景(6) 7.4 ATAM評估方法第7章 軟件體系結構評估 （

53、8）分析體系結構方法 在收集并分析了場景之后，設計師就可把最高級別的場景映射到所描述的體系結構中，并對相關的體系結構如何支持實現該場景做出解釋。在這一步中，評估小組要重復第6步中的工作，把新得到的最高優先級場景與尚未得到的體系結構工作產品對應起來。在第7步中，如果未產生任何在以前的分析步驟中都沒有發現的高優先級場景，則在第8步就是測試步驟。7.4 ATAM評估方法第7章 軟件體系結構評估 （9）描述評估結果(1) 最后，要把ATAM分析中所得到的各種信息進行歸納，并反饋給風險承擔者。這種描述一般要采用輔以幻燈片的形式，但也可以在ATAM評估結束之后，提交更完整的書面報告。 7.4 ATAM評估

54、方法在描述過程中，評估負責人要介紹ATAM評估的各個步驟，以及各步驟中得到的各種信息，包括商業環境、驅動需求、約束條件和體系結構等。最重要的是要介紹ATAM評估的結果：（1）已文檔化了的體系結構方法/風格；（2）場景及優先級；（3）基于屬性的問題；（4）效用樹；（5）所發現的風險決策；（6）已文檔化了的無風險決策；（7）所發現的敏感點和權衡點。第7章 軟件體系結構評估 描述評估結果(2) 7.4 ATAM評估方法第7章 軟件體系結構評估 ATAM評估的階段 第一個階段以體系結構為中心，重點是獲取體系結構信息并進行分析。第二個階段以風險承擔者為中心，重點是獲取風險承擔者的觀點，驗證第一個階段的結

55、果。 7.4 ATAM評估方法 之所以要分為兩個階段，是因為評估人員要在第一個階段收集信息。在整個ATAM評估過程中，評估小組中的部分人（通常是1-3人）要與體系結構設計師和1-2個其他關鍵的風險承擔者（例如，項目經理，客戶經理，市場代表）一起工作，收集信息。對支持分析而言，在大多數情況下，這種信息是不完整的或不適當的，所以，評估小組必須與體系結構設計師一起協作引導出必須的信息，這種協作通常要花幾周的時間。當評估人員覺得已經收集了足夠的信息，并已把這些信息記錄成文檔，則就可進入第二個階段了。第7章 軟件體系結構評估 ATAM評估的階段 7.4 ATAM評估方法第7章 軟件體系結構評估 第一階段

56、(1) ATAM評估小組要與提交待評估的體系結構的小組見面（或許這是雙方第一次會見），這一會議有兩方面的目的，一是組織和安排以后的工作，二是收集相關信息。從組織角度來看，體系結構小組負責人要保證讓合適的人選參加后續會議，還要保證這些人為參加相關會議做了充分的準備，抱著正確的態度。第一天通常作為整個ATAM過程的一個縮影，主要關注1-6步的工作。第一次會議所收集的信息意味著要保證體系結構能得到正確的評估。同時，在第一次會議也會收集和分析一些初步的場景，作為理解體系結構、需要收集和提交的信息、所產生的場景的含義的一種途徑。7.4 ATAM評估方法第7章 軟件體系結構評估 第一階段(2)例如，在第一

57、天，體系結構設計師可能提交部分體系結構，確定部分體系結構風格或方法，創建初步的效用樹，就選定的一組場景進行工作，展示每個場景是如何影響體系結構的（例如可修改性），體系結構又是如何作出響應的（例如：對質量屬性而言，可以是性能、安全性和可用性）。其他的風險承擔者（例如：關鍵開發人員、客戶、項目經理等）可以描述商業環境、效用樹的構建，以及產生場景的過程。7.4 ATAM評估方法第一個階段是一個小型會議，評估小組需要盡可能多地收集有關信息，這些信息用來決定：（1） 后續評估工作是否可行，能否順利進行；（2） 是否需要更多的體系結構文檔。如果需要，則應明確需要哪些類型的文檔，如何提交這些文檔；（3） 哪

58、些風險承擔者應參與第二個階段的工作。第7章 軟件體系結構評估 第一階段(3)7.4 ATAM評估方法第7章 軟件體系結構評估 第一階段(4) 在這一天的最后，評估人員將對項目的狀態和環境、驅動體系結構需求，以及體系結構文檔都有較清晰的認識。在第一次會議和第二次會議之間有一段中斷時間，其長短取決于第一個階段完成的情況。在這段時間內，體系結構設計小組和要評估小組協作，做一些探索和分析工作。前面已經提到過，在第一個階段中評估小組并不構建詳細的分析模型，而是構建一些初步模型，以使評估人員和設計人員能對體系結構有更充分的認識，從而保證第二個階段的工作更有效率。另外，在這段時間內，還要根據評估工作的需要、

59、可用人員的狀況和計劃來決定評估小組的最終人選。例如，如果待評估的系統對安全性的要求很高，則需要讓安全專家參與評估工作；如果待評估的系統是以數據為中心的，則需要讓數據庫設計方面的專家參與評估。7.4 ATAM評估方法第7章 軟件體系結構評估 第二階段這時，體系結構已經被文檔化，且有足夠的信息來支持驗證已經進行的分析和將要進行的分析。已經確定了參與評估工作的合適的風險承擔者，并且給他們提供了一些書面閱讀材料，如對ATAM方法的介紹，某些初步的場景，包括體系結構、商業案例和關鍵需求的系統文檔等。這些閱讀材料有助于保證風險承擔者建立對ATAM評估方法的正確期望。 7.4 ATAM評估方法 因為將有更多

60、的風險承擔者參與第二次會議，且因為在第一次會議和第二次會議之間，可能還要間隔幾天或幾個星期，所以第二個階段首先有必要重新簡單介紹ATAM方法，以使所有與會者達成共同的理解。另外，在每一步進行之前，簡單扼要地介紹該步的工作，也是很有好處的。第7章 軟件體系結構評估 第二階段7.4 ATAM評估方法第7章 軟件體系結構評估 ATAM各步驟中相關的風險承擔者 7.4 ATAM評估方法第7章 軟件體系結構評估 ATAM評估日程安排(1)7.4 ATAM評估方法第7章 軟件體系結構評估 ATAM評估日程安排(2) 7.4 ATAM評估方法在本節介紹一個使用SAAM方法的實例，使用SAAM方法對第3章介紹