陳 艷,葉宏杰,陳 偉

1(中國電子科技集團公司第十五研究所,北京 100083)

2(中國科學院大學,北京 100049)

3(中國科學院 軟件研究所,北京 100190)

當前軟件系統(tǒng)更加趨于具有高可配置性(high configurability)的特點,目標在于提升系統(tǒng)的靈活性和可變性,使開發(fā)人員和系統(tǒng)管理人員能夠在不修改程序代碼的前提下通過改變配置來控制系統(tǒng)的行為以及改變系統(tǒng)的特性.軟件配置是指以用戶需求和軟件的功能、結(jié)構(gòu)及主要特性等為依據(jù),選擇和確定相關(guān)硬件、軟件和固件的型號、版本及數(shù)量,規(guī)劃軟件放置位置和關(guān)聯(lián)關(guān)系,設(shè)置軟件系統(tǒng)相關(guān)參數(shù)值等;狹義上的軟件配置主要指對軟件系統(tǒng)配置參數(shù)取值的設(shè)置[1].

隨著信息技術(shù)與互聯(lián)網(wǎng)技術(shù)的發(fā)展,軟件系統(tǒng)(尤其是網(wǎng)絡(luò)分布式系統(tǒng))的規(guī)模和復雜度不斷提升,其在功能和非功能方面特性的設(shè)置和定制化往往是通過對配置項的不同取值來實現(xiàn)的,由此也使得復雜系統(tǒng)的配置項數(shù)量越來越多、復雜程度越來越高.

但是,大量配置參數(shù)在提高系統(tǒng)靈活性的同時也為應(yīng)用的配置正確性帶來困難[1],為系統(tǒng)后續(xù)運行的可靠性、可用性、易用性以及系統(tǒng)性能等服務(wù)質(zhì)量帶來極大挑戰(zhàn),具體包括:

(1)大量配置項給用戶的使用和操作帶來困難和干擾.不恰當?shù)摹?shù)量過多的配置項設(shè)計,以及缺少系統(tǒng)的、詳細的配置參數(shù)使用說明,會使用戶難以理解配置項與系統(tǒng)特性之間的關(guān)聯(lián)性,因此也很難通過正確調(diào)節(jié)配置來使系統(tǒng)達到預(yù)期效果.Xu 等人實證研究發(fā)現(xiàn),大部分用戶只會修改系統(tǒng)6.1%～16.7%的配置項[2].Yin 等人也指出,有63.6%以上的配置錯誤是在用戶初次修改配置項時發(fā)生的[3].

(2)配置錯誤已經(jīng)成為導致軟件系統(tǒng)錯誤和運行故障的重要因素之一[4].配置錯誤是指由于配置項取值設(shè)置不當而導致的軟件系統(tǒng)錯誤和運行故障,包括參數(shù)錯誤、兼容性錯誤和組件錯誤等[3].軟件配置錯誤往往帶來災(zāi)難性后果.Barroso 等人發(fā)現(xiàn)配置錯誤是Google一個主要服務(wù)運行錯誤的主要原因之一[5].更嚴重地,在2009年,配置錯誤導致整個“.se”域癱瘓了一個多小時,影響了近百萬臺主機的正常工作.

(3)軟件配置與系統(tǒng)性能緊密相關(guān),設(shè)置不當將嚴重影響系統(tǒng)的服務(wù)質(zhì)量.軟件系統(tǒng)的資源需求往往以配置參數(shù)的形式進行設(shè)置,以提高系統(tǒng)的靈活性和可配置性,如緩沖區(qū)大小、最長響應(yīng)時間、最大連接數(shù)等.此類配置參數(shù)如果取值不恰當,將會嚴重影響系統(tǒng)的性能,例如將數(shù)據(jù)庫最大連接數(shù)設(shè)置過小會顯著降低系統(tǒng)的并發(fā)能力,而如何合理設(shè)置此類配置參數(shù),使得系統(tǒng)性能達到最優(yōu)也是一個十分困難的問題.

綜上,軟件配置已經(jīng)成為了一個備受關(guān)注的話題,并且已存在諸多的軟件配置相關(guān)研究工作.本文旨在對已有的研究工作進行梳理,系統(tǒng)化地分析相關(guān)工作,為今后的軟件配置研究提供線索依據(jù)和發(fā)展方向.

本文的組織安排如下:第1 節(jié)首先提出了一個面向軟件配置的分析框架,該框架從軟件生命周期和軟件配置技術(shù)手段兩個維度對軟件配置相關(guān)工作進行劃分和分析評價.第2 節(jié)簡要介紹了本文對軟件配置相關(guān)文獻的檢索和篩選方法與過程.第3 節(jié)分別從軟件生命周期中的設(shè)計階段、開發(fā)階段和后開發(fā)階段(即測試階段、部署階段和生產(chǎn)階段)中所面對的軟件配置問題以及當前代表性的相關(guān)工作進行介紹和分析,以及其他對典型軟件系統(tǒng)進行分析的研究工作.第4 節(jié)對軟件系統(tǒng)配置研究現(xiàn)狀進行總結(jié),分析各類型研究工作的特點,并對軟件配置的未來研究方向作出展望.第5 節(jié)總結(jié)全文.

1 軟件配置分析框架

軟件配置活動存在于軟件生命周期的各個階段,本文從軟件開發(fā)的生命周期,即設(shè)計階段、開發(fā)階段、測試階段、部署階段和生產(chǎn)階段著手,對現(xiàn)有改善軟件配置設(shè)計、減輕不良配置影響以及應(yīng)對配置錯誤的相關(guān)工作進行分析和綜述.除此之外,軟件配置分析的技術(shù)手段包括程序分析和統(tǒng)計分析等,本文也根據(jù)采用的技術(shù)手段對現(xiàn)有軟件配置分析方法進行分類.

本文首先建立基于軟件生命周期的分類方法.軟件配置是軟件系統(tǒng)中的重要組成部分,軟件配置的設(shè)計、開發(fā)、測試和維護包含于軟件系統(tǒng)的設(shè)計、開發(fā)、測試和維護過程中.因此,從軟件生命周期著手,在各個階段中尋求軟件配置面臨的問題以及相應(yīng)的解決方法,可以有效提升軟件配置質(zhì)量.軟件生命周期可以劃分為設(shè)計階段、開發(fā)階段和后開發(fā)階段,其中后開發(fā)階段即測試階段、部署階段和生產(chǎn)階段.在上述各個階段中,軟件配置面臨的主要問題如下:

