軟件適應(yīng)性度量方法研究

摘 要:為了能夠通過軟件的源代碼度量面向?qū)ο筌浖倪m應(yīng)性，提出了一個包含七個具體度量指標的軟件適應(yīng)性度量模型，并開發(fā)了在Java軟件中提取各度量指標的支持工具FlexTool;為了避免通過手動調(diào)整大量軟件源代碼的方式度量軟件適應(yīng)性，使研究人員能夠在不太了解軟件實現(xiàn)細節(jié)的情況下對適應(yīng)性進行度量，提出了將該適應(yīng)性模型應(yīng)用于軟件版本的演化從而度量軟件適應(yīng)性的方法，并通過著名開源軟件Ant的版本演化對該方法的合理性進行了驗證。

關(guān)鍵詞:軟件適應(yīng)性; 度量指標; 度量模型; 版本演化

中圖分類號:TP311文獻標志碼:A

文章編號:1001-3695(2009)09-3334-04

doi:10.3969/j.issn.1001-3695.2009.09.038

Study of software metrics for software flexibility

LIU Shun-zheng， LI Lin， ZHANG Li

(Software Engineering Institute， College of Computer Science Engineering， Beihang University， Beijing 100191， China)

Abstract:In order to measure software flexibility based on object-oriented software’s source codes， this paper proposed a flexibility measurement model including 7 concrete measurement factors， and developed a tool which could extract all the measurement factors from a software coded by Java. Besides， in order to prevent researchers from measuring flexibility through changing source codes manually so that they could measure flexibility even though they were not very familiar with softwares implementation details， this paper proposed a method which used the measurement model based on the software evolution to measure flexibility. In the end， validated that the measurement model and the method proposed were reasonable by using them to a famous open-source software called Ant.

Key words:software flexibility; measurement factors; measurement model; software evolution

當今計算機技術(shù)的快速發(fā)展、軟件運行環(huán)境的不斷變化，以及人們對軟件的要求越來越多等因素，都要求軟件具有更好地適應(yīng)新變化的能力[1]，因此，在軟件的設(shè)計和實現(xiàn)中，其適應(yīng)性和靈活性是需要考慮的一個非常重要的因素。軟件適應(yīng)性是指一個系統(tǒng)或構(gòu)件為適應(yīng)業(yè)務(wù)應(yīng)用和環(huán)境的改變(不包括設(shè)計時能夠確定的改變)進行變化的難易程度[2]。Bengtsson等人[3]認為軟件適應(yīng)性是為了使軟件系統(tǒng)適應(yīng)需求和環(huán)境變化而付出的努力。與軟件的穩(wěn)定性、可操作性等質(zhì)量屬性一樣，適應(yīng)性是軟件一個外部質(zhì)量屬性，很難直接測量。因此，如何量化地表示軟件的適應(yīng)性是對其進行度量的關(guān)鍵。

目前對于軟件適應(yīng)性度量的研究，存在以下兩方面的問題:a)軟件適應(yīng)性的度量還沒有正式的標準，這方面的研究也不多;b)已經(jīng)提出的一些度量方法需要度量人員對所度量的軟件代碼實現(xiàn)十分熟悉，并能根據(jù)變更需求對該軟件實施變更，然而應(yīng)用這種方法對規(guī)模較大的軟件進行度量的工作量太大，使實際可操作性不強。

針對以上兩個問題，本文提出了一個以面向?qū)ο筌浖创a作為考察對象的軟件適應(yīng)性度量模型。該模型具有易用而實際可行的特點，并提出一種應(yīng)用該模型對面向?qū)ο筌浖M行適應(yīng)性度量的方法。最后對該模型及方法的合理性加以驗證。度量軟件的適應(yīng)性本質(zhì)上是要度量軟件變更的難易程度。筆者發(fā)現(xiàn)，雖然無法準確預(yù)知某個軟件未來會發(fā)生哪些變更，但引起軟件版本演化的變更是研究軟件適應(yīng)性的一個合理來源。由此，針對本文提出的軟件適應(yīng)性度量模型，開發(fā)了支持工具FlexTool，它通過分析以Java為開發(fā)語言的軟件前后兩個版本的源代碼，對度量模型的各個度量指標給出測量結(jié)果。

