鄭 冰,李 華

(內(nèi)蒙古大學(xué) 計(jì)算機(jī)學(xué)院,呼和浩特 010021)

1 引 言

SDN架構(gòu)的網(wǎng)絡(luò)中,控制器是負(fù)責(zé)管理底層網(wǎng)絡(luò)的核心和關(guān)鍵組成部分[1,2],也是承載功能豐富的管理軟件的網(wǎng)絡(luò)操作系統(tǒng),其質(zhì)量對(duì)自己所承載的應(yīng)用有很大影響.現(xiàn)有研究結(jié)果[2]表明,包括原型級(jí)控制器在內(nèi),65%以上的控制器均采用了多線程的并發(fā)編程技術(shù),蘊(yùn)含著并發(fā)缺陷,帶來(lái)了網(wǎng)絡(luò)運(yùn)行的不確定.由于SDN的邏輯分層,天然具有異步性,使得并發(fā)缺陷更加需要關(guān)注.發(fā)現(xiàn)與修復(fù)并發(fā)缺陷是重要但耗時(shí)的工作.因此,極有必要對(duì)SDN控制器的并發(fā)缺陷及修復(fù)過(guò)程進(jìn)行深入細(xì)化的研究.如果能夠進(jìn)行量化分析,對(duì)于它的缺陷修復(fù)具有更強(qiáng)的指導(dǎo)意義.

為了便于研究,研究對(duì)象限于代碼和缺陷倉(cāng)庫(kù)開(kāi)放訪問(wèn)的開(kāi)源SDN控制器.現(xiàn)有開(kāi)源SDN控制器主要分為兩種[3]:作為某公司開(kāi)發(fā)的產(chǎn)品的一部分在生產(chǎn)環(huán)境中應(yīng)用和在學(xué)術(shù)研究中作為基礎(chǔ)平臺(tái)使用.雖然SDN控制器的實(shí)現(xiàn)技術(shù)各有不同,但均是基于SDN思想,實(shí)現(xiàn)大致相同的核心功能,提供類似的服務(wù)功能集合,因此各SDN控制器可能會(huì)出現(xiàn)相似的缺陷[3].通過(guò)針對(duì)現(xiàn)有研究和工業(yè)界應(yīng)用情況的調(diào)研,開(kāi)源SDN控制器按照應(yīng)用場(chǎng)景分為3類:商業(yè)級(jí)通用、原型級(jí)通用和特定場(chǎng)景應(yīng)用.基于調(diào)研結(jié)果總結(jié)了每類別中具有代表性的控制器及其代碼級(jí)特征,如表1所示.

表1 按應(yīng)用場(chǎng)景分類的開(kāi)源SDN控制器(1)http://www.openhub.net,2021-04(部分)Table 1 Open source SDN controllers by application scenario1(part)

在SDN控制器并發(fā)控制實(shí)現(xiàn)過(guò)程中,采用了相應(yīng)的并發(fā)編程技術(shù),表1中列出的控制器均是如此.相比單線程控制器,多線程控制器適用于更復(fù)雜的環(huán)境,例如5G、SD-WAN和物聯(lián)網(wǎng)等商業(yè)用途[4].發(fā)現(xiàn)與修復(fù)并發(fā)缺陷需要研究分析并發(fā)缺陷表征和修復(fù)過(guò)程相關(guān)的特征[5],通過(guò)對(duì)該特征的分析,有利于并發(fā)缺陷的再現(xiàn)和修復(fù)策略的制定.在軟件缺陷管理工具的歷史缺陷倉(cāng)庫(kù)和軟件代碼倉(cāng)庫(kù)的提交記錄中保存了多個(gè)維度的缺陷表征和修復(fù)過(guò)程信息,因此可以基于該類數(shù)據(jù)進(jìn)行特征量化分析.

下面以缺陷管理工具Jira獲取的1個(gè)SDN控制器OpenDaylight(以下簡(jiǎn)稱ODL)項(xiàng)目的真實(shí)歷史缺陷作為實(shí)例簡(jiǎn)述研究動(dòng)機(jī).編號(hào)OPNFLWPLUG-1090(2)https://jira.opendaylight.org/browse/OPNFLWPLUG-1090,2021-04的缺陷報(bào)告所描述的缺陷發(fā)生在ODL南向接口插件SDN原生協(xié)議子項(xiàng)目OpenFlowPlugin中,具體表征及修復(fù)過(guò)程:1)報(bào)告者提交報(bào)告:單節(jié)點(diǎn)ODL控制器16臺(tái)交換機(jī)部署下,在初始連接階段出現(xiàn)了部分交換機(jī)連接請(qǐng)求被拒絕的情況;2)報(bào)告者和開(kāi)發(fā)者通過(guò)評(píng)論區(qū)的討論認(rèn)為原因是由于多臺(tái)交換機(jī)同一時(shí)間的握手請(qǐng)求引發(fā)了數(shù)據(jù)競(jìng)爭(zhēng),并且這一問(wèn)題極有可能在大規(guī)模部署的生產(chǎn)環(huán)境中發(fā)生;3)開(kāi)發(fā)者在代碼倉(cāng)庫(kù)提交修復(fù)補(bǔ)丁代碼;4)開(kāi)發(fā)者在Jira中給出2個(gè)ODL版本的修復(fù)代碼鏈接,并修改該缺陷報(bào)告的狀態(tài)為“已解決”.

通過(guò)以上實(shí)例可以看到,真實(shí)的歷史缺陷報(bào)告可以提供并發(fā)缺陷表征和修復(fù)過(guò)程的有用信息.本文以缺陷倉(cāng)庫(kù)真實(shí)歷史并發(fā)缺陷數(shù)據(jù)為研究對(duì)象,采用量化分析的方式給出SDN控制器平臺(tái)并發(fā)缺陷在典型并發(fā)缺陷類型的分布特征和修復(fù)過(guò)程的特征.不同SDN控制器項(xiàng)目并發(fā)缺陷的特征存在可能的共性,這些特征能夠作為模式和規(guī)律傳遞的橋梁,有助于在SDN控制器平臺(tái)上的應(yīng)用程序的開(kāi)發(fā)和調(diào)試,對(duì)SDN相關(guān)產(chǎn)品的理解、發(fā)展和管理也有幫助.本文所指的缺陷量化分析是將SDN控制器軟件缺陷倉(cāng)庫(kù)保存的歷史缺陷在產(chǎn)生和修復(fù)過(guò)程中產(chǎn)生的相關(guān)信息提取為多個(gè)維度的度量數(shù)據(jù),統(tǒng)計(jì)量化計(jì)算分析度量數(shù)據(jù)的活動(dòng).并發(fā)缺陷特征是指在典型并發(fā)缺陷類型的數(shù)量分布特征和修復(fù)過(guò)程特征.

