邊 寒 ,陳小紅 ,金 芝 ,張 民

1(上海市高可信計(jì)算重點(diǎn)實(shí)驗(yàn)室(華東師范大學(xué)),上海 200062)

2(北京大學(xué) 信息科學(xué)技術(shù)學(xué)院 計(jì)算機(jī)科學(xué)與技術(shù)系,北京 100871)

3(高可信軟件技術(shù)教育部重點(diǎn)實(shí)驗(yàn)室(北京大學(xué)),北京 100871)

物聯(lián)網(wǎng)(IoT)系統(tǒng)通過網(wǎng)絡(luò)連接的傳感器和執(zhí)行器監(jiān)視、調(diào)度、管理各種設(shè)備,如汽車、交通信號(hào)燈、空調(diào)、燈等,為用戶提供各種智能服務(wù)以滿足用戶服務(wù)需求,為用戶的日常生活提供便利.在這樣的系統(tǒng)中,用戶服務(wù)需求是智能服務(wù)的根本驅(qū)動(dòng)力.近年來提出的物聯(lián)網(wǎng)面向用戶編程框架,如IFTTT 和Microsoft Flow[1],就是這種背景下的產(chǎn)物.它們?cè)试S用戶使用簡(jiǎn)單的“IF trigger,THEN action(稱為觸發(fā)-命令編程,TAP)”規(guī)則編程.在圖1 所示的智能家居系統(tǒng)中,用戶可以編出這樣的規(guī)則:“如果光線亮度超過 50 000lux,則關(guān)上窗簾”,這個(gè)規(guī)則用TAP 描述為“IF Light.brightness>50000lux THEN close the blind”.但是,實(shí)際上這種TAP 句法描述的是設(shè)備調(diào)度程序,通知軟件去關(guān)窗簾,既不是用戶服務(wù)需求也不是系統(tǒng)行為,服務(wù)需求貼近用戶的需要,比如用戶想要窗簾關(guān)閉使得光線暗點(diǎn),系統(tǒng)行為貼近軟件,它關(guān)心軟件是否要發(fā)出關(guān)窗簾的脈沖的事件,但TAP 句法中的“action”是指通知軟件去關(guān)窗簾的指令,既不同于狀態(tài)“窗簾關(guān)閉”,也不同于事件“關(guān)窗簾的脈沖”.

一些物聯(lián)網(wǎng)系統(tǒng)提出采用面向目標(biāo)的需求方法,如文獻(xiàn)[2]使用領(lǐng)域模型和UML 圖來捕獲服務(wù)需求,支持服務(wù)目標(biāo)的分解,但沒有提出措施來保障物聯(lián)網(wǎng)不同服務(wù)間的一致性和服務(wù)部署的完整性,容易出現(xiàn)一致性和完整性問題.一致性問題是指有兩條或兩條以上的服務(wù)需求之間出現(xiàn)沖突[3,4],而完整性問題是指在某些情況下的輸入,軟件無法給出確切的輸出[5].對(duì)于軟件系統(tǒng)來說,任何由于不一致、不完整導(dǎo)致的差錯(cuò),都可能在現(xiàn)實(shí)世界中產(chǎn)生不良后果,甚至對(duì)用戶的財(cái)產(chǎn)、生命造成威脅[6].在物聯(lián)網(wǎng)系統(tǒng)中,使用TAP 進(jìn)行用戶編程時(shí),用戶并不會(huì)去考慮一致性、完整性問題,使得這些問題更加突出.例如,在一個(gè)智能家居軟件系統(tǒng)中,如果用戶規(guī)定當(dāng)一氧化碳的濃度高于一定閾值時(shí)自動(dòng)開窗,又規(guī)定下雨時(shí)自動(dòng)關(guān)窗,那么如果下雨時(shí)一氧化碳濃度過高,同時(shí)滿足這兩條需求,便會(huì)出現(xiàn)一致性問題,在這種情況下,房間的一氧化碳濃度可能會(huì)超過200mg/L,這是有害甚至致命的;再比如規(guī)定亮度低于一定閾值時(shí)開燈,但沒有規(guī)定高于這個(gè)閾值時(shí)的行為,那就會(huì)出現(xiàn)完整性問題,導(dǎo)致燈一直開著,嚴(yán)重浪費(fèi)能源.現(xiàn)在已有很多工作提供對(duì)TAP 規(guī)則的一致性的檢測(cè)與修復(fù)[7,8],但并沒有在服務(wù)需求層面和系統(tǒng)行為層面上的檢測(cè).

為了實(shí)現(xiàn)正確的“用戶編程”,本文提出在用戶提供的服務(wù)需求的基礎(chǔ)上,從服務(wù)需求中自動(dòng)推導(dǎo)系統(tǒng)行為,并檢測(cè)一致性和完整性,最后自動(dòng)轉(zhuǎn)換為TAP 形式的設(shè)備調(diào)度程序.在定義服務(wù)需求時(shí),基于環(huán)境建模的需求工程思想[9,10],本文認(rèn)為將服務(wù)需求指稱到設(shè)備的狀態(tài)變化上更合適,比如用戶希望的是燈滅了,而不關(guān)心用的是哪種行為使得燈關(guān)了.在從服務(wù)需求到系統(tǒng)行為的推導(dǎo)過程中,根據(jù)文獻(xiàn)[11],必須考慮到環(huán)境特性,在檢測(cè)一致性、完整性時(shí),也需從設(shè)備的角度去考慮,因此,本文提出基于環(huán)境建模的物聯(lián)網(wǎng)系統(tǒng)TAP 規(guī)則生成方法,實(shí)現(xiàn)了服務(wù)需求到程序的自動(dòng)化,主要貢獻(xiàn)包括:

(1) 建立了物聯(lián)網(wǎng)應(yīng)用場(chǎng)景的環(huán)境本體,提供了環(huán)境建模的基本概念和關(guān)聯(lián).針對(duì)物聯(lián)網(wǎng)應(yīng)用場(chǎng)景環(huán)境的特點(diǎn),定義了被監(jiān)視實(shí)體和被控制實(shí)體,并用屬性和狀態(tài)機(jī)對(duì)相應(yīng)特征進(jìn)行了建模;

(2) 給出了基于環(huán)境的用戶服務(wù)需求的定義,將服務(wù)需求指稱到狀態(tài)變化上,定義了基于環(huán)境本體的用戶服務(wù)需求描述方法;

Fig.1 An example of smart house圖1 智能家居的例子

(3) 定義了物聯(lián)網(wǎng)系統(tǒng)的需求一致性和完整性規(guī)則,基于環(huán)境本體使用問題圖[12]進(jìn)行服務(wù)需求到系統(tǒng)行為的自動(dòng)轉(zhuǎn)換,以及基于規(guī)則完成了需求的一致性與完整性的檢測(cè).

本文第1 節(jié)介紹系統(tǒng)行為推導(dǎo)中要使用的問題圖.第2 節(jié)定義物聯(lián)網(wǎng)系統(tǒng)的環(huán)境本體.第3 節(jié)給出本文的方法.第4 節(jié)給出關(guān)鍵算法.第5 節(jié)設(shè)計(jì)實(shí)驗(yàn),對(duì)本文方法進(jìn)行評(píng)估.第6 節(jié)比較相關(guān)工作.第7 節(jié)總結(jié)全文,展望未來工作.

1 預(yù)備知識(shí)

問題圖是問題框架方法[12]需求描述的結(jié)果,在本文中用來承載用戶服務(wù)需求和軟件行為.圖2 給出了問題圖的簡(jiǎn)單示例,軟件問題就是要指定一個(gè)待開發(fā)系統(tǒng)(控制機(jī)器controller machine)來監(jiān)視、控制問題領(lǐng)域(空氣air 和空調(diào)air conditioner),以滿足需求(調(diào)節(jié)溫度adjust temperature).問題領(lǐng)域與機(jī)器之間的連接稱為接口(一種交互),指明了它們之間共享的現(xiàn)象,如控制機(jī)器與空調(diào)之間共享現(xiàn)象開脈沖(OnPulse)和關(guān)脈沖(OffPulse).接口由一方發(fā)起,用“發(fā)起者!{內(nèi)容}”表示,內(nèi)容可以是現(xiàn)象中的事件、狀態(tài)或取值.需求表示為一段自然語言描述的期望,實(shí)際指稱為人們期望在問題領(lǐng)域上發(fā)生的改變,如期望室溫T>30,或者空調(diào)打開(on)或關(guān)閉(off)等,這種期望現(xiàn)象稱為需求現(xiàn)象.對(duì)那些只能觀察而無法控制的需求現(xiàn)象的引用稱為需求引用:如對(duì)于室溫,只能觀察、引用,而不能控制;而對(duì)那些可以控制的需求現(xiàn)象的約束稱為需求約束:如對(duì)于空調(diào),人們可以控制它的開關(guān).需求引用和需求約束都可以表示為接口交互的形式.