(1)設(shè)計階段中的軟件配置問題主要是如何進行配置項的選擇和設(shè)計,即如何在提高軟件的配置性以及減少配置參數(shù)數(shù)量上進行權(quán)衡,從而通過清晰、有限的配置參數(shù)來實現(xiàn)軟件的高可配置.配置項的選定即明確系統(tǒng)的可配置點,指出哪些功能需要以可配置的形式展現(xiàn)給軟件系統(tǒng)的使用者.配置項的設(shè)計即確定配置項在系統(tǒng)中的表示形式,包括配置項的名稱、類型、存儲形式甚至使用的語言等[6].

(2)開發(fā)階段中的軟件配置問題主要是如何進行配置項的實現(xiàn)和管理.配置項實現(xiàn)需要關(guān)注配置項的約束和用戶配置手冊的編寫.配置項的管理即維護已經(jīng)實現(xiàn)的配置項,并有效應(yīng)對其變更.

(3)后開發(fā)階段中的軟件配置問題主要是配置錯誤處理和配置性能分析.配置錯誤處理即應(yīng)對軟件配置帶來的系統(tǒng)錯誤,包括配置錯誤的檢測、診斷和修復等.配置性能分析即分析軟件配置與系統(tǒng)性能間的關(guān)系,包括配置性能間關(guān)系分析以及性能優(yōu)化等.

其次,本文以軟件配置研究工作中所采取的主要技術(shù)手段為依據(jù),對現(xiàn)有的研究工作進行分類分析,主要包括白盒方法(white-box)和黑盒方法(black-box)兩種,以及兩種方法的綜合使用:

(1)白盒方法的適用前提是軟件系統(tǒng)的源代碼(或字節(jié)碼)可獲取,從而能夠?qū)⒛繕讼到y(tǒng)作為白盒處理.采用靜態(tài)程序分析或動態(tài)程序分析技術(shù),分析代碼中配置項的讀入點、控制流和數(shù)據(jù)流等,找到軟件配置與軟件系統(tǒng)本身的關(guān)系,進而解決具體問題.

(2)黑盒方法適用于無法獲得軟件系統(tǒng)源碼的應(yīng)用場景,該方法主要基于統(tǒng)計方法、對比方法、機器學習等技術(shù),通過運行一定數(shù)量的測試用例,觀察目標系統(tǒng)在不同條件下的執(zhí)行結(jié)果,總結(jié)和發(fā)現(xiàn)軟件配置與軟件系統(tǒng)的內(nèi)在關(guān)系,進而解決具體問題.

基于上述觀點和視角,本文以軟件生命周期作為文獻分類的主方法,簡述各項軟件配置相關(guān)的研究工作;當工作涉及到軟件配置與軟件系統(tǒng)關(guān)系時,本文將指出其基于的主要技術(shù)手段.

2 文獻檢索與篩選

為了保證綜述的全面性和時效性,本文采用的檢索策略如下:

(1)將研究工作的檢索范圍設(shè)定在近7年,即2014年～2020年.

(2)以軟件配置(software configuration)為第一關(guān)鍵詞,軟件配置相關(guān)的活動,如:設(shè)計(design)、管理(management)、性能(performance),為第二關(guān)鍵詞,組合成若干關(guān)鍵詞詞組.

(3)使用(2)中的詞組,分別使用谷歌學術(shù)和中國知網(wǎng)搜索引擎進行搜索,并按照相關(guān)性排序、選取相關(guān)性最高的前20 條結(jié)果.再以人工的方式進行去重、篩去不符合需求的文章.

(4)使用(2)中的詞組,在多個文獻數(shù)據(jù)庫中,以與軟件配置相關(guān)的期刊和會議為范圍進行檢索,再以人工的方式進行去重,篩去不符合需求的文章.

(5)分析(2)、(3)步獲得文章的參考文獻,選取在時間范圍內(nèi)且與主題密切相關(guān)的文章,并重復該步驟.

(6)綜合以上(3)～(5)步結(jié)果,構(gòu)成本文檢索范圍.

最終,本文選取了32 篇文章作為本綜述的范圍.文章的發(fā)表時間分布如圖1所示.從圖中可以看出,文章的發(fā)表時間分布較為均勻,表明軟件配置問題是軟件工程領(lǐng)域一個持續(xù)得到關(guān)注和研究的主題.文章的類型分布如圖2所示.大量研究工作集中在配置錯誤的處理上,關(guān)注配置項選定和設(shè)計的工作較少.本文認為,這是因為與此相關(guān)的工作被包含于軟件系統(tǒng)設(shè)計的工作當中,而軟件系統(tǒng)設(shè)計相關(guān)的研究已經(jīng)較為成熟.

圖1 文章發(fā)表時間分布

圖2 文章類別分布

3 軟件配置研究概述

3.1 軟件設(shè)計階段的相關(guān)工作

軟件配置項的選擇和設(shè)計是軟件設(shè)計階段需要解決的問題.需要把需求中的部分可變點抽象出來作為配置項,以提高系統(tǒng)靈活性.配置項的選定應(yīng)該準確且適量,這是因為:(1)不準確的配置項難以表達系統(tǒng)的可變點,增加用戶的理解難度和系統(tǒng)的維護成本;(2)過少的配置項不能滿足系統(tǒng)靈活性的需求,降低用戶滿意度并可能在特定場景下給開發(fā)人員帶來困難;(3)過多的配置項不利于維護,也可能使用戶很難確定需要改動的配置.在完成基于可變點的配置項選定后,需要對配置項進行設(shè)計,完善其語法和語義信息,使其易于理解和使用.配置項的設(shè)計包括配置項的名稱、類型、存儲形式、與變動點的映射關(guān)系等.

在可變點分析與配置項選擇方面,Mu?ante 等人參考基于眾包的需求獲取方法,提出基于眾包的配置項選擇方法[7].方法將眾包分為領(lǐng)域?qū)＜液蜐撛谟脩魞深?其中領(lǐng)域?qū)＜邑撠煷_定系統(tǒng)的可變點,并根據(jù)可變點初步選定配置項,之后專家對潛在用戶的用戶畫像進行分析,并綜合用戶畫像和系統(tǒng)配置問題設(shè)計問卷.潛在用戶負責填寫問卷,展現(xiàn)自己的用戶畫像并表達對系統(tǒng)的反饋.最后,專家和開發(fā)人員對問卷進行統(tǒng)計和分析,確定配置項.該方法的優(yōu)勢在于:(1)使用戶盡早接觸到系統(tǒng)配置,提高配置的可用性和易用性;(2)不僅在配置項的選定過程中有所幫助,在系統(tǒng)版本更迭、配置項變更時,也可以采用類似的方法進行系統(tǒng)配置的更新.其不足之處在于:(1)難以對方法的代價和收益進行定量評估,導致方法代價過大;(2)潛在用戶選擇困難:一方面,在項目開發(fā)初期,難以明確哪些群體是潛在用戶;另一方面,調(diào)研的潛在用戶數(shù)量不好確定,太少可能導致調(diào)研結(jié)果出現(xiàn)偏差,太多則會帶來額外時間和金錢的開銷.

