－－　寫在前面，軟件架構評估是一個大型項目成功的保證，不管是否完全按照書中的操作來完成，但這總是一個必須的過程。老外的技術方面的書一般都很實在，在提出一定的事實和相應的理論基礎后，一般就會列出些很具體的方法，可操作性都比較強，當然，其實其理論在我們看來也沒什么高深之處，可能是思維方式和長期教育環境的不同造成的，在我看來，他們的理論就是對自己的觀點或者方法的一個形而上的邏輯證明，但恰恰這就是最重要的，如果在邏輯上就不具有可推導性，具體的方法再怎么說得天花亂墜也沒有可信度，另外翻譯得也不錯，不象有些書，根本就是外行瞎折騰，翻譯出來只有鬼才看得懂，不如直接去看原版。

建議有空詳讀原文，我把這些摘錄下來是希望能有所參照?！?br>

《軟件架構評估》學習筆記

〈Evluating Software Architectures〉   Authors:  Paul Clements, Rick Kazman, Mark Klein
   清華大學出版社  孫學濤  朱衛東 趙凱 譯

概念：

架構方法：    就是一組架構決策，各個架構決策互相協調，共同實現所期望的質量屬性目標。

架構評估：    架構來自許多離散的決策，而這些決策是可以被分析和審查的。

ATAM：  架構權衡分析方法
Architectures Trade-off Analysis Method

ATAM方法步驟：
共4大部分，9個步驟

部 分	步 驟	主 要活動者	活 動	目 的
1.  表述	1> ATAM方法的表述;	評估負責人	向評估參與者介紹ATAM方法并回答問題。 a. 評估步驟介紹 b. 用于獲取信息或分析的技巧：效用樹的生成、基于架構方法的獲取和分析、對場景的集體討論及優先級的劃分 c.  評估的結果：所得出的場景及其優先級，用以理解和評估架構的問題、描述架構的動機需求并給出帶優先級的效用樹、所確定的一級架構方法、所發現的有風險決 策、無風險決策、敏感點和權衡點等	使參與者對該方法形成正確的預期
	2> 商業動機的表述;	項目發言人 （項目經理或系統客戶）	闡述系統的商業目標 a. 系統最重要的功能 b. 技術、管理、政治、經濟方面的任何相關限制 c. 與項目相關的商業目標和上下文 d. 主要的風險承擔者 e. 架構的驅動因素（即促使形成該架構的主要質量屬性目標）	說明采用該架構的主要因素 （如：高可用性，極高的安全性或推向市場的時機）
	3> 架構的表述;	架構設計師	對架構做出描述 a. 技術約束條件，諸如要使用的操作系統，硬件，中間件之類的約束 b. 該系統必須要與之交互的其他系統 c. 用以滿足質量屬性的架構方法 d. 對最重要的用例場景及生長場景的介紹	重點強調該架構是怎樣適應商業動機的
2. 調查和分析	4> 確定架構方法	架構設計師	確定所用的架構方法,但不進行分析
	5>  生成質量屬性效用樹		生成質量屬性效用樹,詳細的 根結點為效用，一直細分到位于葉子節點的質量屬性場景， 質量屬性場景的（優先級，實現難度）用高（H）、中（M）、低（L）描述；不必精確	得出構成系統效用的質量屬性(性能、可用性、安全性、可修改性、使用性 等)； 具體到場景--刺激--響應模式，并劃分優先級
	6> 分析架構方法		根據上一步得到的高優先級場景，得出應對這一場景的架構方法并對其進行 分析 要得到的結果包括： a. 與效用樹中每個高優先級的場景相關的架構方法或決策； b. 與每個架構方法相聯系的待分析問題； c.  架構分析師對問題的解答； d.  有風險決策，無風險決策、敏感點和權衡點的確認。	確定架構上的有風險決策、無風險決策、敏感點、權衡點等