1 相關(guān)研究

目前，軟件適應(yīng)性的度量還沒有正式的標準，這方面的研究也不多，另外，已經(jīng)提出的一些度量方法在實際中的可操作性不強。Eden等人[1]提出了演化復(fù)雜性的觀點，并演示了在不同的編程方式(面向?qū)ο蠛徒Y(jié)構(gòu)化編程)、體系結(jié)構(gòu)風(fēng)格和設(shè)計模式中，怎樣使用演化復(fù)雜性來測量和比較適應(yīng)性。應(yīng)用該方法，需要對于軟件的各個部分進行語義上和結(jié)構(gòu)上的分析及手動變更，對于大型軟件來說，這樣做需要巨大的工作量。Tsantalis等人[4]給出了一種描述面向?qū)ο笙到y(tǒng)適應(yīng)性度量的模型和方法，他們采用概率的手段來描述變化的不確定性，通過評價當增加一個新的功能或修改一個已有的功能對每一個類可能影響的概率來評估一個面向?qū)ο蟮脑O(shè)計變化的傾向。文獻[5]在軟件體系結(jié)構(gòu)層次提出了軟件適應(yīng)性的FCM(factor-criteria-model)模型，該方法無法應(yīng)用于從軟件源代碼度量適應(yīng)性。有人提出，測量適應(yīng)性的一種更加精確的方法依賴于對軟件變化的影響進行計算的算法或者測量，如用一個針對面向?qū)ο笙到y(tǒng)的變化—影響模型。Chaumun等人[6]得出了一些實驗結(jié)果。

2 軟件適應(yīng)性度量模型

2.1 軟件變更成本

根據(jù)軟件適應(yīng)性的定義[2]，其好壞體現(xiàn)在它適應(yīng)變更的難易程度，所以，適應(yīng)性和軟件的變更是緊密聯(lián)系的。針對軟件變更的原因及變更如何發(fā)生，Eden等人[1]提出了演化步驟的概念，認為軟件是對于一個問題集的實現(xiàn)。當這個問題集變化為一個新的問題集時，軟件為了實現(xiàn)新的問題集，就需要進行相應(yīng)的調(diào)整，從而發(fā)生了變更。借鑒這個觀點，以軟件的源代碼為考察對象，那么軟件的源代碼就是對一個問題集的實現(xiàn)，當問題集發(fā)生變化后，源代碼就將作出調(diào)整以適應(yīng)這種變化，如圖1所示。

基于源代碼度量軟件適應(yīng)性，就是要度量源代碼發(fā)生變更的難易程度。進一步說，就是度量發(fā)生變更的成本的多少。軟件變更的成本可以從兩方面考慮:一方面，它可以是軟件變更所消耗的人力、物力和時間等;另一方面，如圖1所示，它可以是軟件原有源代碼向變更后的源代碼進行調(diào)整的難度，如源代碼的變更量和變更范圍等。在本文中，軟件變更成本指的是后者。如果為了適應(yīng)新的變化，變更源代碼的成本很大，也就是說變更非常困難，那么它的適應(yīng)性就不好;反之，如果軟件只需要較小的成本就可以滿足新的變化，那么它就具有較好的適應(yīng)性。因此，基于源代碼度量軟件的適應(yīng)性問題就歸結(jié)為如何度量源代碼變更成本的問題。為此，必須考察軟件源代碼的特點，以及源代碼的變更發(fā)生在哪些方面。考慮到軟件開發(fā)技術(shù)的發(fā)展趨勢以及目前大部分軟件開發(fā)都采用面向?qū)ο蠹夹g(shù)，也為了進行更有針對性的研究，本文將面向?qū)ο筌浖脑创a作為研究對象。

2.2 度量模型

在面向?qū)ο筌浖校浖匕悺⒎椒ê痛a行等[7]。從源代碼的粒度上來講，類、方法和代碼行的粒度從高到低，是三個粒度層次。軟件變更在這三個層次上都會產(chǎn)生一定的影響，但影響又不盡相同。所以，單純考慮類層次，或者方法層次，或者代碼行層次的變更是不全面的，本文將對各個層次上的變更成本進行考慮。