在配置項設(shè)計原則方面,Xu 等人通過調(diào)研指出現(xiàn)有的系統(tǒng)配置項存在以下問題[2]:(1)大部分用戶只會修改小部分的配置項;(2)相比數(shù)值型配置項,枚舉型配置項更容易被用戶所使用.同時,配置項的值域越小,越不容易出現(xiàn)配置錯誤.由此,作者給出了2個配置項設(shè)計原則:(1)減少或者隱藏不必要和使用頻率低的配置項,對使用頻率不高但確實需要的配置項,可以通過“高級配置”的方式與普通配置項分隔開;(2)縮小無意義的配置項值域,多使用枚舉型的配置項,而枚舉數(shù)量以2～3個為佳.這些原則能夠降低配置項設(shè)計的冗余、提高配置項的質(zhì)量,使用戶更易于配置系統(tǒng).但是這些設(shè)計原則覆蓋面有限,不夠全面和完備,沒有考慮到配置項的命名等問題.例如,有研究顯示,配置項語義含糊是導致配置錯誤的重要原因之一[8].

3.2 軟件開發(fā)階段的相關(guān)工作

開發(fā)階段中的軟件配置相關(guān)工作主要包括配置項實現(xiàn)和配置項管理.

3.2.1 配置項實現(xiàn)

配置項實現(xiàn)以設(shè)計為依據(jù),主要任務(wù)包括:完善配置項的約束,將配置項寫入配置文件或配置庫,編碼實現(xiàn)配置項訪問接口,以及形成配置說明文檔.當前已有工作主要關(guān)注于配置項約束的完善和配置文檔的編寫兩方面.

在配置項的約束方面,Li 等人研究了MySQL、Redis、ApacheHttpd 等常見大型開源系統(tǒng)的軟件配置項,對配置項按照類型進行了分類,并指出了每類配置項的約束[9].作者首先將配置項劃分為字符串型和數(shù)值型兩大類,再將每個大類劃分若干小類,繼續(xù)細分直到語義明確為止.對于每類配置項,作者根據(jù)其類型和運行時需求定義了語法約束和語義約束.如端口號應(yīng)是0–65535中的一個整數(shù)(語法約束)且不能使用已經(jīng)被占用的端口號(語義約束).該文章使用樹狀結(jié)構(gòu)對配置項進行分類,對研究對象系統(tǒng)配置項的覆蓋率達到95%以上,并且具有很好的可擴展性.但基于類型的配置項約束完善方法主要考慮的是單個配置項的約束.現(xiàn)實中的配置項約束不局限于單個配置項內(nèi),還存在于多個配置項之間.對于配置項之間的約束,需要通過其他方法進行完善.

在配置項文檔方面,Zhang 等人實現(xiàn)了配置文件自動注釋工具ConfigFile++[10].作者認為,當前許多系統(tǒng)存配置文件注釋不充分、不規(guī)范的問題,導致了許多的用戶配置錯誤.ConfigFile++從配置項的類型、約束、作用等方面對配置項進行概括,生成統(tǒng)一格式的配置項注釋,插入配置文件中.ConfigFile++沿用Xu 等人的工作[2]和Li 等人的工作[9],分析配置項的類型和約束;對于配置項的作用,ConfigFile++對用戶手冊進行搜索,找到與配置項最相關(guān)的段落,使用TextRank模型[11]提取關(guān)鍵詞,概括配置項作用.最后,ConfigFile++生成統(tǒng)一格式的配置項注釋,插入配置文件中.該方法相當于生成了一份精簡版的用戶手冊,用戶在修改ConfigFile++注釋后的配置文件時,能夠?qū)ε渲庙椨腥娴牧私?減少配置錯誤的發(fā)生.但是,ConfigFile++生成的配置項注釋段落長、信息量大,用戶很難快速找到關(guān)鍵信息,也會成倍地增加配置文件的大小.同時,ConfigFile++生成優(yōu)質(zhì)配置注釋依賴于成熟的用戶手冊.極端情況下,如果系統(tǒng)用戶手冊沒有對配置進行說明,ConfigFile++只能對配置項本身進行分析,能夠提取的信息比較有限.

此外,Nadi 對配置項約束進行了分類[12].作者認為約束按照作用劃分,主要包括以下4 類:(1)底層配置項依賴關(guān)系,配置項間的取值關(guān)聯(lián)隱含在程序代碼中,配置項設(shè)置時必須滿足此類依賴;(2)根據(jù)運行環(huán)境配置系統(tǒng),保證系統(tǒng)在不同環(huán)境下的正確運行;(3)指導用戶進行配置,減少無效配置、提高用戶配置體驗;(4)避免極端情況,防止系統(tǒng)在配置項取某些值時不能正確運行.王燾等人關(guān)注配置項間的關(guān)聯(lián),定義了一致性關(guān)聯(lián)和類型性關(guān)聯(lián)[13].一致性關(guān)聯(lián)指兩個配置項具有相同的值,或一個值是另一個值的子串;類型性關(guān)聯(lián)指兩個配置項之間存在類型上的語義關(guān)聯(lián),若一個配置項的值發(fā)生變化,另一個配置項取值需相應(yīng)進行改變.這兩類關(guān)聯(lián)是配置項之間的約束,要求修改存在關(guān)聯(lián)的配置項時,考慮其他配置項的變化.

文獻[10,12,13]的工作都對配置項約束進行研究,但分類方法和覆蓋面有所不同,總結(jié)如表1所示.

表1 配置項約束研究工作對比總結(jié)

3.2.2 配置項管理

軟件開發(fā)過程中,由于需求的變化或者新功能的增加,配置項可能發(fā)生變化.面對變化,如果缺乏配置項的管理手段,可能會出現(xiàn)配置項更新困難、配置不一致和配置項丟失等問題.因此,配置項的管理是軟件開發(fā)過程中配置項有效性、一致性的重要保證.

