基于環(huán)境建模的物聯(lián)網(wǎng)系統(tǒng)TAP 規(guī)則生成方法*

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

1(上海市高可信計算重點實驗室(華東師范大學(xué)),上海 200062)

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

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

物聯(lián)網(wǎng)(IoT)系統(tǒng)通過網(wǎng)絡(luò)連接的傳感器和執(zhí)行器監(jiān)視、調(diào)度、管理各種設(shè)備,如汽車、交通信號燈、空調(diào)、燈等,為用戶提供各種智能服務(wù)以滿足用戶服務(wù)需求,為用戶的日常生活提供便利.在這樣的系統(tǒng)中,用戶服務(wù)需求是智能服務(wù)的根本驅(qū)動力.近年來提出的物聯(lián)網(wǎng)面向用戶編程框架,如IFTTT 和Microsoft Flow[1],就是這種背景下的產(chǎn)物.它們允許用戶使用簡單的“IF trigger,THEN action(稱為觸發(fā)-命令編程,TAP)”規(guī)則編程.在圖1 所示的智能家居系統(tǒng)中,用戶可以編出這樣的規(guī)則:“如果光線亮度超過 50 000lux,則關(guān)上窗簾”,這個規(guī)則用TAP 描述為“IF Light.brightness>50000lux THEN close the blind”.但是,實際上這種TAP 句法描述的是設(shè)備調(diào)度程序,通知軟件去關(guān)窗簾,既不是用戶服務(wù)需求也不是系統(tǒng)行為,服務(wù)需求貼近用戶的需要,比如用戶想要窗簾關(guā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)的需求方法,如文獻[2]使用領(lǐng)域模型和UML 圖來捕獲服務(wù)需求,支持服務(wù)目標(biāo)的分解,但沒有提出措施來保障物聯(lián)網(wǎng)不同服務(wù)間的一致性和服務(wù)部署的完整性,容易出現(xiàn)一致性和完整性問題.一致性問題是指有兩條或兩條以上的服務(wù)需求之間出現(xiàn)沖突[3,4],而完整性問題是指在某些情況下的輸入,軟件無法給出確切的輸出[5].對于軟件系統(tǒng)來說,任何由于不一致、不完整導(dǎo)致的差錯,都可能在現(xiàn)實世界中產(chǎn)生不良后果,甚至對用戶的財產(chǎn)、生命造成威脅[6].在物聯(lián)網(wǎng)系統(tǒng)中,使用TAP 進行用戶編程時,用戶并不會去考慮一致性、完整性問題,使得這些問題更加突出.例如,在一個智能家居軟件系統(tǒng)中,如果用戶規(guī)定當(dāng)一氧化碳的濃度高于一定閾值時自動開窗,又規(guī)定下雨時自動關(guān)窗,那么如果下雨時一氧化碳濃度過高,同時滿足這兩條需求,便會出現(xiàn)一致性問題,在這種情況下,房間的一氧化碳濃度可能會超過200mg/L,這是有害甚至致命的;再比如規(guī)定亮度低于一定閾值時開燈,但沒有規(guī)定高于這個閾值時的行為,那就會出現(xiàn)完整性問題,導(dǎo)致燈一直開著,嚴(yán)重浪費能源.現(xiàn)在已有很多工作提供對TAP 規(guī)則的一致性的檢測與修復(fù)[7,8],但并沒有在服務(wù)需求層面和系統(tǒng)行為層面上的檢測.

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

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

(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]進行服務(wù)需求到系統(tǒng)行為的自動轉(zhuǎn)換,以及基于規(guī)則完成了需求的一致性與完整性的檢測.

本文第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è)計實驗,對本文方法進行評估.第6 節(jié)比較相關(guān)工作.第7 節(jié)總結(jié)全文,展望未來工作.

1 預(yù)備知識

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

Fig.2 Simple example of a problem digram圖2 問題圖的簡單示例

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

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)境本體則是針對某個具體的領(lǐng)域的環(huán)境建模的結(jié)果,是對上層環(huán)境本體概念和關(guān)聯(lián)在特定領(lǐng)域中的實例化.

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

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

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

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

對于每個環(huán)境實體,都可以用屬性(attribute)來描述其特性,每個屬性都有取值(value).比如被監(jiān)視的環(huán)境實體光線(light),它有屬性亮度,可以用Light.brightness表示,其取值代表光線亮度的大小;再如被控制的環(huán)境實體Bulb,它的屬性為BulbST,即燈的狀態(tài),其屬性值可以為bon或boff,表示燈的開關(guān)狀態(tài).除了屬性之外,還可以使用狀態(tài)機(state machine)來描述一些被控制實體的動態(tài)特性,狀態(tài)機有狀態(tài)(state)、狀態(tài)變遷(transition),而狀態(tài)變遷由事件(event)觸發(fā).比如可以用帶有狀態(tài)bon、boff的狀態(tài)機描述燈的動態(tài)特性,當(dāng)燈接收到開燈的脈沖(bonPulse)時狀態(tài)轉(zhuǎn)為bon,而當(dāng)燈接受到關(guān)燈的脈沖(boffPulse)時狀態(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)造.首先識別領(lǐng)域中的環(huán)境實體.假設(shè)智能家居領(lǐng)域中包含的被控制環(huán)境實體有窗戶(window)、窗簾(blind)和燈(bulb),而被監(jiān)視環(huán)境實體有光照和空氣.這些都是環(huán)境實體的實例.窗戶的屬性為WindowST,描述窗戶的開閉,其取值為wopen或wclosed;窗簾的屬性為BlindST,描述窗簾的開閉,其取值是bopen或bclosed;燈的屬性為BulbST,描述燈的開關(guān),其取值是bon或boff;光照的屬性為brightness,表示亮度,其值在理論上可以是大于0 的任意值;空氣的屬性為溫度(temperature)和濕度(humidity),temperature表示氣溫,其值在理論上可以為–273.15 攝氏度到正無窮;humidity表示空氣的相對濕度,其值在理論上可以為0 到正無窮.這些具體的屬性和取值分別是屬性和值這兩個概念的實例.

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

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