3. 測試	7> 集體討論,確定場景優先級		根據所有風險承擔者的意見形成更大的場景集合 場景分類： a.  用例場景： 描述風險承擔者對系統使用情況的期望。 b.  生長場景： 描述期望架構能在較短時間內允許的擴充與更改。 c.  探察場景： 描述系統生長的極端情況，即架構在某些更改的重壓的情況。 注： 最初的效用樹是由架構設計師和關鍵開發人員創建的。在對場景進行集體討論的過程和設置優先級的過程中，有很多風險承擔者參與其中，與最初的效用樹相比，兩 者之間的不匹配可以揭露架構設計師未曾注意到的方面，從而使得我們發現架構中的重大風險。	由所有風險承擔者通過表決確定這些場景的優先級
	8> 分析架構方法		對第6步重復，使用的是在第7步中得到的高優先級場景，這些場景被認為 是迄今為止所做分析的測試案例	發現更多的架構方法，有風險決策、無風險決策、敏感點、權衡點等
4. 形成報告	9> 結果的表述	評估小組	根據在ATAM評估期間得到的信息（方法、場景、針對質量屬性的問題、 效用樹、有風險決策、無風險決策、敏感點、權衡點等），向與會的風險承擔者報告評估結果。 最重要的是如下ATAM結果： a.  已經編寫了文檔的架構方法； b.  若干場景及其優先級； c.  基于質量屬性的若干問題； d.  效用樹； e.  所發現的有風險決策； f.  已編寫文檔的無風險決策； e.  所發現的敏感點和權衡點。

以上步驟并不是固定的， 有時必須對評估規劃做某些動態的更改，以容許人員或架構信息的改變。

ATAM評估方法的的階段：

第0階段	建立評估小組， 建立評估組織和待評估組織間的合作關系
第1階段	以架構為中心，重點獲取架構信息并對其進行分析。	評估階段，上面的9 個步驟 在這時完成
第2階段	以風險承擔者中心，重點為獲取風險承擔者的觀點，并對第1階段的結果進 行驗證。
第3階段	后續階段，形成最終報告，對后續活動做出規劃，評估組織在此階段實現文 檔和經驗的更新。

評估小組各成員的角色及其職責

角色	職責	理想的 人員素質
評估小組負責人	準備評估；與評估客戶協調；保證滿足客戶的需要；簽署評估合同； 組建評估小組；負責檢查最終報告的生成和提交；	善于協調、安排，有管理技巧。善于與客戶交流；能按時完成任務。
評估負責人	負責評估工作；促進場景的得出；管理場景的選擇及設置優先級的過程；促 進對照架構的場景評估；為現場評估提供幫助	能在眾人面前表現自如。善于指點迷津。對架構問題有深刻的理解，富有架 構評估的實踐經驗。能夠從冗長的討論中得出有價值的發現，或能夠判斷出何時討論已無意義、應進行調整。
場景書記員	在得到場景的過程中負責將場景寫到活動掛圖或白板上，務必用以達成一致 的措辭來描述，未得到準確措辭就繼續討論	寫一手好字，能夠在未搞清楚某個問題之前堅持要求繼續討論，能夠快速理 解所討論的問題并提取出其要點
進展書記員	以電子形式記錄評估的進展情況。捕獲原始場景。捕獲促成場景的每個問 題。捕獲與場景對應的架構解決方案。打印出要分發給各參與人員所采用場景的列表	打字速度快，質量高。工作條理性好。從而能夠快速查找信息。對架構問題 理解透徹。能夠融會貫通地快速搞清技術問題。勇于打斷正在進行的討論以驗證對某個問題的理解，從而保證所獲取信息的正確性
計時員	幫助評估負責人保證評估工作按進度進行。在評估階段幫助控制用在每個場 景上的時間	敢于不顧情面地中斷討論，宣布時間已到。
過程觀察員	記錄評估工作的哪些地方有待改進或偏離了原計劃。通常不發表意見，也可 能偶爾在評估過程中向評估負責人提出基于過程的建議。在評估完成后，負責匯報評估過程，指出應該吸取哪些教訓，以便在未來的評估中加以改進。還負責向整個 評估小組匯報某次評估的實踐情況	善于觀察和發現問題，熟悉評估過程，曾參加過采用該架構評估方法進行評 估
過程監督者	幫助評估負責人記住并執行評估方法的每個步驟	對評估方法的各個步驟非常熟悉。愿意并能夠以不連續的方式向評估負責人 提供指導
提問者	提出風險承擔者或許未曾想到的關于架構的問題	對架構和風險承擔者的需求具有敏銳的觀察力。了解同類系統。勇于提出可 能有爭議的問題，并能不懈地尋求其答案。熟悉相關的質量屬性。

