一種軟件體系結構復雜性的評價方法

摘 要：為了滿足軟件體系結構復雜性的預測和評價需求，通過抽取構件之間的連接，提出了基于復合關系的分層式軟件體系結構，從而能夠清晰、準確地表達構件之間的關系。在該結構基礎上，提出了基于加權圖的復雜性評價模型，并結合實例分析了模型的使用效果。模型能夠準確地刻畫系統結構及構件關系，而且能夠較為客觀地定量評估系統結構復雜性。它具有實現過程簡單、通用性強等特點。

關鍵詞：構件; 軟件體系結構; 軟件復雜性; 評價模型

中圖分類號：TP301 文獻標志碼：A 文章編號：1001-3695(2008)08-2377-03

Approach to evaluating for complexity of software architecture

JIAO Feng1，2， WANG Li-ping3， HOU Jian-min2

(1. School of Information Engineering， University of Science Technology Beijing， Beijing 100083， China; 2. Computer Center， Hebei University of Engineering， Handan Hebei 056038， China; 3. Dept. of Information Engineering， Handan Polytechnic College， Handan Hebei 056002， China)

Abstract:In order to satisfy the requirements of predicting and evaluating complexity of software architecture， this paper presented composite relationships based and layered software architecture， which could exhibit the relationships between components explicitly and accurately， through the separate links between components. Based on the software architecture， proposed weighted graph based evaluation model for complexity， with an example to be analyzed and explained how to use the model. Moreover， the experiment indicates that the software architecture can reflect real structure and the evaluation model can quantitate complexity of software architecture. Finally， it can be concluded that the model owned the characteristics such as simplicity to process， strong universality.

Key words：component; software architecture(SA); software complexity; evaluation model

基于構件的軟件開發已經成為解決大規模復雜軟件開發的有效方法和途徑。除了構件之外，軟件體系結構的作用功不可沒。由于它體現了軟件系統的基本思想和基本結構，不僅可以用于提高系統的開發效率和靈活性，也可以作為早期軟件質量預測和控制的主要依據。近年來，預測和評價軟件體系結構質量的研究已成為熱點。這些研究多集中在SA的可靠性、安全性、可理解性、可維護性、效率等性能方面的分析和評價^[1]，而對結構本身復雜性的研究相對較少。但在實際應用中，體系結構復雜性對系統質量的影響卻是不容忽視的，過于復雜的體系結構會帶來較低的可理解性和可維護性；過于簡潔的體系結構的又有可能造成可靠性和安全性的下降，所以各性能屬性之間是相互影響、相輔相成的^[2]。如何客觀正確地度量系統的復雜性，如何找出它與其他屬性之間的平衡關系都是SA評價研究的重要內容。

與傳統的結構化軟件關注語句細節不同，基于構件的軟件體系結構更多地關注構件及構件之間交互的關系，因此對于復雜性的分析和評價有其獨特性。文獻[2]定義并詳細闡述了各種復雜性屬性，但并未給出復雜性的度量方法或模型。文獻[3]利用類聯系圖描述構件之間的交互關系，進而通過模塊化程度分析構件的耦合性和內聚性，以此得出SA的質量。該方法理論性較強，結構較為嚴謹，主要用于對已實現系統的分析和評價。文獻[4，5]則建立基于有向圖的依賴模型，借以反映構件間的依賴關系，但每個依賴關系的耦合性可能有所不同，將有可能影響對SA評價結果，而且構件自身的復雜性也會對系統有影響。本文基于這些研究，提出了一種基于復合關系的復雜性評價模型。模型通過引入業務概念，將構件之間的復雜交互關系提取為一種分層的復合關系，并將這種復合關系抽象為一種邏輯復合構件。轉換后的結構使得構件之間的交互關系層次分明、邏輯清晰，易于分析評價。不僅考慮到構件自身復雜性，還考慮了不同的交互關系對于系統結構的影響，其分層的結構使其更能適用于大規模復雜軟件系統。

1 基于加權圖的復雜性評價模型

在面向領域的應用系統中，根據業務特性抽象出業務構件，不僅大大提高領域軟件的重用粒度，縮短開發周期，提高開發效率，而且有利于生命周期各階段之間的無縫對接以及業務對象的可追蹤。本文提出的基于復合關系的軟件體系結構就是利用這個特點，將所有構件按業務概念不斷地由小到大進行組合，直到最后形成一個層次結構。最低層是真實的構件，其他層的構成是組合起來的邏輯構件，即復合構件，作為構成SA的一個基本元素。但復合構件并不是構件的疊加，而是封裝了構件之間的交互關系，如膠合代碼、腳本。