本文工作貢獻(xiàn)如下:

1)給出一種半自動(dòng)化量化分析SDN控制器并發(fā)性缺陷的框架方法;從軟件缺陷管理周期出發(fā),提出與SDN控制器軟件并發(fā)缺陷數(shù)量修復(fù)過(guò)程相關(guān)的時(shí)間因素、缺陷影響、重要性和復(fù)雜度以及修復(fù)影響4個(gè)維度及10個(gè)具體度量,并給出度量指標(biāo)的提取和計(jì)算方法;

2)在兩個(gè)廣泛使用的SDN控制器ODL和ONOS上進(jìn)行了一系列實(shí)證研究.基于所給出的修復(fù)過(guò)程度量,對(duì)所獲取的SDN控制器并發(fā)缺陷進(jìn)行量化分析,給出了在典型并發(fā)缺陷類型的數(shù)量分布和修復(fù)過(guò)程特征的對(duì)比量化分析結(jié)果;給出了經(jīng)過(guò)處理后的數(shù)據(jù)集,包含本文從ODL和ONOS所提取的修復(fù)過(guò)程特征的并發(fā)缺陷數(shù)據(jù).

本文的其余部分組織如下:第2部分是相關(guān)工作,介紹與SDN控制器并發(fā)缺陷分析的相關(guān)工作并提出本文的研究問(wèn)題;第3部分提出一種量化分析框架,給出修復(fù)過(guò)程度量,詳細(xì)闡述了所采用的研究方法;第4部分給出SDN 控制器軟件并發(fā)缺陷的量化分析結(jié)果,并進(jìn)行了有效性分析;第5部分總結(jié)全文并給出未來(lái)工作展望.

2 相關(guān)工作

目前針對(duì)SDN控制器缺陷的研究工作主要從以下幾個(gè)方面展開(kāi):通過(guò)文獻(xiàn)綜述的方法進(jìn)行缺陷特征的分析,Yu等人[6]給出了SDN中可能出現(xiàn)缺陷的表征及根因;通過(guò)來(lái)自學(xué)術(shù)研究和生產(chǎn)運(yùn)維中的觀察及經(jīng)驗(yàn)總結(jié)缺陷特征,Canini等人[7]關(guān)注了SDN控制器應(yīng)用程序中存在的邏輯缺陷;通過(guò)實(shí)證研究的方法,利用真實(shí)缺陷報(bào)告獲得SDN控制器缺陷特征,Vizarreta等人[5]通過(guò)統(tǒng)計(jì)分析方法給出了所報(bào)告缺陷數(shù)量的學(xué)習(xí)曲線模式和錯(cuò)誤檢測(cè)率的變化規(guī)律,又通過(guò)對(duì)ODL和ONOS控制器缺陷的研究[3],專門(mén)關(guān)注由分布式SDN控制器集群造成的缺陷,給出了缺陷的分類和根因分析.這些研究引入了預(yù)測(cè)SDN控制器缺陷數(shù)量、位置的模型和工具,但是并沒(méi)有考慮特定的并發(fā)缺陷類型及其修復(fù)過(guò)程特征.關(guān)于SDN控制器的并發(fā)缺陷,Miserez等人[8]研究了SDN控制器和交換機(jī)交互引入的并發(fā)缺陷,并基于事件執(zhí)行的有向無(wú)環(huán)圖給出了相應(yīng)的并發(fā)缺陷檢測(cè)工具SDNRacer;MAY等人[9]進(jìn)一步給出了SDN并發(fā)缺陷的檢測(cè)工具BigBug.這些研究更多關(guān)注的是SDN架構(gòu)中南向交互引入的并發(fā)缺陷及其檢測(cè),并沒(méi)有過(guò)多關(guān)注由于控制器軟件本身的多線程和分布式部署引發(fā)的并發(fā)缺陷及其修復(fù)過(guò)程特征.

由于不確定性,并發(fā)缺陷在開(kāi)發(fā)和維護(hù)過(guò)程中的檢測(cè)與修復(fù)一直是困擾開(kāi)發(fā)者和使用者的難題.對(duì)于其他軟件系統(tǒng)并發(fā)缺陷的研究有:Leesatapornwongsa 等人[10]對(duì)于數(shù)據(jù)中心分布式系統(tǒng)并發(fā)缺陷的表征、觸發(fā)原因等進(jìn)行了研究;Lu等人[11]對(duì)現(xiàn)實(shí)世界的真實(shí)并發(fā)缺陷進(jìn)行了廣泛研究;Gunawi等人[12]在對(duì)3000多個(gè)真實(shí)云系統(tǒng)故障事件的研究中,關(guān)注了由并發(fā)缺陷帶來(lái)的云系統(tǒng)不確定性;石劍君等人[13]對(duì)操作系統(tǒng)并發(fā)缺陷的研究現(xiàn)狀進(jìn)行了分析.但是不同領(lǐng)域軟件系統(tǒng)的并發(fā)缺陷都會(huì)有所不同[10],對(duì)于SDN控制器這類網(wǎng)絡(luò)操作系統(tǒng)亦是如此[8],需要進(jìn)行有針對(duì)性研究.

從真實(shí)缺陷報(bào)告中提取數(shù)據(jù)進(jìn)行缺陷特征的分析,在許多與缺陷相關(guān)的研究中扮演著重要的基礎(chǔ)性角色,相關(guān)研究包括:Zaman等人[14]對(duì)Firefox和Chrome的性能和非性能缺陷報(bào)告進(jìn)行了量化分析,發(fā)現(xiàn)性能故障比非性能故障更難處理;Catolino等人[15]通過(guò)量化分析的方法研究了軟件缺陷的根因分類和特征;Zheng等人[16]專門(mén)針對(duì)云平臺(tái)OpenStack缺陷報(bào)告中的歷史缺陷進(jìn)行挖掘,給出了觸發(fā)云平臺(tái)缺陷的事件因素和動(dòng)作特征.對(duì)缺陷報(bào)告的挖掘分析可以通過(guò)對(duì)所關(guān)注的特定度量指標(biāo)的量化統(tǒng)計(jì)分析實(shí)現(xiàn)[17].

缺陷是軟件產(chǎn)品期望屬性的偏離,現(xiàn)有研究并沒(méi)有對(duì)于真實(shí)SDN控制器并發(fā)缺陷的數(shù)量分布及其具體修復(fù)過(guò)程特征的研究.因此本文提出以下研究問(wèn)題:

RQ1:SDN 控制器在各類型并發(fā)缺陷上的數(shù)據(jù)分布特征如何?各類型并發(fā)缺陷在SDN控制器各功能模塊上的數(shù)據(jù)分布特征如何?

RQ2:以缺陷修復(fù)過(guò)程的多維度量作為表征,SDN控制器并發(fā)缺陷的修復(fù)過(guò)程特征是什么? SDN控制器的并發(fā)與非并發(fā)缺陷在修復(fù)過(guò)程特征上的區(qū)別是什么?