商業目標分析結果表： 
             

	內容列表	詳細備注
主要商業目標	為跨學科的地球科學研究提供支持
	大批量數據的并發攝入、處理和分配
次要商業目標	為外部開發的科學算法／應用程序提供支持
	科學數據再處理
其他商業目標	采用自動化操作，以盡可能減少操作成本

系統質量屬性列表：

質量屬性目標	標識號（數字表示效用樹中的子序號）	針對質量屬性的要求
可維護性	M1	更改某個子系統時不要求改動其他子系統
	M2	把子系統的部署要求分別降到最低
	M3	把回歸測試時間從5天減少到1天
可靠性	R1	不至于因為數據輸入輸出而導致某個系統資源崩潰或等待較長時間，如超過 10分鐘
	R2	請求（輸入出）中的某一部分數據錯誤不會妨礙其他部分的正常使用
	R6	因系統崩潰或備份造成的無法提供服務的時間不能超過1小時
可操作性	O10	系統應該能在20分鐘內根據用戶類型、數據類型、介質類型、目的地或用 戶對1000項定單重新設置優先級
	O14	應該能在不需要操作干涉的情況下，通過V0網關為1000個并發請求提 供服務
可擴展性	S2	能同時支持50個場站
	S3	能夠支持來自100個數據源的輸入
性能	P1	在某種查詢算法下，對Landsat L-7查詢可使響應速度能提高5倍

第一階段獲得的帶優先級的效用樹：
第1層： 效用

第2層：質量屬性	第3層：質量屬性求精	第4層：質量屬性場景	重要性	難度	累加和
可維護性	M1：對一個子系統的更改不要求改動其他子系統	M1.1：部署下一個科學數據服務器版本，實現對當前版本的更新。升級 應該在8小時以內完成，并且不應影響其他子系統及查找、瀏覽或預定功能的使用。	30	30	60
	M2：獨立地回退子系統的部署	M2.1：使科學數據服務器從M1回退	20	20	40
可操作性	O10：系統應該能在20分鐘內根據用戶類型、數據類型、介質類型、目 的地或用戶對1000項定單重新設置優先級	O10.1：積壓任務管理-- 在系統連續24小時不能正常工作后，應在30分鐘內為所積壓的任務設置優先級，以保證各任務能夠按優先級得以處理且正常的操作能夠得以維持，不會在恢復正 常操作狀態后降低吞吐量	30	20	50
	O14：應該能在不需要操作干涉的情況下，通過V0網關為1000個并 發請求提供服務	O14.1：MODAPS連續24小時不能正常工作，恢復并請求2天的 數據；按優先級進行處理	20	20	40
		O14.2：接收100個并發查詢請求，不拒絕高優先級的請求，在性能 允許的情況下完成處理，不使系統過載	20	20	40
可靠性／可用性	Ra1：失敗的或掛起時間超過10分鐘的數據輸入輸出不占用系統資源	Ra1.1：L-7按預定用FTP方式把數據推到某個FTP服務器已經 崩潰的節點，在第一個請求未能成功處理的10分鐘內系統被掛起，在請求被掛起期間內所有資源可用，不影響其他節點的分配。	30	10	40
可擴展性	Sc2：系統能夠支持50個節點	Sc2.1：跨節點訂單可記錄50個節點，跨5節點訂單歷時2分鐘。 Sc2.2：跨節點用戶注冊在24個小時內經歷50個節點。	20 20	30 30	50 50
性能	P1：把Landsat L-7搜索的響應速度提高5倍	P1.1：正常情況下Landsat L-7搜索100次命中的時間不超過30秒	30	20	50
		注：這些難度等級只是粗粒度的劃分，不必過于認真