1.1 基于復合關系的軟件體系結構

基于復合關系的軟件體系結構(composite relationship based software architecture，CRSA)核心思想是整個應用系統被看成最大的一個復合構件，它由若干較小的構件復合而成，這些構件又由更小的構件復合而成，如此反復，直到原子構件(即不可拆分的構件稱為原子構件)。CRSA形式化定義如下:

定義1 復合構件和復合關系。由多個不同的構件組合而成的構件，稱為復合構件(Cc)。Cc={vi|vi是原子構件或復合構件，i=1，2，…，n}。

復合構件與被復合構件之間的關系稱為復合關系，用“→”表示。例如復合關系集合E={Cc→Cb1，Cc→Cb2 ，Cc→Cb2}中的三個關系表示復合構件Cc由構件Cb1、構件Cb2、構件Cb3復合而成。

定義2 CRSA。設有非空的原子構件集合Ω，CRSA是由非空集合Ω的部分子集構成的Ω的集類，記為UΩ。設SΩ表示Ω的所有子集構成的冪集，則有UΩSΩ。

設同一抽象粒度的復合構件歸為一層，構成層集合A，則UΩ可以演變為由n層集合構成的集類，UΩ={Ai，i=1，2，…，n}，且是一個單調集類，即A1A2…Ai…An。其中：A1表示抽象層次最高的構件集合;An表示抽象層次最低的構件集合，即原子構件的全集，A2~An-1的各集合分別對應第2~n-1層構件集合。

圖1是一個CRSA的結構示意圖。它是一個四層結構，包含有四個原子構件（AC1、AC2、AC3、AC4）和三個復合構件（CC1、CC2、CC3）。其中，AC1與AC2合成復合構件CC1、CC1又與AC4合成CC2、CC2與AC3合成CC3、CC3就相當于最終的系統。CC1、CC2都具有相對完整的業務功能和較強的封裝性。這種由復合構件和原子構件組成的軟件體系結構具有原理簡單、實現容易等特點。

定義3 構件關聯度和構件貢獻度。復合關系的關聯依賴程度，稱為構件的關聯度。如Cb1到構件Cc的關聯度，記為w(Cc→Cb1)。

設構件Ck的功能集為FC={fci，i=1，2，…，n}，復合構件P需要構件Ck提供服務，將Ck提供的功能集記為HC={hcj|hcj∈FC， j=1，2，…，m，m≤n}， HcFc，則s=m/n(s≤1)，s稱為構件Ck對復合構件P的貢獻度，記為D(Cc→Cb1)。構件的貢獻度是構件關聯度的重要組成部分，它為評估系統復雜性提供了度量手段。

1.2 基于加權圖的復雜性評價模型定義

在CRSA基礎上，提出基于有向加權圖的復雜性評價模型GEMC(graph-based evaluation model for complexity)。

定義4 GEMC模型。GEMC是一個帶權的有向無環圖DAG，表示為一個二元組D={V，E}，且D是一個偏序集合。其中， V、E分別是節點集合和有向邊集合。節點集合V={v1，v2，…，vn}中的每一個元素v對應于CRSA中的一個構件，邊集合E={eij| eij=〈vi，vj〉，vi，vj∈V， i，j= 1，2，…，n }中的一個元素eij對應于CRSA中一個復合關系。E中的每一條邊，賦予一個非負數的權重，記為w(eij)，且w(eij)∈[0，1]。w(eij)對應于節點(即構件)vi到vj的關聯度w(vi→vj )。

定義5 構件的共享度和構件的復雜度。GEMC中一個構件節點的入度稱為該構件節點的共享度。一個構件節點的出度稱為該構件的復雜度。

定義6 體系結構的復雜性通路。體系結構的復雜性通路P是指從頂級節點到葉節點的一條通路，記為P=(e1，e2，…，en)。其中ei是GEMC模型中的邊。通路P上各邊的權值之和稱為通路的權，記為w(P)=∑ei∈Pw(ei)。其中，ei權值最大的那條通路稱為最大權通路，權值最小的那條通路稱為最小權通路。

在CBD開發中，復雜性通路提供了分析和預測系統復雜性瓶頸的方法。

2 工作原理及特點

基于CRSA和GEMC模型實現系統結構復雜性評估的基本思想是：復雜性由原子構件本身的復雜性和復合構件的復雜性構成。

a) 原子構件復雜性：其度量方法受構件實現方法的影響，具體是，若構件內部是結構化程序，則需采用傳統的度量方法，如McCabe方法、Halstead方法等；若是面向對象程序，則宜采用面向對象的度量方法。