Tang 等人介紹了Facebook 配置管理套件[14].套件由Configerator、Gatekeeper、PackageVessel、Sitevars以及MobileConfig 組成.Configerator 提供最底層功能,提出配置即代碼(configuration as code)的思想.配置通過平臺無關(guān)語言Thrift 編寫,輸出JSON 格式的配置文件.Sitevars 提供編寫和修改配置的圖形化接口.Package-Vessel 解決大型配置文件頻繁更新的問題,將配置文件和其元數(shù)據(jù)分開更新.元數(shù)據(jù)上傳時立即更新;對于配置文件本身,PackageVessel 從元數(shù)據(jù)中找到文件位置,使用混合訂閱P2P 模型傳輸.Gatekeeper 負責新特性發(fā)布,控制特性的部分開放、對部分用戶開放或禁用等,控制產(chǎn)品逐步推出.MobileConfig 負責解決移動端APP的配置問題,包括平臺多樣性、移動網(wǎng)絡(luò)速度和新舊版本兼容性等問題.Facebook的配置管理工具套件的優(yōu)點在于:(1)提出“配置即代碼”的概念,可以通過類似管理代碼的方法管理配置項,提高配置的可維護性;(2)從多角度考慮配置管理過程中可能遇到的困難,并設(shè)計了相應(yīng)的解決方案.該套件對于大型項目的配置管理具有很高的參考價值.但另一方面,該套件并不適用于中小型規(guī)模的軟件系統(tǒng),此類軟件系統(tǒng)的配置相對簡單,使用上述工具反而可能帶來不必要的開銷和效率的降低.

配置的管理可以依賴第三方工具完成,許多研究人員著手于開發(fā)配置項收集分析工具,輔助進行配置項管理.Tuncer 等人開發(fā)的云平臺上的配置項自動發(fā)現(xiàn)和提取工具ConfEx[15]是該類工作的代表之一.對待檢測系統(tǒng),ConfEx 首先根據(jù)詞匯表和文件名劃分出各個配置文件所屬的軟件;其次ConfEx 對配置文件進行文本分析,以鍵值對的形式提取出文件中的配置項及其取值;然后消除歧義,保證每個鍵只對應(yīng)唯一的值;最后將解析得到的配置文件和配置項列表展現(xiàn)給用戶.對于httpd、MySQL和Ngnix 等大型應(yīng)用,該工具可以找到99.7%的配置文件及包含的配置項,而之前的方法Augeas[16]只能找到35.8%.但ConfEx的核心工作在于配置文件的發(fā)現(xiàn)上,對于配置項的提取,ConfEx僅是沿用了Augeas的方法.ConfEx 僅提供了配置項提取方法,并不涉及配置項的語義和約束等信息.

此外,Bartusevics 等人設(shè)計了一套模型驅(qū)動的軟件配置管理方式[17].該方式定義了配置管理過程中的3 種模型:環(huán)境模型、行為模型和分支模型,以及2 條規(guī)則:環(huán)境轉(zhuǎn)換規(guī)則和分支合并規(guī)則.應(yīng)用該方法,在配置變化時,首先明確變化在模型變更中的體現(xiàn),然后基于規(guī)則進行模型的轉(zhuǎn)化,完成配置項的管理.Perera提出了一種自動化配置管理方法[18].該方法通過程序分析,自動發(fā)現(xiàn)系統(tǒng)中的配置項及其約束,存入數(shù)據(jù)庫中進行統(tǒng)一管理.相比參照程序規(guī)格說明書進行管理,該方法更具有可靠性、且能夠發(fā)現(xiàn)說明書與實際程序不符之處.Jin 等人開發(fā)了配置項查找工具PreFinder[19].PreFinder 工作流程分為4 步:(1)通過程序分析和API調(diào)用提取配置項;(2)根據(jù)分隔符和貪心算法對配置項名稱分詞;(3)對自然語言查詢輸入進行縮略語轉(zhuǎn)化、停止詞消除等預(yù)處理;(4)使用TF-IDF 算法計算查詢與各個配置項的關(guān)聯(lián)性,推薦配置項.PreFinder是最早將自然語言處理技術(shù)應(yīng)用于配置領(lǐng)域的工作之一.曾廣福等人提出了枚舉類型配置項配置空間的提取方法[20].該方法使用程序分析技術(shù),找到枚舉類型配置項集中定義的代碼段,提取配置項的枚舉值,確定配置空間.作者使用Redis、MySQL 等6 款常用C/C++開源軟件進行測試,結(jié)果顯示該方法的提取準確率高于80%.復雜軟件系統(tǒng)通常使用配置框架,如Java Properties、Spring 等,統(tǒng)一管理配置.Sayagh 等人研究了配置框架對系統(tǒng)開發(fā)的影響[21].通過對2000 余個Java 項目和11 種Java 配置框架的分析,作者指出基礎(chǔ)、成熟、文檔完備的框架經(jīng)常在開發(fā)中被使用且穩(wěn)定性較好.

本文認為已有工作主要從以下兩方面提高軟件開發(fā)過程中配置項管理的能力:(1)配置演化變更管理,建立和完善配置項變更應(yīng)對機制,以成熟的理論和工具變更配置項(包括參考文獻[14,17]);(2)配置理解發(fā)現(xiàn),發(fā)現(xiàn)和理解系統(tǒng)配置項,對配置項進行集中管理(包括參考文獻[15,18–20]).兩類工作相輔相成.在實際配置管理過程中,可以首先通過(2)中工作的方法整理配置項,建立配置管理中心,然后通過(1)中工作的方法變更配置.

3.3 軟件后開發(fā)階段的相關(guān)工作

軟件后開發(fā)階段主要包括測試、部署和生產(chǎn).在這3個階段中,軟件配置所面臨的主要問題既有相似性,側(cè)重點又有所不同.3個階段都以配置錯誤處理和優(yōu)化為主.測試階段側(cè)重于配置錯誤的處理;部署階段側(cè)重于配置項調(diào)優(yōu);運維階段則同時關(guān)注配置錯誤處理和性能優(yōu)化兩方面.

3.3.1 配置錯誤處理

軟件配置錯誤常見且負面影響極大,因此,盡早地發(fā)現(xiàn)軟件配置錯誤并進行修復極為重要.軟件配置錯誤處理主要分為檢測、診斷和修復3個階段[1].錯誤檢測主要判斷系統(tǒng)是否存在配置錯誤,或者當前系統(tǒng)錯誤是否是軟件配置導致的;錯誤診斷主要分析配置錯誤具體是由哪一個或者哪一組配置項導致的,以及為什么會導致配置錯誤;錯誤修復為錯誤的配置項重新設(shè)置正確的值,使系統(tǒng)可以正確運行.此外,還有一些工作研究配置項在程序中的表現(xiàn)形式(如程序中的配置項讀入點、配置項在程序中的類型等),輔助進行配置錯誤的處理.