Fig.2 Simple example of a problem digram圖2 問題圖的簡(jiǎn)單示例

問題圖的左右兩邊分別承載了用戶服務(wù)需求和軟件行為.其中,用戶服務(wù)需求用需求現(xiàn)象及其之間的關(guān)系來描述,表示在問題圖右邊的需求引用和約束處.如圖2 中右邊虛線處a和c中的需求現(xiàn)象,要求當(dāng)溫度高于30°、低于20°時(shí),空調(diào)要處于打開和關(guān)閉狀態(tài),這是用戶需要的,是用戶的服務(wù)需求.軟件行為用規(guī)約現(xiàn)象及其現(xiàn)象之間的關(guān)系來描述,表示在問題圖左邊的接口處.如圖2 左邊實(shí)線接口a和b處,共享現(xiàn)象要求當(dāng)溫度高于30°時(shí),控制器發(fā)出開空調(diào)的脈沖,而溫度低于20°時(shí)則發(fā)出關(guān)空調(diào)的脈沖,這規(guī)定了軟件的系統(tǒng)行為.需要注意的是,在問題圖中,從用戶服務(wù)需求中導(dǎo)出軟件系統(tǒng)行為需要領(lǐng)域知識(shí),本文使用環(huán)境本體來描述這些領(lǐng)域知識(shí).

2 物聯(lián)網(wǎng)系統(tǒng)的環(huán)境本體

本體是共享概念模型的明確的形式化規(guī)范說明[13].我們定義環(huán)境本體來提供環(huán)境建模的基本概念和概念間的關(guān)聯(lián).根據(jù)是否領(lǐng)域相關(guān),將環(huán)境本體分為兩類:上層環(huán)境本體和領(lǐng)域環(huán)境本體.其中,上層環(huán)境本體描述通用的環(huán)境建模中的概念和關(guān)聯(lián),領(lǐng)域環(huán)境本體則是針對(duì)某個(gè)具體的領(lǐng)域的環(huán)境建模的結(jié)果,是對(duì)上層環(huán)境本體概念和關(guān)聯(lián)在特定領(lǐng)域中的實(shí)例化.

2.1 上層環(huán)境本體

物聯(lián)網(wǎng)系統(tǒng)的環(huán)境可以看作是與系統(tǒng)發(fā)生交互的一組實(shí)體(稱為環(huán)境實(shí)體)的集合,因此環(huán)境實(shí)體(environment entity)是環(huán)境本體中的最基本的概念.在具體的應(yīng)用場(chǎng)景中,智能家居中的燈、窗簾、人、空氣等都是環(huán)境實(shí)體.這些環(huán)境實(shí)體可以分為兩類.

(1) 被監(jiān)視的環(huán)境實(shí)體(monitored entity):這類環(huán)境實(shí)體僅可被物聯(lián)網(wǎng)系統(tǒng)以監(jiān)視的方式獲取其狀態(tài)值,但卻無法直接改變這些實(shí)體的狀態(tài),即,實(shí)體的狀態(tài)是自主變化,不以人的意志為轉(zhuǎn)移的.例如,智能家居中涉及到的室內(nèi)空氣、光照等;

(2) 被控制的環(huán)境實(shí)體(controlled entity):對(duì)于這類環(huán)境實(shí)體,不僅可以獲取其狀態(tài)值(即各項(xiàng)屬性值),而且可以向這些環(huán)境實(shí)體發(fā)送事先定義好的指令,以改變其狀態(tài).各種嵌入式設(shè)備均屬于該類實(shí)體,如智能家居中的日光燈、窗戶、電動(dòng)窗簾等.而它們的改變既可以是狀態(tài)也可以是屬性值,例如,燈既可以用“開、關(guān)”來描述,也可以用具體的亮度數(shù)值來描述.

對(duì)于每個(gè)環(huán)境實(shí)體,都可以用屬性(attribute)來描述其特性,每個(gè)屬性都有取值(value).比如被監(jiān)視的環(huán)境實(shí)體光線(light),它有屬性亮度,可以用Light.brightness表示,其取值代表光線亮度的大小;再如被控制的環(huán)境實(shí)體Bulb,它的屬性為BulbST,即燈的狀態(tài),其屬性值可以為bon或boff,表示燈的開關(guān)狀態(tài).除了屬性之外,還可以使用狀態(tài)機(jī)(state machine)來描述一些被控制實(shí)體的動(dòng)態(tài)特性,狀態(tài)機(jī)有狀態(tài)(state)、狀態(tài)變遷(transition),而狀態(tài)變遷由事件(event)觸發(fā).比如可以用帶有狀態(tài)bon、boff的狀態(tài)機(jī)描述燈的動(dòng)態(tài)特性,當(dāng)燈接收到開燈的脈沖(bonPulse)時(shí)狀態(tài)轉(zhuǎn)為bon,而當(dāng)燈接受到關(guān)燈的脈沖(boffPulse)時(shí)狀態(tài)轉(zhuǎn)為boff.

這些概念之間還存在著一定的關(guān)聯(lián).圖3 給出了這些概念之間的關(guān)聯(lián),這些關(guān)聯(lián)的含義見表1.

Fig.3 Concept association diagram of environment ontology圖3 環(huán)境本體的概念關(guān)聯(lián)圖

Table 1 Relations and meanings of concepts in environment ontology表1 環(huán)境本體概念關(guān)聯(lián)及其含義

2.2 智能家居的領(lǐng)域環(huán)境本體

以智能家居為例,我們來說明領(lǐng)域環(huán)境本體的構(gòu)造.首先識(shí)別領(lǐng)域中的環(huán)境實(shí)體.假設(shè)智能家居領(lǐng)域中包含的被控制環(huán)境實(shí)體有窗戶(window)、窗簾(blind)和燈(bulb),而被監(jiān)視環(huán)境實(shí)體有光照和空氣.這些都是環(huán)境實(shí)體的實(shí)例.窗戶的屬性為WindowST,描述窗戶的開閉,其取值為wopen或wclosed;窗簾的屬性為BlindST,描述窗簾的開閉,其取值是bopen或bclosed;燈的屬性為BulbST,描述燈的開關(guān),其取值是bon或boff;光照的屬性為brightness,表示亮度,其值在理論上可以是大于0 的任意值;空氣的屬性為溫度(temperature)和濕度(humidity),temperature表示氣溫,其值在理論上可以為–273.15 攝氏度到正無窮;humidity表示空氣的相對(duì)濕度,其值在理論上可以為0 到正無窮.這些具體的屬性和取值分別是屬性和值這兩個(gè)概念的實(shí)例.

對(duì)于每個(gè)被控制實(shí)體,需要進(jìn)一步識(shí)別其狀態(tài)機(jī).在智能家居領(lǐng)域中,窗戶、窗簾和燈的狀態(tài)機(jī)如圖4 所示,以燈為例,當(dāng)其處于bon狀態(tài)時(shí),表示燈開著,如果此時(shí)收到一個(gè)bonPulse事件,則繼續(xù)開著,如果收到boffPulse事件,則關(guān)閉;當(dāng)其處于boff狀態(tài)時(shí),表示燈關(guān)著,如果此時(shí)收到一個(gè)bonPulse事件,則燈打開,反之,如果收到boffPulse事件,則仍然關(guān)閉.這些都是狀態(tài)機(jī)、事件、狀態(tài)、遷移概念的具體實(shí)例.

Fig.4 State machine of controlled environment ontology in smart home systems圖4 智能家居系統(tǒng)的被控制環(huán)境實(shí)體的狀態(tài)機(jī)圖

3 本文方法

在環(huán)境本體的支持下,本文提出了生成TAP 規(guī)則的方法框架,如圖5 所示.在用戶撰寫服務(wù)需求后,首先借助環(huán)境本體對(duì)系統(tǒng)行為進(jìn)行推導(dǎo),得到初始問題圖,然后對(duì)其進(jìn)行一致性、完整性檢測(cè).若通過檢測(cè),則將檢測(cè)后的問題圖結(jié)合現(xiàn)象指令對(duì)照表生成TAP 規(guī)則,否則返回給用戶修改服務(wù)需求.

Fig.5 Architecture of our approach圖5 本文方法框架

3.1 用戶服務(wù)需求的撰寫

首先,我們來定義用戶的服務(wù)需求.本文基于環(huán)境建模思想,將服務(wù)需求指稱到環(huán)境實(shí)體變化上,在物聯(lián)網(wǎng)系統(tǒng)中,環(huán)境實(shí)體的變化通常表現(xiàn)為環(huán)境實(shí)體的不同狀態(tài).例如,在下雨時(shí),窗戶要處于關(guān)閉這一狀態(tài).沿用但區(qū)別于TAP 規(guī)則的“IF trigger THEN action”句法,本文將使用如下句法以供用戶表達(dá)服務(wù)需求.