場景分析表：

1.  場景描述：

場景號：M1.1	場景：（M1.1）部署下一個科學數據服務器版本，實現對當前版本的更 新。升級應該在8小時以內完成，并且不應影響其他子系統及查找、瀏覽或預定功能的使用。
質量屬性	可維護性
環境	常規維護
刺激	部署下一個科學數據服務器版本，實現對當前版本的更新，并添加對經緯度 的支持。
響應	升級應該在8小時以內完成，并且不應影響其他子系統及查找、瀏覽或預定 功能的使用。

 

架構決策	有風險決策	敏感點	權衡點	無風險決策
AD1：接口的向后兼容性	R1
AD2：客戶占位程序在服務器中的靜態連接	R2
AD3：關鍵運行數據庫的單個副本	R3	S1	T1,T2
AD4：關于分布在整個系統中的數據類型的信息	R4,R5,R6	S2
AD5：獨立于子系統的名稱			T3
AD6：采用穩定、簡單API的分布式對象				NR1
AD7：源文件間末受控制的依賴性	R7
推理：定性的或量化的關于為什么這組架構決策能夠滿足此場景所表達的每個質量屬 性要求的基本原理。
架構圖： 一個或多個表示架構視圖的圖形，標注出支持上述推理的架構信息，必要的可加上解釋性文字描述。

ARID評估方法
      ----   Active Reviews for Intermediate Design

         ATAM和SAAM都是適用于對軟件的完整架構進行評估的方法。但是，架構經常是要經歷很長時間，階躍式地逐漸完善，而不是一開始就以最終確定的完美形式 出現的。
         在架構設計過程中，對已經完成的部分逐步進行評審，及時發現某些部分的錯誤，不一致性或者是考慮不周的地方，而且在大多數項目開發中經常需要對系統的每個 大組件或子系統進行這種評審。這一階段需要的是一種簡單易用的評估方法，應該重點關注適宜性，以一種風險承擔者能夠接受的方式展示設計方案，并能在缺少詳 細文檔的情況下進行架構評估，這時就要用到ARID方法，active reviews for Intermediate Design。ARID最適合于對尚不完善的架構進行評估，在這一階段，設計人員就是想搞清楚從要求使用該設計架構的其他部分的角度來看，所采用的設計方 案是否合適?；蛟S設計中的這個框架的潛在采用者／重用者想要搞清楚該怎樣使用這一框架。

傳統設計評審和積極設計評審中所用的指令對比

傳統設 計評審問題	積極設 計評審中所用的指令
每個程序是否都定義了例外情況	寫出每個程序可能出現的例外情況。
每個程序是否都定義了正確的例外情況？	寫出每個參數合法值的范圍或集合，寫出在哪些狀態下調用程序是非法的。
是否定義了數據類型？	對每個數據類型，請寫出：  1. 該數據類型直接量的表示； 2.  該類型變量的聲明； 3.   該數據類型的最大值和最小值。
這些程序是否充分？	編寫按該方案實現某已定義任務的一小段偽代碼。
是否對某個應用程序的性質都做了足夠詳細的說明？	對每個應用程序，寫出其最長執行時間，并列出它可能消耗的共享資源。

ATAM，SAAM，ARID的比較