3 研究方法

3.1 方法的整體框架

SDN控制器并發(fā)缺陷的量化分析需要領(lǐng)域知識(shí)和對(duì)代碼庫(kù)的熟悉才能獲得有意義的變化規(guī)律和分布特征[18].為了解決前面提出的問(wèn)題,給出量化分析方法的框架如圖1所示,具體步驟如下:

圖1 SDN控制器并發(fā)缺陷量化分析方法框架Fig.1 Framework of quantitative analysis method for concurrent bugs of SDN controller

步驟1.數(shù)據(jù)收集及預(yù)處理.自動(dòng)化進(jìn)行缺陷報(bào)告數(shù)據(jù)的采集構(gòu)成原始數(shù)據(jù)集BD;對(duì)文本數(shù)據(jù)進(jìn)行預(yù)處理,生成文本語(yǔ)料數(shù)據(jù)集.

步驟2.修復(fù)過(guò)程特征提取.依據(jù)軟件缺陷生命周期,提出修復(fù)過(guò)程的分析維度,給出修復(fù)過(guò)程度量和計(jì)算方法,利用Python工具計(jì)算提取修復(fù)過(guò)程特征,構(gòu)成具有修復(fù)過(guò)程特征的數(shù)據(jù)集BD*.

步驟3.生成并發(fā)缺陷研究數(shù)據(jù)集.給出并發(fā)缺陷類型作為分類依據(jù),利用自己設(shè)計(jì)的Python工具實(shí)現(xiàn)基于關(guān)鍵字檢索缺陷報(bào)告文本語(yǔ)料集,獲得候選缺陷報(bào)告.通過(guò)對(duì)代碼提交記錄和候選缺陷報(bào)告的人工篩選進(jìn)行交叉驗(yàn)證,結(jié)合BD*獲得具有修復(fù)過(guò)程特征的并發(fā)缺陷報(bào)告數(shù)據(jù)集CD.通過(guò)對(duì)BD*中的非并發(fā)缺陷報(bào)告進(jìn)行分層隨機(jī)采樣獲得比較分析需要的非并發(fā)缺陷數(shù)據(jù)集樣本NCD.

步驟4.并發(fā)缺陷量化分析.給出量化統(tǒng)計(jì)分析方法,基于數(shù)據(jù)集CD和NCD,給出具體的量化分析結(jié)果,回答研究問(wèn)題.

3.2 數(shù)據(jù)收集及預(yù)處理

開(kāi)源社區(qū)缺陷管理工具(例如,Jira、Bugzilla)的缺陷倉(cāng)庫(kù)保存的歷史缺陷報(bào)告數(shù)據(jù)可以公開(kāi)訪問(wèn)直接獲取.現(xiàn)有研究主要通過(guò)缺陷管理工具提供的開(kāi)放API(Application Programming Interface)下載和爬蟲(chóng)爬取兩種方式自動(dòng)獲取缺陷報(bào)告數(shù)據(jù)[16].為了確保數(shù)據(jù)集中只包含真正的歷史缺陷,選擇“Issue type”為“Bug”的缺陷報(bào)告,并保留缺陷管理工具中提供的所有預(yù)定義標(biāo)簽的數(shù)據(jù)作為量化分析的數(shù)據(jù)來(lái)源.雖然缺陷管理工具可能不同,項(xiàng)目定義的標(biāo)簽也會(huì)有所區(qū)別,但是按照通用的缺陷管理流程,一般由以下預(yù)定義標(biāo)簽組成:編號(hào)(Issue ID)類型(Issue type)、狀態(tài)(Status)、創(chuàng)建者(Created)、優(yōu)先級(jí)(Priority)、建立日期(Created)、摘要(Summary)、描述(Description)和評(píng)論(Comments)等.這些信息構(gòu)成了以缺陷報(bào)告編號(hào)為索引的包含m條缺陷報(bào)告原始數(shù)據(jù)集合BD={b1,b2,…,bj,…,bm},其中,預(yù)定義標(biāo)簽是缺陷報(bào)告bj的默認(rèn)屬性,具有量化分析所需要的元數(shù)據(jù)信息,可以直接映射或派生為并發(fā)缺陷修復(fù)過(guò)程的具體度量.

對(duì)于缺陷報(bào)告bj中的文本數(shù)據(jù),是由缺陷報(bào)告者和開(kāi)發(fā)者提供的自然語(yǔ)言描述文本[5].具體包括:

1)摘要:是對(duì)缺陷問(wèn)題核心的簡(jiǎn)練概括描述;

2)詳細(xì)描述:不僅有自然語(yǔ)言描述,也時(shí)常附有觸發(fā)缺陷的執(zhí)行路徑、代碼片段、輸出日志等,還可能包括報(bào)告者對(duì)于修復(fù)措施的建議;

3)評(píng)論:包含了開(kāi)發(fā)者和報(bào)告者之間關(guān)于如何診斷和解決缺陷問(wèn)題以及對(duì)于具體修復(fù)措施的討論,也包含在代碼倉(cāng)庫(kù)的修復(fù)鏈接.

缺陷文本中的信息可以作為識(shí)別并發(fā)缺陷以及修復(fù)過(guò)程度量提取(例如并發(fā)缺陷所影響的節(jié)點(diǎn)數(shù)目)的數(shù)據(jù)來(lái)源.將3個(gè)字段的文本內(nèi)容以缺陷報(bào)告編號(hào)為索引進(jìn)行拼接,構(gòu)成分析所需要的文本語(yǔ)料集.然后,在原始數(shù)據(jù)集BD的基礎(chǔ)上,計(jì)算提取修復(fù)過(guò)程度量,基于文本語(yǔ)料數(shù)據(jù)集和相應(yīng)代碼倉(cāng)庫(kù)的提交記錄篩選并發(fā)缺陷.

3.3 修復(fù)過(guò)程特征提取

在缺陷管理工具中,缺陷生命周期是缺陷在最終解決之前所要經(jīng)歷的多個(gè)階段,其核心任務(wù)是修復(fù)軟件缺陷,因此本文所研究的特征關(guān)注了缺陷修復(fù)過(guò)程特征.在缺陷生命周期管理過(guò)程中,基于缺陷管理工具的典型缺陷修復(fù)過(guò)程如下[5,19]:1)報(bào)告者提交一個(gè)缺陷報(bào)告;2)缺陷被分配給開(kāi)發(fā)者;3)開(kāi)發(fā)者診斷缺陷并確定修復(fù)策略,這期間可以通過(guò)評(píng)論區(qū)與報(bào)告者進(jìn)行交互;4)開(kāi)發(fā)者修復(fù)缺陷,并標(biāo)記缺陷報(bào)告狀態(tài)為“已解決”或“修復(fù)”.