其中,

· entity.trigger 有如下表達(dá)方式.

? 當(dāng)entity 為被監(jiān)視的環(huán)境實(shí)體時(shí),使用entity.attribute 表示實(shí)體的屬性取某個(gè)值或?qū)儆谀骋环秶?例如,光照為3 000lux,則寫作Light.brightness=3000,而光照大于3 000lux,則寫作Light.brightness>3000(為了自動(dòng)化流程考慮,僅使用數(shù)值,省略單位);

? 當(dāng)entity 為被控制的環(huán)境實(shí)體時(shí),可以使用entity.state 表示實(shí)體處于某個(gè)狀態(tài),如Window.wclosed表示窗戶處于關(guān)閉狀態(tài),也可以是entity.attribute,其表達(dá)方式與上一條類似;

? 另外,trigger 可以是帶有與、或操作符的復(fù)雜句子,其中,與關(guān)系用&&表示,或關(guān)系用符號(hào)||表示.

· entity.state 為被控制的環(huán)境實(shí)體及其狀態(tài).

例如,如果用戶想表達(dá)當(dāng)光線的亮度大于50 000lux 時(shí)窗簾處于關(guān)閉狀態(tài),則觸發(fā)條件中的實(shí)體為光線,是被監(jiān)視實(shí)體,亮度大于50 000lux 即光線的屬性“亮度”大于50 000lux,因此,這個(gè)服務(wù)需求的entity.trigger 就是Light.brightness>50000;為了表達(dá)窗簾處于關(guān)閉狀態(tài),entity.state 就是Blind.bclosed,因此,這條服務(wù)需求為“IFLight.brightness>50000THENBlind.bclosed”.而如果用戶想表達(dá)當(dāng)窗簾關(guān)閉時(shí)燈打開的服務(wù)需求,實(shí)體為窗簾,是被控制實(shí)體,而trigger,即窗簾關(guān)閉的狀態(tài),就是bclosed,因此,這個(gè)服務(wù)需求的entity.trigger 就是Blind.bclosed;為了表達(dá)開燈,entity.state 就是Bulb.bon,因此,這條服務(wù)需求為“IFBlind.bclosedTHENBulb.bon”.

對(duì)于復(fù)雜的服務(wù)需求,即含有與或關(guān)系的需求,也采用同樣的處理方式.例如,想要表達(dá)當(dāng)氣溫高于25°且亮度大于25 000lux 時(shí)窗戶處于打開狀態(tài),這個(gè)服務(wù)需求有兩個(gè)觸發(fā)條件,涉及兩個(gè)被監(jiān)視實(shí)體:空氣和光線,觸發(fā)條件則分別是空氣的屬性溫度大于25°和光線的屬性亮度大于25 000lux,因此,這條需求的前半部分是Air.temperature>25 和Light.brightness>25000 的與;而entity.state 就是窗戶要處于打開狀態(tài),即Window.wopen,因此,這條需求為“IFAir.temperature>25 &&Light.brightness>25000 THENWindow.wopen”.

另外,在用戶書寫服務(wù)需求時(shí)就需要引入環(huán)境本體,讓用戶選擇相應(yīng)的設(shè)備,而不是隨便寫.這么做的好處在于:大多數(shù)用戶并不熟悉所有設(shè)備的性能和效果,如果讓用戶毫無限制地書寫需求,將會(huì)造成大量因不熟悉設(shè)備而造成的錯(cuò)誤或遺漏.而環(huán)境本體中包含了各個(gè)設(shè)備及其狀態(tài)、效果,使用環(huán)境本體能夠在用戶書寫服務(wù)需求時(shí)提示他們?cè)O(shè)備的效果,防止用戶寫出一些荒謬的服務(wù)需求,從而減少后期檢測(cè)與修改的工作量.

3.2 系統(tǒng)行為的推導(dǎo)

系統(tǒng)行為的推導(dǎo)分為兩步.

第1 步,將第3.1 節(jié)定義的服務(wù)需求標(biāo)記到問題圖中.每一條服務(wù)需求都能對(duì)應(yīng)一個(gè)問題圖,其中的信息可以定義問題圖的右邊部分.具體的對(duì)應(yīng)如下所示:首先是環(huán)境實(shí)體與問題領(lǐng)域的對(duì)應(yīng),在“IF 〈entity.trigger〉THEN 〈entity.state〉”中,entity 就是與系統(tǒng)交互的環(huán)境實(shí)體,它們就是問題圖的問題領(lǐng)域,就像圖6 中的服務(wù)需求“IFAir.temperature>30 THENWindow.wopen”的Air和Window可以直接轉(zhuǎn)換成問題領(lǐng)域Air和Window.其次,trigger 和state 與需求引用和約束中的現(xiàn)象相對(duì)應(yīng),trigger 作為需求的條件,表示對(duì)需求的引用,可以直接畫為需求引用,而state 則是用戶期望看到的現(xiàn)象,是對(duì)需求的約束,可以直接畫為需求約束,現(xiàn)象發(fā)起者應(yīng)該是其前面的entity.如圖6 中Air.temperature>30 就可以直接轉(zhuǎn)為需求引用Air!{temperature>30},Window.wopen可以直接轉(zhuǎn)為需求約束Window!{wopen}.橢圓形需求里面直接標(biāo)注標(biāo)號(hào)即可,如圖6 中的Req1.

第2 步則需要根據(jù)環(huán)境本體推導(dǎo)相應(yīng)的系統(tǒng)行為,即定義問題圖的左邊接口部分.對(duì)于簡(jiǎn)單服務(wù)需求,即entity.trigger 中沒有與或關(guān)系的,考慮trigger 和state 的不同實(shí)體類型,分別加以處理.

· 無論entity.trigger 中的entity 是被監(jiān)視實(shí)體還是被控制實(shí)體,都將需求引用中的條件直接拷貝過來,就像圖6 中的M和Air之間的接口.

· 對(duì)于entity.state 中的實(shí)體,則需要通過其狀態(tài)機(jī),查找觸發(fā)狀態(tài)state 的事件,將其作為共享現(xiàn)象放在接口中,而且這個(gè)接口必須是軟件發(fā)出的,如圖6 所示,Window狀態(tài)機(jī)里的狀態(tài)wopen的觸發(fā)事件為wopenPulse,則接口就可以定義為M!{wopenPulse}.

而針對(duì)包含與或關(guān)系的復(fù)雜用戶服務(wù)需求,其處理可如下所示.

· 如果是與關(guān)系連接了多個(gè)entity.trigger,則對(duì)于每一個(gè)entity.trigger,該entity 對(duì)應(yīng)的問題領(lǐng)域都要與需求通過需求引用相連,然后在需求引用上根據(jù)trigger 添加需求現(xiàn)象;

· 如果是或關(guān)系連接,即“IFa||bTHENentity.state”形式的需求,則表示若a發(fā)生或者b發(fā)生,entity 都應(yīng)該處于state 狀態(tài),那么若將a和b拆開,使得這條需求變?yōu)閮蓷l,即“IFaTHENentity.state”和“IFbTHENentity.state”,其代表的含義也是一樣的.比如“IFAir.temperature<25||Air.humidity>25 THENWindow.wclosed”,就可以拆為“IFAir.temperature<25 THENWindow.wclosed”和“IFAir.humidity>25 THENWindow.wclosed”.因此,對(duì)這種帶有或關(guān)系的需求,我們將其拆解為兩句,分別轉(zhuǎn)換為問題圖.

Fig.6 Schematic diagram of problem diagram generation圖6 問題圖生成的示意圖

3.3 一致性與完整性的檢測(cè)

我們從環(huán)境實(shí)體的角度來定義不一致與不完整,在常規(guī)的服務(wù)需求不一致的定義的基礎(chǔ)上,根據(jù)trigger 和state 的不同情況,本文考慮3 種類型的需求不一致.

(1) 范圍不一致:超過一條需求的trigger 中的范圍有交集,而它們的state 實(shí)體相同,內(nèi)容不同,導(dǎo)致需求發(fā)生沖突.例如,智能家居系統(tǒng)的用戶規(guī)定“IFLight.brightness<30000 THENWindow.wclosed”和“IFLight.brightness>15000 THENWindow.wopen”,那么,當(dāng)亮度處于15 000lux 到30 000lux 之間時(shí),這兩條需求同時(shí)作用在窗戶上,但state 正好相反,從而導(dǎo)致了范圍不一致的情況;

(2) 與或不一致:一條需求中trigger 復(fù)雜的與、或關(guān)系所導(dǎo)致上午不一致.例如,如果用戶規(guī)定“IF (Air.temperature>25 &&Light.brightness>25000)&&(Air.temperature<25 &&Air.humidity<30)THENWindow.wopen”,該需求前半句要求溫度高于25°而后半句要求溫度低于25°,使用與連接說明需要同時(shí)滿足這兩個(gè)條件,因此這是永遠(yuǎn)也無法達(dá)到的,從而導(dǎo)致了與或的不一致.