另一方面，在類、方法和代碼行等不同粒度層次上，軟件的變更成本又可以從兩方面考慮:a)變更元素數(shù)量的多少，即變更的規(guī)模大小;b)變更發(fā)生在軟件的多大范圍之內(nèi)。前者從整體的數(shù)量上考察軟件變更的難易程度，即認為如果變更量占軟件的比例很大，則軟件的適應(yīng)性是比較不好的。后者則是從變更所牽扯的范圍這個角度考慮，即認為如果變更導(dǎo)致軟件進行范圍很大的改動，則軟件的適應(yīng)性是比較不好的，相反，如果變更比較集中，則變更易于實現(xiàn)，從而適應(yīng)性較好。

概括以上的觀點，將度量面向?qū)ο筌浖创a的變更成本進行歸納，如表1所示。

對于面向?qū)ο筌浖兏杀镜亩攘堪惖脑黾印h除和修改，方法的增加、刪除和修改以及代碼行的增加、刪除和修改。然而，由于各個類、方法之間相互依賴，使得變更之間并不是獨立的，而是存在一定的影響關(guān)系。本文從整個軟件范圍內(nèi)度量變更的成本，則已經(jīng)將變化的影響計算在內(nèi)，從而建立了度量軟件變更成本的度量模型，如圖2所示。

先將軟件的變更成本分為變更比率和變更覆蓋范圍兩個考慮方面，然后細分它們各自具體的度量指標:

a)變更比率。它考察由變更引起的軟件元素變化的比例，即考察軟件源代碼的相對改動量是很大的還是較小的。一般而言，大量的改動意味著較大的變更成本，此時認為軟件的適應(yīng)性較差;相反，如果軟件變更引起的源代碼變動量很小，則變更成本就小，軟件的適應(yīng)性就較好。定義了五個度量指標來量化地表示變化比率，它們分別是代碼變更率、類代碼行平均變更率、類代碼行最大變更率、方法代碼行平均變更率和方法代碼行最大變更率。這里使用了相對量，從而排除了軟件規(guī)模的影響。2.3節(jié)將給出這五個度量指標的定義和形式化的計算表達式。

b)變更覆蓋范圍。它考察軟件發(fā)生的變更是否集中在少部分軟件元素中，即源代碼的改動是集中在少部分類或方法中還是涉及到了廣泛大量的類和方法。對于前者，因為實現(xiàn)變更所關(guān)注的軟件元素很集中，所以變更成本更小，此時認為該軟件的適應(yīng)性較好;對于后者，變更的實現(xiàn)需要維護人員理解每個軟件元素的含義并顧及各個軟件元素之間的依賴關(guān)系，這樣的變更成本較大，則該軟件的適應(yīng)性較差。定義兩個度量來量化地表示變化覆蓋范圍，即類變更覆蓋范圍和方法變更覆蓋范圍。2.3節(jié)將給出這兩個度量指標的定義和形式化的計算表達式。

2.3 度量組的定義

在給出各個度量指標的定義之前，先對其中用到的符號及子表達式的含義給出說明:

在以下各定義中，LoC表示代碼行，software表示某個軟件，class表示類，classi表示某個類，method表示方法，methodj表示某個方法。下標old表示原有數(shù)量，下標added表示增加數(shù)量，下標changed表示修改數(shù)量，下標removed表示刪除數(shù)量。在形如LoCx(y)的表達式中，y可以是software或classi或methodj;x可以是old或added或changed或removed，比如，LoCadded(software)表示軟件增加的代碼行數(shù)。形如classx或methodx的表達式表示類數(shù)或方法數(shù)，如classremoved表示刪除的類數(shù)。

以下分別給出了圖2中列出的七個度量指標的定義，并定義了它們的形式化計算表達式。

定義1 代碼變更率LoC_ChangeRate度量了軟件變更的代碼行數(shù)占軟件變更后代碼行總數(shù)的比率:

LoC_ChangeRate=變更的代碼行數(shù)/變更后代碼總行數(shù)(1)

其中:變更的代碼行數(shù)= LoCadded(Software) + LoCchanged(software)，變更后的代碼總行數(shù) = LoCold(software) + LoCadded(software) -LoCremoved(Software)。

定義2 類代碼行平均變更率ClassLoC_MeanChangeRate度量了軟件中類的代碼變更率的平均值:

classLoC_MeanChangeRate=(∑mi=1類的i的代碼行變更率)/m(2)

其中:m=classold-classremoved。類i的代碼行變更率classLoC_ChangeRate(classi)度量了某個類i變更的代碼行數(shù)占變更后該類代碼行總數(shù)的比率:

classLoC_ChangeRate(classi)=(LoCadded(classi)+LoCchanged(classi))/(LoCold(classi)+LoCadded(Classi)-LoCremoved(classi))

定義3 類代碼行最大變更率classLoC_MaxChangeRate度量了軟件中類的代碼變更率的最大值:

ClassLoC_MaxChangeRate=

max({類i的代碼行變更率|1≤i≤m})(3)

其中:類i的代碼行變更率classLoC_ChangeRate(classi)的定義見定義2。

定義4 方法代碼行平均變更率methodLoC_MeanChanged-Rate度量了軟件中方法的代碼變更率的平均值:

methodLoC_MeanChangeRate=(∑nj=1方法j的代碼行變更率)/n(4)

其中:n=methodold -methodremoved。方法j的代碼行變更率methodLoC_ChangeRate(methodj)度量了某個方法j變更的代碼行數(shù)占變更后該方法代碼行總數(shù)的比率:

methodLoC_ChangeRate(methodj)=(LoCadded(Methodj)+LoCchanged(methodj))/(LoCold(Methodj)+LoCadded(methodj)-LoCremoved(methodj))

定義5 方法代碼行最大變更率methodLoC_MaxChange-Rate度量了軟件中方法的代碼變更率的最大值:

methodLoC_MaxChangeRate=

max({方法j的代碼行變更率|1≤j≤n})(5)

其中:方法j的代碼行變更率methodLoC_ChangeRate(methodj)的定義見定義4。

定義6 類變更覆蓋范圍class_ChangeRange度量了軟件中變更的代碼在類層次上的集中程度:

class_ChangeRate=代碼變更的類數(shù)/變更后的總類數(shù)(6)

其中:代碼變更的類數(shù)=classadded+classchanged，變更后的總類數(shù)=classold+classadded -classremoved。

定義7 方法變更覆蓋范圍method_ChangeRange度量了軟件中變更的代碼在方法層次上的集中程度:

method_ChangeRate=代碼變更的方法數(shù)/變更后的總方法數(shù)(7)

其中:代碼變更的方法數(shù)=methodadded+methodchanged，變更后的總方法數(shù)=methodold+ methodadded -methodremoved。

2.4 度量舉例:Maze Game

Maze Game的原型來自于GoF(Gang of Four)的經(jīng)典著作[8]。它解決如何靈活地為一個迷宮游戲(Maze Game)構(gòu)造迷宮(Maze)的問題。對于Maze Game，下面有兩種實現(xiàn)方案:第一種是沒有使用設(shè)計模式的簡單實現(xiàn)，第二種則應(yīng)用了Builder和Abstract Factory兩個設(shè)計模式并作了一些抽象。Builder設(shè)計模式分離了復(fù)雜對象的構(gòu)造和它的表示，Abstract Factory模式為創(chuàng)建一組相關(guān)的對象提供了接口。這兩個模式的應(yīng)用為軟件提供了更多的靈活性，因此，基于第二種設(shè)計方案的代碼實現(xiàn)具有更好的適應(yīng)性。

本文用Java語言實現(xiàn)了這兩種設(shè)計方案，并由源代碼得到了它們的類圖。圖3和4分別是應(yīng)用設(shè)計模式并進行抽象前后Maze Game的類圖。