結(jié)合典型缺陷修復(fù)過(guò)程,基于BD數(shù)據(jù)集中包含的元數(shù)據(jù)信息,以下給出缺陷修復(fù)過(guò)程中所關(guān)注的4個(gè)維度和10個(gè)修復(fù)過(guò)程度量的定義和相應(yīng)的形式化描述.

定義 1.(缺陷修復(fù)過(guò)程(FTP)).假設(shè)所有缺陷報(bào)告都被分配了正確的狀態(tài)和優(yōu)先級(jí),缺陷修復(fù)過(guò)程表示為四元組FTP={T,S,I,F},其中:

·T表示缺陷修過(guò)程中的時(shí)間因素,可以表示為三元組T= {t_tr,t_dr,t_acomm},缺陷修復(fù)過(guò)程中涉及的主要時(shí)間點(diǎn)包括,從缺陷的報(bào)告開(kāi)始,期間的評(píng)論互動(dòng),再到最后的缺陷解決或修復(fù),可以反映缺陷修復(fù)的效率;

·S表示缺陷影響的范圍,可以表示為二元組S={n_affv,n_node},由報(bào)告者或開(kāi)發(fā)者認(rèn)定缺陷發(fā)生所影響的版本數(shù)和節(jié)點(diǎn)數(shù),可以反映缺陷發(fā)生的具體部署配置,對(duì)修復(fù)過(guò)程也會(huì)產(chǎn)生影響;

·I表示重要性和復(fù)雜度,由三元組I={priority,n_comm,n_sdc}表示,是開(kāi)發(fā)者或報(bào)告者認(rèn)為缺陷對(duì)于軟件質(zhì)量影響的重要程度以及表征修復(fù)缺陷本身的復(fù)雜程度;

·F表示修復(fù)結(jié)果,可以表示為二元組F={n_patches,n_fixv},是開(kāi)發(fā)者對(duì)缺陷修復(fù)的最終結(jié)果.

針對(duì)4個(gè)維度中的指標(biāo),依據(jù)可獲取原則,本文選取了10個(gè)具體度量,其詳細(xì)描述如表2所示.

表2 并發(fā)缺陷修復(fù)過(guò)程量化分析維度及具體度量Table 2 Quantitative analysis of the measurement and metrics of concurrent bugs fix process

利用Python工具自動(dòng)化實(shí)現(xiàn)具體度量數(shù)據(jù)的計(jì)算提取,所采用的方式包括從數(shù)據(jù)集中直接獲取、通過(guò)計(jì)算派生和通過(guò)文本提取3類:

1)在直接獲取的數(shù)據(jù)中,補(bǔ)丁數(shù)n_patches是通過(guò)代碼倉(cāng)庫(kù)的提交記錄和代碼審計(jì)倉(cāng)庫(kù)獲得.

2)通過(guò)計(jì)算派生的數(shù)據(jù)主要指時(shí)間因素(T)中的度量,其中,平均評(píng)論時(shí)間間隔t_acomm可以表征每條缺陷報(bào)告的報(bào)告者和開(kāi)發(fā)者之間互動(dòng)的頻率,所設(shè)計(jì)的計(jì)算方法如公式(1)所示:

(1)

其中k表示缺陷報(bào)告的評(píng)論數(shù)(n_comm=k),t_commi表示該缺陷報(bào)告第i條評(píng)論的提交時(shí)間.

3)通過(guò)文本提取的數(shù)據(jù)主要指節(jié)點(diǎn)數(shù)n_node,可以表征發(fā)生缺陷時(shí)的具體部署配置,這里的節(jié)點(diǎn)數(shù)主要指發(fā)生缺陷時(shí)的SDN控制器的節(jié)點(diǎn)數(shù)目.具體賦值方法:節(jié)點(diǎn)數(shù)對(duì)缺陷無(wú)影響或缺陷報(bào)告中描述模糊的情況,均賦值為0;單控制器節(jié)點(diǎn)部署賦值為1;控制器集群部署情形下按照具體節(jié)點(diǎn)數(shù)賦值.

為了保證所分析的并發(fā)缺陷的準(zhǔn)確性,只關(guān)注已解決和已修復(fù)的歷史缺陷報(bào)告.從原始數(shù)據(jù)集BD的m條缺陷報(bào)告中篩選出n條符合要求的報(bào)告,按照上述方法,計(jì)算提取出FTP 4個(gè)維度的度量,形成數(shù)據(jù)集BD*.

3.4 生成并發(fā)缺陷研究數(shù)據(jù)集

為了有效的收集SDN控制器的歷史并發(fā)缺陷,采用基于關(guān)鍵字的檢索方式篩選并發(fā)缺陷[17,18,20].在文本語(yǔ)料具備相關(guān)信息的基礎(chǔ)上,需要進(jìn)行并發(fā)缺陷相關(guān)的關(guān)鍵字的選擇.本文關(guān)注的并發(fā)缺陷是指:兩個(gè)或兩個(gè)以上的線程因交互作用于一個(gè)或多個(gè)共享資源而引起的程序崩潰或掛起,或產(chǎn)生與串行執(zhí)行不同的結(jié)果,且這樣的結(jié)果是不確定的.表3給出了具體并發(fā)缺陷類型的描述及對(duì)應(yīng)的檢索關(guān)鍵字.

生成并發(fā)缺陷研究數(shù)據(jù)集的過(guò)程如下:

1)對(duì)文本語(yǔ)料集進(jìn)行篩選,保留已完成和已修復(fù)缺陷報(bào)告的n條語(yǔ)料數(shù)據(jù),包含了各種類型的缺陷,基于表3中的關(guān)鍵字,利用Python工具采用檢索技術(shù)篩出包含一個(gè)或多個(gè)關(guān)鍵字及其單詞變形的缺陷報(bào)告,獲得候選集.

表3 并發(fā)缺陷類型描述與關(guān)鍵字Table 3 Description and keywords of concurrent bugs

2)通過(guò)對(duì)候選集與代碼倉(cāng)庫(kù)中的提交記錄進(jìn)行交叉核對(duì)的人工篩選方法獲得SDN控制器的真實(shí)并發(fā)缺陷,并在數(shù)據(jù)集中標(biāo)記具體并發(fā)缺陷類型,生成并發(fā)缺陷報(bào)告數(shù)據(jù)集CD.其中代碼提交記錄可以從缺陷報(bào)告中的修復(fù)鏈接獲取,也可以從代碼倉(cāng)庫(kù)(例如Git)的提交日志獲取.