(3) 覆蓋不一致:多條需求state 中的實(shí)體相同、內(nèi)容不同,于是不同的trigger 導(dǎo)致后執(zhí)行的state 覆蓋了先執(zhí)行的state.例如,一條需求要求亮度大于20 000lux 時(shí)燈處于關(guān)閉狀態(tài),而另一條需求要求窗簾關(guān)閉時(shí)燈處于打開狀態(tài),假如亮度大于20 000lux 時(shí),窗簾關(guān)上了,那么此時(shí)根據(jù)需求2,燈應(yīng)該是打開的,于是開燈的狀態(tài)覆蓋了關(guān)燈的狀態(tài),但其實(shí)此時(shí)亮度仍然大于20 000lux,根據(jù)需求1,燈應(yīng)該是關(guān)閉的,從而導(dǎo)致覆蓋不一致的情況.

從服務(wù)需求的定義出發(fā),根據(jù)環(huán)境實(shí)體的性質(zhì),本文考慮如下兩種需求不完整的情況.

(1) 狀態(tài)不完整:將所有服務(wù)需求對(duì)應(yīng)的問題圖合并起來,它們并沒有涉及到環(huán)境本體中所有實(shí)體的所有狀態(tài),從而導(dǎo)致需求的不完整.例如,在一組需求中,只有窗簾狀態(tài)為開的情況,卻并沒有使得窗簾狀態(tài)為關(guān)的情況(即Blind.bclosed),而這是不完整的;

(2) 屬性不完整:所有需求的trigger 并沒有覆蓋到對(duì)應(yīng)實(shí)體屬性可達(dá)的全部范圍,導(dǎo)致在某些情況下無法準(zhǔn)確地判斷實(shí)體該處于的狀態(tài).例如,兩條需求分別規(guī)定了Light.brightness>20000 與Light.brightness<15000 時(shí)燈應(yīng)該處于打開和關(guān)閉的狀態(tài),但當(dāng)亮度處于15 000lux 和20 000lux 中間情況時(shí),是否應(yīng)該保持上一時(shí)刻的狀態(tài)?還是根據(jù)一些其他標(biāo)準(zhǔn)來決定是否改變燈的狀態(tài)?這在燈的服務(wù)需求中并沒有提到,因此這是不完整的.

3.4 TAP規(guī)則的生成

TAP 規(guī)則的生成分為兩個(gè)階段.

(1) 從問題圖生成系統(tǒng)行為:根據(jù)檢測(cè)過的問題圖,首先確定問題圖中的問題領(lǐng)域中是對(duì)應(yīng)需求引用還是需求約束,若為引用,則其問題領(lǐng)域的接口對(duì)應(yīng)IF 里面的內(nèi)容,如果有多個(gè)引用,則使用“&&”進(jìn)行連接;若為約束,則其問題領(lǐng)域的接口對(duì)應(yīng) THEN 里面的內(nèi)容.如圖 7 所示,問題領(lǐng)域Air是需求引用,則其接口“Air!{temperature>30}”為IF 里的內(nèi)容,而問題領(lǐng)域Window對(duì)應(yīng)的是需求約束,則其接口“M!{wopenPulse}”為THEN里的內(nèi)容,由此生成系統(tǒng)行為:IFAir.temperature>30 THENM.wopenPulse,但這并不是最終的TAP 規(guī)則.

(2) 從系統(tǒng)行為到TAP 規(guī)則:將系統(tǒng)行為與現(xiàn)象指令對(duì)照表中的相關(guān)條目進(jìn)行對(duì)照后才能生成最終的TAP規(guī)則.其中,現(xiàn)象指令對(duì)照表是一組軟件行為與指令的對(duì)應(yīng)關(guān)系,如圖7 所示,wopenPulse對(duì)應(yīng)指令open the window,這個(gè)對(duì)照表可以由設(shè)備領(lǐng)域?qū)＜姨峁?將系統(tǒng)行為中的“M.wopenPulse”替換為指令open the window,就可以得到TAP 規(guī)則“IFAir.temperature>30 THENopen the window”.

Fig.7 Schematic diagram of generating TAP rules圖7 TAP 規(guī)則生成示意圖

4 關(guān)鍵算法

為了實(shí)現(xiàn)第3 節(jié)中提出的方法,我們開發(fā)了TAP 規(guī)則生成工具,可以通過http://re4cps.org/dsigs 對(duì)其進(jìn)行訪問,相應(yīng)的視頻demo 在http://re4cps.org/examples#DSIGS 給出.本節(jié)給出一些關(guān)鍵算法,主要包括:服務(wù)需求轉(zhuǎn)換為問題圖的算法、一致性檢測(cè)算法和完整性檢測(cè)算法以及TAP 生成算法.

4.1 服務(wù)需求轉(zhuǎn)換為問題圖的算法

服務(wù)需求轉(zhuǎn)換為問題圖算法就是要實(shí)現(xiàn)第3.2 節(jié)中提到的系統(tǒng)行為的推導(dǎo),該算法的主要思路是:首先處理服務(wù)需求中的與、或關(guān)系,然后對(duì)于每一條服務(wù)需求,依照第3.2 節(jié)所述的對(duì)應(yīng)關(guān)系,根據(jù)服務(wù)需求構(gòu)建問題圖的問題領(lǐng)域和引用,最后借助環(huán)境本體構(gòu)建問題圖的接口.

具體步驟如算法1 所示.其中,第5 行～第7 行對(duì)服務(wù)需求中的與、或關(guān)系進(jìn)行預(yù)處理,第9 行～第13 行循環(huán)遍歷需求的entity.trigger(如果沒有與關(guān)系連接多個(gè)entity.trigger,則循環(huán)只進(jìn)行1 次),構(gòu)建與trigger 有關(guān)的問題領(lǐng)域、需求引用和接口,第14 行～第16 行則處理entity.state,構(gòu)建與其有關(guān)的問題領(lǐng)域、需求約束和接口.假設(shè)服務(wù)需求的總條數(shù)為n,算法中有兩個(gè)循環(huán),均與n有關(guān),因此該算法的時(shí)間復(fù)雜度為O(n2).

算法1.服務(wù)需求轉(zhuǎn)換為問題圖.

輸入:所有服務(wù)需求reqs,環(huán)境本體eo;

輸出:問題圖集合ProDgms={prodgm1,prodgm2,...,prodgmn}.

4.2 一致性檢測(cè)算法與完整性檢測(cè)算法

根據(jù)第3.3 節(jié)給出的一致性和完整性定義,我們?cè)O(shè)計(jì)需求的一致性檢測(cè)算法和完整性檢測(cè)算法.一致性檢測(cè)算法的主要思路是:首先根據(jù)問題圖的需求引用和需求約束,獲取所有的(trigger,state)對(duì);然后檢測(cè)實(shí)體相同的state 對(duì)應(yīng)的trigger 是否有重合,從而檢測(cè)范圍不一致和覆蓋不一致,將不一致的需求反饋給用戶;最后根據(jù)(trigger,state)對(duì)中的trigger 檢測(cè)是否發(fā)生與或不一致,如果發(fā)生,則將對(duì)應(yīng)的需求反饋給用戶.

一致性檢測(cè)算法的具體步驟如算法2 所示,算法第2 行抽取所有問題圖中的(trigger,state)對(duì),第3 行構(gòu)造entityMap 存放實(shí)體相同、內(nèi)容不同的state 對(duì)應(yīng)的trigger,根據(jù)entityMap,第4 行～第17 行的循環(huán)檢測(cè)范圍不一致與覆蓋不一致,第18 行～第29 行的循環(huán)則根據(jù)所有trigger 檢測(cè)與或不一致,檢測(cè)過程中如果出現(xiàn)了不一致,則輸出不一致的需求,算法返回false,若沒有不一致,則算法最終返回true.算法中最深的嵌套循環(huán)有3 個(gè),但2 個(gè)循環(huán)都執(zhí)行常數(shù)次,因此,算法2 的時(shí)間復(fù)雜度是O(n).

為了獲取需求引用包含的所有trigger 及對(duì)應(yīng)的state,本文設(shè)計(jì)了resolveProDgm函數(shù)來抽取所有問題圖中的(trigger,state)對(duì),其具體步驟如算法3 所示,算法第3 行遍歷所有問題圖中的需求,第7 行～第9 行的循環(huán)讀取需求引用中的現(xiàn)象,獲取trigger,第10 行讀取需求約束中的現(xiàn)象,獲取state.假設(shè)需求的條數(shù)為n,算法的時(shí)間復(fù)雜度為O(n).