Xu 等為盡早發(fā)現(xiàn)配置錯誤,將軟件測試的思想引入軟件配置中,提出了軟件配置測試方法[22].配置測試分為3 步:(1)將硬編碼在源代碼中的配置項參數(shù)化;(2)給配置項賦予實際運行環(huán)境中使用的值;(3)運行測試用例.作者還提出了以下幾點看法:(1)配置測試應(yīng)該保證測試的充分性和路徑覆蓋率;(2)可以沿用軟件測試中的測試用例,因為這些測試用例已經(jīng)包含了大多數(shù)配置項的執(zhí)行路徑;(3)當軟件測試的測試用例不足以覆蓋執(zhí)行路徑時,需要配置測試專用的測試用例;(4)當配置出現(xiàn)變更時,需要對變更的配置項本身和依賴該配置項的所有配置項進行配置測試.該方法指出可以像測試代碼一樣充分測試配置,避免配置錯誤的發(fā)生.但是,大型軟件系統(tǒng)配置項數(shù)量多、結(jié)構(gòu)復雜,如何設(shè)計測試用例,通過少量用例覆蓋大部分配置,作者在文中并沒有進一步討論.

Wang 等人對比異常日志與正常日志的差異,開發(fā)了基于日志的配置錯誤診斷工具MisconfigDoctor[23].MisconfigDoctor 分為學習和診斷兩個階段.在學習階段,MisconfigDoctor 首先違背配置項約束,產(chǎn)生若干錯誤的配置,再分別在正確和錯誤的配置上運行測試用例,得到日志輸出,并對日志文件進行移除時間戳、統(tǒng)一單詞形式等預(yù)處理.MisconfigDoctor 比較正常日志和異常日志,記錄每個配置錯誤對應(yīng)的“+語句”(正常日志不出現(xiàn)而異常日志出現(xiàn)的句子)、“–語句”(正常日志出現(xiàn)而異常日志不出現(xiàn)的句子),以此作為配置錯誤的特征存入庫.在診斷階段,對于新的異常日志,MisconfigDoctor對異常日志進行預(yù)處理,與特征庫中的各個配置錯誤進行比對,得到最有可能的數(shù)個配置錯誤.實驗顯示,該方法檢測出了31個真實存在的配置錯誤.該方法充分利用了程序日志,以白盒的方法進行配置錯誤的診斷.但是,該方法也存在一些不足:(1)依賴于軟件系統(tǒng)的日志信息.如果系統(tǒng)日志區(qū)分度不足,MisconfigDoctor很難進行正確的診斷;(2)該方法只能診斷出學習階段中預(yù)定義的配置錯誤,難以發(fā)現(xiàn)新類型的配置錯誤.

Zhang 等人研究軟件更新過程中產(chǎn)生的配置錯誤,開發(fā)了工具ConfSuggester,推斷導致配置錯誤的配置項[24].ConfSuggester 運行過程分為3個階段:運行程序、比較結(jié)果和推斷配置項.運行程序階段,ConfSuggester 使用相同配置文件和輸入運行更新前后兩個版本的程序,檢測每個程序斷言執(zhí)行的次數(shù)和判斷為真的頻率.比較結(jié)果階段,ConfSuggester 首先將新舊兩個版本對應(yīng)的程序斷言進行匹配,然后計算每個斷言的執(zhí)行次數(shù)和判斷為真頻率的調(diào)和平均數(shù),當平均數(shù)偏差大于閾值時,該斷言存在問題.推斷配置項階段,ConfSuggester 進行程序切片,找到引起問題斷言表現(xiàn)不同的配置項并計算權(quán)重,輸出結(jié)果.ConfSuggester可以在1.8的平均推薦順位上找到配置錯誤,而之前的工具[25]需要在15.3的平均推薦順位才能找到.Conf-Suggester 在發(fā)現(xiàn)更新引起的配置錯誤上表現(xiàn)較好,但擴展性有限.對于長期存在的配置錯誤和無法提供歷史版本的系統(tǒng),ConfSuggester 作用有限.另一方面,當程序規(guī)模較大時,簡單的輸入很難覆蓋到所有程序斷言,需要高質(zhì)量或者多數(shù)量的輸入為ConfSuggester 提供支持.

配置項取值不同會影響程序的控制流.發(fā)現(xiàn)異常控制流是解決配置錯誤的重要方法之一.Nguyen 等人開發(fā)了程序交互發(fā)現(xiàn)工具iGen[26].程序交互,指配置項值與程序代碼覆蓋間的關(guān)聯(lián),即配置項值對程序控制流的影響.iGen 生成多份被測程序的配置文件并運行程序,劃分出每份配置文件覆蓋和未覆蓋的代碼.當覆蓋條件由多個配置項取值的合取組成時,若多份配置文件覆蓋到同一段代碼,iGen 對這些配置文件的配置項進行交運算并繼續(xù)生成多組配置文件,重新運行和計算直到結(jié)果不再變化.結(jié)果集合表示對應(yīng)代碼被覆蓋到時各個配置項的取值范圍.類似地,當覆蓋條件由多個配置項取值的析取組成,或由多個配置項的析取和合取共同構(gòu)成時,iGen 也設(shè)計了相應(yīng)檢測算法.在29個程序片段上的實驗顯示,iGen 計算出各個程序交互的平均F1-score 達到了99.7%.該方法的局限性在于:(1)檢測的配置項類型以離散的數(shù)值型為主,當配置項是字符串型時,該方法不適用.當配置項是連續(xù)的數(shù)值型時,該方法很難得到準確的結(jié)果;(2)當配置項數(shù)量多、值域大時,檢測的準確性會有所降低.