3)為了進(jìn)行對(duì)比分析,采用分層抽樣的方式篩選同等數(shù)量非并發(fā)缺陷樣本.將所有非并發(fā)缺陷數(shù)據(jù)按照缺陷報(bào)告創(chuàng)建日期和所屬的功能模塊劃分為多個(gè)類別,以保證所選取的樣本盡量與并發(fā)缺陷報(bào)告具有相同的分布,減少后續(xù)量化分析中的誤差,然后從每個(gè)類別中隨機(jī)抽樣選擇缺陷報(bào)告組成非并發(fā)缺陷對(duì)比分析數(shù)據(jù)集NCD.

3.5 量化分析方法

采用的具體統(tǒng)計(jì)分析方法包括:

1)對(duì)于分類數(shù)據(jù),通過(guò)統(tǒng)計(jì)不同分類下的數(shù)量,給出頻數(shù)和頻率(頻數(shù)與數(shù)據(jù)總數(shù)的比值)分布.

2)對(duì)于數(shù)據(jù)分布特征的描述性統(tǒng)計(jì),通過(guò)統(tǒng)計(jì)學(xué)中常用的集中趨勢(shì)分析給出,采用的測(cè)度值包括,平均值、中位數(shù)、四分位數(shù)(75%)、極大值和眾數(shù).

3)兩個(gè)獨(dú)立樣本比較檢驗(yàn),對(duì)于需要進(jìn)行兩組數(shù)據(jù)的對(duì)比分析時(shí),統(tǒng)計(jì)學(xué)中經(jīng)常假設(shè)數(shù)據(jù)滿足某種分布,由于待檢驗(yàn)數(shù)據(jù)集中的數(shù)據(jù)特征不一定遵循特定的分布,因此,并不假設(shè)數(shù)據(jù)服從某種分布,為了檢驗(yàn)兩個(gè)獨(dú)立樣本數(shù)據(jù)組間(并發(fā)缺陷和非并發(fā)缺陷)的特征值(修復(fù)過(guò)程特征)是否存在顯著差異,使用Mann-Whitney U檢驗(yàn)方法[16](簡(jiǎn)稱MW U檢驗(yàn))進(jìn)行統(tǒng)計(jì)檢驗(yàn),這是一種非參數(shù)檢驗(yàn),并且不需要做出數(shù)據(jù)具有正態(tài)分布的假設(shè).顯著性水平α=0.05取,如果p<0.05時(shí)認(rèn)為所檢驗(yàn)的兩組數(shù)據(jù)間存在統(tǒng)計(jì)學(xué)上的顯著差異.其中,p 值(P-value)是當(dāng)原假設(shè)為真時(shí),所得到的樣本觀察結(jié)果或更極端結(jié)果出現(xiàn)的概率,p值也稱為觀察到的顯著性水平.

通過(guò)上述方法量化分析比較不同控制器之間以及控制器的并發(fā)缺陷和非并發(fā)缺陷在不同度量上的分布特征.

4 實(shí)例分析

4.1 實(shí)例研究對(duì)象選取

在采用實(shí)例進(jìn)行研究時(shí),選擇有代表性的SDN控制器作為實(shí)例研究對(duì)象非常重要.為了確保代表性所采用的選擇標(biāo)準(zhǔn)是:缺陷倉(cāng)庫(kù)可以公開(kāi)訪問(wèn)且有至少1000條的缺陷報(bào)告;代碼倉(cāng)庫(kù)可以公開(kāi)訪問(wèn),社區(qū)達(dá)到一定規(guī)模,此條標(biāo)準(zhǔn)通過(guò)代碼行數(shù)和貢獻(xiàn)者人數(shù)衡量;項(xiàng)目年限超過(guò)5年,保證并發(fā)缺陷具有足夠長(zhǎng)的演進(jìn)歷史可供量化分析;項(xiàng)目活動(dòng)水平,通過(guò)一年內(nèi)代碼倉(cāng)庫(kù)的提交次數(shù)衡量.

按照以上標(biāo)準(zhǔn),通過(guò)對(duì)表1中控制器相關(guān)數(shù)據(jù)的對(duì)比,選擇ODL和ONOS作為實(shí)例研究對(duì)象.選擇二者的其他優(yōu)勢(shì)包括:ODL和ONOS是目前較為典型的生產(chǎn)級(jí)開(kāi)源SDN控制器[2],二者面對(duì)的主要目標(biāo)用戶不同,實(shí)現(xiàn)功能組件亦有所區(qū)別,一定程度上可以覆蓋相對(duì)較多應(yīng)用場(chǎng)景的SDN控制器并發(fā)缺陷特征.尤其是,ODL生態(tài)中包含了控制器和在控制器平臺(tái)上實(shí)現(xiàn)的不同功能的網(wǎng)絡(luò)應(yīng)用程序,可以認(rèn)為其缺陷倉(cāng)庫(kù)包含了以控制器為核心的控制平面、數(shù)據(jù)平面和應(yīng)用平面在內(nèi)的歷史缺陷報(bào)告集合.由此保證了實(shí)例研究對(duì)象的代表性.

下面按照3.1節(jié)給出量化分析方法的框架,對(duì)實(shí)例研究對(duì)象進(jìn)行處理及分析.

按照?qǐng)D1的步驟1進(jìn)行數(shù)據(jù)收集及預(yù)處理,通過(guò)Jira API自動(dòng)獲取ODL和ONOS可以公開(kāi)訪問(wèn)的歷史缺陷報(bào)告,進(jìn)行初步篩選統(tǒng)計(jì)的數(shù)據(jù)集信息如表4所示.其中,項(xiàng)目總體的缺陷修復(fù)率是指有明確解決方案的缺陷報(bào)告數(shù)/總?cè)毕輬?bào)告數(shù),ODL比ONOS的缺陷修復(fù)率低,主要因?yàn)槿毕菡w修復(fù)率與項(xiàng)目規(guī)模呈負(fù)相關(guān)關(guān)系[16].需要說(shuō)明的是,雖然二者缺陷報(bào)告在絕對(duì)數(shù)量上有差距,但是量化分析更關(guān)心的是相對(duì)數(shù)量,并不會(huì)影響分析結(jié)果.

經(jīng)過(guò)了圖1的步驟2和步驟3,對(duì)有明確解決方案的缺陷報(bào)告進(jìn)行修復(fù)過(guò)程特征提取、關(guān)鍵字匹配、人工篩選以及分層隨機(jī)抽樣后的數(shù)據(jù)集樣本數(shù)量如表5所示.

表5 各篩選階段的缺陷報(bào)告數(shù)據(jù)集樣本數(shù)量Table 5 Number of bug report data set samples at each stage

在表5中,對(duì)用于分析的數(shù)據(jù)進(jìn)行了相應(yīng)的預(yù)處理,例如,將優(yōu)先級(jí)由文本映射為數(shù)字,根據(jù)不同粒度計(jì)算時(shí)間因素的度量,對(duì)于修復(fù)時(shí)間以“天”為粒度計(jì)算、對(duì)于回復(fù)延遲以“小時(shí)”為粒度計(jì)算等.