b) 復合構件的復雜性：復合構件反映構件之間的交互關系。交互關系有多種類型，如調用關系、事件、數據訪問、連接、流、仲裁器、適配器、分配器等。文獻[6]進行了詳細的分類和闡述。這些關系歸納起來主要分為兩類，即直接交互關系和間接交互關系。直接交互關系就是直接方法調用，如方法、事件委托、RPC等。相應的構件模型有Enterprise JavaBeans、CORBAComponent Model、 COM、 UML2.0 等。這類關系沒有明顯的代碼，硬連接在構件程序中，沒有獨立的實體。而間接交互關系則不同，它有獨立的實體，有相應的代碼，如膠合代碼或腳本等。該連接實體通過在構件之間傳遞信息，起著協調的作用。相應的構件模型有JavaBeans、Koala等^[7]。

這些不同類型的交互關系有著不同的耦合性和內聚性，它們對SA的復雜性有較大影響。在本文中通過分配不同的分值以表示各種關系的復雜程度，分值獲得后重新映射在[0，1]之間。因為交互關系分為兩大類，且直接交互關系是強耦合的，間接交互關系是弱耦合的所以直接交互關系的分值限定在(0，0.5)內，而間接交互關系的分值限定在[0.5，1)內。各類型的具體分值則可以采用經驗值、專家打分等方法確定。如何確定權值的細節問題不在本文的討論范圍。

2.1 工作原理

評價模型采用自下而上的方法，即先獲取原子構件的復雜性，再逐層計算復合構件的復雜性，最后獲得系統的復雜性。

1) 第一層復合構件復雜性度量

第一層復合構件是由原子構件復合而成，其評價方法與其他層復合構件的評價方法略有不同，因此單獨考慮。圖2是一個第一層構件結構示意圖，顯示了原子構件層和第一層復合構件。復合構件Ck由原子構件集{P1， P2，…，Pi，…，Pn}復合而成，它們之間的邊eki被賦予了一定的權值wki，用于表示復合關系的關聯度，它的值并不等于交互關系的分值，而等于該分值的比例，具體到圖2的例子，就是該分值的1/2（一般情況下）。DC(ck)表示復合構件Ck的度量值，n表示原子構件的個數，yi表示原子構件Pi的度量值，則復合構件Ck的度量計算見式(1)。

DC(ck)=∑ni=1wkiyi(1)

其中：wki≤1，yi≤1。因此Yk≤n，n也是節點k的出度，wki就是交互關系的分值，yi的計算如下：

yi=DA(pi)×βki(2)

其中：βki表示原子構件i對復合構件k的貢獻度；DA(pi)表示原子構件pi的復雜性的度量值。用γ表示構件i的所有關聯度的均值，則其計算如下：

γ=1/n∑nk=1βki(3)

其中：n是構件節點i的入度；βki是構件節點i對上層構件節點k的關聯度。根據實踐經驗，若γ<0.5，說明構件i的設計可能不合理(如功能過多、規模過大等)，存在隱患，建議重新設計。另一條經驗是：設wki中的最大值與最小值之差為Δ=wmaxi-wmini，當Δ≥0.5且γ≥0.5時，說明構件i的可重用性差。

2)第二層以上復合構件復雜性度量

不同于原子構件，復合構件反映交互關系的一種邏輯構件，一般情況下，復合構件的貢獻度為1。第二層以上復合構件復雜性的度量如式(4)所示，DC(cc)表示復合構件的度量值，Yk表示下層復合構件的度量值。

DC（cc）=∑nk=1wckDC(ck)(4)

由GEMC原理可以得出，頂層復合構件的復雜性就是系統的復雜性。GEMC通過計算原子構件的復雜性、復合構件的復雜性，可以完成對CRSA的復雜性評價。基于加權圖的模型計算可以通過鄰接矩陣計算得出每一個復合構件或系統的復雜性。

2.2 模型特點

GEMC復雜性評價模型具有如下特點:

a)實用性強。易于理解、易于使用，實現過程簡單且速度快，有利于工具化和自動化。

b)靈活性高。適用于不同規模的體系結構。

c)可用于設計階段。可以在軟件開發生命周期的早期實施復雜性分析與控制，有利于降低系統開發的風險和成本，而不必像其他模型那樣等到所有的構件都已經基本實現之后才能進行評估。

3 示例分析

經典的GoF設計模式中的Facade模式和Mediator模式通過代入本模型分析，充分驗證了兩種模式較低的復雜性和較強的靈活性。除此之外，GEMC模型還可以分析原子構件對于整個結構的影響。下面是一個實例，即石油鉆井模擬的套管層次設計系統(application for casing program design，ACPD )。ACPD是一個典型四層CRSA，從下到上依次為基本功能構件層、基本業務構件層、業務構件層和應用系統構件層，抽象層次依次增高。

