基于場景的兩種軟件體系結構評估方法

收稿日期：2008-01-17；修回日期：2008-03-24

基金項目：上海市政府重點學科建設基金資助項目（滬教委科(2006)47）

作者簡介：沈群力(1973-)，男，安徽青陽人，博士研究生，主要研究方向為信息管理與信息系統(shenqunli@163.com);劉杰(1964-)，男，江蘇揚州人，教授，博導，主要研究方向為信息管理與信息系統*

(1.上海商學院，上海200235；2.復旦大學 管理學院 上海，200433)

摘 要：基于場景的軟件體系結構評估方法通過場景將系統的質量需求轉換為風險承擔者與系統的交互活動，通過低代價的事前評估活動降低軟件的質量風險。SAAM及ATAM兩種方法在具體的實際評估活動中，它們在場景的生成、風險承擔者的商業動機的表述、軟件體系結構的描述等方面存在著很大的不同，兩種評估方法各有特長，其評估方法在具體的場景執行環節上具有不確定性，將定量的度量方法與定性場景結合是提高評估的有效途徑。

關鍵詞：場景；軟件體系結構；軟件體系結構分析法；體系結構權衡分析法；效用樹

中圖分類號：TP311.5

文獻標志碼：A

文章編號：1001-3695(2008)10-3015-03

Two software architecture evaluation methods based on scenario

SHEN Qun-li¹，2， LIU Jie²

(1.Shanghai Business School， Shanghai 200235， China; 2. School of Management， Fudan University， Shanghai 200433， China)

Abstract:Software architecture evaluation methods switch quality demand to interaction between risk-receivers and the system. Advancing evaluation could reduce quality risk when software was designed. SAAM and ATAM were two different evaluation methods which have their merits when applied in creating scenario， describing business motivation and software architecture and so on. Neither methods can’t ensure certainty when applied in particular performance， so it is an effective way to combine quantitative methods and scenario qualitative evaluation.

Key words：scenario; software architecture; software architecture analysis method; architecture tradeoff analyis method; utility tree

軟件體系結構是指組成該軟件系統的一個或多個結構，它們構成軟件的各個部分，形成這些組件的外部可見屬性及相互關系[1]。在大型復雜軟件系統的設計中，軟件體系結構是軟件設計階段的早期產物，它決定著軟件產品能否順利開發及最終軟件產品的質量。因此對軟件體系結構的分析評估就是事先通過代價低廉的評估活動來識別軟件結構中存在的潛在風險，降低項目開發中的不確定性，找出軟件體系結構中影響系統質量的主要因素及改進措施，并在此基礎上檢驗軟件的質量需求是否在具體設計中得到體現，并預測未來軟件質量。

目前，最著名并被廣泛接受的基于場景的軟件體系結構分析評價方法是由SEI（Software Engineering Institute）首先提出，其最具代表性的方法便是SAAM（software architecture analysis method，軟件體系結構分析法）和ATAM（architecture tradeoff analysis method，體系結構權衡分析法）。兩者都是通過分析軟件體系結構對場景（系統的使用或修改活動）的支持程度來判斷該體系結構在多大程度上滿足該場景所代表的質量需求。

1 場景內涵

軟件體系結構評估中，評估人員關注的是軟件系統質量，這些質量可用性能、可靠性、可用性、安全性、易修改性、功能性、可變性、集成性、互操作性等相關屬性來表示。為達到目的，評估人員首先要精確地提出具體質量指標，并以這些質量指標作為軟件體系結構優劣的評估標準，為達到這一目的所采用相關機制方法便是場景。場景是軟件體系結構分析評價中常用的一種技術，由用戶、外部激勵等初始化，場景包括系統中的事件和觸發該事件的特定激勵。

基于場景的評估方式就是將對系統質量需求轉換為一系列風險承擔者與系統的交互活動，分析軟件體系結構對這一具體活動的支持程度。在評估過程中將考慮所有與系統相關人員(包括風險承擔者)對質量的需求，從而確定應用領域功能與軟件體系結構之間的映射。在此基礎上設計用于體現待評估質量屬性的場景以及軟件體系結構對場景的支持程度。例如用一系列對軟件的修改來反映易修改性方面需求，用一系列攻擊性操作來代表安全性方面需求等。