4.2 并發(fā)缺陷的量化分析

4.2.1 并發(fā)缺陷分類數(shù)據(jù)特征分析

本部分的量化分析結(jié)果可以回答RQ1,給出SDN 控制器在各類型并發(fā)缺陷和在各功能模塊之間的數(shù)據(jù)分布特征.對(duì)于所獲得的歷史缺陷報(bào)告數(shù)據(jù)集,統(tǒng)計(jì)不同分類下的頻數(shù)與頻率分布.ODL和ONOS所發(fā)生并發(fā)缺陷類型分布特征如表6 所示.

表6 歷史缺陷報(bào)告在并發(fā)缺陷類型的分布特征Table 6 Distribution of concurrent bugs for historical bug reports

基于表6給出的數(shù)據(jù),對(duì)5種類型的并發(fā)缺陷的實(shí)例分析如下:

1)原子性違背:一般是由于線程交錯(cuò)操作缺乏約束破壞了假定具有原子性的操作.例如,在 ODL中的OPNFLWPLUG-1075,由于破壞模型驅(qū)動(dòng)項(xiàng)目MD-SAL中事務(wù)寫(xiě)操作的原子性導(dǎo)致了端口事件線程關(guān)閉.ODL使用Java的CAS(Compare and Swap)指令實(shí)現(xiàn)原子性,CAS 指令被看作是硬件鎖.ODL和ONOS中原子性違背的歷史缺陷數(shù)量較少且大多發(fā)生在項(xiàng)目初期.

2)順序違背:多個(gè)線程在同時(shí)執(zhí)行時(shí),未能按預(yù)期設(shè)計(jì)的順序進(jìn)行交互,出現(xiàn)了不正確交錯(cuò)執(zhí)行.在SDN控制器所涉及的相關(guān)協(xié)議實(shí)現(xiàn)中,為了加強(qiáng)事件之間的因果關(guān)系,事件排序是必要的.其中,典型的問(wèn)題是在控制器和交換機(jī)的交互中寫(xiě)(FLOW_MOD)和讀(PACKET_IN)發(fā)生了順序違背,交換機(jī)的轉(zhuǎn)發(fā)狀態(tài)可能會(huì)有很大的不同.例如,ODL的NETCONF協(xié)議項(xiàng)目中的NETCONF-93,多個(gè)配置通過(guò)一個(gè)會(huì)話異步發(fā)送,導(dǎo)致操作互相干擾,多個(gè)寫(xiě)的提交操作出現(xiàn)了亂序的問(wèn)題.而ONOS項(xiàng)目中出現(xiàn)的流表規(guī)則的提交順序沖突也屬于此類問(wèn)題.

3)數(shù)據(jù)競(jìng)爭(zhēng):是由共享資源引發(fā),也包括共享數(shù)據(jù)庫(kù),是2個(gè)實(shí)例項(xiàng)目中出現(xiàn)最多的并發(fā)缺陷類型,這也與現(xiàn)有研究的結(jié)論相符合[13].在SDN網(wǎng)絡(luò)中,特有的重要共享數(shù)據(jù)資源是流表,ODL提供兩種數(shù)據(jù)存儲(chǔ),配置存儲(chǔ)(config datastores)用于存儲(chǔ)用戶所需的狀態(tài),操作存儲(chǔ)(operational datastores)用于存儲(chǔ)實(shí)際的網(wǎng)絡(luò)狀態(tài).ONOS的共享數(shù)據(jù)庫(kù)是流規(guī)則存儲(chǔ)(FlowRulesStores).由于共享造成的數(shù)據(jù)競(jìng)爭(zhēng),可能發(fā)生在節(jié)點(diǎn)內(nèi)部,也可能發(fā)生在節(jié)點(diǎn)之間.例如,ODL項(xiàng)目中的BGPCEP-645,關(guān)閉對(duì)端并更新路由時(shí)發(fā)生對(duì)共享資源的競(jìng)爭(zhēng)訪問(wèn).對(duì)于非死鎖類的并發(fā)缺陷,大多可以歸因于數(shù)據(jù)競(jìng)爭(zhēng),也是任何并發(fā)軟件系統(tǒng)中的基本問(wèn)題.

4)死鎖:死鎖在2個(gè)實(shí)例項(xiàng)目中都有發(fā)生,ODL項(xiàng)目中發(fā)生的更多.例如,ODL項(xiàng)目中的CONTROLLER-1893,應(yīng)用程序線程出現(xiàn)了死鎖.在NETVIRT-424中出現(xiàn)了典型的ABBA死鎖,由于互斥鎖的粒度不恰當(dāng)(粒度較粗),與 MAC 相關(guān)流的互斥鎖在 ELAN + MAC 上的鎖定無(wú)法操作,解決方法是通過(guò)鎖定更細(xì)粒度的互斥鎖鎖定ELAN+MAC+DPID.SDN集群中會(huì)發(fā)生分布式死鎖,即每個(gè)節(jié)點(diǎn)都在等待以便其他節(jié)點(diǎn)進(jìn)行下一步操作,引發(fā)整個(gè)集群掛起.例如,ONOS-1965在Leader選舉過(guò)程中,候選節(jié)點(diǎn)重啟后沒(méi)有出現(xiàn)在候選列表中,引發(fā)了死鎖.

5)并發(fā)類型狀態(tài)缺陷:會(huì)使系統(tǒng)進(jìn)入不正確的狀態(tài).典型的是發(fā)生在SDN集群部署中,尤其是集群中的全局網(wǎng)絡(luò)狀態(tài)保存在多個(gè)同步的控制器中,并分散保存在數(shù)據(jù)平面的交換機(jī)中,如果出現(xiàn)并發(fā)類型狀態(tài)缺陷,會(huì)造成不同控制節(jié)點(diǎn)有不同的全局視圖的后果.在表6中,值得關(guān)注的是ONOS比ODL有更多的歷史并發(fā)類型狀態(tài)缺陷,這是因?yàn)镺NOS在設(shè)計(jì)之初即考慮了分布式的集群部署方式實(shí)現(xiàn),采用邏輯上集中控制實(shí)現(xiàn)分布式核心層.在ONOS缺陷管理工具中,報(bào)告者對(duì)于出現(xiàn)故障的表征更傾向于采用出現(xiàn)“狀態(tài)不一致”等文字描述,為了區(qū)別于4類典型并發(fā)缺陷,本文將這些缺陷歸類為并發(fā)類型狀態(tài)缺陷.例如,ONOS-4515中的數(shù)據(jù)平面轉(zhuǎn)發(fā)設(shè)備角色在3個(gè)集群節(jié)點(diǎn)間不同步,其中1個(gè)節(jié)點(diǎn)看到角色為“none”的5臺(tái)轉(zhuǎn)發(fā)設(shè)備,另外2個(gè)節(jié)點(diǎn)看到角色為“standby”的5臺(tái)轉(zhuǎn)發(fā)設(shè)備.為了讓SDN控制器網(wǎng)絡(luò)正常運(yùn)行,這些集群節(jié)點(diǎn)的狀態(tài)必須是一致的.