完整性檢測(cè)算法的主要思路是:首先抽取所有問題圖中的(trigger,state)對(duì);然后將涉及到的所有state 與環(huán)境本體對(duì)比,檢測(cè)狀態(tài)不完整,將沒有涉及到的狀態(tài)反饋回用戶;最后根據(jù)擁有相同實(shí)體的state 對(duì)應(yīng)的trigger,檢測(cè)屬性不完整,將沒有覆蓋到的情況反饋回用戶.其主要步驟如算法4 所示.算法的2 行調(diào)用resolveProDgm函數(shù),獲取了所有的(trigger,state)對(duì),第4 行～第6 行的循環(huán)初始化states,第7 行～第13 行根據(jù)states 和環(huán)境本體檢測(cè)狀態(tài)不完整,第14 行～第24 行的循環(huán)則檢測(cè)屬性不完整.假設(shè)需求數(shù)量為n,算法4 的第2 行用到了resolveProDgm函數(shù),其時(shí)間復(fù)雜度為O(n),而之后的循環(huán)都只有1 層,最多只循環(huán)n次,因此該算法的時(shí)間復(fù)雜度為O(n).

4.3 TAP規(guī)則生成算法

根據(jù)第3.4 節(jié)TAP 規(guī)則的生成方法,可以設(shè)計(jì)具體生成算法,其主要思路為:首先根據(jù)問題圖需求引用對(duì)應(yīng)接口中的內(nèi)容,確定TAP 規(guī)則的trigger;然后根據(jù)問題圖需求約束對(duì)應(yīng)的接口,構(gòu)建系統(tǒng)行為;最后根據(jù)現(xiàn)象指令對(duì)照表,獲取現(xiàn)象對(duì)應(yīng)的指令,將系統(tǒng)行為轉(zhuǎn)換為TAP 規(guī)則.

算法的主要步驟如算法5 所示.第2 行遍歷所有檢測(cè)后的問題圖,第6 行獲取所有需求引用對(duì)應(yīng)的問題領(lǐng)域,第7 行～第10 行的循環(huán)獲取這些問題領(lǐng)域?qū)?yīng)接口中的現(xiàn)象,作為TAP 規(guī)則的trigger,第10 行為系統(tǒng)行為,第11 行根據(jù)映射table(即現(xiàn)象指令對(duì)照表)將系統(tǒng)行為轉(zhuǎn)換為對(duì)應(yīng)的指令.假設(shè)需求條數(shù)為n,嵌套的2 個(gè)循環(huán),即第6 行的循環(huán)執(zhí)行常數(shù)次,因此,該算法的時(shí)間復(fù)雜度為O(n).

算法2.一致性檢測(cè)算法.

輸入:問題圖集合ProDgms={prodgm1,prodgm2,..,prodgmn};

輸出:是否滿足一致性以及不滿足一致性的需求.

算法3.resolveProDgm:解析問題圖,抽取所有trigger 與state.

輸入:問題圖集合ProDgms={prodgm1,prodgm2,...,prodgmn};

輸出:ProDgms 中的所有(trigger,state)對(duì),將其存放在映射map 中.

5 方法評(píng)估

以智能會(huì)議室系統(tǒng)為背景,本節(jié)對(duì)本文方法進(jìn)行評(píng)估,主要回答以下幾個(gè)問題.

(1) 本方法的準(zhǔn)確性和效率如何?與人工編寫TAP 規(guī)則相比,使用本文方法制定TAP 規(guī)則會(huì)有更高的準(zhǔn)確性和效率嗎?

(2) 本方法的性能如何?是否適用大規(guī)模系統(tǒng)?

(3) 環(huán)境本體的構(gòu)建時(shí)間是否對(duì)方法的使用造成影響?

算法4.完整性檢測(cè)算法.

輸入:問題圖集合ProDgms={prodgm1,prodgm2,...,prodgmn},環(huán)境本體eo;

輸出:是否滿足完整性,若不滿足,則輸出為何不滿足.

算法5.TAP 生成算法.

輸入:檢測(cè)后的問題圖集合ProDgms={prodgm1,prodgm2,...,prodgmn},現(xiàn)象指令對(duì)照表table;

輸出:TAP 規(guī)則集合rules.

5.1 準(zhǔn)確性與效率

為了回答這個(gè)問題,我們?cè)O(shè)計(jì)了一系列對(duì)比實(shí)驗(yàn):首先將用戶分為兩組:本方法組和TAP 組.本方法組首先書寫服務(wù)需求,然后通過本文方法,在進(jìn)行一致性、完整性的檢測(cè)和修改后,生成TAP 規(guī)則;而TAP 組則由人工直接編寫TAP 規(guī)則,并對(duì)其進(jìn)行一致性、完整性的檢測(cè)和修改.為了避免用戶背景造成的差異,我們又將用戶分為兩類:專業(yè)類和非專業(yè)類.其中,專業(yè)用戶為軟件工程在讀的學(xué)生,他們參加過一些與需求相關(guān)的課題,有一定的需求工程方面的知識(shí);非專業(yè)用戶為旅游經(jīng)濟(jì)學(xué)、醫(yī)學(xué)或語言學(xué)專業(yè)的學(xué)生,沒有任何計(jì)算機(jī)或軟件工程方面的學(xué)科知識(shí).由此,本方法組和TAP 組又分別分為兩個(gè)對(duì)照組,共4 組實(shí)驗(yàn).我們總共邀請(qǐng)了24 名用戶,每組各6 名.

我們請(qǐng)每個(gè)用戶對(duì)一個(gè)限定的物聯(lián)網(wǎng)場(chǎng)景書寫10 條需求,規(guī)定該場(chǎng)景中的實(shí)體只有空氣、光線、人、窗戶、窗簾、投影儀、空調(diào)和燈,空氣有溫度和濕度兩個(gè)屬性,光線有亮度屬性,人可以按下投影儀的開關(guān),窗戶和窗簾有open和closed的狀態(tài),投影儀和燈有on和off的狀態(tài),而空調(diào)的狀態(tài)則可以是cold、hot和off.對(duì)于專業(yè)的本方法組,我們告知他們書寫需求的格式、環(huán)境中的實(shí)體以及實(shí)體的狀態(tài)取值;對(duì)于非專業(yè)的本方法組,由于對(duì)領(lǐng)域知識(shí)沒有了解,我們直接告訴他們需求句式IF entity.trigger THEN entity.state 中,entity.trigger 和entity.state 的可填內(nèi)容;對(duì)于專業(yè)的TAP 組,我們告知他們編寫規(guī)則的格式、環(huán)境中的實(shí)體以及實(shí)體的狀態(tài)取值,讓他們推測(cè)環(huán)境本體中的指令;對(duì)于非專業(yè)的TAP 組,我們直接告訴他們規(guī)則句式IF entity.trigger THEN action 中entity.trigger 和action 的可填內(nèi)容.對(duì)于兩個(gè)TAP 組,在編寫完規(guī)則后,告訴他們一致性、完整性的定義,并要求他們對(duì)自己編寫的規(guī)則進(jìn)行手動(dòng)檢測(cè)和修改.

在每組實(shí)驗(yàn)中,我們分別統(tǒng)計(jì)本方法組用戶書寫需求所花費(fèi)的時(shí)間,本方法組用戶檢測(cè)和修改需求使其滿足一致性與完整性花費(fèi)的時(shí)間,TAP 組用戶編寫規(guī)則所花費(fèi)的時(shí)間,TAP 組用戶人工進(jìn)行一致性與完整性檢測(cè)所花費(fèi)的時(shí)間,TAP 組用戶修改規(guī)則花費(fèi)的時(shí)間,所有用戶修改前、后的一致性、完整性錯(cuò)誤數(shù)以及所有用戶最終得到的TAP 規(guī)則的準(zhǔn)確率.在實(shí)際記錄時(shí),兩個(gè)本方法組由于使用計(jì)算機(jī)程序自動(dòng)地對(duì)一致性、完整性進(jìn)行檢測(cè),因此檢測(cè)時(shí)間很短,在總時(shí)間中,我們忽略了這些檢測(cè)時(shí)間.最終實(shí)驗(yàn)結(jié)果見表2.

從表2 中可以得出如下結(jié)論:本方法的準(zhǔn)確率和效率確實(shí)超過可用閾值.首先,觀察修改前、后的不一致和不完整數(shù)量可以發(fā)現(xiàn),相比于TAP 組手動(dòng)檢測(cè)和修改錯(cuò)誤,使用本方法進(jìn)行檢測(cè)和修改大大減少了錯(cuò)誤的數(shù)量,而對(duì)比表中各個(gè)組的最后一行可以發(fā)現(xiàn),無論是專業(yè)組還是非專業(yè)組,使用本方法得到的TAP 規(guī)則的準(zhǔn)確率普遍高于TAP 組;其次,對(duì)比表中各個(gè)組的前4 行,即與時(shí)間相關(guān)的數(shù)據(jù)可以發(fā)現(xiàn),無論是專業(yè)組還是非專業(yè)組,盡管本方法組書寫需求花費(fèi)的時(shí)間普遍超出TAP 組直接編寫規(guī)則的時(shí)間,但在對(duì)其進(jìn)行一致性、完整性的檢測(cè)與修改后,本方法組花費(fèi)的總時(shí)間基本上都低于TAP 組.由此我們可以回答問題1,與人工編寫TAP 規(guī)則相比,使用本文方法生成的TAP 規(guī)則確實(shí)有更高的準(zhǔn)確性和效率.