a)基本功能構件層：有四個原子構件，分別是邏輯構件C31、計算構件C32、顯示構件C33和數據構件C34。

b)基本業務構件層：由基本的業務構件組成，是復合構件，包括確定表層套管C21、確定技術套管C22、確定尾管C23和確定套管數據C24四個構件。

c) 業務構件層：面向業務的構件，也是復合構件，包括確定套管個數構件C11、確定套管長度構件C12、確定水泥返高構件C13和確定套管直徑構件C14。

d) 應用系統層：由業務構件復合而成。在本例中，通過業務層的四個復合構件，最終得到了套管層次的套管直徑、套管長度、套管個數等參數。

ACPD的GEMC描述為

G={V，E}

V={C0，C11，C12，C13，C14，C21，C22，C23，C24，C31，C32，C33，C34}

E={C0→C11，C0→C12，C0→C13，C0→C14，C11→C24，C12→C21，

C12→C22，C12→C23，C13→C33，C13→C24，C14→C22，C14→C24，C21→C33，C21→C34，C22→C31，C22→C32，C22→C33，C22→C34，C23→C31C23→C32 C23→C33，C22→C34，C24→C34 }

w(Ci→Cj)=1（構件之間的關系均設為同樣的類型）。

在本例中考慮最理想情況下，GEMC中最底層的四個構件C31、C32、C33、C34的復雜性DA(pi)均取1，且貢獻度βki也均為1，此時得到的系統復雜性DC(s)為14，作為基準值。然后其他條件不變，當每個原子構件的復雜性DA(pi)分別取0.6時，得到的DC(s)分別為13.70、13.70、13.40、13.10，這四個值與基準值一起構成一條線，如圖3所示的“◆”連線，C00表示基準值，C31、C32、C33、C34表示這四個構件的復雜性分別取0.6時系統復雜性的度量值；同理可得每個原子構件復雜性DA(pi)分別取0.85時系統復雜雜性由0.6提高到0.85時，系統的復雜性增大，表明原子構件的共享度越大對系統結構影響也越大也越高。

實驗結果表明，CRSA模型能準確刻畫系統結構和構件關系，GEMC模型能夠客觀、準確、定量地評估系統結構復雜性，而且能夠幫助設計人員和開發人員確定系統的復雜性瓶頸。

4 結束語

針對領域工程，給出了基于復合關系的分層式軟件體系結構CRSA，并針對CRSA提出了基于加權有向圖的復雜性評價模型GEMC。實踐當中，該模型不僅可以評價已有系統的復雜性，也可早期評價設計階段的系統復雜性。

同時從實驗結果看，GEMC模型簡單、定性準確、容易實現，適用于不同規模的系統復雜性評價。但同時，本文中沒有詳細闡述如何確定復合關系權值大小，也沒有討論復雜性與其他SA屬性之間的依存關系，這些都將在以后的工作中繼續深入研究。

參考文獻：

[1]DOBRICA L，NIEMELA .A survey on software architecture analysis methods[J]. IEEE Trans on Software Engineering， 2002，28(7):638-653.

[2]MAZHELIS O， LEHTO J A， MARKKULA J， et al. Defining Complexity factors for architecture evaluation framework:[C]// Proc of the 39th Hawaii International Conference on System. Hawaii: IEEE Computer Society，2006: 1-10.

[3]SARTIP K I.IEEE International Workshop on Program Comprehension[M].Toronto:IEEE Computer Society，2001:259-268.

[4]ALHAZBI S M. Measuring the complexity of component-based system architectzere[C]// Proc of International Conference on Information and Communication Technologies: From Theory to Applications. 2004:593-594.

[5]SANGAL N，JORDAN E， SINHA V ，et al.Proc of the 20th annual ACM SIGPLAN Conference on Object Oriented Programming Systems Languages and Applications [C].San Diego: ACM Press，2005:167-176.

[6]MEHTA N R，MEDVIDOVIC N， PHADKE S. Towards a taxonomy of software connectors[C]// Proc of the 22nd Int’l Conf on Software Engineering.New York:ACM Press，2000: 178-187.

[7]LAU K K，UKIS V，VELASCO P，et al. A component model for separation of control flow from computation in component-based systems[J]. Electronic Notes in Theoretical Computer Science，2006，163(1):57-69.

注：本文中所涉及到的圖表、注解、公式等內容請以PDF格式閱讀原文