王志剛，胥茜

（湖南師范大學(xué)數(shù)學(xué)與計算機學(xué)院，長沙 410081）

軟件架構(gòu)權(quán)衡分析方法探討

王志剛，胥茜

（湖南師范大學(xué)數(shù)學(xué)與計算機學(xué)院，長沙 410081）

軟件架構(gòu)是一個復(fù)雜的不良問題，架構(gòu)師必須憑借豐富的經(jīng)驗才能完成這項工作，而架構(gòu)過程實際上是一個不斷權(quán)衡的過程。然而架構(gòu)的好壞切實關(guān)系到軟件質(zhì)量與效益。為了幫助理解軟件架構(gòu)的本質(zhì)和架構(gòu)實現(xiàn)，概述軟件架構(gòu)權(quán)衡方法的基本原理，詳細(xì)總結(jié)這一方法的基本步驟，對一些關(guān)鍵概念給出樣例以便于理解。希望借此減少軟件架構(gòu)的盲目性，為好的軟件架構(gòu)和設(shè)計提供幫助。

軟件架構(gòu)；質(zhì)量屬性；場景；架構(gòu)權(quán)衡

0 引言

創(chuàng)新軟件架構(gòu)新方法，是提高軟件效率和質(zhì)量的最主要途徑[1]。架構(gòu)權(quán)衡分析方法是一種結(jié)構(gòu)化的技術(shù)，用于理解軟件密集型系統(tǒng)架構(gòu)中固有的權(quán)衡。該方法提供一種原則來評估軟件架構(gòu)的適應(yīng)性，它涉及通過一致的方法對軟件架構(gòu)的關(guān)聯(lián)質(zhì)量屬性（可修改性、安全性、性能、可用性等）進(jìn)行評估，從而考察其適應(yīng)性。這些屬性相互作用，而改善其中一個往往導(dǎo)致一個或多個其他屬性變差。該方法幫助了解影響質(zhì)量屬性交互的架構(gòu)決策。架構(gòu)權(quán)衡分析方法是一個螺旋模型，它從備選架構(gòu)開始分析和風(fēng)險緩解，從而導(dǎo)出改進(jìn)的架構(gòu)。

1 權(quán)衡分析的重要性

在任何學(xué)科中，所有的設(shè)計都涉及到權(quán)衡，這是眾所周知的。困難之處是如何做出明智的、甚至是最優(yōu)的權(quán)衡。設(shè)計決策通常圍繞軟件開發(fā)而預(yù)訂的戰(zhàn)略、成本、進(jìn)度和人員等因素。

因此，需要一套完備措施可以幫助架構(gòu)師在需求和設(shè)計階段能夠很便宜地解決問題，并能得到正確的問題，它指導(dǎo)用戶，讓相關(guān)人員在需求中尋找沖突，并在軟件架構(gòu)中系統(tǒng)地解決這些沖突。在實現(xiàn)這個方法時，假設(shè)屬性特定的分析是相互依賴的，并且每個質(zhì)量屬性都通過特定的架構(gòu)元素與其它屬性發(fā)生聯(lián)系。架構(gòu)元素是組件及其屬性，或者是影響某些質(zhì)量屬性的組件之間關(guān)系的屬性[2]。例如，流程的優(yōu)先級是一個可能影響性能的架構(gòu)元素。架構(gòu)權(quán)衡分析方法幫助識別屬性之間的這些依賴關(guān)系，稱之為權(quán)衡點。這是架構(gòu)權(quán)衡分析方法和其它軟件分析技術(shù)之間的主要區(qū)別，它明確地考慮了多個屬性之間的聯(lián)系，并且允許有原則的權(quán)衡這種難免的聯(lián)系。其他的分析框架，雖然也考慮聯(lián)系，但只以非正式的或者在較高的抽象級別考慮。權(quán)衡點來自于受多個屬性影響的架構(gòu)元素。

2 權(quán)衡分析方法簡述

系統(tǒng)架構(gòu)和軟件的質(zhì)量有著密不可分的關(guān)聯(lián)[3]。雖然詳細(xì)設(shè)計、數(shù)據(jù)結(jié)構(gòu)、算法、編碼和測試等也很重要，但是，軟件的性能、可用性和可修改性等的好壞很大程度上取決于系統(tǒng)架構(gòu)，而且整體軟件結(jié)構(gòu)更關(guān)系到系統(tǒng)成功與否[4]。因此，在構(gòu)建之前，嘗試并確定系統(tǒng)是否注定要滿足其所期望的質(zhì)量，這是架構(gòu)權(quán)衡分析方法的目標(biāo)所在。