Table 2 Result of user study表2 調(diào)研結(jié)果

本方法對(duì)非專業(yè)用戶更有用.無論是花費(fèi)的總時(shí)間,還是最終的準(zhǔn)確率,在非專業(yè)組中,本方法組都要明顯好于TAP 組.原因在于,專業(yè)組的用戶由于擁有比較豐富的背景知識(shí),在進(jìn)行人工的一致性、完整性檢測(cè)時(shí)也能做到比較高的準(zhǔn)確率,所以這一現(xiàn)象在專業(yè)組并不十分明顯,但這在非專業(yè)組則非常明顯.由此我們認(rèn)為,與人工組相比,使用本文的方法,對(duì)非專業(yè)用戶來說確實(shí)更友好.

我們還注意到,同一組中不同用戶的書寫時(shí)間與最終準(zhǔn)確率也可能有較大的差異,造成這種差異的原因有二.

其一,用戶所書寫的需求、編寫的規(guī)則其復(fù)雜程度不同,導(dǎo)致準(zhǔn)確率有所不同.如一些用戶書寫的需求或規(guī)則的trigger 都不包含與、或連接符,也不包含受控制實(shí)體的狀態(tài),僅包含受感知實(shí)體的屬性值,這樣的需求或規(guī)則就比較簡(jiǎn)單,能夠?qū)懗鲚^高的準(zhǔn)確率;而另外一些用戶則執(zhí)著于復(fù)雜的需求,這就導(dǎo)致錯(cuò)誤較多.

其二,其他領(lǐng)域知識(shí)的差異導(dǎo)致了書寫時(shí)間上的差別.例如,同樣學(xué)習(xí)軟件工程并對(duì)需求工程有一定認(rèn)識(shí),一名專業(yè)用戶僅花費(fèi)了12 分鐘便寫完了程序,而另一名專業(yè)用戶卻花費(fèi)了30 分鐘才寫完需求,經(jīng)過詢問發(fā)現(xiàn),其對(duì)光照的單位勒克斯(lux)和相對(duì)濕度沒有概念,因此花費(fèi)了較多時(shí)間查閱資料才完成了需求撰寫.由此可見,盡管專業(yè)背景差距不大,但其他一些影響因素,如生活經(jīng)驗(yàn)、其他領(lǐng)域的知識(shí)等,也會(huì)導(dǎo)致評(píng)估的結(jié)果出現(xiàn)波動(dòng).

與人們普遍認(rèn)知不同,專業(yè)組一些用戶的最終準(zhǔn)確率無法達(dá)到100%,且專業(yè)組的書寫時(shí)間大都比非專業(yè)組更長(zhǎng).我們探究了其中的原因,準(zhǔn)確率無法達(dá)到100%是因?yàn)樗麄兯鶎懙囊恍┬枨蟊M管沒有違反一致性、完整性,但需求本身卻是錯(cuò)誤的.例如,一名專業(yè)用戶寫的需求“IFAir.humidity>45 THENWindow.open”,當(dāng)空氣濕度大于一定數(shù)值(下雨了)時(shí)窗戶處于打開狀態(tài),這是背離生活實(shí)際的,因此這是一條沒有違反一致性、完整性,但卻錯(cuò)誤的需求;專業(yè)組平均花費(fèi)更長(zhǎng)的時(shí)間是因?yàn)閷I(yè)組擁有更多的背景知識(shí),在書寫需求時(shí)有更多的考量,而非專業(yè)組則完全憑借實(shí)際經(jīng)驗(yàn).

5.2 性 能

本節(jié)對(duì)本文方法的自動(dòng)化流程進(jìn)行性能分析.我們?cè)O(shè)計(jì)了5 組實(shí)驗(yàn),分別評(píng)估服務(wù)需求轉(zhuǎn)換為問題圖的算法、一致性檢測(cè)算法、完整性檢測(cè)算法、TAP 生成算法以及整個(gè)本文方法的性能.對(duì)于每組實(shí)驗(yàn),本文都設(shè)計(jì)了10 個(gè)實(shí)驗(yàn),分別對(duì)10 條、30 條、50 條、100 條、200 條、300 條、500 條、800 條、1 000 條、1 200 條需求運(yùn)行算法,并記錄了所花費(fèi)的時(shí)間.本文的實(shí)驗(yàn)環(huán)境為64 位Win10 系統(tǒng),Intel(R) Core(TM) i7-9700k CPU @3.60 GHZ,32 G RAM.

每個(gè)實(shí)驗(yàn)的服務(wù)需求都是使用程序自動(dòng)生成的.當(dāng)評(píng)估服務(wù)需求轉(zhuǎn)換為問題圖的算法以及TAP 生成算法時(shí),我們生成了完全正確的服務(wù)需求;當(dāng)評(píng)估一致性、完整性檢測(cè)算法以及整個(gè)流程時(shí),生成的需求有20%的概率為不一致的需求,20%的概率為不完整的需求,如果生成出不一致的需求,再分別以1/3 的概率隨機(jī)生成3 種不一致;如果生成出不完整的需求,再分別以1/4、1/4、1/2 的概率隨機(jī)生成狀態(tài)不完整、不包含與或的屬性不完整、包含與或的屬性不完整.為了防止隨機(jī)性影響評(píng)估結(jié)果,每個(gè)實(shí)驗(yàn)進(jìn)行了10 次,我們分別記錄了每次實(shí)驗(yàn)的不一致、不完整個(gè)數(shù)和時(shí)間消耗,對(duì)10 次結(jié)果取平均值作為評(píng)估結(jié)果.10 組實(shí)驗(yàn)的不一致、不完整的平均個(gè)數(shù)見表3,最終的性能評(píng)估結(jié)果如圖8 所示.

Table 3 Average number of inconsistency/incompleteness and their distribution in experiments表3 實(shí)驗(yàn)中的不一致、不完整平均個(gè)數(shù)及分布情況

由圖8 的趨勢(shì)可以看出,本方法的性能超過可用閾值.服務(wù)需求到問題圖的轉(zhuǎn)換算法、TAP 生成算法、一致性檢測(cè)算法與完整性檢測(cè)算法的用時(shí)都在隨著需求條數(shù)的增加而增加,且速率并沒有很大,這與前文算法復(fù)雜度為O(n)和O(n2)的計(jì)算基本符合.由此可以認(rèn)定,本方法可適用于大規(guī)模系統(tǒng).

從圖8 還可看出,當(dāng)需求提高到一定數(shù)量時(shí),服務(wù)需求轉(zhuǎn)換為問題圖的算法花費(fèi)的時(shí)間明顯超過一致性、完整性檢測(cè)算法和TAP 生成算法所花費(fèi)的時(shí)間,其原因在于:假設(shè)需求條數(shù)為n,則由第4 節(jié)可知,一致性檢測(cè)算法、完整性檢測(cè)算法和TAP 生成算法的時(shí)間復(fù)雜度都為O(n),但服務(wù)需求轉(zhuǎn)換為問題圖算法的復(fù)雜度為O(n2),因此,轉(zhuǎn)換算法的時(shí)間復(fù)雜度是高于兩種檢測(cè)算法和TAP 生成算法的,隨著需求條數(shù)的增加,環(huán)境本體中的狀態(tài)總數(shù)相應(yīng)地增加后,理應(yīng)花費(fèi)更多的時(shí)間.

另外,圖8 中一致性檢測(cè)算法與完整性檢測(cè)算法的時(shí)間消耗并不是嚴(yán)格的單調(diào)遞增.我們認(rèn)為,這與實(shí)驗(yàn)設(shè)計(jì)時(shí)每組案例的服務(wù)需求中不一致與不完整的數(shù)量是有關(guān)系的,即服務(wù)需求一致(完整)和服務(wù)需求不一致(不完整)在檢測(cè)時(shí)所花費(fèi)的時(shí)間是不一樣的.為了證明這一點(diǎn),我們又設(shè)計(jì)了4 組實(shí)驗(yàn)進(jìn)行對(duì)比:第1、第2 組實(shí)驗(yàn)分別評(píng)估在沒有一致性(完整性)錯(cuò)誤的情況下運(yùn)行一致性(完整性)檢測(cè)算法的性能,而第3、第4 組實(shí)驗(yàn)分別評(píng)估有一致性(完整性)錯(cuò)誤的情況下運(yùn)行一致性(完整性)檢測(cè)算法的性能,其中,第3、第4 組實(shí)驗(yàn)的一致性、完整性問題的平均個(gè)數(shù)仍可見表3.每組實(shí)驗(yàn)仍然按服務(wù)需求的個(gè)數(shù)分為10 個(gè)實(shí)驗(yàn),每個(gè)實(shí)驗(yàn)做10 次,記錄其所花費(fèi)的時(shí)間,結(jié)果取平均值.最終結(jié)果如圖9 所示.