2 基于場景評估方式的兩種代表性方法簡述

21 SAAM——軟件體系結構分析法

SAAM是一種相對簡單的軟件體系結構評估方法。最初用來分析軟件體系結構的可修改性，后來實踐證明該方法不僅可用于可移植性、可修改性、可擴充性、可集成性等質量屬性及系統功能進行快速評估，還可用于對性能、可靠性等其他質量屬性的啟發式評估，SAAM是最早形成文檔并得到廣泛使用的軟件體系結構分析方法。具體評估步驟如圖1所示。

SAAM的評估包括六個活動，分別為：a)場景的生成，風險承擔者集體討論，反映自己的需求；b)軟件體系結構描述，采用某種參評各方都能夠充分理解的形式對即將評估軟件體系結構描述；c)場景分類并確定優先級，保證在有限資源下優先考慮最重要的場景；d)對間接場景的單個評估；e)場景相互作用的評估，即多個場景要求更改體系結構的同一組件；f)總體評估，根據相對重要性來確定每個場景的權重，通過權重得出總體評價。

SAAM不僅可以對單個構架評估，還可以對多個構架進行比較。不僅可以促進軟件構架文檔質量的提高，還可以促進參與評估的風險承擔者之間交流溝通。

22 ATAM——體系結構權衡分析法

ATAM 方法是SEI于2000 年在SAAM方法基礎上提出的，它是考慮了可修改性、性能、可靠性和安全性等多種質量屬性的軟件體系結構評價方法，并能確定這些相互制約屬性之間的折中點。ATAM方法包括四大部分，共計九個步驟：a)表述，通過表述進行信息交流，包括ATAM方法表述、商業動機表述、軟件體系結構的表述，共三個步驟。b)調查分析，包括確定軟件體系結構的方法、生成質量屬性效用樹、分析軟件體系結構方法，共三個步驟。c)測試包括集體討論并確定場景的優先級、分析軟件體系結構方法，共兩個步驟。d)形成報告，即評估結果的表述。

ATAM 通過用調查表來收集影響軟件體系結構質量屬性的要素，描述質量屬性的特征，盡管九個步驟按編號排列，但并不一定嚴格遵照這種瀑布模型，評估人員可以在九個步驟中進行跳轉和迭代。ATAM能針對性能、實用性、安全性和可修改性這些質量屬性，在系統開發之前對其重要性進行評價和折中。當評估活動結束后，將評估的結果與需求作對比，如果系統預期行為與需求充分接近，設計者就可以繼續進行更高級別的設計或實現；如果分析發現了問題，就對所設計的軟件結構、模型或需求進行修改，從而開始迭代過程。

3 兩種方法具體應用中的不同性比較

基于場景的軟件體系結構評估方法用場景代替對質量屬性的空洞描述，提高軟件測試的可行性。在具體的實際運用中，兩種方法又有各自不同的特點。

31 場景的生成方式不同

SAAM 方法采用頭腦風暴(brainstorming) 技術構建場景，要求風險承擔者列舉出若干場景，并將場景分為直接場景和間接場景兩類，分別支持對體系的靜態分析和動態分析。直接場景類似用例，按照現有的構架開發出來的系統能夠直接實現的場景。間接場景，有時也叫更改案例，在實際評估中，如果軟件體系結構不能直接支持某一直接場景，就需要對現有的軟件體系結構作修改，對現有構架作一些修改才能支持的場景便是間接場景。評估中對于直接場景，軟件體系設計師需清楚表述該體系結構將如何執行這些場景；對間接場景，設計師應說明需要對體系結構作哪些修改才能適應間接場景的要求，并估計出這些更改的代價。通過綜合各間接場景對軟件體系結構的影響，可以測試出軟件在生命周期內的適應性和可更改性。在具體評估中并給場景設置優先級別來保證在有限的時間內最先考慮最重要的場景。