盡管存在分析特定質(zhì)量屬性的方法，這些分析通常是在孤立的情況下進(jìn)行的。然而，實際上某個屬性往往對另一個屬性有影響，例如安全對性能，性能對可修改性，可用性對安全；另外，成本受所有屬性的影響等等。雖然優(yōu)秀的架構(gòu)師了解架構(gòu)過程必需進(jìn)行權(quán)衡，但是缺少合適的原則指導(dǎo)這一過程，尤其是屬性交互過程。

軟件架構(gòu)通常是在摸索中進(jìn)行的。在系統(tǒng)構(gòu)建過程中，權(quán)衡是必須的，但需用特別的方式實現(xiàn)。

在選擇架構(gòu)以滿足廣泛的質(zhì)量屬性時，設(shè)計人員已經(jīng)使用了一些技術(shù)來降低風(fēng)險。比如選擇兩種模式，一種移植性好，另一種易于修改。但是對模式的分析卻沒有很深入。這些模式的用戶在構(gòu)建之前不知道該架構(gòu)的可移植性、可修改性或健壯性。

架構(gòu)權(quán)衡通過分析性能、可靠、可修改和安全等屬性，以確定需求是否得到保障。它推動客戶、開發(fā)和維護(hù)等人員相互協(xié)作，從而明確需求，最終協(xié)助相關(guān)人員找到屬性交互權(quán)衡點，并為軟件架構(gòu)的后繼過程提供指導(dǎo)框架。因此它是一種架構(gòu)級的設(shè)計方法，

3 架構(gòu)權(quán)衡分析模型

架構(gòu)權(quán)衡分析設(shè)計方法是一種螺旋模型，如圖1所示。通過相關(guān)人員更深入地了解系統(tǒng)，進(jìn)而擾動設(shè)計，最終通過又一輪的迭代降低系統(tǒng)風(fēng)險。但它與一般螺旋模型不同，不需要涉及任何實現(xiàn);每次迭代都是由分析結(jié)果激發(fā)，并產(chǎn)生新的、更詳細(xì)和更有見識的設(shè)計。

圖1 架構(gòu)權(quán)衡分析方法步驟

架構(gòu)的分析包括操作、控制和度量幾組架構(gòu)元素、環(huán)境因素和架構(gòu)約束。架構(gòu)師的主要任務(wù)是構(gòu)建架構(gòu)，導(dǎo)出系統(tǒng)行為，而系統(tǒng)行為又必須受成本預(yù)算的約束。延遲或吞吐量等屬性都是性能需求，但是這些需求與架構(gòu)元素有關(guān)，而架構(gòu)元素又受制于可用的資源。例如:CPU的進(jìn)程分配和并發(fā)進(jìn)程調(diào)度策略、共享數(shù)據(jù)的存儲與訪問策略。架構(gòu)師要充分把握這些架構(gòu)元素與系統(tǒng)性能之間的關(guān)系，在滿足需求的前提下適當(dāng)?shù)夭倏厮鼈儭?/p>

然而，這一任務(wù)通常缺少合適的工具。好的架構(gòu)師全憑自己的直覺、經(jīng)驗，以及原型設(shè)計做指導(dǎo)。偶爾還會將顯式建模步驟作為設(shè)計活動，或者對單個質(zhì)量屬性進(jìn)行顯式的形式化分析。

3.1 方法的步驟

該方法有四個主要領(lǐng)域:場景和需求收集、架構(gòu)視圖和場景實現(xiàn)、模型構(gòu)建和分析，以及權(quán)衡。一般來說,一旦系統(tǒng)初始場景和需求已經(jīng)抽出，并且在一組初始架構(gòu)或小的架構(gòu)被提出來后,則針對任何提議的設(shè)計對每個質(zhì)量屬性進(jìn)行評價或隔離。在評估之后，有一個評論步驟，該步驟會發(fā)現(xiàn)影響多個屬性的權(quán)衡點。在評論之后，可以改進(jìn)模型并重新評估;或更改模型以反映這些改進(jìn)并重新評估;或改變一些需求。詳細(xì)步驟如下。

（1）收集場景

引出系統(tǒng)使用場景。在任何架構(gòu)分析開始之前，需求都是存在的。在其他情況下，場景驅(qū)動需求。分析過程也可以從這兩種方式中獲利。引出場景時對功能和質(zhì)量需求進(jìn)行操作，以促進(jìn)相關(guān)人員之間的交流，并挖掘系統(tǒng)應(yīng)該支持的重要活動。

（2）收集需求、約束和環(huán)境

除了場景之外，還必須確定基于屬性的系統(tǒng)需求、約束和環(huán)境。每個需求可以從假定的場景中得到一個特定的值，或更加泛化。環(huán)境必須具有特征，因為隨著進(jìn)化，對這些也影響屬性分析的因素在設(shè)計的后續(xù)分析和約束時要被記錄下來。這一步非常強調(diào)從前面的步驟中重新考慮場景，以確保它們能夠解釋重要的質(zhì)量屬性。步驟（1）和（2）可以交互進(jìn)行。