除了上述工作之外,Sayagh 等人將研究重點放在跨軟件棧的配置錯誤上,指出跨棧配置錯誤由于配置項數(shù)量多、層間配置項關(guān)系復雜等因素,處理較為困難.在此之上,作者提出了基于程序分析的模塊化方法,診斷出可能出錯的配置項[27].該方法已經(jīng)應(yīng)用到實踐中,發(fā)現(xiàn)并修復了1082個配置錯誤.Santolucito 等人使用機器學習的關(guān)聯(lián)規(guī)則挖掘算法研究配置項是否有誤[28].作者從配置文件中提取配置項并進行訓練,使用基于關(guān)聯(lián)規(guī)則的學習算法得到一系列配置項的規(guī)則,以此判斷一個配置項是否存在問題.經(jīng)過實驗,該方法可以檢測出多種類型的配置項錯誤,并保持著11%～18%的低誤報率.Xu 等人開發(fā)了工具PCHECK 用于檢測延遲性配置錯誤[29].延遲性配置錯誤是指在系統(tǒng)啟動時不會觸發(fā),但隨著系統(tǒng)運行、執(zhí)行到特定語句時觸發(fā)的配置錯誤.這類配置錯誤通常難以發(fā)現(xiàn).PCHECK通過程序分析的手段,生成能夠檢測配置項是否存在錯誤的代碼并插入程序中.實驗表明該方法可以有效檢測出延遲性配置錯誤,并對其他類型的配置錯誤也具有一定的檢測能力.Potharaju 等人開發(fā)了工具Conf-Seer,用于檢測配置錯誤,并給出修復方案[30].ConfSeer結(jié)合了自然語言處理、信息檢索和交互式學習等多種技術(shù),建立解決配置錯誤的知識庫,檢測和修復配置錯誤.該工具的準確率達到了80%～97.5%,并且有運行開銷低的優(yōu)點.Xu 等人開發(fā)了自動推測配置項類型的工具ConfTypeInfer[31].ConfTypeInfer 使用基于配置項名稱的方法和抽象語法樹分析方法推測配置項的類型.基于配置項名稱的方法通過配置項詞典分析配置項名稱的語義信息,確定其類型;抽象語法樹分析方法通過分析程序的抽象語法樹,確定配置項是否為枚舉類型,是基于配置項名稱方法的補足.兩種方法綜合使用,ConfTypeInfer的準確率達到了90%以上.Dong 等人開發(fā)了識別程序中配置項讀入點的工具ORPLocator[32].ORPLocator 工作流程如下:(1)以程序代碼和配置父類作為輸入;(2)根據(jù)配置父類識別出配置子類;(3)提取子類中從配置文件中讀取配置項值的方法;(4)找到調(diào)用這些方法的代碼,得到配置項對應(yīng)變量.實驗表明,該方法可以在大型程序中找到95%的配置項讀入點.

本文對上述工作關(guān)注點和配置分析采用的技術(shù)手段的總結(jié)如表2所示.

表2 配置錯誤處理研究工作總結(jié)和對比

由表2可看出:

(1)配置錯誤處理方面的工作采用的技術(shù)手段以白盒分析方法為主(7 項工作使用了白盒分析方法,4 項工作使用了黑盒分析方法).本文認為,其原因在于:1)配置錯誤的處理通常由軟件開發(fā)方進行,其有能力獲取軟件代碼,可以實行白盒分析;2)白盒分析方法可以覆蓋到更多的配置錯誤,相比黑盒方法更容易找到和處理不常出現(xiàn)的錯誤,且具有更高的準確率.

(2)配置錯誤修復方面的研究工作較少(僅文獻[26,30]的工作可以輔助進行配置錯誤修復).本文認為,其原因在于:許多配置錯誤的修復需要運用領(lǐng)域知識進行人工修復,自動化程度較低,難以形成系統(tǒng)化的工作.

3.3.2 配置參數(shù)調(diào)優(yōu)

軟件配置與系統(tǒng)性能密切相關(guān).通過調(diào)整配置以改善系統(tǒng)性能,首先要建立模型,表示配置項與系統(tǒng)性能的關(guān)系;然后根據(jù)實際需求和約束,為配置項設(shè)定恰當?shù)闹?通過配置參數(shù)調(diào)優(yōu)達到優(yōu)化系統(tǒng)性能的最終目標.

Sarka 等人研究了建立配置項與系統(tǒng)性能關(guān)系模型時對配置項進行抽樣的方法[33].方法在模型準確率與樣本采樣代價之間進行權(quán)衡,提出了基于頻率的投影抽樣來實現(xiàn)模型準確率和獲取樣本代價間的平衡.投影抽樣是在選定初始樣本后,每次迭代中新增一定數(shù)量的樣本產(chǎn)生(樣本容量,準確率)點對,并使用常見的曲線進行擬合,找到一條能夠較好表達當前模型樣本容量和準確率曲線的方法.方法基于頻率選取初始樣本,使初始樣本中每個配置項都至少需要被啟用和禁用若干次,這樣生成的樣本才具有代表性,能夠快速找到擬合度高的曲線.實驗顯示,投影抽樣方法優(yōu)于漸進抽樣,而基于頻率的初始樣本選取方法也在大多數(shù)情況下比傳統(tǒng)的隨機選取和多路選取方法好.

Wang 等人開發(fā)了用于系統(tǒng)性能調(diào)優(yōu)的配置框架SmartConf[34].該框架根據(jù)用戶期望的系統(tǒng)性能,由系統(tǒng)自動調(diào)整系統(tǒng)配置以滿足需求.使用SmartConf 框架時,開發(fā)者說明哪些配置項與什么性能相關(guān),并設(shè)定配置項的初始值;用戶說明期望的系統(tǒng)性能,系統(tǒng)通過SmartConf 控制器,自動調(diào)整配置項的值.SmartConf 控制器通過控制理論實現(xiàn),系統(tǒng)下一時刻的性能由當前時刻配置項的值所決定,而當前時刻配置項的值又由上一時刻配置項的值、以及當前時刻系統(tǒng)性能與用戶期望的誤差所共同決定.實驗結(jié)果顯示,相比靜態(tài)取值,SmartConf 動態(tài)修改配置項的值可以提高系統(tǒng)1.2～1.5倍的性能.SmartConf的不足在于需要開發(fā)人員指出配置項和性能指標之間的關(guān)聯(lián),需要豐富的領(lǐng)域知識和前提條件.如果能夠?qū)崿F(xiàn)配置項-性能指標關(guān)聯(lián)自動發(fā)現(xiàn)功能,SmartConf的動態(tài)調(diào)整效果可以進一步提升.另一方面,由于SmartConf 在系統(tǒng)運行時動態(tài)修改配置項,因此不適用于運行時可以動態(tài)更新配置并使之生效的系統(tǒng)和場景.