為了使這個迷宮游戲更加豐富，假設(shè)在其后的版本中，它需要提供對裝有炸彈的(bombedRoom，bombedWall)和具有魔法的房間(enchantedRoom，enchantedDoor)的支持，并可以在某些房間之間用水溝(channel)代替墻壁，如圖5所示。

對于圖3和4的兩種設(shè)計，為了將圖5中的類加入游戲，分別對兩種設(shè)計施加了變更，并進行了代碼實現(xiàn)。對每種實現(xiàn)，使用FlexTool分別統(tǒng)計變更前后兩個版本代碼的變化比率和變化覆蓋范圍等九個度量指標，如圖6所示。

從圖6中可以看出，未使用模式實現(xiàn)的七個變更成本度量指標均高于使用了模式實現(xiàn)的相應(yīng)度量指標，其中有四個度量指標前者是后者的2倍左右，最高的達到2.73倍。與使用了模式的實現(xiàn)相比，未使用模式的實現(xiàn)在代碼變更率、類代碼平均變更率、類代碼最大變更率和方法代碼變更率方面都較大，這說明未使用模式的實現(xiàn)為了適應(yīng)變更，需要修改大量的源代碼，從而造成其適應(yīng)性較差，相比之下，使用了模式的實現(xiàn)則要理想得多。在類變更覆蓋范圍與方法變更覆蓋范圍這兩項度量指標上，使用了模式的實現(xiàn)也比未使用模式的實現(xiàn)略好。因此，由度量模型得到的數(shù)據(jù)與預(yù)期相符，從而反映了度量模型的合理性。

3 由軟件版本演化度量軟件適應(yīng)性

在第2章中，提出了度量軟件變更成本的度量模型，給出了各個度量指標的形式化定義，并用一個實例驗證了度量模型的合理性。但是對于一個實際的軟件，這種獲取它的兩種不同的代碼實現(xiàn)并根據(jù)問題集的變化變更軟件源代碼，從而通過測量變更成本度量軟件適應(yīng)性的方法卻不易實現(xiàn)。一方面是因為對于每一個待度量適應(yīng)性的軟件，很難獲得它的多個不同實現(xiàn)方案以供比較;另一方面，對于大型的軟件，針對問題集的每個變化而一一對源代碼作出調(diào)整(如Maze Game示例那樣)，以此考察其變更成本的方法工作量非常巨大以至于難以實現(xiàn)。 3.1 從軟件版本演化度量軟件適應(yīng)性

軟件的適應(yīng)性是由變更的難易程度來反映的，即變更成本，變更成本則由各種可能的變更對軟件的綜合作用來確定。如果認為一個軟件是基于當前的需求而建立的，那么它未來可能的變更可以認為是個不確定因素。一個軟件在演化的過程中，可能的變更是很多的，其中一些變更發(fā)生的概率很小。考慮所有可能會發(fā)生的變更情況是不切實際也是沒有必要的，而那些發(fā)生概率較大的變更對變更成本起著主要作用。在概率論的統(tǒng)計推斷理論中，對于參數(shù)估計問題，極大似然估計法認為一個事件在一次觀察中出現(xiàn)，應(yīng)該認為這個事件出現(xiàn)的可能性是很大的[9]。借鑒這個觀點，即已經(jīng)發(fā)生的事件具有比較大的概率發(fā)生。而軟件版本的演化中涉及的變更作為已經(jīng)發(fā)生的變更，可以認為是軟件最有可能發(fā)生的變更。因此，從軟件版本的演化中去研究軟件的適應(yīng)性，是個比較合理的方式。

綜上所述，由于軟件的版本演化過程中包含了軟件最有可能發(fā)生的變更，可以通過度量軟件版本的變更成本來衡量該軟件的適應(yīng)性。對于開源軟件，可以比較容易地得到其源代碼在版本間發(fā)生的改動，從而研究其變更成本。具體來講，將第2章中建立的變更成本的度量模型應(yīng)用于軟件版本的演化過程，對該演化過程中的每個度量成本指標進行測量。對于一個軟件，設(shè)它有版本1和2，在由版本1向2演化的過程中，分別測量其代碼變更率、類代碼行平均變更率、類代碼行最大變更率、方法代碼行平均變更率、方法代碼行最大變更率、類變更覆蓋范圍和方法變更覆蓋范圍，由式(8)來得到變更成本的度量:

變更成本=∑5i=0ai×Fi(8)

其中:Fi表示度量指標i，F(xiàn)1表示代碼變更率，F(xiàn)2表示類代碼行平均變更率，F(xiàn)3表示方法代碼行平均變更率，F(xiàn)4表示類變更覆蓋范圍，F(xiàn)5表示方法變更覆蓋范圍;ai是Fi的權(quán)值，它可以根據(jù)研究者的側(cè)重點不同而進行合適的選取，這里簡單地取a1=a2=a3=a4=a5=0.2，即變更成本是以上五個度量指標值的平均。類代碼行最大變更率和方法代碼行最大變更率可以作為變更成本的額外參考指標。如果變更成本很小，則說明該軟件的適應(yīng)性較好;反之，如果變更成本很大，則該軟件的適應(yīng)性較差。

3.2 實例驗證及分析:Ant的版本演化

以開源軟件Ant的版本演化來對本文度量模型，以及第2章提出的通過版本演化度量軟件適應(yīng)性的方法加以驗證。

Ant是Apache組織開發(fā)的一種基于Java的著名構(gòu)建工具[10]，具有優(yōu)秀的跨平臺性和操作上的簡易性，并被集成到了眾多的集成開發(fā)環(huán)境中。作為軟件的一個重要質(zhì)量屬性，一般期望隨著版本的演化和軟件的不斷改善，軟件的適應(yīng)性越來越好[11]。因此，期望Ant的適應(yīng)性在版本的演化過程中不斷增強。

收集了Ant軟件的從1.1到1.7.0的17個版本，并通過適應(yīng)性分析工具FlexTool，度量了軟件變更成本度量模型中的七個度量指標。本文挑選了軟件變更較大的八個版本演化進行比較，為了簡便，以下將其編號為版本演化1~8，它們按照演化發(fā)生的時間依次往后。引起Ant變更的主要因素有對以往特性的改變、增加功能和修改Bug等。一般而言，與其他變更相比，修改Bug對軟件的影響較小。另外，很難確定各個變更原因?qū)浖淖兏唧w產(chǎn)生多大的影響，因此，假設(shè)除修改Bug外的變更原因?qū)浖挠绊懚枷嗤瑢⒚總€版本的變化原因數(shù)定義為0.4×對以往特性的改變數(shù)+0.4×增加功能數(shù)+0.2×修改Bug數(shù)，得到了各個度量指標相對于變更原因的平均值，如表2所示。其中類最大代碼變更率和方法最大代碼變更率不需要進行平均處理。

對于每個版本演化，本文對表2中的數(shù)據(jù)進行了歸一化處理(類最大代碼變更率和方法最大代碼變更率除外)，即以表格中每一個單元格的數(shù)據(jù)除以相應(yīng)列的最大值作為其歸一化后的值;然后通過歸一化后的數(shù)據(jù)，根據(jù)式(8)得到變更成本。因為變更成本較大意味著適應(yīng)性較差，所以，以變更成本的倒數(shù)來表示適應(yīng)性，并將各個版本適應(yīng)性的變化趨勢繪制成折線圖，如圖7所示。

從圖7中可以看到，用本文度量模型得到的Ant的適應(yīng)性隨著其版本的演化總體上呈現(xiàn)出不斷變好的趨勢。當然也注意到，并非每次變更反映出的軟件適應(yīng)性都得到提高，如通過版本演化4測量的適應(yīng)性比通過版本演化3測量的適應(yīng)性略低，這是符合直觀認識的。因為軟件版本的每次演化并非只致力于提高其適應(yīng)性等質(zhì)量屬性，而是由于各種原因造成的，這些綜合因素影響的結(jié)果使得軟件適應(yīng)性并非隨著版本的演化單調(diào)地提高，但其總體趨勢卻是不斷變好的。實驗的結(jié)果與筆者的預(yù)期相符，即Ant的適應(yīng)性在版本的演化過程中不斷增強。

4 FlexTool介紹