（3）描述架構(gòu)視圖

場景、需求和工程設(shè)計原則共同組成備選架構(gòu)。此外，不需從零起步設(shè)計，例如遺留系統(tǒng)、互操作性，以及以前的項目的成功與失敗都可以約束架構(gòu)空間。

備選架構(gòu)必須以與每個重要質(zhì)量屬性相關(guān)的架構(gòu)元素和屬性來描述。例如，重復(fù)和表決方案是可靠性的一個重要因素;并發(fā)分解、過程優(yōu)先級、吞吐量估計和排隊計劃對性能非常重要;就系統(tǒng)安全而言，入侵模型與防火墻都是關(guān)鍵;而就軟件的可修改性而言，則抽象和封裝非常必要。此外，對每種特性進(jìn)行分析所需的詳細(xì)信息通常在不同的架構(gòu)視圖中被捕獲。多種視圖可以用于架構(gòu)分析，例如:模塊視圖（對工作分配和信息隱藏推理）、進(jìn)程視圖（有關(guān)性能推理）、數(shù)據(jù)流視圖（功能需求推理）、類視圖（共享對象定義推理），等等。

關(guān)于架構(gòu)表示還有另外一個重要的觀點:在陳述時往往試圖對多個相互競爭的架構(gòu)進(jìn)行比較。然而，設(shè)計人員通常認(rèn)為他們一次只處理一個單一的架構(gòu)。為什么這些觀念會不一致?從一般角度來看，架構(gòu)是一組被分配給一組結(jié)構(gòu)元素的功能集合，由一組視圖描述。幾乎所有的變更都會改變這些視圖中的某一個，從而形成一個新的架構(gòu)。雖然這一點看起來像是樹枝分叉，但在這一背景下，這是重要的樹枝，原因是架構(gòu)權(quán)衡分析是在屬性模型的基礎(chǔ)上實現(xiàn)，建構(gòu)和維護(hù)這些模型也能幫助理解架構(gòu)的理由。要更改架構(gòu)功能的任何方面，如結(jié)構(gòu)元素、協(xié)調(diào)模型，將影響一個或多個模型。一旦提出了變更，修改后的架構(gòu)與原件之間會有沖突，因此要進(jìn)行新舊之間的比較。因此，架構(gòu)權(quán)衡分析方法是在競爭的架構(gòu)中進(jìn)行選擇的一個連續(xù)過程，雖然對于不知情的旁觀者來說這些架構(gòu)看起來幾乎是一樣的。

（4）分析屬性

在獲得初始架構(gòu)后，就可以分別對它們的所有屬性進(jìn)行分析。對分析的順序沒有要求;也不需要評論需求與屬性之間的交互。并發(fā)單獨地分析屬性是分離關(guān)注點的一種策略，在分析過程中，不同特長的專家可以充分發(fā)揮自己的專業(yè)知識。

分析結(jié)果將引導(dǎo)出系統(tǒng)行為關(guān)于特定屬性值的陳述，例如：請求的平均響應(yīng)時間60 ms;失敗的平均時間是1.8天;系統(tǒng)能有效抵御已知的網(wǎng)絡(luò)攻擊;平臺硬件單個成本為50萬元;該軟件每年需要4人維護(hù);等等。

（5）識別敏感性

這一步?jīng)Q定單個屬性分析對特殊架構(gòu)元素的敏感性；也就是說，架構(gòu)的一個或多個屬性是變化的。模型能夠隨機應(yīng)變，以捕獲這些設(shè)計更改，并對結(jié)果進(jìn)行評估。任何受變化影響的架構(gòu)建模值都是敏感點。

（6）確定權(quán)衡點

對步驟（4）中構(gòu)建的模型進(jìn)行評估，并找到架構(gòu)的平衡點。盡管這是評論設(shè)計的標(biāo)準(zhǔn)實踐，但是可以通過將此評論集中在屬性特定的分析交互上，特別是權(quán)衡點的定位來獲得顯著的額外效益。

一旦確定了架構(gòu)的敏感點，平衡點就是這樣一些架構(gòu)元素，有若干屬性對其都很敏感。例如，設(shè)服務(wù)器數(shù)量是一個架構(gòu)元素，則C/S架構(gòu)的性能、可用性和安全性都對這個元素非常敏感，而服務(wù)器數(shù)量越多，被攻擊的點就越多，故安全性與其成反比。因此，這個元素是C/S架構(gòu)的一個權(quán)衡點，最終必須對服務(wù)器數(shù)量進(jìn)行取舍。

3.2 架構(gòu)權(quán)衡分析方法的迭代

