基本介紹
- 中文名：軟體體系結構分析方法
- 外文名：software architecture analysis method
- 套用：軟體體系結構分析
- 分析方法分類：定性分析和定量分析
- 相關概念：質量屬性、風險承擔者、場景
- 主要方法：SAAM、ATAM、ALPSM等方法
簡介,SAAM方法,特定目標,評估技術,質量屬性,風險承擔者,體系結構描述,方法活動,方法驗證,ATAM方法,特定目標,質量屬性,風險承擔者,體系結構描述,評估技術,方法的活動,領域知識庫的可重用性,ALPSM,特定目標,評估技術,風險承擔者,方法的活動,
簡介
軟體體系結構(SoftwareArchitecture,sA)為軟體系統提供了一個結構、行為和屬性的高級抽象，由構成系統的元素的描述、這些元素的相互作用、指導元素集成的模式以及這些模式的約束組成。軟體體系結構不僅指定了系統的組織結構和拓撲結構，並且顯示了系統需求和構成系統的元素之間的對應關係，提供了一些設計決策的基本原理。
軟體體系結構分析評價的目的是為了識別體系結構設計中的潛在風險，驗證系統的質量需求在設計中是否得到了體現，預測系統的質量並幫助開發人員進行設計決策。
軟體體系結構分析方法分為：①定性分析：採用基於checklist、questionnaire和場景的分析評價技術；②定量分析：採用基於度量指標、模擬、原型系統和數學模型等技術，在關注具體的質量特性時，在上述技術基礎上，還需要特定的技術和方法支持。
SAAM方法
SAAM(Scenario-based Architecture Analysis Method)是卡耐基梅隆大學軟體工程研究所的Kazman等人於1983年提出的一種非功能質量屬性的體系結構分析方法，是最早形成文檔並得到廣泛使用的軟體體系結構分析方法。最初它用於比較不同的軟體體系的體系結構，用來分析SA的可修改性，後來實踐證明也可用於其它的質量屬性如可移植性、可擴充性等，發展成了評估一個系統的體系結構。
特定目標
SAAM的目標是對描述應用程式屬性的文檔，驗證基本的體系結構假設和原則。此外，該分析方法有利於評估體系結構固有的風險。SAAM指導對體系結構的檢查,使其主要關注潛在的問題點，例如需求衝突或僅從某一參與者的觀點出發的不全面的系統設計。SAAM不僅能夠評估體系結構對於特定系統需求的使用能力，也能被用來比較不同的體系結構。
評估技術
SAAM所使用的評估技術是場景技術，場景代表了描述體系結構屬性的基礎，描述了各種系統必須支持的活動和將發生的變化。
質量屬性
這一方法的基本特點是把任何形式的質量屬性都具體化為場景，但是，可修改性是SAAM分析的主要質量屬性。
風險承擔者
SAAM協調不同參與者所感興趣的方面,作為後續決策的基礎，提供了對體系結構的公共理解。
體系結構描述
SAAM方法用於體系結構的最後版本，但早於詳細設計。體系結構的描述形式應當與被所有參與者理解。功能、結構和分配被定義為描述體系結構的3個主要方面。功能就是系統所要完成的任務。在描述結構時，為了在一個共同的層次上理解和比較不同的體系結構，使用一個小而簡單的辭彙集。所提供的體系結構應當包括一個靜態表示(系統計算、數據構件、數據和控制連線)和一個動態表示(系統隨時間怎么變化)。從功能到結構的分配指出了領域功能是怎樣被軟體結果實現的。
方法活動
SAAM的主要輸入問題是問題描述、需求聲明和體系結構描述。圖1所示描繪了SAAM分析活動的相關輸入及評估過程。
SAAM分析評估體系結構的過程包括五個步驟：
1) 場景開發。通過各類風險承擔者協商討論，開發一些任務場景，這些場景能夠體現系統所支持的各種活動，或者描述經過一定時期後系統可能要進行的各種變化，各角色開發的場景能夠反映自己需求。開發場景的關鍵是捕獲系統重用方式。
2) 軟體體系結構描述。軟體體系結構描述是體系結構評估的前提和基礎。體系結構應該以一種(對於分析人員)易於理解的、合乎語法規則的體系結構表示，而且這種表示應能體現系統的計算構件、數據構件以及構件之間的關係(數據和控制)。對於沒有直接的體系結構描述可用的軟體系統，可使用逆向工程的方法進行提取。場景的形成與SA的描述通常是相互促進的並且需要重複的進行。
3) 單個場景的評估。首先，進行場景分類，即將其分為直接場景和間接場景。所謂直接場景,是指開發的系統已經能滿足的場景，而間接場景則是要對現有的體系結構中的構件和連線件適當的變化才能滿足的場景。其次，對於直接場景需要弄清體系結構是如何實現這些場景的，針對間接場景，列出為支持該場景所需要對體系結構做出的修改，以及這些變化難易程度、實現代價，估計出這些修改的代價。最後，應生成一個關於特定體系結構的場景描述列表。
4) 場景互動的評估。有可能不同的間接場景需要修改同一個構件和連線件，這種情況下，場景與構件和連線件發生互動。場景互動的作用在於，它以一種非常清晰的方式顯示了模組的不同本質，能夠反映出系統構件劃分的質量，並在一定程度上表達了產品設計的功能分配。通過對場景互動的分析，應能得出系統中所有的場景對系統中的構件所產生影響的列表。
5) 總體評估。SAAM最終的步驟是對場景和場景間的互動做一個總體的權衡和評價，即按照重要性為每個場景及場景互動分派權值，權值的選擇反映了該場景表現的質量因素的重要程度，對於體系結構影響較大的質量因素，其權值較大，而影響該質量因素的場景和場景互動也應該賦予較高的權值。最後將這些權值加起來得出總體評價。
方法驗證
SAAM是一種成熟的方法，已被套用到眾多系統中，這些系統包括空中交通管制、嵌入式音頻系統、WRCS(修正控制系統)、KWIC(根據上下文查找關鍵字系統)等。
ATAM方法
ATAM(Architecture Tradeoff Analysis Method)是在SAAM的基礎上發展起來的，SEI於2000年提出ATAM方法，針對性能、實用性、安全性和可修改性，在系統開發之前，對這些質量屬性進行評價和折中。SAAM考察的是軟體體系結構單獨的質量屬性，而ATAM提供從多個競爭的質量屬性方面來理解軟體體系結構的方法。使用ATAM不僅能看到體系結構對於特定質量目標的滿足情況，還能認識到在多個質量目標間權衡的必要性。
特定目標
ATAM的目標是在考慮多個相互影響的質量屬性的情況下，從原則上提供一種理解軟體體系結構的能力的方法。對於特定的軟體體系結構，在系統開發之前，可以使用ATAM方法確定在多個質量屬性之間的折衷的必要性。
質量屬性
ATAM方法分析多個相互競爭的質量屬性。在開始時，考慮的是系統的可修改性、安全性、性能和可用性。
風險承擔者
在於場景、需求收集有關的活動中，ATAM方法需要所有系統相關人員參與。當然這也包括一個軟體體系結構設計者。
體系結構描述
體系結構空間受到歷史遺留系統、互操作性和以前失敗的項目約束。在5個基本結構的基礎上進行體系結構描述，這5個結構從Kruchten的4+1視圖派生而來的，其中的邏輯視圖被分為功能結構和代碼結構。這些結構加上它們之間適當的映射可以完成描述一個體系結構。同時需要幾個不同的視圖：動態視圖顯示系統怎樣通信,系統視圖顯示軟體和硬體之間的分配關係，源視圖顯示構件和系統怎樣組成對象。用一組訊息順序圖顯示運行時的互動和場景，對體系結構描述加以註解。ATAM方法被用於體系結構設計中或被另一組分析人員用於檢查最終版本的體系結構。
評估技術
將ATAM方法視為一個框架，該框架依賴於質量屬性，可以使用不同的分析技術。它集成了多個優秀的單一理論模型，其中的每一個都能夠高效、實用地處理屬性。
另一種評估技術是場景。從不同的體系結構角度，有3種不同類型的場景。它們是：用例，包括對系統典型的使用，還用於引出信息；增長場景，用於涵蓋與其的系統修改；探測場景，用於涵蓋那些可能會對系統造成“壓迫”的極端的修改。這一方法中有一個三元的場景角色。這一技術有助於把含混不清、非定量化的需求和約束用具體的術語表達出來。此外，場景有助於系統參與者之間的通信，因為這迫使它們在對需求的理解上達成共識。
ATAM還使用定性的啟發式分析方法，該方法是從基於屬性的體系結構風格派生出來的。在對一個質量屬性構造了一個精確分析模型時要進行分析，定性的啟發式分析方法就是這種分析的粗粒度的版本。現在的對每種屬性的分類體系是ATAM方法的另一個基礎。這些分類體系有助於確保屬性的覆蓋，並提供提出啟發式問題的基本原則。ATAM還適用篩選問題，它把推理引導向或使之關注向體系結構更為重要的部分。這起到了限制進行詳細審查的體系結構的部分的大小的作用。提出這些問題比立即構造定量的屬性模型更為實際。它們抓住了更為嚴格和形式化的分析中的典型問題的本質。
方法的活動
ATAM被分為4個主要活動領域(或階段)。它們分別是：場景和需求收集，體系結構視圖和場景實現，屬性模型構造分析。圖2詳細描述了包括場景在內的活動，圖3描述了和每個階段相關的步驟，還描述了體系結構設計和分析改進中可能存在的疊代。
屬性專家獨立地創建和分析它們的模型，然後它們交換信息(澄清和創建新的需求)。屬性分析是相互依賴的,因為每個屬性都會涉及到其它屬性。獲得屬性互動的方法有兩種：使用敏感度分析來發現折衷點，通過檢查假設。
敏感點是一個或多個構件(構件之間關係)的一個屬性，這個屬性對於達到系統某一方面的質量非常關鍵。因此在實際套用時，對這個體系結構參數的修改將顯著地影響模型的值。如果一個構件(構件之間關係)有多個敏感點，則稱之為折衷點。折衷點至少是一個質量屬性的敏感點，並影響多個質量屬性。
在體系結構設計中，ATAM提供了疊代的改進。除了通常從場景(通過和系統相關人員面談得出)派生而來的需求，還有很多對行為模式和執行環境的假設。由於屬性之間存在著“折衷”，每一個假設都要被檢查、驗證和提問,以此作為ATAM方法的結果。在完成所有這些操作之後，把分析的結果和需求進行比較，如果系統預期的行為大都接近於需求，設計者就可以繼續前進，進行下一步更為詳細地設計或實現。
在分析揭示某個問題的情況下，要開發出一個用於修改軟體體系結構、模型或需求的“行動計畫”，如圖3所示，這導致該方法的另一次疊代。ATAM並沒有要求進行的分析所有的質量屬性，因此，允許設計者先關注主要屬性，然後逐漸引入其它屬性。
領域知識庫的可重用性
領域知識庫通過基於屬性的體系結構風格(ABAS)維護。ABAS有助於從體系結構風格的概念轉向基於特定質量屬性模型的推理能力。獲取一組基於屬性的體系結構風格的目標在於要把體系結構設計變得更為慣例化、更可預測，並得到一個基於屬性的體系結構分析的標準問題集合，使設計和分析之間的聯繫更為緊密。
ALPSM
體系結構層次的軟體可維護性預測，ALPSM(Architecture Level Prediction of Software Maintenance)通過在體系結構層次考察場景的影響來分析軟體體系得可維護性。
特定目標
該方法用所作修改的大小作為預測的依據來衡量要是系統適應一個場景所付出的努力。
評估技術
ALPSM定義了一個維護簡檔，類似於一個修改場景集合，它代表了用於進一步完善系統的維護任務。一個場景描述和系統相關的一個行動，或一系列的行動，因此，一個修改場景描述某一個維護任務。
風險承擔者
在ALPSM方法活動中，這涉及到了系統設計人員。
方法的活動
如圖4所示，該方法有很多輸入：需求聲明、體系結構描述、來自軟體工程師的專門意見以及可能存在的歷史維護數據。ALPSM包括以下6個步驟：
(1) 標識維護任務的分類；
(2) 合成場景；
(3) 為每個場景分配權重；
(4) 估計所有元素的大小；
(5) 為場景編寫腳本；
(6) 計算預測的維護成本。
在第1步中，以套用或程式描述為基礎，明確地表達所預期的修改的種類。然後，為每一個維護任務，定義一個有代表性的場景集合。按照這些場景在特定時間間隔內發生的可能性，為場景分配權重。為了能夠估計修改的大小，系統中所有構件的大小都是確定的。有3種技術可被用於估計構件人小，它們是：使用優選的預測技術；一種改進的面向對象的度量標準；在能夠獲得早期版本的或類似套用的歷史數據的情況下，可以使用現存的大小數據，並可以通過外推得到新的構件的數據。把這些場景所影響的大小乘以它們發生的機率，再求它們的和，就可以得到總體維護成本。每個場景實現所影響的大小是通過確定它們影響的構件和修改的程度計算出來的。