ATAM在具體評估中將場景分為三類：a)用例場景(use case scenario)。描述用戶的期望與正在運行的系統交互，用于信息的獲取。b)生長場景(growth scenario)。預期的系統變更與質量屬性關系。c)探索場景(exploratory scenario)。暴露當前設計的極限或邊界，顯示可能隱含的假設，即弄清這些更改的影響。場景的具體使用中評估小組請風險承擔者對三類場景進行集體討論，根據風險承擔者的意見將代表相同行為或相同質量屬性的場景進行合并，確定其中若干個場景，最后通過投票的方式來確定這些場景的優先級別。這就要求軟件設計師必須清楚地向風險承擔者表達軟件結構設計中所使用任何明確的體系結構方法，風險承擔者根據確定使用的體系結構方法，采用“刺激—環境—響應”來生成三類場景。

32 風險承擔者商業動機表述方式不同

軟件體系結構的評估參與人員主要有風險承擔者及評估小組成員，不同的風險承擔者對軟件的質量屬性有著不同的組織目標，不同的組織目標是由商業動機的出發點不一樣而造成的，在軟件體系結構階段就應該考慮他們的商業動機及目標滿足程度。

SAAM只是將不同組織的需求目標簡單地聯系在一起，評估中由開發人員、維護人員、用戶和管理人員等風險承擔者將其所關心的目標問題以場景形式提出，這樣不同領域的風險承擔者根據自己領域特點及對軟件的需要確定若干場景，評估小組根據他們確定的場景來評估軟件系統特定方面的性能。對同一系統，由于不同風險承擔者確定的場景不同，評估的結果也將不同。這種將商業動機不經過深入的數據處理就轉換為場景的評估方式具有一定的不精確性，只能是一種粗糙的評估方式。

ATAM建立在SAAM的基礎上，借助于效用樹(quality attribute utility tree)將風險承擔者的商業目標轉換成質量屬性需求，再轉換成代表自己商業目標的場景。對風險承擔者不同的商業動機，評估人員首先確定不同商業動機所代表的質量屬性與其他質量屬性比較，得到相對重要性的矩陣，并運用層次分析法來確定質量屬性的優先組合，將模糊的目標定量化，生成質量屬性效用樹，這樣評估人員更容易關注效用樹的葉節點，更好地滿足處在高優先級位置的場景而需采用的軟件體系結構方法，更為精確地定義質量需求。效用樹的理論基礎是管理學中的“需要理論”，即通過刺激及其所產生期望響應來描述場景，根據期望的迫切程度確定場景優先級別，在理想情況下，所有場景都以“刺激—環境—響應”的形式表述。ATAM通過不同質量屬性之間的交互及依賴關系，尋求不同質量屬性之間的折中機制，因此ATAM方法在具體評估分析過程中要求記錄系統風險、找出敏感點(sensitivity points) 及折中點(tradeoff points) ，同時也改進了體系結構的相關文檔。

33 軟件體系結構的描述方式不同

在評估之前，首席軟件設計師需要對軟件體系結構作詳略適當的講解，這種信息講解的表達透徹程度將直接影響體系結構的分析質量。在講解過程中，評估小組還要詢問更多相關信息，只有選擇合適的視圖才能更清晰地表達相關信息。

ATAM方法中軟件體系結構的描述采用Philippe Kruchten“4+1”視圖模型，即從五個不同的視角點描述系統的體系結構，四個視圖模型從特定的不同方面描述軟件的體系結構，忽略與此無關的實體。描述系統的功能需求采用邏輯視圖，即系統提供給最終用戶的服務；描述系統的運行特性采用進程視圖，側重關注非功能性的需求（如性能、可用性），該視圖服務于系統集成人員，方便后續性能測試；硬件配置采用物理視圖描述，該視圖服務于系統工程人員，解決系統的拓撲結構、系統安裝、通信等問題；軟件模塊的組織與管理采用開發視圖描述，該視圖服務于軟件編程人員，方便后續的設計與實現；最后用場景視圖刻畫構件之間的相互關系。將四個視圖有機地聯系起來，場景視圖不僅可以描述一個特定的視圖內的構件關系，而且可以描述不同視圖間的構件關系。在四個視圖中，邏輯視圖、開發視圖主要用來描述系統的靜態結構；進程視圖、物理視圖主要用來描述系統的動態結構。ATAM在實際運用中并非每個系統都必須將五個視圖都畫出來，而是各有側重。