除了上述工作之外,Zhang 等人提出基于傅里葉變換的系統(tǒng)性能配置模型以及模型學習方法[35].將該方法在多個系統(tǒng)上的準確率達到92.5%以上,而模型的構(gòu)建僅使用2.2%的樣本.系統(tǒng)性能不佳經(jīng)常是由于系統(tǒng)資源不足、程序競爭資源產(chǎn)生的,為此Feng 等人開發(fā)了檢測系統(tǒng)資源競爭并通過調(diào)整配置項解決競爭的工具Relax[36].Relax 通過靜態(tài)程序分析的方法找到和資源相關(guān)的軟件配置項,調(diào)整競爭軟件對資源的占有率以解決沖突.引入Relax 后,程序的運行時間能夠縮短15%以上.關(guān)于選取模型的學習樣本,Nair 等人認為建立精確的配置性能模型是代價巨大且不必要的,無需精確的性能值即可對配置方案進行排名[37].作者提出了基于排名的方法,顯著地降低了建立模型的成本,并在多個系統(tǒng)中取得了明顯的成果.Kaltenecker 等人提出了基于距離的采樣方法[38].該采樣策略基于距離度量和概率分布,以給定的概率分布在配置項空間中采集配置項樣本.經(jīng)過實驗,該方法在配置項空間較大時仍然可以建立更準確的性能模型.Han 等人使用神經(jīng)網(wǎng)絡(luò)估計系統(tǒng)性能,分析輸入程序、服務(wù)器配置配置、云服務(wù)器間干擾程度與程序執(zhí)行時間之間的關(guān)系[39].在用戶選擇購買時,使用該模型評估當前服務(wù)器配置的性能,購買到恰當配置的服務(wù)器資源.

本文對上述工作關(guān)注點和配置分析采用的技術(shù)手段的總結(jié)如表3所示.

表3 配置參數(shù)調(diào)優(yōu)工作總結(jié)和對比

由表3可看出:在配置參數(shù)調(diào)優(yōu)領(lǐng)域,許多工作的焦點集中在快速建立高質(zhì)量的配置數(shù)據(jù)集上.本文認為,這是因為:1)軟件系統(tǒng)配置項多、配置空間巨大,采集典型的配置樣本集合比較困難.2)對每一個配置樣本,系統(tǒng)都需要以該配置運行系統(tǒng)才能采集評估指標,獲取評估指標代價較大.3)數(shù)據(jù)集建立后,構(gòu)建配置性能模型的方法有一定的數(shù)學理論作為支撐,相對容易.

3.4 其他工作

除了上述工作之外,還有一些工作的重點在于對已有系統(tǒng)配置的分析和實證研究方面.

Jha 等人以908個Android 應(yīng)用程序的配置文件(即manifest.xml 文件)為研究對象,對這些文件的版本變更過程進行分析和總結(jié),找到了一系列Android 應(yīng)用程序配置變更的規(guī)律[40].實證研究發(fā)現(xiàn):(1)配置變更的主要原因是新增組件(占全部變更的44.0%)和申請新的權(quán)限(占全部變更的14.6%).進一步地,作者總結(jié)認為Android 應(yīng)用程序發(fā)生配置變更的首要原因是應(yīng)用程序新增功能.(2)Android 應(yīng)用程序配置變更的頻繁程度和其功能點數(shù)量并沒有明顯的關(guān)系.(3)除了新增功能之外,很大一部分配置變更是由于改進用戶界面.改進用戶界面的手段包括更新主題、圖表、導航欄等(占全部變更的21.6%).(4)Android 應(yīng)用程序常在新增功能點方面做無用功,即新增了一個功能點、但過一段時間后又由于某些原因刪除了這個功能點.這些發(fā)現(xiàn)能夠?qū)ndroid 應(yīng)用程序的更新提供指導,并對軟件配置變更的研究有一定的意義.

Sayagh 等人以WordProcess (WP)為例,研究了跨軟件棧系統(tǒng)中低層軟件配置對高層應(yīng)用的影響[41].WP 按調(diào)用關(guān)系從上至下可以分為3 層:WP 插件、WP本身和PHP.研究分析發(fā)現(xiàn):(1)WP 插件為提高可用性,通常將配置項存儲在數(shù)據(jù)庫中;而WP 本身也是如此.因此,數(shù)據(jù)庫中的配置項可能屬于軟件中的任意一層.(2)WP 插件跨層使用配置項的情況較為常見,平均每個插件使用1.4個PHP 層配置項、并修改0.4個PHP 層配置項的值.(3)單個配置項被多個插件同時使用的情況十分常見,78.88%的可配置常量和85.16%的數(shù)據(jù)庫配置項會同時被至少2個插件使用,而單個配置項同時被最多458個插件使用.(4)配置項間接使用的情況比直接使用的情況更多.這些發(fā)現(xiàn)說明了跨軟件棧系統(tǒng)中可能潛藏著許多配置問題.進一步地,這些發(fā)現(xiàn)能夠為跨軟件棧配置錯誤處理提供理論依據(jù).

4 分析和展望

通過對綜述范圍內(nèi)(除參考文獻[1,3–6,8,11,16,25,42–44]外，均為綜述范圍內(nèi)的文獻)的研究成果分類和分析,本文對當前軟件配置領(lǐng)域的相關(guān)研究成果所具有的特點總結(jié)如下:

(1)在軟件生命周期中,軟件配置的研究成果主要集中于開發(fā)階段和后開發(fā)階段,統(tǒng)計結(jié)果如圖3所示.其中,配置錯誤處理、配置項管理和配置參數(shù)調(diào)優(yōu)是研究的熱點.本文認為,這是因為:1)配置項數(shù)量和復雜度的增加,簡單維護配置文件或數(shù)據(jù)庫已經(jīng)很難滿足需求、難以應(yīng)對復雜的情況,因此需要新的技術(shù)和工具輔助進行配置項管理,提高效率;2)配置錯誤和系統(tǒng)性能不佳是軟件配置缺陷的直接表現(xiàn),配置錯誤處理和配置參數(shù)調(diào)優(yōu)是解決問題的直接手段.由于軟件系統(tǒng)的配置項的增加,配置缺陷逐漸暴露,首先要解決的就是直接體現(xiàn)的配置錯誤和系統(tǒng)性能問題.

圖3 不同階段軟件配置領(lǐng)域文章數(shù)量統(tǒng)計

(2)黑盒方法和白盒方法都廣泛應(yīng)用于軟件配置相關(guān)的研究中,統(tǒng)計結(jié)果如圖4所示.總體而言,兩種方法的使用頻率相近,但在具體領(lǐng)域,黑盒方法和白盒方法各有優(yōu)劣,故使用率存在較大差異.

圖4 各領(lǐng)域工作采用的技術(shù)手段分布