3 本文方法

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

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

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

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

其中,

· entity.trigger 有如下表達方式.

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

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

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

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

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

對于復(fù)雜的服務(wù)需求,即含有與或關(guān)系的需求,也采用同樣的處理方式.例如,想要表達當(dāng)氣溫高于25°且亮度大于25 000lux 時窗戶處于打開狀態(tài),這個服務(wù)需求有兩個觸發(fā)條件,涉及兩個被監(jiān)視實體:空氣和光線,觸發(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ù)需求時就需要引入環(huán)境本體,讓用戶選擇相應(yīng)的設(shè)備,而不是隨便寫.這么做的好處在于:大多數(shù)用戶并不熟悉所有設(shè)備的性能和效果,如果讓用戶毫無限制地書寫需求,將會造成大量因不熟悉設(shè)備而造成的錯誤或遺漏.而環(huán)境本體中包含了各個設(shè)備及其狀態(tài)、效果,使用環(huán)境本體能夠在用戶書寫服務(wù)需求時提示他們設(shè)備的效果,防止用戶寫出一些荒謬的服務(wù)需求,從而減少后期檢測與修改的工作量.

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

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

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

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

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

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

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

· 如果是與關(guān)系連接了多個entity.trigger,則對于每一個entity.trigger,該entity 對應(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”.因此,對這種帶有或關(guān)系的需求,我們將其拆解為兩句,分別轉(zhuǎn)換為問題圖.

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

3.3 一致性與完整性的檢測

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

(1) 范圍不一致:超過一條需求的trigger 中的范圍有交集,而它們的state 實體相同,內(nèi)容不同,導(dǎo)致需求發(fā)生沖突.例如,智能家居系統(tǒng)的用戶規(guī)定“IFLight.brightness<30000 THENWindow.wclosed”和“IFLight.brightness>15000 THENWindow.wopen”,那么,當(dāng)亮度處于15 000lux 到30 000lux 之間時,這兩條需求同時作用在窗戶上,但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°,使用與連接說明需要同時滿足這兩個條件,因此這是永遠(yuǎn)也無法達到的,從而導(dǎo)致了與或的不一致.

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

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

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

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

3.4 TAP規(guī)則的生成

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

(1) 從問題圖生成系統(tǒng)行為:根據(jù)檢測過的問題圖,首先確定問題圖中的問題領(lǐng)域中是對應(yīng)需求引用還是需求約束,若為引用,則其問題領(lǐng)域的接口對應(yīng)IF 里面的內(nèi)容,如果有多個引用,則使用“&&”進行連接;若為約束,則其問題領(lǐng)域的接口對應(yīng) THEN 里面的內(nèi)容.如圖 7 所示,問題領(lǐng)域Air是需求引用,則其接口“Air!{temperature>30}”為IF 里的內(nèi)容,而問題領(lǐng)域Window對應(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)象指令對照表中的相關(guān)條目進行對照后才能生成最終的TAP規(guī)則.其中,現(xiàn)象指令對照表是一組軟件行為與指令的對應(yīng)關(guān)系,如圖7 所示,wopenPulse對應(yīng)指令open the window,這個對照表可以由設(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)鍵算法

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

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

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

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

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

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

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

4.2 一致性檢測算法與完整性檢測算法

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

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

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

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

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

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

算法的主要步驟如算法5 所示.第2 行遍歷所有檢測后的問題圖,第6 行獲取所有需求引用對應(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)象指令對照表)將系統(tǒng)行為轉(zhuǎn)換為對應(yīng)的指令.假設(shè)需求條數(shù)為n,嵌套的2 個循環(huán),即第6 行的循環(huán)執(zhí)行常數(shù)次,因此,該算法的時間復(fù)雜度為O(n).

算法2.一致性檢測算法.

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

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

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

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

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

5 方法評估

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

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

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

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

算法4.完整性檢測算法.

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

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

算法5.TAP 生成算法.

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

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

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

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

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

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

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

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

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

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

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

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

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

5.2 性 能

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

6 相關(guān)工作

與本文相關(guān)的工作包括物聯(lián)網(wǎng)系統(tǒng)的需求獲取方法、需求的一致性與完整性檢測以及TAP 的一致性與完整性檢測方法.目前已有一些獲取物聯(lián)網(wǎng)系統(tǒng)需求的工作.如文獻[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)域知識,但它只用在需求獲取上,沒有用在一致性、完整性的檢測上.還有一些工作側(cè)重在物聯(lián)網(wǎng)的非功能需求上,例如,文獻[15]基于i*框架[16],在物聯(lián)網(wǎng)系統(tǒng)的開發(fā)早期對安全與隱私需求進行捕獲.文獻[17]則基于K-model,允許開發(fā)者根據(jù)模版編寫JSON 形式的代碼,然后通過這些代碼撰寫、修改非功能需求.本文的需求涉及服務(wù)需求和功能需求,并未涉及非功能需求.

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

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

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

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

7 總結(jié)與展望

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

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