ITEM	ATAM	SAAM	ARID
涉及的質量屬性	不面向任何具體的質量屬性，但據其歷史，它更側重于可修改性，安全性， 可靠性和性能。	主要是可修改性和功能。	設計方法和適宜性。
分析的對象	架構方法或樣式；闡述過程、數據流、使用、物理或模塊視圖的架構文檔。	架構文檔，特別是闡述邏輯或模塊視圖的部分。	組件的接口規范。
適用階段	在架構設計方法已經選定之后。	在架構已經將功能分配到各個模塊中以后。	在架構設計期間。
采用的方法	利用效用樹和對場景的集體討論來搞清楚質量屬性需求。通過對架構方法的 分析確定出敏感點、權衡點和風險。	利用對場景的集體討論搞清楚質量屬性需求。通過來驗證功能或對更改成本 作出估計。	積極評審設計，對場景進行集體討論。
資源需求	一般用3天的時間，另外還有預先的準備時間和之后的總結時間。參評人員 有客戶、架構設計師、風險承擔者和4人評估小組。	一般用2天時間，另外還有之后的總結時間，參評人員有客戶、架構設計 師、風險承擔者和3人評估小組。	一般用2天時間，另外還有預先的準備時間和之后的總結時間。參評人員有 架構設計師、設計人員、風險承擔者和2人評估小組。

所有的評估方法至少要用下列兩種技巧：

  --  提問技巧。         用問卷、檢查列表或場景來調查某個架構滿足其質量屬性需求的方式。架構評估中所用的提問技巧通常涉及到要做某些“思維實驗”，以預期系統的表現，因為此時 系統還不存在。
  --  度量技巧。          要用某個工具對軟件產品進行度量。度量技巧包括要運行所評估架構對應系統的模擬程序，以搞清系統的某些情況。要選擇恰當的單位。對復雜性、耦合度和內聚性 的度量通常用來得出可修改性的結論。對數據流的度量（即度量沿通信通道的數據量的大小及其頻率）則可用來對系統性能或性能瓶頸做出預測。


應注意的危險信號：

• 架構必須與當前的組織結構相對應。因為有相應的組織而添加 不必要的部分。
• 最頂層的架構組件超過了25個。過于復雜，架構設計師可能 難以進行明智的控制，負責實現架構的設計人員那當然也無法做到這一點。
• 設計方案的剩余部分受某一項需求的左右。架構是以滿足極高的可用性需求為目標的。如果降低這一需求，整個架構就會顯得過于復雜。過分強調某一 需求可能會使其他需求得不到重視。
• 架構信賴操作系統中的可變部分。這樣使架構受到操作系統升級的影響；這一明顯的設計缺陷在實際中經常出現，其頻度令人驚訝。
• 在可用標準組件的地方卻使用了專用組件，使整個架構信賴于某個供應商。
• 組件的定義是根據硬件劃分確定的。硬件會隨著系統的演進而變化，硬件組件可能會合并成更通用的處理器，或分解成專用的設備。如果軟件獨立于硬 件結構，就可使其免受硬件變化的影響。
• 有超出可靠性要求之外的冗余。這表明設計人員意見不一，導致不必要的復雜性，也會使系統維護的難度加大。
• 設計方案受例外情況的左右；重點強調的是可擴充性而不是共核部分。
• 開發組織不能確定出誰是系統架構設計師。
• 構架設計師或項目經理在確定該架構的風險承擔者時感到很困難，這可能意味著他們根本就沒有考慮關于風險承擔者的問題。
• 開發人員在對某兩個組件的組件的交互進行編程時有過多的選擇余地。出現這種情況的原因可能是架構上提供了太大的選擇自由，或者沒有考慮這一問 題。意味著架構還要進一步完善。
• 當要求架構設計師提供文檔時，除了類圖外，拿不出任何其他材料。
• 當要求架構設計師提供文檔時，拿出的是大量的由某一工具自動生成的文檔，但這些文檔根本沒人看過。
• 所提供的架構文檔陳舊，顯然已經過時。
• 當要求對架構做出表述時，設計人員或編程人員或者不能做出表述，或者所做的表述與架構設計師所講的內容存在很大的差別。
• there must be more as the process progressed.

對項目開發威脅最大的管理問題：