(3)對于配置錯誤處理領(lǐng)域的工作,本文已在3.3.1節(jié)末尾作出分析.在其他方面的工作,采用的技術(shù)手段以黑盒分析方法為主.本文認為,其原因在于:1)其他方面的工作通常有軟件的使用者參與,不宜將代碼實現(xiàn)暴露給用戶;2)配置參數(shù)調(diào)優(yōu)關(guān)注軟件配置與系統(tǒng)性能間的關(guān)系,其中涉及到語言優(yōu)化問題和操作系統(tǒng)層面問題等,基于白盒方法進行分析并不適用.

(4)使用白盒方法對軟件系統(tǒng)配置進行分析的一般流程如下:1)獲取系統(tǒng)配置項;2)找到配置項在程序中的讀入點;3)切片分析,找到配置項影響的控制流和數(shù)據(jù)流;4)定位所分析問題對應(yīng)的程序片段;5)分析配置項控制流、數(shù)據(jù)流和對應(yīng)程序片段的關(guān)系;6)評價各個配置項與所分析問題的關(guān)聯(lián)度,排序并給出結(jié)論.

(5)使用黑盒方法對軟件系統(tǒng)配置進行分析,一般從以下幾方面考慮:1)分析配置項名稱和值中的語義信息;2)收集多份配置文件,通過數(shù)據(jù)挖掘和機器學習等方法發(fā)現(xiàn)配置項取不同值時和所分析問題的關(guān)聯(lián);3)收集系統(tǒng)用戶手冊和論壇相關(guān)問答,通過自然語言處理等方法提取有用知識;4)收集日志信息,挖掘日志輸出和配置的關(guān)聯(lián).

綜合上述幾點,本文認為,在選擇使用黑盒方法還是白盒方法進行軟件系統(tǒng)配置分析時,可以從以下幾方面進行考慮:

(1)問題領(lǐng)域.當進行配置錯誤處理時,白盒方法更為常用;當進行配置性能調(diào)優(yōu),尤其涉及到多軟件系統(tǒng)、操作系統(tǒng)層面的問題時,通?？紤]黑盒方法.

(2)程序源碼是否可獲得.如果可獲得,可以考慮使用白盒方法進行分析,否則只能使用黑盒方法.

(3)是否存在額外資源(如用戶手冊、日志輸出等).如果存在,有助于提升黑盒方法分析的準確度;如果只有單一配置文件,使用白盒方法分析準確度更高.

通過對當前軟件配置錯誤檢測、診斷與修復相關(guān)的研究熱點和主要工作進行分析,本文認為該領(lǐng)域的未來研究趨勢包括以下方面:

(1)跨軟件棧配置錯誤的處理.對于單個軟件堆棧上的配置錯誤處理的研究,目前發(fā)展較為充分,但對于跨軟件棧的配置錯誤處理,研究成果仍然較少.而在實際應(yīng)用中,跨軟件棧的大型復雜分布式系統(tǒng)已成為常態(tài).調(diào)查顯示,相比單軟件配置錯誤,跨軟件棧的配置錯誤更容易導致系統(tǒng)崩潰,且修復難度不低于單軟件配置錯誤[27].因此,對于跨軟件棧配置錯誤問題的研究將是未來的研究發(fā)展趨勢之一.

(2)基于深度學習的配置優(yōu)化.隨著配置項數(shù)量的增長和軟件性能指標的增加,傳統(tǒng)的機器學習模型面臨著建模難度大和需求訓練集樣本容量大的問題.在其他領(lǐng)域(如聲紋識別領(lǐng)域[42,43])的成果表明,面對復雜的建模問題,深度學習方法和傳統(tǒng)機器學習方法相比模型表示更簡單、準確率更高.因此,本文認為,在未來幾年的研究中,深度學習方法會逐步應(yīng)用于以提高系統(tǒng)性能為目標的配置優(yōu)化中.

(3)軟件配置演化維護.持續(xù)演化已成為軟件系統(tǒng)發(fā)展演進的重要特征,其中的軟件配置也隨之一同演化和發(fā)展,并貫穿于軟件生命周期的各個階段.因此,對于軟件配置問題的理解和認識更加需要站在全生命周期的視角去理解和看待,將各個階段融會貫通,通過持續(xù)軟件工程的方法提高軟件配置在系統(tǒng)持續(xù)演進過程中的維護和管理能力.例如,通過不斷的迭代演進將后開發(fā)階段發(fā)現(xiàn)的配置問題反饋到新一輪迭代中的配置設(shè)計和實現(xiàn)中,不斷提升軟件配置的質(zhì)量、合理性和可理解性等.

(4)軟件配置領(lǐng)域知識的匯聚與運用.開源軟件和技術(shù)社區(qū)的發(fā)展積累了大量的軟件數(shù)據(jù),其中也包括與軟件配置相關(guān)的數(shù)據(jù)與知識,散落和隱藏在多源異構(gòu)的軟件倉庫與社區(qū)中.例如,從Docker Hub、GitHub和StackOverflow中都能夠獲取與軟件系統(tǒng)配置相關(guān)的數(shù)據(jù)和知識[44].因此,從上述數(shù)據(jù)來源中分析抽取軟件配置知識,并進行有效的組織和管理(如知識圖譜),也是后續(xù)研究中提高配置領(lǐng)域知識應(yīng)用的一個有效方法和途徑.

(5)新軟件形態(tài)和技術(shù)中的配置問題.隨著云計算、人工智能和大數(shù)據(jù)等技術(shù)的成熟運用,基于這些技術(shù)的軟件系統(tǒng)和平臺不斷涌現(xiàn).新場景下是否衍生出新的軟件配置需求和問題,已有軟件配置方法和成果是否能夠應(yīng)對,還有待進一步研究.

5 結(jié)束語

隨著軟件系統(tǒng)規(guī)模的不斷擴大,以及用戶對系統(tǒng)靈活可定制性要求的逐漸提高,軟件配置已經(jīng)成為軟件工程領(lǐng)域的一個重要話題.國內(nèi)外眾多學者和研究人員從不同視角出發(fā),對軟件配置的諸多問題展開研究,取得了眾多成果.本文對軟件配置領(lǐng)域的研究現(xiàn)狀和主要成果進行分析綜述,首先分析了軟件配置面臨的問題,然后提出了基于軟件生命周期和技術(shù)手段的軟件配置相關(guān)研究工作的分析框架,然后基于該框架對當前主流的研究成果和研究現(xiàn)狀進行分類總結(jié)和分析評價,最后總結(jié)當前軟件配置領(lǐng)域研究工作的特點,并對未來研究方向提出了展望和建議,對于今后該領(lǐng)域的繼續(xù)和深入研究具有一定的借鑒意義.