對比分析結(jié)果與系統(tǒng)需求。若系統(tǒng)的預(yù)測行為與它的需求足夠接近時，設(shè)計人員可以開始詳細(xì)設(shè)計和實現(xiàn)。在實踐中，繼續(xù)使用分析模型跟蹤架構(gòu)對支持開發(fā)、部署和維護(hù)是很有用的。在一個系統(tǒng)的生命周期中，設(shè)計和分析永遠(yuǎn)不會停止。

在分析揭示問題后，可以制定一個改變架構(gòu)、模型或需求的行動計劃。該行動計劃將利用對權(quán)衡點的特定屬性進(jìn)行分析和識別，這就導(dǎo)致了另一次迭代。需要明確的是，這些步驟是非線性的，并且以復(fù)雜的方式相互作用:分析可以導(dǎo)致對需求的重新考慮;模型的構(gòu)建可以指出那些沒有充分考慮或在架構(gòu)中沒有記錄的因素。這也是為什么把這些步驟描述成一個螺旋狀的原因。

4 結(jié)語

基于對系統(tǒng)屬性的充分分析，集中對權(quán)衡點進(jìn)行識別，架構(gòu)權(quán)衡分析方法的動機是希望在相互競爭的架構(gòu)中做出合理的選擇。架構(gòu)權(quán)衡分析方法還可以作為早期澄清需求的工具。運用架構(gòu)權(quán)衡分析和分析后獲得的結(jié)果，架構(gòu)師對系統(tǒng)能否滿足其需求的能力有了更強的理解和信心。包括用于激發(fā)特定屬性分析的場景和這些分析結(jié)果還為所做的架構(gòu)選擇提供文檔依據(jù)。

[1]劉璘,周明輝,尹剛.大數(shù)據(jù)時代軟件工程專題前言[J].軟件學(xué)報,2017,28（6）:1327-1329.

[2]王志剛,高磊.軟件發(fā)布規(guī)劃的形式化探討.計算機時代[J],2013,（12）:12-14.

[3]Federal Segment Architecture Methodology（FSAM）Practitioner’s Training version 1.0.http://www.fsam.gov.

[4]白金.軟件架構(gòu)模式在信息系統(tǒng)開發(fā)中的應(yīng)用分析[J].通信世界,2017（5）:249-250.

[5]王智超,王敏,熊燕.軟件架構(gòu)設(shè)計之多視角分析[J].現(xiàn)代計算機，2014,（10）:35-37.

[6]李衛(wèi)華,傅曉東.可拓創(chuàng)新軟件體系結(jié)構(gòu)研究[J].廣東工業(yè)大學(xué)學(xué)報,?2016,34（02）:2-5.

[7]楊波,于茜,張偉,吳際,劉超.GitHub開源軟件開發(fā)過程中影響因素的相關(guān)性分析[J].軟件學(xué)報,2017,28（6）:1330-1342.

[8]王煒,陳未如.軟件架構(gòu)切片在軟件可靠性評估中的應(yīng)用[J].微計算機信息,2008,28（1）:290-292.

[9]王志剛,高磊.軟件發(fā)布規(guī)劃遺傳算法探討.軟件導(dǎo)刊[J]，2016,15（11）:56-58.

[10]王志剛,高磊.軟件發(fā)布規(guī)劃的遺傳算法實現(xiàn)與解釋.現(xiàn)代計算機[J],2016（12）:3-6.

[11]俞析蒙.基于驗證的軟件架構(gòu)演化分析與評估[D].南京:東南大學(xué),2015.

[12]Norman Hendrich,Hannes Bistry,張建偉.助老服務(wù)機器人系統(tǒng)設(shè)計及軟件架構(gòu)[J].Engineering,2015,1（1）:26-34.

Discussions on the Approach of Software Architecture Tradeoff Analysis

WANG Zhi-gang,XU Qian
（College of Math and Computer Science,Hunan Normal University,Changsha 410081）

Software architecture is a complex and wicked problem.Architects have to rely on rich experience to do this work,and the architecture pro?cess is actually a process of constantly weighing.However,the qualities and efficiency of software are very important.In order to under?stand the essence of the software architecture and its implementation,summarizes the basic principle of software architecture tradeoff meth?od,introduces the basic steps of it in detail,some samples are given to understand the key concepts.It is hoped to reduce the blindness of software architecture and to help with good software architecture and design.

Software Architecture;Quality Attribute;Scenario;Architecture Tradeoff

1007-1423（2017）33-0048-04

10.3969/j.issn.1007-1423.2017.33.012

王志剛（1962-），男，湖南沅江人，碩士，教授，研究方向為軟件工程、計算機網(wǎng)絡(luò)

胥茜（1993-），女，湖南岳陽人，在讀碩士研究生，研究方向為軟件工程

2017-11-09

2017-11-20