對(duì)于并發(fā)缺陷在功能模塊上的數(shù)量分布,由于ODL生態(tài)中包含了以控制器為核心的3個(gè)平面的缺陷報(bào)告集合,以O(shè)DL為例進(jìn)行分析.ODL控制器采用模塊化的設(shè)計(jì),不同子項(xiàng)目一般代表不同的功能模塊.參考ODL官方網(wǎng)站的信息(3)https://www.opendaylight.org,2021-04和現(xiàn)有研究[5],對(duì)ODL進(jìn)行功能模塊劃分,給出SDN控制器并發(fā)缺陷在功能模塊上的數(shù)量分布,如圖2所示.

圖2 ODL歷史并發(fā)缺陷在功能模塊上的分布特征Fig.2 Distribution of ODL historical concurrency bugs on functional modules

由圖2可以發(fā)現(xiàn),南向接口插件和控制器核心功能的并發(fā)缺陷數(shù)量較多.在SDN控制平面和數(shù)據(jù)平面南向交互過(guò)程中涉及了多個(gè)協(xié)議,如OVSDB、NETCONF和POF等,而使用協(xié)議通信實(shí)現(xiàn)平面間的交互,增加、修改、刪除和查看轉(zhuǎn)發(fā)設(shè)備的配置和狀態(tài)信息,對(duì)應(yīng)了多線程實(shí)現(xiàn)中的讀和寫(xiě)操作,容易引入并發(fā)缺陷.在與傳統(tǒng)網(wǎng)絡(luò)互聯(lián)的南向插件中,發(fā)生死鎖的情況使最多的,并且主要發(fā)生在3層網(wǎng)絡(luò)路由的相關(guān)功能中.另外,控制器通過(guò)南向協(xié)議下發(fā)配置策略中出現(xiàn)的并發(fā)缺陷同樣較為典型.例如,在通過(guò)NETCONF配置網(wǎng)絡(luò)的過(guò)程中,NETCONF-58只通過(guò)REST操作,當(dāng)刪除和初始化連續(xù)發(fā)生時(shí),出現(xiàn)了事務(wù)鏈上的數(shù)據(jù)競(jìng)爭(zhēng),導(dǎo)致事務(wù)鏈?zhǔn)?解決方法是修改操作的邏輯順序,首先應(yīng)該刪除配置而不是立即替換它,即,修改 POST>PUT 為POST>DELETE>POST.北向應(yīng)用出現(xiàn)并發(fā)缺陷的數(shù)據(jù)較少,主要是基于意圖通過(guò)流編程實(shí)現(xiàn)網(wǎng)絡(luò)配置更新過(guò)程中出現(xiàn)的順序違背(GBP-288).另外,在集群部署情況下,對(duì)于以多控制器為中心的東西向分布式協(xié)議的交互中,ODL具有多任務(wù)并發(fā)的特性,因此出現(xiàn)并發(fā)缺陷相關(guān)的問(wèn)題主要是在核心控制器功能模塊的集群(clustering)組件中.

通過(guò)以上分析發(fā)現(xiàn):數(shù)據(jù)競(jìng)爭(zhēng)仍是SDN控制器中最常出現(xiàn)的并發(fā)缺陷類型;由于分布式的部署方式,ONOS控制器中并發(fā)類型狀態(tài)缺陷出現(xiàn)較多;ODL控制器中南向接口插件和控制器核心功能的并發(fā)缺陷數(shù)量較多,集群組件是發(fā)現(xiàn)并發(fā)缺陷過(guò)程中值得關(guān)注的組件.

4.2.2 并發(fā)缺陷修復(fù)特征量化分析

本部分給出的數(shù)據(jù)和分析可以回答RQ2,給出SDN控制器并發(fā)缺陷的修復(fù)過(guò)程特征的分析,以及并發(fā)與非并發(fā)缺陷在修復(fù)過(guò)程特征上的區(qū)別分析.表7給出了在修復(fù)過(guò)程度量上的量化分析結(jié)果,包括:并發(fā)缺陷數(shù)據(jù)(CD)和非并發(fā)缺陷數(shù)據(jù)(NCD)集中趨勢(shì)分析的測(cè)度值,每個(gè)修復(fù)過(guò)程度量的分布在并發(fā)缺陷和非并發(fā)缺陷兩個(gè)分類上的Mann-Whitney U檢驗(yàn)的漸進(jìn)顯著性結(jié)果p值.為了可讀性和避免異常值,在計(jì)算統(tǒng)計(jì)值時(shí),去掉0值的影響,并且僅統(tǒng)計(jì)度量值是離散型數(shù)據(jù)(例如n_node)的眾數(shù).

表7 SDN控制器并發(fā)缺陷修復(fù)特征量化統(tǒng)計(jì)信息Table 7 Descriptive statistics of concurrency bugs for SDN controllers

通過(guò)定量方法來(lái)調(diào)查SDN控制器軟件中并發(fā)和非并發(fā)缺陷在修復(fù)過(guò)程的異同.對(duì)于表7具體分析如下:

1)時(shí)間因素的分析.與預(yù)先的設(shè)想并不相同,SDN控制器中修復(fù)并發(fā)缺陷和非并發(fā)缺陷所投入時(shí)長(zhǎng)的區(qū)別并不明顯.相比其他軟件,如Apache、ZooKeeper、 Spark 等開(kāi)源軟件中并發(fā)錯(cuò)誤平均修復(fù)時(shí)間(82天)[13],SDN控制器的并發(fā)缺陷的平均修復(fù)時(shí)間是66天左右,需要的修復(fù)時(shí)間更短.對(duì)于反映互動(dòng)頻率的度量t_acomm,雖然p=0.054,區(qū)別并不顯著,但是通過(guò)集中趨勢(shì)分析的測(cè)度值可以發(fā)現(xiàn),相對(duì)非并發(fā)缺陷而言,并發(fā)缺陷的平均討論時(shí)間間隔更短,報(bào)告者和開(kāi)發(fā)者互動(dòng)的頻率相對(duì)更高,對(duì)于SDN控制器,修復(fù)并發(fā)缺陷并不容易,需要通頻繁互動(dòng)補(bǔ)充必要的信息,例如觸發(fā)缺陷的配置及操作,可能的根因的討論等.