支持工具FlexTool實現(xiàn)了對軟件變更成本模型中七個度量指標的自動計算。它以軟件變更前后兩個版本的源代碼作為輸入，經(jīng)過預(yù)處理、變更分析、源代碼比較和結(jié)果計算等五個主要分析步驟，最終得到代碼變更率、類代碼行平均變更率、類代碼行最大變更率、方法代碼行平均變更率、方法代碼行最大變更率、類變更覆蓋范圍、方法變更覆蓋范圍七個變更成本度量指標，大大方便了數(shù)據(jù)的收集過程。其中:預(yù)處理模塊刪除了源代碼中存在的注釋和空行;變更分析模塊分別構(gòu)造了軟件前后兩個版本的抽象語法樹，并據(jù)此對源代碼中類、方法的變更點和相同點進行分析和記錄;源代碼比較模塊根據(jù)變更分析模塊得到的中間結(jié)果，生成源代碼比較文件，并調(diào)用文件比較工具對源代碼進行比較;結(jié)果計算模塊綜合變更分析模塊和源代碼比較模塊得到的中間結(jié)果，計算出七個變更成本度量指標。本文中Maze Game實例和Ant實例的變更成本數(shù)據(jù)均通過FlexTool獲得。

5 結(jié)束語

已有的軟件適應(yīng)性度量方法由于過于依賴度量人員對于軟件源代碼的熟悉程度，從而變得不具有很好的實際操作性。根據(jù)軟件適應(yīng)性的定義并在借鑒了前人研究的基礎(chǔ)上，提出以軟件的變更成本來表征軟件的適應(yīng)性，由此提出了軟件變更成本的度量模型，并對其中的每個度量指標的計算方法進行了定義。通過Maze Game這個實例，驗證了度量模型的合理性。然后，提出應(yīng)用本文度量模型，以考察軟件版本的演化來對適應(yīng)性進行度量，并論述了度量方法。最后，通過對著名開源軟件Ant的版本演化進行數(shù)據(jù)分析，驗證了度量模型以及度量方法的合理性。另外，本文度量數(shù)據(jù)的提取均通過本文開發(fā)的FlexTool支持工具對源代碼的分析得到。

參考文獻:

[1]EDEN A H， MENS T. Measuring software flexibility[J]. Software IEE Proceedings， 2006， 153(3):113-125.

[2]IEEE 610.12-1990 standard glossary of software engineering termino-logy[S]. Los Alamitos: IEEE Press， 1999.

[3]BENGTSSON P， LASSING N， BOSCH J， et al. Architecture-level modifiability analysis (ALMA)[J]. The Journal of Systems and Software， 2004， 69(1-2):129-147.

[4]TSANTALIS N， CHATZIGEORGIOU A， STEPHANIDES G. Predicting the probability of change in object-oriented systems[J]. IEEE Trans on Software Engineering， 2005， 31(7):601-604.

[5]高暉，張莉.軟件體系結(jié)構(gòu)層次的適應(yīng)性度量技術(shù)研究[J].計算機科學(xué)， 2008， 35(4):51-57.

[6]CHAUMUN M A， KABAILI H， KELLER R K， et al. A change impact model for changeability assessment in object-oriented software systems[C]//Proc of the 3rd European Conference on Software Maintenance and Reengineering. Washington: IEEE Press， 1999:130-138.

[7]ECKEL B. Java 編程思想[M].陳昊鵬，譯.北京:機械工業(yè)出版社，2007:354-355.

[8]GAMMA E， HELM R， JOHNSON R， et al. Design patterns elements of reusable object-oriented software[M].[S.l.]:Addison Wesley， 1995:46-52.

[9]韓於羹.應(yīng)用數(shù)理統(tǒng)計[M].北京:北京航空航天大學(xué)出版社，2004:132-133.

[10]The Apache Software Foundation. Apache Ant introduction[EB/OL]. (2006-11-6) [2008-07-04]. http://ant.apache.org.

[11]BANSIYA J， DAVIS C G. A hierarchical model for object-oriented design quality assessment[J]. IEEE Trans on Software Enginee-ring， 2002， 28(1):4-17.