SAAM 則提倡使用非常單純的體系結構要素。對體系結構的靜態描述一般都要區別數據的連接（數據在組件之間的傳遞）和控制連接（一個組件調用另一個組件執行某個功能）；對軟件體系結構的動態描述主要描述系統在各個不同時間的行為，給出軟件的體系結構。軟件體系結構的描述既可以用自然語言來描述系統的整體行為，又可以采用某種形式的結構化的描述，表述形式相對靈活。

4 結束語

SAAM與ATAM方法相比較，是一種相對簡單的軟件體系結構評價方法，進行培訓和準備的工作量較少。盡管SAAM評估步驟及細節較少，但是涉及的內容更多，在評估中沒有提供體系結構質量屬性的清晰度量，評估過程過于依賴專家經驗。總體評估時還需根據場景對系統功能的相對重要性設置權重，確定總體評價，權重的設置具有很強主觀性，故SAAM方法適于體系結構的粗糙評價，用于邊設計邊評估的軟件體系結構開發過程。

ATAM 方法是目前被驗證有效并廣泛使用的一種體系結構評估方法，但沒有對質量屬性作深入分析， 同樣缺少定量數據來支持分析結果。ATAM 方法盡管揭示了體系結構如何滿足特定的質量目標，而且還提供了這些質量是如何交互的，即它們之間如何權衡，但這些設計決策將影響整個軟件生命周期，且軟件實現后很難修改這些決策的影響。

目前對體系結構分析與評價大多采用基于場景的技術，這種技術存在著一定的不確定性。如何根據某質量特征使確立的場景更有代表性和完備性，如何為構造的場景確定合適的邊界條件，即停止準則等。這些在具體應用中都有很大的主觀性及經驗性，而度量的評估方法在這方面做得較好，將定量的度量方法與定性場景結合是提高軟件體系結構評估的有效途徑。

參考文獻：

[1]BASS L， CLEMENTS P，KAZMANR. Software architecture in practice [M].Reading， Massachusetts: Addison-Wesley， 2002.

[2]張友生.軟件體系結構.[M]. 2版. 北京:清華大學出版社，2006:256-279.

[3]劉霞，李明樹，王青，等. 軟件體系結構分析與評價方法評述[J].計算機研究與發展，2005，42(7):1247-1254.

[4]沈群力，劉淵.微支付系統的解決方案研究[J].安徽大學學報，2002，26(3):29-31.

[5]沈群力，唐思章，劉杰.基于微支付的網絡認證協議[J].上海商學院學報，2006，7(1):27-30.

[6]沈群力.信息系統分析與設計實驗教學探討[J].實驗科學與技術，2007，5(2):84-86.

[7]GRIMANA A， PEREZAM， MENDOZAL， et al. Feature analysis for architectural evaluation methods[J]. The Journal of Systems and Software， 2006， 79 (2):871-888.

[8]OLUMOFIN F G， MISIO V B. A holistic architecture assessment method for software product lines [J]. Information and Software Technology， 2007， 49(4): 309-323.

[9]LOPEZ M. Application of an evaluation framework for analyzing the architecture tradeoff analysis methodSM[J]. The Journal of Systems and Software，2003，68 (12): 233-241.

[10]ARES J， GARCIA R， JURISTO R， et al. A more rigorous and comprehensive approach to software process assessment[J]. Software Process: Improvement and Practice， 2000， 5 (1):3-30.

[11]CLEMENTS P， KAZMAN R. Valuating software architecture methods and case studies [M]. [S.l.]:Addison-Wesley， 2002:235-241.