Fig.8 Result of performance analysis圖8 性能分析結(jié)果

Fig.9 Time cost of consistency and completeness checking圖9 一致性與完整性檢測(cè)的時(shí)間消耗

由圖9 可以看出,與有錯(cuò)誤相比,當(dāng)問題圖中不存在一致性、完整性錯(cuò)誤時(shí),進(jìn)行一致性、完整性檢測(cè)的時(shí)間大為縮短.因此,使用本文方法進(jìn)行TAP 規(guī)則生成時(shí),如果用戶書寫的需求本身質(zhì)量極高,沒有錯(cuò)誤,就不會(huì)因?yàn)橐恢滦?、完整性的檢測(cè)而增加時(shí)間.

5.3 環(huán)境本體構(gòu)建時(shí)間

與直接書寫TAP 規(guī)則相比,使用本方法需要先建立環(huán)境本體,本節(jié)試圖討論是否值得花費(fèi)這些時(shí)間去建立環(huán)境本體:即建立環(huán)境本體能否節(jié)省更多的其他時(shí)間,以及隨著需求數(shù)的增多,這些建立環(huán)境本體的時(shí)間消耗能否忽略不計(jì).

在第5.1 節(jié)的準(zhǔn)確性與效率的評(píng)估實(shí)驗(yàn)中,環(huán)境本體包含5 個(gè)被控制實(shí)體,它們共有11 個(gè)狀態(tài)、24 個(gè)轉(zhuǎn)換關(guān)系.盡管用戶平均花費(fèi)了7 分鐘來建立和修改環(huán)境本體,但與人工檢測(cè)相比,本方法自動(dòng)檢測(cè)一致性、完整性錯(cuò)誤,節(jié)省了更多時(shí)間,加上本文的方法還會(huì)提示錯(cuò)誤的語句,幫助用戶進(jìn)行修改.可以看出,在10 條需求的情況下,建立環(huán)境本體所花費(fèi)的時(shí)間就已經(jīng)小于本方法節(jié)省的時(shí)間了,而如果在需求較多的場(chǎng)合,盡管由于實(shí)體增多,建立環(huán)境本體的時(shí)間也有一定的增加,但這與人工檢測(cè)一致性、完整性花費(fèi)的大量時(shí)間相比,一定是利大于弊的.因此我們認(rèn)為,使用本方法,花費(fèi)一些額外的時(shí)間建立環(huán)境本體可節(jié)省更多的時(shí)間,是值得的.

本文還設(shè)計(jì)了一組實(shí)驗(yàn)以證明上述結(jié)論.我們認(rèn)為,盡管需求的數(shù)量不斷增加,但是如果建立環(huán)境本體、書寫需求、推導(dǎo)系統(tǒng)行為、進(jìn)行一致性/完整性檢測(cè)和修改到規(guī)則生成完畢,這個(gè)過程所花費(fèi)的總時(shí)間漸漸趨于穩(wěn)定的話,就能夠說明,在需求規(guī)模到達(dá)一定程度后,就可以基本忽略建立環(huán)境本體對(duì)效率的影響.因此,我們?cè)O(shè)計(jì)了10 個(gè)實(shí)驗(yàn),編號(hào)1 到10,分別統(tǒng)計(jì)了在10 條、30 條、50 條、100 條、200 條、300 條、500 條、800條、1 000 條、1 200 條需求的情況下,總時(shí)間(建立環(huán)境本體的時(shí)間與上述步驟時(shí)間之和)與需求條數(shù)的比值,即平均每條需求需要花費(fèi)的時(shí)間,實(shí)驗(yàn)結(jié)果如圖10 所示.

Fig.10 Ratio of total time to number of requirements圖10 建立環(huán)境本體與上述步驟總時(shí)間和需求數(shù)量的比值

由圖10 可以看出,當(dāng)需求數(shù)量上升時(shí),總時(shí)間與需求數(shù)的比值會(huì)逐漸地趨于穩(wěn)定,也就是說,建立環(huán)境本體的時(shí)間越來越短,甚至?xí)呌?,其原因有二:一是領(lǐng)域?qū)＜以絹碓绞煜きh(huán)境本體的構(gòu)建,構(gòu)建環(huán)境本體會(huì)越來越快;二是同一個(gè)領(lǐng)域中很多元素可以復(fù)用.例如,一個(gè)智能家居物聯(lián)網(wǎng)系統(tǒng),當(dāng)用戶撰寫10 條需求時(shí),環(huán)境本體涉及的被控制實(shí)體只有燈、窗戶、窗簾,而當(dāng)用戶撰寫50 條需求時(shí),環(huán)境本體涉及的被控制實(shí)體有燈、窗簾、窗戶、空調(diào)和電視,那么燈、窗戶、窗簾這部分的環(huán)境本體是可以復(fù)用的,這就減少了構(gòu)建環(huán)境本體的時(shí)間.受這兩方面的影響,建立環(huán)境本體的時(shí)間被分?jǐn)偟搅嗽絹碓蕉嗟男枨笾?逐漸變得可以忽略不計(jì).

需要注意的是,本文方法的正確執(zhí)行依賴于正確的環(huán)境本體.若環(huán)境本體出現(xiàn)錯(cuò)誤,那么本文方法的正確性也將受到影響.如錯(cuò)誤地添加了一個(gè)不該存在的環(huán)境實(shí)體,則在檢測(cè)完整性時(shí),會(huì)錯(cuò)誤地將一些沒有問題的需求判斷為狀態(tài)不完整;若環(huán)境本體中的遷移出現(xiàn)錯(cuò)誤,如某個(gè)遷移條件寫錯(cuò),則在根據(jù)環(huán)境本體推導(dǎo)系統(tǒng)行為時(shí),有可能會(huì)找不到對(duì)應(yīng)的系統(tǒng)行為,導(dǎo)致出錯(cuò).事實(shí)上,在第5.1 節(jié)的用戶調(diào)研中,已經(jīng)出現(xiàn)了這樣的問題.專業(yè)組的一名用戶花費(fèi)了14 分鐘進(jìn)行需求的修改,這在有本文方法提示錯(cuò)誤的情況下,已經(jīng)是很長(zhǎng)的時(shí)間了.經(jīng)過詢問發(fā)現(xiàn),其在修改過程中發(fā)現(xiàn)自己的環(huán)境本體建立錯(cuò)誤,因此重新建立了環(huán)境本體,再對(duì)需求進(jìn)行了更改,所以耗時(shí)較長(zhǎng).所以,在構(gòu)建環(huán)境本體時(shí),強(qiáng)調(diào)兩點(diǎn):環(huán)境本體應(yīng)該為領(lǐng)域?qū)＜覙?gòu)建;環(huán)境本體建好之后應(yīng)該進(jìn)行同行審查,盡量降低錯(cuò)誤的可能性.

6 相關(guān)工作

與本文相關(guān)的工作包括物聯(lián)網(wǎng)系統(tǒng)的需求獲取方法、需求的一致性與完整性檢測(cè)以及TAP 的一致性與完整性檢測(cè)方法.目前已有一些獲取物聯(lián)網(wǎng)系統(tǒng)需求的工作.如文獻(xiàn)[2]介紹了一套制定和規(guī)范物聯(lián)網(wǎng)系統(tǒng)需求的方法,物聯(lián)網(wǎng)系統(tǒng)的需求規(guī)格說明包括:領(lǐng)域模型、描述目標(biāo)及其關(guān)系的目標(biāo)視圖以及用UML 圖描述的目標(biāo)規(guī)范(goals’ specification).它采用面向目標(biāo)的方法理念[14],將需求指稱到目標(biāo)上,比較主觀,而我們采用的基于環(huán)境建模的需求工程理念,將需求指稱到環(huán)境設(shè)備的狀態(tài)變化上,比較客觀.另外,其領(lǐng)域模型與我們的環(huán)境本體一樣,都屬于領(lǐng)域知識(shí),但它只用在需求獲取上,沒有用在一致性、完整性的檢測(cè)上.還有一些工作側(cè)重在物聯(lián)網(wǎng)的非功能需求上,例如,文獻(xiàn)[15]基于i*框架[16],在物聯(lián)網(wǎng)系統(tǒng)的開發(fā)早期對(duì)安全與隱私需求進(jìn)行捕獲.文獻(xiàn)[17]則基于K-model,允許開發(fā)者根據(jù)模版編寫JSON 形式的代碼,然后通過這些代碼撰寫、修改非功能需求.本文的需求涉及服務(wù)需求和功能需求,并未涉及非功能需求.