2)缺陷影響的分析.對(duì)于并發(fā)缺陷和非并發(fā)缺陷,影響節(jié)點(diǎn)數(shù)的度量n_node的區(qū)別顯著(p?0.05),因此,主要分析并發(fā)缺陷所影響的節(jié)點(diǎn)數(shù)目.SDN網(wǎng)絡(luò)中,在測(cè)試或生產(chǎn)部署的過(guò)程中,包括單控制器節(jié)點(diǎn)部署和控制器集群部署兩種方式.單控制器節(jié)點(diǎn)在開(kāi)發(fā)測(cè)試階段比較常見(jiàn),生產(chǎn)環(huán)境中多以集群方式進(jìn)行部署.并發(fā)缺陷影響的節(jié)點(diǎn)數(shù)目可以分為不同的情形:①只發(fā)生在單個(gè)SDN控制器節(jié)點(diǎn),尤其是在連接多臺(tái)交換機(jī)的單控制器擴(kuò)展性測(cè)試中出現(xiàn)并發(fā)缺陷的情形出現(xiàn)較多;②只發(fā)生在集群中,例如,BGPCEP-442是發(fā)生在集群(3節(jié)點(diǎn))中的數(shù)據(jù)競(jìng)爭(zhēng);③在單節(jié)點(diǎn)和集群中均發(fā)生,這類缺陷出現(xiàn)的情形最為普遍.但是受限于數(shù)據(jù)集來(lái)自于開(kāi)發(fā)階段的SDN控制器,節(jié)點(diǎn)觸發(fā)范圍的規(guī)模較小:多為1個(gè)節(jié)點(diǎn)(表7中眾數(shù)為1);涉及到控制器集群,多為3個(gè)節(jié)點(diǎn),例如,在ODL關(guān)于集群的并發(fā)缺陷報(bào)告中,以3節(jié)點(diǎn)集群測(cè)試?yán)鶊?bào)告的缺陷為主;最大為7個(gè)節(jié)點(diǎn)的情形.對(duì)于ONOS,在集群部署的情況下,即使一個(gè)缺陷只出現(xiàn)在一個(gè)節(jié)點(diǎn)上,它也會(huì)將其影響傳播到其他節(jié)點(diǎn)或組件,從而導(dǎo)致集群的一部分或整個(gè)集群失敗.對(duì)于非并發(fā)缺陷,節(jié)點(diǎn)數(shù)的影響并不明顯,集中趨勢(shì)分析中的多個(gè)測(cè)度值為0.

3)重要性和復(fù)雜度的分析.并發(fā)缺陷和非并發(fā)缺陷在優(yōu)先級(jí)上的區(qū)別并不顯著,但是在文本長(zhǎng)度和評(píng)論數(shù)上均區(qū)別顯著(p?0.05),并發(fā)缺陷仍然是SDN控制器項(xiàng)目投入更多關(guān)注的缺陷類型.

4)修復(fù)影響的分析.從表7中可以看到,在所給出的2個(gè)度量上,兩組數(shù)據(jù)均區(qū)別顯著.與修復(fù)非并發(fā)性缺陷相比,修復(fù)并發(fā)缺陷明顯涉及更多的補(bǔ)丁,有更多的修復(fù)影響版本,明顯需要開(kāi)發(fā)者投入更多工作量進(jìn)行修復(fù).

在SDN控制器中由于各平面的分離和分布式的部署方式,并發(fā)缺陷仍然需要關(guān)注.通過(guò)對(duì)比分析發(fā)現(xiàn):并發(fā)缺陷在修復(fù)過(guò)程中,需要通過(guò)配置特定節(jié)點(diǎn)數(shù)目的SDN控制器才能夠復(fù)現(xiàn);雖然并發(fā)缺陷并沒(méi)有賦予更高的優(yōu)先級(jí),但是需要開(kāi)發(fā)人員投入更多工作量進(jìn)行復(fù)現(xiàn)并修復(fù).這些發(fā)現(xiàn)可以為并發(fā)缺陷檢測(cè)和修復(fù)提供有用的指南.

4.3 有效性分析

對(duì)于實(shí)證研究需要討論數(shù)據(jù)身來(lái)源是否真實(shí)可靠的有效性以及所得結(jié)論是否具有推廣價(jià)值的有效性[21].由于所研究的缺陷是經(jīng)過(guò)真實(shí)項(xiàng)目的開(kāi)發(fā)團(tuán)隊(duì)成員的確認(rèn),設(shè)置狀態(tài)為“已關(guān)閉”或“已解決”的缺陷,并通過(guò)與提交代碼記錄的交叉對(duì)比,因此認(rèn)為是可以真實(shí)地反映實(shí)際缺陷情況的;其次,研究只關(guān)注ODL和ONOS兩個(gè)SDN控制器項(xiàng)目的缺陷數(shù)據(jù)量的相對(duì)關(guān)系,從這個(gè)意義上說(shuō),在一定程度上可以屏蔽在代碼規(guī)模和功能復(fù)雜程度的差異;第三,對(duì)于并發(fā)缺陷,基于關(guān)鍵字的搜索可能會(huì)遺漏一些真正的并發(fā)缺陷,但不包含任何所選關(guān)鍵字的并發(fā)缺陷報(bào)告極有可能沒(méi)有包含完整信息,對(duì)分析而言沒(méi)有用;第四,如4.1節(jié)所述,所選擇實(shí)例分析SDN控制器項(xiàng)目具有代表性,但是,由于ODL和ONOS是開(kāi)源項(xiàng)目,研究結(jié)果可能不適用于閉源的SDN控制器項(xiàng)目,未來(lái),需要更多的數(shù)據(jù)來(lái)支撐更可靠的結(jié)論.

5 結(jié) 語(yǔ)

本文提出了SDN控制器軟件并發(fā)缺陷量化分析方法框架,對(duì)SDN控制器軟件的并發(fā)缺陷進(jìn)行了實(shí)證量化分析.所提出的量化分析框架并不依賴于具體的SDN控制器軟件,因此方法具有一定的通用性,可以用于或適應(yīng)其他軟件系統(tǒng).基于軟件缺陷生命周期給出了4個(gè)維度10個(gè)具體度量作為并發(fā)缺陷修復(fù)過(guò)程的評(píng)估指標(biāo).采用統(tǒng)計(jì)學(xué)中的量化分析方法研究了SDN控制器并發(fā)性缺陷在不同類型并發(fā)缺陷和功能模塊的分布特征以及在所給出的修復(fù)過(guò)程度量所表現(xiàn)特征,可以為SDN控制器平臺(tái)使用者和基于平臺(tái)進(jìn)行應(yīng)用開(kāi)發(fā)的開(kāi)發(fā)者提供一個(gè)新的視角理解SDN控制器中出現(xiàn)的并發(fā)缺陷.也可以為SDN控制器的部署和后期維護(hù)提供便利支持更好地管理控制器應(yīng)用軟件產(chǎn)品,改善SDN控制器平臺(tái)的并發(fā)缺陷修復(fù)過(guò)程.