• 沒有清楚地確定出風險承擔者
• 項目開發中沒有相關領域專家的參與
• 項目資金沒有真正落實
• 沒有指定項目經理或項目負責人
• 沒有制定出項目計劃或規劃
• 部署日期不實際
• 沒有明確的衡量優劣的標準
• 沒有選定軟件的架構
• 雖然在每個層面上都有一位架構設計師，但沒有人對總體架構負責
• 沒有編寫總體架構計劃
• 沒有獨立的負責編寫需求的小組存在
• 沒有硬件和安裝規則
• 沒有合適而獨立的性能研究計劃
• 沒有合適的質量保證組織
• 沒有制定出系統測試計劃
• more

影響項目開發成敗的性能方面的問題：

• 最終用戶沒有確定出性能需求
• 未收集與性能相關的數據
• 沒有確定性能開銷
• 所期望的通信速率未能得到證實
• 未采用任何用以度量處理時間的機制或處理數量未得到證實
• 未采用任何評估手段來保證能夠處理所要求的吞吐量
• 未采用任何評估手段來保證硬件上能夠滿足處理的需要
• 沒有性能模型
• more
  

附A：

 風險承擔者列表：

風險承 擔者	定義	所關心 的問題
系統的生產者
軟件架構設計師	負責系統的架構以及在相互競爭的質量需求間進行權衡的人	對其他風險承擔者提出的質量需求所要進行的解釋和調停
開發人員	設計或編程人員	架構描述的清晰和完整、 各部分的內聚性和受限耦合、 清楚的交互機制
維護人員	系統初次布署完成后對系統進行更改的人	可維護性、確定某個更改發生后必須對系統中哪些地方進行改動的能力
集成人員	負責組件集成或者組裝的人員	與開發人員相同
測試人員	負責系統測試的開發人員	集成、一致的錯誤處理協議； 受限的組件耦合、組件的高內聚性、概念完整性
標準專家	負責搞清所開發軟件必須滿足的標準（現有的或未來的）細節的開發人員	對所關心問題的分離、可修改性、互操作性
性能工程師	分析系統的工作產品以確定系統是否滿足其性能及吞吐量需求的人員	易理解性、概念完整性、性能、可靠性
安全專家	負責保證系統滿足其安全性需求的人士	安全性
項目經理	負責為各小組配置資源、保證開發進度、保證不超出預算的人士，負責與客 戶打交道	架構層次上結構清楚，便于組建小組；任務劃分結構、進度標志和最后期限 等
產品線經理或“擁有重用權的人”	設想該架構和相關資產怎樣在該組織的其他開發中得以重復利用的人	可重用性、靈活性
系統的消費者
客戶	系統的購買者	開發進度、總體預算、系統的有用性、滿足用戶（或市場）需求的情況
最終用戶	所實現系統的使用者	功能性、可用性、沒有易用性？
應用開發者（對產品架構而言）	利用該架構及其他已有可重用組件，通過將其實例化而構建產品的人	架構的清晰性、完整性、簡單交互機制、簡單剪裁機制
任務專家、任務規劃者	知道系統將會怎樣使用以實現戰略目標的客戶代表，視野比最終用戶更為開 闊	功能性、可用性、靈活性
系統服務人員
系統管理員	負責系統運行的人（如果區別于用戶的話）	容易找到可能出現問題的地方
網絡管理員	管理網絡的人員	網絡性能、可預測性
服務代表	為系統在該領域中的使用和維護提供支持的人	使用性、可服務性、可剪裁性
接觸系統或與系統交 互的人
該領域或團體的代表	類似系統或所考察系統將要在其中運行的系統的構建者或擁有者	可互操作性
系統架構設計師	整個系統的架構設計師；負責在軟硬件之間進行權衡并選擇硬件環境的人	可移植性、靈活性、性能和效率
設備專家	熟悉該軟件必須與之交互的硬件的人；能夠預測硬件技術的未來發展趨勢的 人	可維護性、性能
以上就是所有的風險 承擔者的角色及其關注的問題。 軟件架構評估的質量在很大程度上取決于為評估召集起來的風險 承擔者的素質。