關(guān)于需求的完整性與一致性,也已有很多工作.文獻(xiàn)[18]闡述了不一致、不完整的需求將會(huì)給軟件開發(fā)帶來的災(zāi)難性后果,并且給出了度量軟件需求規(guī)格說明(SRS)完整性、一致性的指標(biāo),但其完整性、一致性需要人工去保障;文獻(xiàn)[19]進(jìn)行了一致性自動(dòng)檢測(cè),它將需求表示為SCR 表格符號(hào),將軟件系統(tǒng)表示為有限狀態(tài)自動(dòng)機(jī),并通過靜態(tài)分析方法自動(dòng)檢測(cè)其一致性;文獻(xiàn)[20]使用一種基于狀態(tài)的需求規(guī)范語言——RSML 來表示需求,并利用RSML 的特性,對(duì)其進(jìn)行了完整性與一致性的分析;文獻(xiàn)[21]為了提高需求的完整性,提供了一個(gè)自然語言處理工具,撰寫需求時(shí),該工具會(huì)自動(dòng)提示可能會(huì)用到的術(shù)語或關(guān)系,幫助需求工程師發(fā)現(xiàn)相關(guān)的概念和交互,從而更準(zhǔn)確地撰寫需求;文獻(xiàn)[22]基于障礙分析,將模型檢測(cè)和機(jī)器學(xué)習(xí)相結(jié)合,識(shí)別、評(píng)估和解決可能阻礙系統(tǒng)目標(biāo)的異常情況,從而產(chǎn)生符合完整性的需求.這些方法既沒有用在物聯(lián)網(wǎng)系統(tǒng)中,不支持用戶編程,也沒有使用環(huán)境知識(shí)進(jìn)行檢測(cè).

也有一些工作是基于知識(shí)進(jìn)行需求一致性與完整性檢測(cè)的.例如,文獻(xiàn)[8]提出了一種基于知識(shí)的需求工程過程方法以保證需求的一致性和完整性.其作者提出一種基于框架本體和生產(chǎn)規(guī)則的混合模型來表示系統(tǒng)需求,將本體框架與生產(chǎn)規(guī)則結(jié)合在一起,從而對(duì)需求的一致性、完整性進(jìn)行檢測(cè);文獻(xiàn)[23]提出的框架使用專家代理來協(xié)助用戶進(jìn)行需求定義,該框架使用知識(shí)庫和案例庫來幫助用戶定義一套符合完整性和一致性的系統(tǒng)需求,它允許控制權(quán)在用戶和專家代理之間來回切換,為需求編寫提供了協(xié)作媒介;文獻(xiàn)[24]給出了一種本體驅(qū)動(dòng)的基于目標(biāo)的需求工程元模型,該模型基于推理技術(shù),結(jié)合了本體一致性檢測(cè)與規(guī)則驅(qū)動(dòng)的完整性測(cè)試,既可以用來捕獲需求,也可以度量演化中的需求模型的正確性與覆蓋度.這些基于知識(shí)的方法與本文有相似之處,本文的環(huán)境本體其實(shí)也是知識(shí),但本文的環(huán)境本體是關(guān)于物聯(lián)網(wǎng)系統(tǒng)的環(huán)境知識(shí).

還有很多需求的一致性檢測(cè)是基于模式語言的形式化及形式化驗(yàn)證方法.文獻(xiàn)[25]使用規(guī)范模式系統(tǒng)形式的受限制自然語言來描述系統(tǒng)需求,然后自動(dòng)地將其轉(zhuǎn)換為時(shí)間計(jì)算樹邏輯,再轉(zhuǎn)換為一階邏輯公式,使用Z3對(duì)其執(zhí)行SMT 分析,檢測(cè)需求是否一致;文獻(xiàn)[26]使用BTC 模式表示需求[27],為了最小化分析成本,它使用了有界模型檢測(cè)方法來檢測(cè)一致性;文獻(xiàn)[28]定義了一種名為SafeNL 的安全需求模式語言,以類自然語言的方式表達(dá)需求,然后將其自動(dòng)轉(zhuǎn)換為時(shí)鐘約束規(guī)范語言,通過有界模型檢測(cè)的方法檢測(cè)安全需求的一致性;文獻(xiàn)[29]為簡(jiǎn)化通用模式提出了新的形式化一致性概念,即偏序一致性.偏序一致性可識(shí)別系統(tǒng)的關(guān)鍵案例,并驗(yàn)證這些案例是否會(huì)引起需求之間的沖突.該文首先使用計(jì)數(shù)自動(dòng)機(jī)對(duì)簡(jiǎn)化通用模式表示的需求進(jìn)行形式化建模,然后對(duì)偏序一致性進(jìn)行了形式化的定義,給出了檢測(cè)需求模型是否違背偏序一致性的方法;文獻(xiàn)[30]提出了一種針對(duì)汽車系統(tǒng)的結(jié)構(gòu)化需求撰寫語言,它使用汽車系統(tǒng)的本體來提供詞法和句法的標(biāo)準(zhǔn),將需求的一致性檢測(cè)轉(zhuǎn)換為一個(gè)布爾命題的證明,然后使用定理證明的方法來檢測(cè)需求一致性.這些方法中的模型檢測(cè)和定理證明,都是重量級(jí)的形式化方法,效率難以保證,且返回結(jié)果難以為一般用戶所理解.

現(xiàn)在已有一些工作采用形式化方法對(duì)TAP 規(guī)則進(jìn)行一致性檢測(cè).例如,文獻(xiàn)[7]中的AutoTap,允許用戶使用TAP 規(guī)則來描述需求,也允許用戶定義系統(tǒng)必須滿足的屬性.AutoTap 將用戶書寫的規(guī)則和屬性轉(zhuǎn)換為L(zhǎng)TL 公式,使用模型檢測(cè)的方法檢測(cè)它們是否有沖突.張秋萍等人開發(fā)的工具[31]使用形式化方法,將TAP 規(guī)則轉(zhuǎn)換為CTL 與LTL 公式,然后借助NuSMV 工具檢測(cè)其一致性;文獻(xiàn)[32]同樣使用了形式化方法,使用線性混合自動(dòng)機(jī)建模物聯(lián)網(wǎng)系統(tǒng),然后進(jìn)行可達(dá)性分析來檢測(cè)其一致性.這些方法都是對(duì)TAP 進(jìn)行檢測(cè),這與本文截然不同,本文檢測(cè)的是系統(tǒng)行為之間是否沖突;而且本文方法實(shí)際上是基于規(guī)則的方法,效率較高,且使用規(guī)模較大.

7 總結(jié)與展望

為了實(shí)現(xiàn)從服務(wù)需求到設(shè)備調(diào)度程序的自動(dòng)生成,讓終端用戶參與物聯(lián)網(wǎng)系統(tǒng)的開發(fā),本文提出了基于環(huán)境建模的TAP 規(guī)則生成方法,自動(dòng)地基于環(huán)境模型從服務(wù)需求中推導(dǎo)系統(tǒng)行為,檢測(cè)系統(tǒng)行為的完整性與一致性,并最后轉(zhuǎn)換為TAP 規(guī)則.本文構(gòu)建了環(huán)境本體,提供了環(huán)境建模的概念和關(guān)聯(lián),描述了物聯(lián)網(wǎng)系統(tǒng)中的各個(gè)設(shè)備的狀態(tài)、屬性、行為以及它們之間的關(guān)系.然后,基于環(huán)境本體,支持從用戶撰寫的服務(wù)需求推導(dǎo)出系統(tǒng)行為,對(duì)其進(jìn)行一致性、完整性檢測(cè)以及TAP 規(guī)則轉(zhuǎn)換的全過程.本文還對(duì)該方法進(jìn)行了評(píng)估,結(jié)果表明,其有較好的性能、效率以及準(zhǔn)確性;評(píng)估還表明,隨著需求數(shù)的增加,建立環(huán)境本體的時(shí)間變得可以忽略不計(jì),并能節(jié)省很多人工檢測(cè)一致性、完整性問題的時(shí)間.

本文僅關(guān)注于物聯(lián)網(wǎng)系統(tǒng)的功能需求,并未涉及時(shí)間、安全性、隱私性、可信賴度等非功能需求.未來工作將考慮對(duì)這些非功能需求進(jìn)行捕獲和檢測(cè).另外,在環(huán)境本體的構(gòu)建中,目前都還只依賴于領(lǐng)域?qū)＜?下一步工作將考慮采用半自動(dòng)甚至全自動(dòng)的方法進(jìn)行構(gòu)建.