面向安卓應(yīng)用建模的IFML擴展*

陸一飛, 潘敏學(xué), 張 天, 王林章, 李宣東

(計算機軟件新技術(shù)國家重點實驗室(南京大學(xué)),江蘇 南京 210023)

隨著智能機與平板電腦的日漸普及,安卓設(shè)備及其應(yīng)用市場蓬勃發(fā)展.近年來,在谷歌公司的推廣下,安卓(Android)這一開源操作系統(tǒng)被廣泛應(yīng)用于移動智能終端.根據(jù)Gartner 公司的調(diào)研[1],截至2018 年第一季度,安卓系統(tǒng)在智能手機市場的占有率已經(jīng)達到85%.此外,至2018 年6 月,單在Google Play 應(yīng)用商店中可獲得的安卓應(yīng)用已超過330 萬[2].毫無疑問,安卓設(shè)備以及安卓應(yīng)用已逐漸成為移動計算市場的主流.安卓應(yīng)用在擁有越來越豐富功能的同時,還需要應(yīng)對各種各樣的操作環(huán)境的變化[3],導(dǎo)致其應(yīng)用復(fù)雜度也呈現(xiàn)指數(shù)級的增長.同時,為了能更好地搶占市場,安卓應(yīng)用需要適配盡可能多的設(shè)備和系統(tǒng)版本.而其多樣化和碎片化,使得同一個應(yīng)用經(jīng)常需要開發(fā)多個版本,用于適配不同版本的安卓系統(tǒng)和設(shè)備.這些因素綜合在一起,使得相應(yīng)的開發(fā)與測試中的工作量大為增加.

針對上述問題,模型的使用是一種比較常見的方式.通過模型來描述并設(shè)計安卓應(yīng)用,可將原本繁瑣的應(yīng)用主體分解為不同的模塊逐個處理,降低了開發(fā)的整體難度.模型的使用可以將安卓應(yīng)用中設(shè)備、系統(tǒng)版本相關(guān)和無關(guān)的部分相分離,使得應(yīng)用的邏輯設(shè)計這一類不因設(shè)備和系統(tǒng)版本變化的部分得到充分復(fù)用,避免重復(fù)開發(fā).目前,國際上已有學(xué)者將各類模型應(yīng)用于安卓應(yīng)用的設(shè)計和開發(fā).Parada 等人采用UML 類圖和時序圖作為移動應(yīng)用的高層抽象模型,并基于這些模型實現(xiàn)了代碼的部分自動化生成[4];Heitk?tter 等人針對數(shù)據(jù)驅(qū)動應(yīng)用,基于md2這一MVC 結(jié)構(gòu)模型進行移動端的模型驅(qū)動開發(fā)[5].然而,這些模型都是為傳統(tǒng)的桌面應(yīng)用設(shè)計,沒有考慮安卓應(yīng)用本身的特點.與傳統(tǒng)的桌面應(yīng)用不同,安卓應(yīng)用由事件驅(qū)動,大量依賴于圖形化用戶界面(GUI)[6],這就需要有能夠有效對GUI 進行建模的語言.交互流建模語言(interaction flow modeling language,簡稱為IFML)[7]作為面向?qū)ο蠼M織OMG 的年輕標(biāo)準(zhǔn),倡導(dǎo)以圖形的形式描述軟件系統(tǒng)前端設(shè)計中的展現(xiàn)內(nèi)容及與用戶之間的交互.它能夠與其他基于UML 的模型兼容,有良好的可擴展性與兼容性.它以事件流為驅(qū)動,重視用戶、系統(tǒng)事件以及人機交互,能夠有效地應(yīng)對安卓應(yīng)用基于GUI 的事件驅(qū)動特性.因此,本文將研究基于IFML 對安卓應(yīng)用建模的方法.

根據(jù)用戶的需求,在設(shè)計階段,面向安卓應(yīng)用建立的IFML 模型,能夠有效地描述安卓應(yīng)用中極為重要的GUI 結(jié)構(gòu)以及各GUI 元素間的交互關(guān)系,即工作流的傳遞,并利用其強大的表達能力促進開發(fā)人員對應(yīng)用設(shè)計的認識,指導(dǎo)開發(fā)工作系統(tǒng)、有效地進行,減少理解誤區(qū).此外,IFML 模型所包含的豐富語義使得依據(jù)該模型進行的測試效果極為有效.這些測試的執(zhí)行能夠保證應(yīng)用實現(xiàn)與設(shè)計,即IFML 模型保持一致,從而保證開發(fā)質(zhì)量.同時,在應(yīng)用的演化過程中,開發(fā)人員可以通過增量式修改IFML 模型來驅(qū)動演進工作的進行.在已建立IFML模型的基礎(chǔ)上,開發(fā)人員僅需要低額的工作量便可完成其上的修改工作,這使得IFML 建模的初期成本被不斷稀釋.該IFML 模型還擁有廣泛的應(yīng)用前景,通過提高自動化的方式,無論是代碼的自動化生成還是測試的自動化生成與執(zhí)行,都能有效地減少開發(fā)成本,提高開發(fā)效率.然而當(dāng)前的IFML 廣泛應(yīng)用于多平臺應(yīng)用的建模,在描述安卓應(yīng)用時太過寬泛,對安卓應(yīng)用端特有元素的描述能力較為欠缺,因此將IFML 應(yīng)用于安卓應(yīng)用開發(fā)的效果將大打折扣.為此,本文研究了IFML 面向安卓端的擴展,以此提高IFML 對安卓應(yīng)用的描述能力.基于該擴展后的IFML,使用者能夠建立與安卓應(yīng)用更加契合的模型,用于安卓應(yīng)用的設(shè)計、開發(fā)和持續(xù)發(fā)展.

本文的工作與貢獻主要包括4 個方面.(1)本文提出了面向安卓平臺的IFML 擴展,以更好地對安卓應(yīng)用進行IFML 建模.(2)對于IFML 標(biāo)準(zhǔn)中非形式化的部分及本文提出的擴展部分,我們都給出了形式化的定義,為基于IFML 模型的各類開發(fā)和測試方法奠定了理論基礎(chǔ).(3)探索了面向安卓端的IFML 的應(yīng)用前景,針對安卓應(yīng)用的測試需求開發(fā)了基于IFML 模型的安卓應(yīng)用的建模與測試工具ADAMANT.利用該工具,使用者可以以圖形化的方式建立IFML 模型,并利用模型生成測試用例并執(zhí)行.(4)基于ADAMANT,本文為當(dāng)前5 個真實的安卓應(yīng)用進行了IFML 建模,并基于模型對應(yīng)用進行了測試.其良好的測試結(jié)果表明了將IFML 應(yīng)用于安卓應(yīng)用的建模以推進開發(fā)工作這一方法的可行性.

本文第1 節(jié)從總體上介紹IFML 及其特點,并簡要介紹其主體組成結(jié)構(gòu).第2 節(jié)以一個安卓應(yīng)用為例描述當(dāng)前IFML 在描述安卓應(yīng)用時的不足,說明擴展IFML 以用于安卓應(yīng)用開發(fā)工作的必要性.第3 節(jié)有針對性地對IFML 進行安卓平臺的擴展,并對擴展后的IFML 模型進行實例描述.第4 節(jié)在第3 節(jié)的基礎(chǔ)上,提出擴展后的IFML 模型,以及模型中執(zhí)行語義的形式化定義.第5 節(jié)介紹本文實現(xiàn)的建模與測試工具ADAMANT,并將其應(yīng)用于5 個安卓應(yīng)用之上,用于探索面向安卓應(yīng)用的IFML 擴展在指導(dǎo)應(yīng)用開發(fā)過程中的可行性.第6 節(jié)探討并比較在移動應(yīng)用中使用模型輔助開發(fā)、測試,以及對IFML 擴展這3 方面的已有工作.第7 節(jié)總結(jié)全文,提出未來的研究方向和改進目標(biāo).

1 交互流建模語言

交互流建模語言IFML 是以圖形的形式描述軟件系統(tǒng)前端設(shè)計中的展示內(nèi)容、與用戶之間的交互以及行為控制等內(nèi)容的可視化建模語言[7].它在2013 年被OMG 協(xié)會納為標(biāo)準(zhǔn),并在2015 年發(fā)表了1.0 官方正式文檔.

Table 1 The introduction to commonly used elements of IFML model表1 IFML 模型中常用元素簡介

IFML 的主要目的在于提供軟件工程師們用以描述圖形化界面應(yīng)用前端的IFML 模型(IFMLModel),它可以支持諸如桌面應(yīng)用、網(wǎng)頁應(yīng)用等等多種終端上的應(yīng)用,具有較強的泛用性.IFML 模型以樹狀結(jié)構(gòu)抽象代表了應(yīng)用中各前端元素,以及各元素之間的交互關(guān)系.本文在表1 中對IFML 模型中的常用元素進行了介紹.

大體而言,IFML 模型中存在多個視圖容器,代表應(yīng)用或系統(tǒng)中的界面.每個視圖容器可以擁有屬于自己的視圖組件來表示該界面上的控件元素.在視圖組件上又可包含視圖組件部件來對該視圖組件進一步補充說明.視圖容器和視圖組件可以擁有參數(shù)元素來輔助表示模型的狀態(tài),并且參數(shù)的數(shù)值可參與表達式的計算,其計算結(jié)果用于模型內(nèi)的邏輯判斷.此外,視圖容器、視圖組件或視圖組件部件也可持有事件元素.當(dāng)事件被觸發(fā)時,交互流會從該事件導(dǎo)出,傳遞給其他元素,用于表示視圖焦點或是數(shù)據(jù)的轉(zhuǎn)移.與此同時,交互流上的參數(shù)綁定組將會進行參數(shù)的傳遞.特別地,當(dāng)導(dǎo)向流指向行為元素時,行為所代表的業(yè)務(wù)邏輯將會被執(zhí)行,完成后將會觸發(fā)其上的行為事件,從而引出新的交互流指向其他元素.

2 案例分析

本節(jié)將介紹一個來自Github 上的安卓開源應(yīng)用Good Weather,并使用標(biāo)準(zhǔn)的IFML 為其建模.Good Weather用于展示當(dāng)?shù)氐奶鞖庑畔?該應(yīng)用可在Github、Google Play 及F-droid 上獲取.

Fig.1 Three views of Good Weather and their relations圖1 Good Weather 應(yīng)用的3 個視圖及它們之間的關(guān)系

圖1 顯示了Good Weather 這一安卓應(yīng)用的GUI 視圖,以及各視圖之間的跳轉(zhuǎn)關(guān)系.其中,圖1-2 為Good Weather 應(yīng)用的主界面.它顯示了選定城市的天氣與相關(guān)環(huán)境信息.通過點擊右上角的3 個圖標(biāo)按鈕可以分別對天氣進行刷新、對城市進行文本搜索(如圖1-3 所示)以及進行GPS 位置搜索.在主界面中,也可通過向右滑動打開其側(cè)邊欄(如圖1-1 所示),點擊其中的Setting、Feedback 以及Donate Bitcoin 文本,也可分別打開設(shè)定、反饋以及捐款頁面.

圖2 顯示的是本文為Good Weather 應(yīng)用建立的IFML 模型中的主界面和側(cè)邊欄部分(如圖1-2 和圖1-1 所示).在該IFML 模型中,本文以視圖容器(白色方角框)來表示主界面、工具欄以及側(cè)邊欄這類整體的界面.在這些視圖容器中,我們以視圖組件(灰色圓角框)來表示文本、圖片、圖標(biāo)以及按鈕這些控件,它們可觸發(fā)相應(yīng)的事件(圖中白色小圓圈),引起交互流的傳遞.如HomeButton 這一視圖組件代表了主界面左上角的按鈕,其上的事件touch the button,表示用戶在點擊這一按鈕時將會將交互流導(dǎo)向SideBar 這一容器,即應(yīng)用的側(cè)邊欄.此外,該模型中也以參數(shù)isLocated 來表示該應(yīng)用當(dāng)前是否進行了定位,使用激活表達式來判斷是否根據(jù)isLocated 的值來顯示詳細的天氣信息,并在行為locating 的執(zhí)行中會動態(tài)地修改isLocated 的值(其具體執(zhí)行過程由UML 動態(tài)模型表示).此過程中IFML 原有的模型元素概念太過寬泛,不足以精確描述安卓應(yīng)用中的獨有元素,具體有以下3 類.

1)豐富的界面元素.安卓設(shè)備較小的設(shè)備屏幕,無法同時容納大量的控件元素,因而需要多個界面來協(xié)同完成應(yīng)用的功能.為此,諸如工具欄、側(cè)邊欄等僅占據(jù)屏幕一部分的輕量級界面容器被廣泛應(yīng)用于界面間的跳轉(zhuǎn)或?qū)Ш?它們與占據(jù)應(yīng)用整個屏幕的、用于實現(xiàn)應(yīng)用主功能的各個界面,在外觀和使用方式上都存在較大的差異,無法由IFML 中原有的視圖容器和視圖組件進行有效區(qū)分.而對于安卓端的控件,諸如文本、按鈕、圖片等諸多元素,它們的外形以及其上可觸發(fā)的事件各異(如文本和按鈕上通?？梢赃M行長按、點擊操作,而圖片則通?？梢赃M行滑動、縮捏操作等等),以原IFML 中的視圖容器和視圖組件統(tǒng)一地表示這些元素可能會引起設(shè)計和實現(xiàn)中的誤解,為此,我們需要對IFML 中的視圖容器和視圖組件進行擴展,進而有效地區(qū)分這些容器和組件.

2)多樣的用戶手勢.眾所周知,安卓應(yīng)用也支持多樣的用戶手勢,如點擊、長按、滑動等.同時,在同一個控件上,不同的手勢操作通常會引起不同的事件行為.例如,在文件管理類應(yīng)用中,對于以列表形式出現(xiàn)的文件列,普通的點擊操作將會打開該文件的詳細信息界面,而長按操作則會彈出文件的操作菜單,包含刪除、移動、詳情等等.原IFML 僅以事件下的子類型、視圖元素事件(ViewElementEvent)來進行統(tǒng)一的表示.因此,在上述的IFML 模型中,為了區(qū)分各事件所代表的具體操作行為,仍需要使用自然語言來進行輔助說明.這一方式不但建模時存在不便,而且在設(shè)計和實現(xiàn)時也可能會引入歧義.為此,對于安卓用戶手勢的擴展也勢在必行.

3)繁多的系統(tǒng)事件.同時,由于安卓設(shè)備便攜的特點,安卓應(yīng)用往往還需處理多樣的系統(tǒng)事件,如電量變化、網(wǎng)絡(luò)連接、GPS 定位、傳感器感知等類型的事件.在IFML 中,它們都由事件下的子類型系統(tǒng)事件(SystemEvent)來統(tǒng)一表示.這樣的表示方式也過于籠統(tǒng),因此,本文也對安卓端的系統(tǒng)事件進行了擴展.

Fig.2 A part of IFML model for Good Weather圖2 Good Weather 應(yīng)用的部分IFML 模型

綜上所述,本文擬對IFML 標(biāo)準(zhǔn)進行面向安卓端的擴展,從而將IFML 模型應(yīng)用于安卓應(yīng)用的建模,在應(yīng)用的演進過程中持續(xù)性地指導(dǎo)應(yīng)用的設(shè)計與實現(xiàn)工作.

3 面向安卓平臺的IFML 擴展

由于原IFML 在用于安卓應(yīng)用建模時存在種種不足,本文認為需要對IFML 進行面向安卓端的擴展.為此,本文以安卓官方指導(dǎo)文檔為基礎(chǔ),并以當(dāng)前安卓應(yīng)用中的主流常用元素作為補充,提出了以下3 個方面的安卓端擴展:(1)對視圖容器與視圖組件的擴展;(2)對表達式和行為的擴展;(3)對事件的擴展.

3.1 針對視圖容器與視圖組件的擴展

視圖容器代表的是一個整體性的界面,本文為其添加了安卓應(yīng)用視圖容器(AndroidAppContainer)作為安卓端應(yīng)用中使用的視圖容器子類型,并在其下添加滑動窗口(scroller)、抽屜(drawer)、屏幕(screen)、工具欄(toolbar)和網(wǎng)頁(Web)這5 個實例子類型.滑動窗口表示可上下或左右滑動的視圖容器;抽屜是指可從左/右滑出的側(cè)邊欄;工具欄表示應(yīng)用中具有導(dǎo)航或顯示標(biāo)題等輔助功能的工具欄容器;網(wǎng)頁則表示以網(wǎng)頁風(fēng)格展示的視圖容器;屏幕表示應(yīng)用中進行主體的信息展示,與用戶交互的整體性界面容器,與其他4 個元素進行區(qū)分.通過對這些安卓常用視圖容器的特例化,使得建模更加便捷的同時有效區(qū)分了各類常用元素.其具體關(guān)系結(jié)構(gòu)可如圖3 所示.

Fig.3 The Android extension to ViewContainer圖3 視圖容器的安卓端擴展

視圖組件代表的是視圖容器中用于展示信息或接受輸入的、并可引發(fā)應(yīng)用事件的組件.IFML 標(biāo)準(zhǔn)中所有的組件均以視圖組件來表示,過于籠統(tǒng).本文為其添加安卓應(yīng)用視圖組件(AndroidAppComponent)這一子類型表示安卓應(yīng)用中使用到的視圖組件,并給出了以下更加具體的視圖組件實例:按鈕(Button)表示按鈕類型的組件,其下有子類型:狀態(tài)改變按鈕(CompoundButton)表示會引起狀態(tài)切換的按鈕;文本(Text)表示文本類型的組件;圖標(biāo)(Icon)表示圖標(biāo)組件;圖片(Image)表示圖片組件;編輯框(EditText)表示為文本輸入框;進度條(ProgressBar)表示為進度條組件.本文還添加了模板自定義組件(CustomComponent)允許用戶自定義使用到的組件類型.其具體的關(guān)系結(jié)構(gòu)可如圖4 所示.

Fig.4 The Android extension to ViewComponent圖4 視圖組件的安卓端擴展

此外,針對安卓系統(tǒng)上一些獨有的界面元素,相應(yīng)地,本文使用安卓系統(tǒng)視圖容器(AndroidSystemContainer)與安卓系統(tǒng)視圖組件(AndroidSystemComponent)來表示.本文亦在其下創(chuàng)建了一組實例:通知區(qū)域(Notification Area)表示安卓應(yīng)用中的通知欄區(qū)域元素,通知(Notification)表示其中的通知提示信息.該組實例能夠簡化建模過程,并且由于安卓系統(tǒng)中通知區(qū)域的唯一性,該組實例能夠與之對應(yīng).

3.2 針對表達式與行為的擴展

表達式定義了一個無副作用的語句,可以在執(zhí)行后返回特定的結(jié)果,以便IFML 模型進行邏輯判斷.在IFML標(biāo)準(zhǔn)中存在多種表達式的實用子類型,在本文中主要使用并介紹其中兩類:交互流表達式,用于判斷對應(yīng)的事件在當(dāng)前狀況下最終觸發(fā)了哪些交互流;激活表達式,用于判斷該表達式所屬元素是否可見/可觸發(fā).本文還額外定義了兩種表達式,來輔助進行IFML 模型中的邏輯判斷,分別是:

(1)定義表達式新的子類型,默認表達式(DefaultExpression).作為表達式邏輯中重要的參與元素,參數(shù)持有一個默認表達式類型的屬性defaultValue,它將賦予該參數(shù)的最初值.然而,原IFML 中并未定義其對應(yīng)的表達式子類型,為此,本文添加了該默認表達式,專門用于以表達式形式直接賦予參數(shù)以最初的數(shù)值.

(2)定義有副作用的,即計算時可以修改參數(shù)數(shù)值的新表達式子類型,執(zhí)行表達式(ExcutionExpression).在原IFML 中,行為用于表示由事件所引起的事務(wù)邏輯.其具體執(zhí)行需要借用UML 活動圖等動態(tài)模型來表示.然而,對于通常的安卓應(yīng)用開發(fā)來說,多個模型的使用以及模型間的頻繁切換太過繁瑣.為此,本文在行為下添加一個執(zhí)行表達式類型的成員executionContent,來輕量級地描述某行為中的具體邏輯.通過執(zhí)行executionContent可以修改部分參數(shù)的數(shù)值,表示行為所代表的業(yè)務(wù)邏輯對模型狀態(tài)的影響.

此外,安卓終端也有許多諸如通話、攝像、照相等設(shè)備獨有的行為,本文也為其進行了安卓終端的擴展:擴展了安卓行為(AndroidAction),用以表示安卓應(yīng)用中所引發(fā)的事務(wù)邏輯,并添加了安卓行為事件(Android Action Event)與之對應(yīng),表示為安卓行為執(zhí)行結(jié)束后所觸發(fā)的行為事件.同時,本文添加了相機行為(Camera Action)和相機行為事件(CameraActionEvent)這一對實例,用于表示照相/錄像的行為以及對應(yīng)的行為事件;類似地,還有話筒行為(MicrophoneAction)與話筒行為事件(MicrophoneActionEvent),此處不再一一詳述.這些安卓行為能夠與安卓上的特有行為相對應(yīng),簡化對該類復(fù)雜行為進行的繁雜建模過程,提高了模型的可用性.

3.3 針對事件的擴展

除了第3.2 節(jié)中擴展的行為事件外,在第2 節(jié)中,我們提及原IFML 用視圖元素事件與系統(tǒng)事件分別表示安卓應(yīng)用中豐富的用戶手勢和安卓系統(tǒng)所引起的繁多的事件.為此,本文也對這兩類事件進行了擴展.

本文首先在系統(tǒng)事件下擴展了新的子類型:安卓系統(tǒng)事件(AndroidSystemEvent)用于表示安卓終端上系統(tǒng)產(chǎn)生的事件,同時還在該類型下添加了5 個實用子類型:電池事件(BatteyEvent),表示電池狀況所引起的系統(tǒng)事件;存儲事件(StorageEvent),表示系統(tǒng)存儲引起的系統(tǒng)事件;傳感器事件(SensorEvent),表示安卓終端傳感器產(chǎn)生的系統(tǒng)事件;通知事件(NotificationEvent),表示安卓終端的信息通知產(chǎn)生的系統(tǒng)事件;連接事件(Connection Event),表示系統(tǒng)連接產(chǎn)生的系統(tǒng)事件,最終的擴展結(jié)構(gòu)可如圖5 所示.

Fig.5 The Android extension to SystemEvent圖5 系統(tǒng)事件的安卓端擴展

同時,我們還對其中的連接事件和傳感器事件作了進一步的劃分:連接事件可繼續(xù)劃分為5 個子類型:藍牙事件(BlueToothEvent)、NFC 事件(NFCEvent)、WiFi 連接事件(WifiEvent)、P2P 事件(P2PEvent)以及USB 事件(USBEvent);而傳感器事件則可細分為 3 個類型:運動傳感器事件(MotionSensorEvent)、環(huán)境傳感器(Environment SensorEvent)和位置傳感器事件(PositionSensorEvent),其下可繼續(xù)進行劃分,這里不再詳細描述.

安卓端提供了通過壓力和電容感知對屏幕的觸摸捕捉的支持,與PC 的鼠標(biāo)和鍵盤控制相比有著更豐富的動作與手勢.為此,本文為視圖元素事件添加子類型:安卓視圖元素事件(AndroidElementEvent)表示安卓終端上用戶交互所觸發(fā)的事件,在其下還增加了8 個實用子類型:觸摸事件(TouchEvent),表示用戶輕量級觸摸屏幕觸發(fā)的事件;雙擊事件(DoubleTapEvent),表示用戶在屏幕同一處位置快速點擊兩次所觸發(fā)的事件;長按事件(Long PressEvent),表示用戶長按所觸發(fā)的事件;縮捏事件(PinchEvent),表示用戶在屏幕上觸摸由外向內(nèi)縮捏或由內(nèi)向外伸展的行為所觸發(fā)的事件;滑動事件(SwipeEvent),表示用戶左右滑動所觸發(fā)的事件;滾動事件(ScrollEvent),表示用戶上下滑動所觸發(fā)的事件;輸入事件(OnInputEvent),表示為用戶進行文本輸入的事件;拖拽事件(Drap DropEvent),表示為用戶拖拽行為觸發(fā)的事件.同時,與第3.1 節(jié)中自定義組件相對應(yīng),本文也建立了自定義事件(CustomEvent)模板,可供用戶自定義可觸發(fā)的事件以及具體的觸發(fā)行為.最終的擴展結(jié)構(gòu)可如圖6 所示.上述事件的安卓擴展,不僅方便了建模過程,還對執(zhí)行該事件所可能需要的參數(shù)進行了限制,初步進行了標(biāo)準(zhǔn)化,給IFML 建模帶來極大的方便的同時減少了用非形式化語言描述時可能引起的歧義.

Fig.6 The Android extension to ViewElementEvent圖6 視圖元素事件的安卓端擴展

3.4 擴展后的IFML模型實例

仍以第2 節(jié)中驅(qū)動案例Good Weather 為例,使用該擴展后的IFML 為其建模也會更加準(zhǔn)確.圖7 展示了最終建立的擴展后的IFML 模型,并在各元素附近進行了標(biāo)號.

對于圖1-1 中Good Weather 所擁有的主界面,我們以擴展后的屏幕元素來表示,即圖中WeatherMainScreen元素(vc1),在開發(fā)中它對應(yīng)于一個Activity(安卓中最基本的活動應(yīng)用組件).隨后可以看到主界面上存在大量的控件用于顯示天氣信息,在IFML 模型中,我們將這些控件整合起來,使用特殊的類型Detail 來簡化表示,即元素Weather Detail Information(vp4).在主界面的上方,存在一條工具欄,它在實現(xiàn)中作為Activity 的特殊附屬控件ToolBar 或ActionBar 而存在,因此在擴展后的IFML 中,我們將它以工具欄元素ToolBar(vc3)嵌套在WeatherMain Screen 元素內(nèi),來表示它的附屬關(guān)系.而在該工具欄上,存在各式的按鈕、文本以及圖標(biāo),它們在開發(fā)中作為Button、Text 以及ImageButton 等類型的控件而出現(xiàn).在IFML 中則對應(yīng)于本文擴展的按鈕Home Button(vp1)、文本Title(vp2)和圖標(biāo)LocatingIcon 元素(vp3)(這里,為了簡化只顯示了其中的定位圖標(biāo)).隨后,圖1-2 中應(yīng)用的側(cè)邊欄,在開發(fā)中以DrawerLayout 這一布局來實現(xiàn),并且通常為整個應(yīng)用的所有Activity 所共享,為此,我們在IFML 模型中以抽屜元素SideBar 來表示(vc2),并獨立于所有其他的視圖容器類元素.其上也包含這一側(cè)邊欄中的各類文本組件(vp5,vp6,vp7).同時,在主界面和側(cè)邊欄可通過左右滑動來相互切換,因此可使用擴展后的滑動事件,即圖中的right swipe 和left swipe 元素以及它們所引出的交互流(e2,i2和e5,i5)來表示,在開發(fā)中,它們通常對應(yīng)于滑動類型的事件監(jiān)聽器.在工具欄上的Home 按鈕以及定位圖標(biāo)上的點擊事件也類似于此(e1,i1和e3,i3).

可以看到,文中對視圖容器、視圖組件以及事件的擴展可幫助開發(fā)者有效地區(qū)分各個不同類型的界面、控件以及事件.同時,這些IFML 元素也能與各類開發(fā)組件相對應(yīng),因此能夠有效地指導(dǎo)開發(fā)工作系統(tǒng)地進行.

Fig.7 A part of IFML model for Good Weather after the Android extension圖7 擴展后Good Weather 應(yīng)用的部分IFML 模型

此外,該應(yīng)用中與事件交互相關(guān)的邏輯我們也可使用參數(shù)、表達式以及行為來表示.在該應(yīng)用中,用戶需要先進行定位(元素vp3上的觸摸事件e3),隨后應(yīng)用根據(jù)地點位置請求天氣信息數(shù)據(jù)(我們將這個請求過程用行為元素Locating 來表示,即a1),并最終將這一數(shù)據(jù)在組件Weather Detail Information 中顯示出來.這一串邏輯的具體內(nèi)容也需要參數(shù)和表達式的幫助:我們用參數(shù)isLocated(p1)來表示該應(yīng)用是否進行了定位操作并獲取了天氣信息,同時,該參數(shù)使用圖中默認表達式(xd1)將其初始化為false,即最初并未進行定位.根據(jù)設(shè)計意圖,僅當(dāng)進行了定位,即參數(shù)isLocated 為true 時,才會顯示詳細的天氣信息,即組件Weather Detail Information 的顯示.因此,我們將激活表達式(xa1)的內(nèi)容設(shè)置為 if(isLocated){return true;}else{return false;},使其計算結(jié)果與參數(shù)isLocated 保持一致,并由組件Weather Detail Information 持有該激活表達式.顯然,其顯示狀態(tài)最終與參數(shù)isLocated 保持一致,從而達到了我們的設(shè)計要求.對應(yīng)地,Locating 行為具體的邏輯執(zhí)行可以由這一執(zhí)行表達式(xe1)表示:我們以isLocated=true 輕量地表示參數(shù)isLocated 所代表的定位,發(fā)送請求,信息展示這一連串邏輯的執(zhí)行,并且執(zhí)行完成后isLocated 的值發(fā)生了改變,因此也將最終決定組件Weather Detail Information 顯示與否.

通過執(zhí)行表達式的使用,我們將應(yīng)用的內(nèi)部邏輯以表達式的形式進行輕量級的建模,一定程度上避免了使用UML 動態(tài)模型進行詳細的行為建模的繁瑣過程,同時將IFML 中的邏輯表示僅限于IFML 本身,避免了多模型相互引用的情形,最終降低了建模的復(fù)雜度,簡化了建模過程.

本文的安卓端擴展,實際上在IFML 模型的泛用性(抽象能力)以及表現(xiàn)力上達到了一個均衡點.利用該擴展后的IFML 為安卓應(yīng)用進行建模時更加方便、快捷,在降低建模的復(fù)雜度的同時也使得模型所展現(xiàn)的設(shè)計意圖更加精準(zhǔn)、明確.同時,通過將安卓端常用元素加入擴展中,使得建立的IFML 模型也更加貼近實際的安卓應(yīng)用.在開發(fā)過程中,它能夠作為設(shè)計標(biāo)準(zhǔn)指導(dǎo)實現(xiàn)工作的進行,避免實現(xiàn)工作偏離設(shè)計意圖所導(dǎo)致的額外工程量,因此,能夠有效地提高開發(fā)效率.此外,基于該擴展后的IFML 模型,也可實現(xiàn)部分開發(fā)工作的自動化.典型的方式,例如利用這一建立/修改后的IFML 模型,自動化生成實現(xiàn)代碼,或是生成相應(yīng)的測試用例,驅(qū)動應(yīng)用的開發(fā)/演進工作的進行,并最終利用這些用例檢驗應(yīng)用開發(fā)是否正確,都能極大地提高安卓應(yīng)用的開發(fā)效率.為此,本文也研究了對擴展后的IFML 模型的形式化定義,使得通過IFML 模型自動化生成測試用例或是實現(xiàn)代碼,都成為可能.

4 IFML 模型的形式化定義

IFML 標(biāo)準(zhǔn)文檔僅對模型的語法進行了形式化的定義,而其中的語義則采用了自然語言這一類非形式化的方式進行了描述,因此,標(biāo)準(zhǔn)中的許多語義不夠準(zhǔn)確.為了更好地支持IFML 模型在安卓應(yīng)用開發(fā)中的使用,我們對標(biāo)準(zhǔn)中模糊的部分進行了嚴(yán)格的定義,并連同前文提出的安卓端擴展,對擴展后的IFML 模型進行了形式化的定義.更重要的,本文也對IFML 模型的動態(tài)語義進行了形式化定義,從而使得IFML 模型中事件觸發(fā)、交互流傳遞以及模型狀態(tài)遷移都有唯一的解釋.因此,在使用該IFML 模型中的定義來描述安卓應(yīng)用中的界面構(gòu)成,以及界面間的交互時都極為準(zhǔn)確,避免了該IFML 模型在作為設(shè)計意圖體現(xiàn)時可能產(chǎn)生的歧義.

首先,我們給出IFML 模型中各個重要元素的形式化定義.

定義1.X={x1,x2,…,xn}為IFML 模型中被使用到的表達式集合.對于任意x∈X,x為一個三元組x=(xt,l,b),其中,xt用于標(biāo)記該表達式所屬的具體類型;l表示解析當(dāng)前表達式所使用的語言,如Java、OCL 等;b以文本形式存儲了該表達式的表示.本文將X按照不同的類型劃分為不同的集合,由第3.2 節(jié)已知,共有4 個子類型,即X=XA∪XI∪XD∪XE,XA,XI,XD,XE分別表示為激活表達式、交互流表達式、默認表達式以及執(zhí)行表達式的集合.

定義2.VE={ve1,ve2,…,ven}為IFML 模型中視圖元素的集合.VE可進一步分為視圖容器和視圖組件,記為VE=VCT∪VCP,其中,VCT表示視圖容器的集合,VCP表示視圖組件的集合.無論對于視圖容器還是視圖組件,對任意ve∈VE,均有ve=(vet,ax,SE,vc),vet標(biāo)記了該視圖元素的具體類型;ax∈XA為該元素對應(yīng)的激活表達式;SE表示其上可以觸發(fā)的視圖元素事件的集合(見定義5);vc∈VCT,表示該容器/組件的父容器.ax與SE均可為空,當(dāng)ax為空時,該視圖容器/組件默認激活.僅當(dāng)ve∈VCT時,vc可能為空,表示該視圖容器為最外層容器.

定義3.VP={vp1,vp2,…,vpn}為IFML 模型中的視圖組件部件的集合.對于任意vp∈VP,均有vp=(vpt,ax,SE,pvp),vpt表示該視圖組件部件的具體類型;ax表示該視圖組件部分所對應(yīng)的激活表達式,SE表示其上可以觸發(fā)的視圖元素事件的集合,pvp∈VCP∪VP,表示該組件部分所屬的父視圖組件或父視圖組件部件.ax,SE,pvp均可為空,特別地,當(dāng)ae為空時,表示該視圖組件部件默認活躍.

定義4.A={a1,a2,…,an}為IFML 模型中行為的集合.對于任意a∈A,均有a=(at,ax,SE,vc,ex),at表示該行為的具體類型;ax為該行為所對應(yīng)的激活表達式;SE表示從屬于該行為的行為事件的集合;vc表示為該行為所從屬于的視圖容器,即父容器,其值可以為空,表示該行為獨立于所有的視圖容器;ex∈XE,即本文擴展的execution Content,用于表示其內(nèi)部邏輯對應(yīng)的執(zhí)行表達式.

定義5.E={e1,e2,…,en}為IFML 模型中事件的集合.對于任意e∈E,均有e=(et,ax,ix,SI,pe),其中,et表示為該事件的具體類型;ax代表該事件對應(yīng)的激活表達式;ix∈XI為交互流表達式,其計算值表示該事件在當(dāng)前情況下會觸發(fā)哪些交互流;SI表示為該事件可觸發(fā)的交互流的集合;pe表示為該事件所從屬的視圖容器/視圖組件/視圖組件部件/行為.其中,ax,ix,pe均可為空.當(dāng)ax為空時,表示該事件默認活躍,當(dāng)ix為空時,會觸發(fā)SI中所有交互流.本文按照擴展內(nèi)容,將事件E分為3 個類型,記為E=ES∪EA∪EV,其分別表示為系統(tǒng)事件、行為事件以及視圖元素事件的集合.當(dāng)某一事件屬于視圖元素事件時,其pe為視圖容器/視圖組件/視圖組件部件;當(dāng)它為行為事件時,pe恒為行為,即若ae=(et,ax,ix,SI,pe)∈EA,則有pe∈A.

定義6.I={i1,i2,…,in}為IFML 模型中交互流的集合.交互流可分為導(dǎo)向流與數(shù)據(jù)流,記為I=N∪D,對于任一i∈I,均有i=(it,s,t,PBG).其中,it表示該交互流具體為導(dǎo)向流還是數(shù)據(jù)流;s為觸發(fā)當(dāng)前交互流的事件,表示為該交互流的起始點;t為該交互流的終點,t∈VE∪VP∪A,為視圖元素、視圖組件部件或行為.特別地,一個行為事件觸發(fā)的交互流不再導(dǎo)向另一個行為,即任意的行為事件ae=(et,ax,ix,SI,pe),若有交互流i=(it,s,t,PBG)使得i∈SI,則t?A.PBG={pb1,pb2,…,pbn}為參數(shù)綁定組,表示該交互流所攜帶的數(shù)據(jù)綁定信息的集合.對于任意pb∈PB,其表示為一條參數(shù)綁定信息,有pb=(sp,tp),表示為在當(dāng)前狀態(tài)下將源參數(shù)sp的值傳遞給目標(biāo)參數(shù)tp.

定義7.P表示為IFML 模型中被使用到的參數(shù)的集合,有P={p1,p2,…,pn},對于任意p∈P,其可用一個三元組表示p=(d,te,dx):d以枚舉類型表示該參數(shù)p為入?yún)⒒蚴浅鰠?te表示該參數(shù)的具體類型;dx∈XD,以默認表達式的形式給定該參數(shù)在初始情況下的默認數(shù)值.

有了以上定義,我們可以給出IFML 模型的形式化定義.

定義8.一個IFML 模型為一個六元組M=(V,A,E,I,X,P,vI),其中,

·V={v1,v2,…,vn}為視圖元素(視圖容器和視圖組件)和視圖組件部件的集合,即V=VE∪VP.

·A={a1,a2,…,an}為行為的集合.

·E={e1,e2,…,en}為事件的集合.

·I={i1,i2,…,in}為交互流的集合.

·X={x1,x2,…,xn}為表達式的集合.

·P={p1,p2,…,pn}為參數(shù)的集合.

·vI∈V為該IFML 模型最初情況下顯示的視圖容器.

在給出擴展后IFML 模型的語法后,本文也給出該IFML 模型的動態(tài)語義,即對IFML 模型的模型狀態(tài)和模型中的執(zhí)行路徑進行定義.IFML 模型雖然與常用的控制流模型類似,使用交互流來表示狀態(tài)的轉(zhuǎn)化,但是由于其復(fù)雜性,控制流模型中簡單的“點-邊-點”模式難以表現(xiàn)出IFML 模型中交互執(zhí)行的豐富含義.同時,根據(jù)IFML的語義,是事件觸發(fā)了交互流從而導(dǎo)致了狀態(tài)的轉(zhuǎn)化,交互流無法脫離事件而單獨存在,故本文以IFML 模型中的事件和狀態(tài)的交替序列來表示其執(zhí)行路徑.IFML 模型的運行時狀態(tài),可記為CS,表示一組激活的視圖容器、視圖組件、視圖組件部件和行為的集合,以及參數(shù)和它們當(dāng)前值的映射集合.形式化地,狀態(tài)CS可定義為一個二元組(CM,CA),CM為上述的激活元素集合,即CM?V∪A;CA即為上述的參數(shù)和它們當(dāng)前值的鍵值映射集合P→U,其中,P,U分別是參數(shù)以及實際值的集合,對于任意參數(shù)pi∈P,均有唯一實際值ui∈U與之對應(yīng).

為了更好地描述狀態(tài)CS=(CM,CA),我們又有以下函數(shù)的定義.

·定義函數(shù)計算激活表達式來判斷元素是否被激活:對于任意元素vi∈A∪V∪E,其激活表達式ax有函數(shù)eval(vi.ax,CA)=b來計算在CA所給定的參數(shù)值下該激活表達式的值,b為布爾值類型,為true 時,表示該元素vi被激活.

·定義函數(shù)來判斷在給定可見元素時其他元素是否可見:對于任意元素vi,vj∈V∪A,存在函數(shù)Lv(vi,vj)=b,b為布爾值類型,為真時,表示在元素vi可見時vj也可見.當(dāng)給定擁有當(dāng)前狀態(tài)的視圖焦點的可見元素vi∈V時,該元素必定已被激活,即對于vi的激活表達式axi有eval(axi,CA)=true.此時,vi的父容器也必然可見,即對于vi的父容器pvi,有Lv(vi,pvi)=true 成立.據(jù)此定義,該Lv函數(shù)可繼續(xù)遞歸于pvi的父節(jié)點.特別地,當(dāng)可見元素vi∈A時,有且僅有vi自身可見,即僅有Lv(vi,vi)=true.從而我們可以通過該函數(shù)獲取視圖焦點轉(zhuǎn)移后可見元素的集合,即若vi獲得視圖焦點(當(dāng)前可見),則當(dāng)前所有的默認可見元素可用集合{x∈A∪V|Lv(vi,x)=true}來表示.

·定義函數(shù)來執(zhí)行行為中的執(zhí)行表達式:對于任意元素ai=(at,ax,SE,vc,ex)∈A,有函數(shù)exec(ex,CA)=CA′,表示為通過執(zhí)行ai中的執(zhí)行表達式來改變CA中元素的數(shù)值,從而得到新的映射集合CA′來代替CA.

·定義函數(shù)來計算事件中的交互流表達式獲取觸發(fā)的交互流集合:對于任意事件ei=(et,ax,ix,SI,pe)∈E,其下的交互流表達式ix∈XI,存在函數(shù)eval(ix,CA)=SI′,SI′表示為ix所對應(yīng)的事件在當(dāng)前狀態(tài)下所觸發(fā)的交互流的集合,并有當(dāng)ix為空時,eval(ix,CA)=SI.

·定義函數(shù)來執(zhí)行交互流中的參數(shù)綁定信息:對于任意交互流ii=(it,s,t,PBG),若其PBG存在,則有函數(shù)exec(PBG,CA)=CA′表示執(zhí)行這一值的傳遞過程,形成新的參數(shù)與其值的映射集合CA′代替CA表示狀態(tài)參數(shù)的更新.

·定義函數(shù)計算默認表達式初始化參數(shù)的值:對于任意參數(shù)pi=(d,te,dx)∈P,有函數(shù)exec(dx,CA)=CA′表示對該參數(shù)的數(shù)值進行初始化,CA′中參數(shù)pi被賦予了其dx中給定的數(shù)值.并在初始狀態(tài)下,給定CA=?,可對于IFML模型中所有的參數(shù)pi∈P,執(zhí)行CA←exec(dx,CA),最終即可得到其初始的參數(shù)與其值的映射集合.

在當(dāng)前狀態(tài)CS=(CM,CA)下,我們又可以定義函數(shù)enable:CM→E,enable(CM)表示為當(dāng)前狀態(tài)下活躍元素可觸發(fā)的事件集合,并對于其中任意e=(et,ax,ix,SI,pe)∈enable(CM),均需滿足eval(ax,CA)=true,pe∈CM.通過從enable(CM)中選擇任意事件ei=(ete,axe,ixe,SIe,pee)后,我們可以通過以下步驟從原狀態(tài)CS變化到新狀態(tài)CS′,即

1.若pee∈A,則需要先執(zhí)行該行為,記為a=(ata,axa,SEa,vcta,exa),其中的執(zhí)行表達式,即CAi'←exec(exa,CAi).

2.取SI′=eval(ixe,CAi'),由上述定義可知集合SI′表示為該ei在當(dāng)前狀態(tài)下所觸發(fā)的交互流集合,并且其中的導(dǎo)向流集合可記為SNI,SNI?SI′.對于交互流i=(iti,si,ti,PBGi)∈SI′,需要依次執(zhí)行CA′←exec(PBGi,CAi'),即進行參數(shù)的傳遞.

3.根據(jù)第2 步中導(dǎo)向流集合可重新計算新狀態(tài)CS′的CM′:先將CM刪除其中視圖焦點轉(zhuǎn)移過程中失去視圖焦點的部分,即.隨后,添加其獲得視圖焦點的元素,即遍歷選擇SNI中的導(dǎo)向流ii=(iti,si,ti,PBGi)∈SNI,可知下一狀態(tài)下獲得視圖焦點/直接控制流的元素記為ti,對其逐個進行.最終完成遍歷后即可獲得新狀態(tài)CS′下對應(yīng)的CM′.

最終我們可給出下述定義9.

定義9.對于任意給定的IFML 模型M=(V,A,E,I,X,P,vI),根據(jù)M生成的一條n步長(n＞0)的可執(zhí)行路徑ρ定義為以下一條序列:

其中,CSi(0≤i≤n)即為上述定義的在該可執(zhí)行路徑ρ中的一個運行時狀態(tài).特別地,CS0表示為該IFML 模型的初始狀態(tài),記為CS0=(CM0,CA0).為初始化CA0,可先給定CA=?,對該IFML 模型中所有的參數(shù)p=(d,te,dx)∈P,逐次執(zhí)行CA←exec(dx,CA),最終即可得到其初始的映射集合CA0.而已知vI表示為該IFML 模型的初始視圖容器,則有CM0={x∈A∪V|Lv(vI,x)=true&&eval(x.ax,CA0)=true},可以獲得最初的CM0.

不妨仍然以圖 7 所示的 IFML 模型為例.由第 3.4 節(jié)中的建模過程可知,對于該 IFML 模型M,有M=(V,A,E,I,X,P,vI),其中有V={vc1～vc3,vp1～vp7},A={a1},E={e1～e5},I={i1～i5},X={xe1,xa1,xd1},P={p1},且有初始視圖容器vI=vc1,即為圖1-1 所示的主界面(即WeatherMainScreen 元素,其最左端標(biāo)有D 字樣,含義為Default,表示該最外層的視圖容器即為初始容器).此時,初始狀態(tài)CS0=(CM0,CA0).最初CA0=?,對于模型中的唯一參數(shù)p1=(d1,te1,xd1),對其初始化,有CA0←exec(xd1,CA0),CA0={p1→false}為初始的CA.并且,已知當(dāng)且僅當(dāng)vx∈{vc1,vc2,vp1,vp2,vp3,vp4},有Lv(vc1,vx)=true(表示當(dāng)vc1顯示時,這些元素也默認顯示).而其中vp4=(vc1,xa1,?,null),其顯示狀態(tài)受激活表達式xa1影響,在初始狀態(tài)CA0下eval(xa1,CA0)=false,即不顯示.故,CM0={x∈A∪V|Lv(ti,x)=true&&eval(x.ax,CA0)=true},即CM0={vc1,vc2,vp1,vp2,vp3}.至此,初始狀態(tài)CS0=(CM0,CA0)的初始化完成.

隨后,通過函數(shù)enable(CM0)={e1,e2,e3}可獲得當(dāng)前可觸發(fā)的事件.不妨假設(shè)此時執(zhí)行事件為e3,記為e3=(et3,null,null,SI3,vp3).有SI3={i3},有且僅有1 條交互流,即為e3唯一能觸發(fā)的交互流,其中,i3=(it3,e3,a1,?),可知視圖焦點轉(zhuǎn)移到行為a1上,a1=(at1,null,SE1,null,xe1).此時,既無參數(shù)傳遞,也無執(zhí)行表達式,故CA不變,有CA1=CA0={p1→false}.同時,CM首先去除失去焦點的元素,即觸發(fā)事件e3的父元素CM0},有隨后,CM再加上重新獲得視圖焦點的元素,即a1.而a1∈A,由之前的函數(shù)定義可知,有且僅有Lv(a1,a1)=true,且a1未持有激活表達式,故{a1}.通過執(zhí)行事件e3,我們實現(xiàn)了狀態(tài)轉(zhuǎn)移:

而在狀態(tài)CS1下時,enable(CM1)={e4},e4=(et4,null,null,SI4,a1).此時,需執(zhí)行a1中的執(zhí)行表達式xe1,因此有CA2←exec(xe1,CA1),最終CA2={p1→true}.同時,SI4={i4}僅有1 條交互流,i4=(it4,e4,vc1,?)即為所需執(zhí)行的交互流,其目標(biāo)元素vc1將獲得視圖焦點.在去除失去焦點的元素a1后,CM2'=?.已知當(dāng)且僅當(dāng)vx∈{vc1,vc2,vp1,vp2,vp3,vp4},有Lv(vc1,vx)=true,而且CA2={p1→true},eval(xa1,CA2)=true,故與初始狀態(tài)CS0不同,元素vp4也將加以顯示,即,最終,CM2={vc1,vc2,vp1,vp2,vp3,vp4},故我們實現(xiàn)了第2步狀態(tài)轉(zhuǎn)移

從IFML 模型的初始狀態(tài)CS0=(CM0,CA0)開始,按照上述示例不斷地通過enable 函數(shù)選擇一個當(dāng)前可觸發(fā)事件執(zhí)行并更新狀態(tài),我們便可獲得一條可執(zhí)行路徑

通過對擴展后的IFML 模型中各元素的屬性以及各元素間關(guān)系的形式化定義,在將這些元素轉(zhuǎn)化為安卓應(yīng)用中的組件元素,即代碼的生成時,能夠形成固定的轉(zhuǎn)化規(guī)則,使得自動化代碼生成成為可能;而對IFML 模型中模型狀態(tài)以及可執(zhí)行路徑的定義,則制定了IFML 模型狀態(tài)間通過觸發(fā)事件來互相轉(zhuǎn)化的轉(zhuǎn)化規(guī)則,從而使得自動化地遍歷IFML 模型生成測試用例并執(zhí)行成為可能,本文也對這一部分內(nèi)容加以實現(xiàn),可詳見下一節(jié).

5 案例研究與分析

經(jīng)過本文上述章節(jié)對IFML 進行的安卓端擴展,在安卓應(yīng)用開發(fā)中使用該擴展后的IFML 進行對應(yīng)用需求、設(shè)計的建模,能夠使得應(yīng)用的設(shè)計以更精確、更加貼合實際安卓應(yīng)用的方式來加以展現(xiàn).并且,通過文本對該擴展后的IFML 模型的形式化定義,這一IFML 模型除了在設(shè)計和實現(xiàn)上起到這一指導(dǎo)性的作用外,還能具有諸如自動化測試之類的具體用途.基于該IFML 模型的測試能夠檢測應(yīng)用的實現(xiàn)是否與應(yīng)用的設(shè)計保持一致,從而保證應(yīng)用在開發(fā)過程中的正確性,這是設(shè)計模型的一種常見使用場景.本節(jié)將探索擴展的IFML 在安卓應(yīng)用基于模型的測試這一場景下的可行性.為此,本文首先實現(xiàn)了基于擴展的IFML 模型的建模與測試工具ADAMANT,并選取了5 個當(dāng)前較為知名的開源安卓應(yīng)用作為案例來進行分析研究.

5.1 基于擴展的IFML模型的建模與測試工具ADAMANT

工具ADAMANT 源自于IFML 官網(wǎng)上一個基于Sirius 項目[8]的IFML 建模項目.我們對該項目按本文面向安卓應(yīng)用的IFML 擴展進行了修改和完善.最終,ADAMANT 以eclipse 插件的形式集成起來,使用它即可在eclipse IDE 上以圖形化的方式為安卓應(yīng)用進行IFML 建模.如圖8 所示,即為我們提供的IFML 建模視角.

Fig.8 The modeling perspective of ADAMANT圖8 工具ADAMANT 的建模視角

在如圖8 所示的視角中,用戶在建立相應(yīng)的IFML 模型項目后,可以從右側(cè)工具欄內(nèi)選擇不同的包,從中選擇不同類型的IFML 元素,將其拖拽至主界面,這即表示在該IFML 模型中建立了相應(yīng)的元素實例;在選中IFML模型中的元素實例后,也可以在下方的屬性標(biāo)簽欄中對該元素的屬性進行設(shè)置.此外,右側(cè)工具欄中,Android、AndroidExtensions 等即為本文對該工具的安卓端擴展,利用這些包內(nèi)元素,可以簡化建模過程,使用者也可以創(chuàng)建具有安卓特點的元素實例,使得建立的IFML 模型更加貼合安卓應(yīng)用.

隨后,我們也為ADAMANT 添加了測試功能——當(dāng)使用者根據(jù)該IFML 模型中的設(shè)計實現(xiàn)了相應(yīng)的安卓應(yīng)用后,ADAMANT 可以根據(jù)這一IFML 模型自動化地生成相應(yīng)的測試用例,并在給定的設(shè)備上自動化地執(zhí)行,從而檢驗最終實現(xiàn)的應(yīng)用制品是否與原本的應(yīng)用設(shè)計保持一致.具體而言,ADAMANT 讀出了IFML 模型數(shù)據(jù)后,根據(jù)第4 節(jié)中對IFML 模型以及其中可執(zhí)行路徑的定義,ADAMANT 通過模型遍歷的方式,生成大量的可執(zhí)行路徑,并可按不同的事件覆蓋準(zhǔn)則選擇路徑集合將其轉(zhuǎn)化為測試用例并執(zhí)行.

這個過程中,最為重要的即為模型遍歷,圖9 給出了該遍歷算法的偽代碼表示.算法主體,即pathsTraversing函數(shù)的入?yún)S 表示為當(dāng)前模型的狀態(tài),Paths 表示為生成測試用例的集合,SE 則表示為當(dāng)前路徑中事件的集合.模型的遍歷以初始狀態(tài)CS0開始執(zhí)行這一pathsTraversing 函數(shù),Paths 和SE 均為?.在該函數(shù)中,它通過enable函數(shù)獲取當(dāng)前狀態(tài)下任何可能觸發(fā)的事件,遍歷選擇事件加入當(dāng)前的路徑的事件集合SE 中(第2 行～第4 行).若達到中止條件時(第5 行,中止條件諸如當(dāng)前路徑中的事件數(shù)達到了預(yù)先設(shè)定的最大值),則檢查當(dāng)前事件是否未被覆蓋并對該路徑真正可執(zhí)行進行檢測(第6 行).如果可行,便會根據(jù)當(dāng)前的可執(zhí)行路徑生成對應(yīng)測試用例并將其加入Paths 中(第7 行～第9 行);而若未達到中止條件,則通過possibleSIGroup 函數(shù)獲取該事件可能觸發(fā)的交互流(第10 行～第11 行),并根據(jù)選擇的交互流更新模型狀態(tài)為CS′,遞歸上述pathsTraversing 函數(shù)(第12 行～第13 行).此過程中獲得的Paths 集合即為根據(jù)該IFML 模型生成的測試用例集合.最后,ADAMANT 在測試框架Robotium[25]的支持下,將這些測試用例運行在待測應(yīng)用之上,并記錄測試執(zhí)行時間、測試錯誤日志等測試執(zhí)行信息.

Fig.9 The algorithm of generating test cases via traversing the IFML model圖9 遍歷IFML 模型生成測試用例算法

在實際應(yīng)用中,ADAMANT 允許開發(fā)人員將應(yīng)用設(shè)計意圖以IFML 模型的形式來展示,從而指導(dǎo)應(yīng)用的開發(fā)工作,使開發(fā)人員達成統(tǒng)一的設(shè)計認知,避免誤解.同時,ADAMANT 根據(jù)IFML 模型生成的測試用例,可作為應(yīng)用實現(xiàn)和設(shè)計是否保持一致的一個檢驗標(biāo)準(zhǔn),當(dāng)測試用例執(zhí)行失敗時,則說明當(dāng)前的應(yīng)用很可能與設(shè)計意圖相悖,并且ADAMANT 記錄的錯誤日志也可幫助開發(fā)人員定位異常點.在應(yīng)用的演進過程中,ADAMANT 的效果則會更加明顯:開發(fā)人員根據(jù)新的需求使用ADAMANT 對IFML 模型進行修改,以指導(dǎo)應(yīng)用的修改工作,而ADAMANT 高度自動化的測試功能,則避免了在不斷演進過程中測試用例的重復(fù)編寫,提高了開發(fā)效率.

5.2 ADAMANT應(yīng)用建模分析

由于應(yīng)用的開發(fā)工作是一個較為漫長的過程,本文沒有在設(shè)計時就開始利用ADAMANT 進行建模,隨后實現(xiàn)應(yīng)用并使用ADAMANT 的測試功能檢驗開發(fā)工作的正確完成.替代性地,本文直接選擇了當(dāng)前已開發(fā)好的5個知名的應(yīng)用.這5 個應(yīng)用均來自Wiki 和Github 所提供的安卓知名開源應(yīng)用的列表[9,10].我們選定了這些應(yīng)用最新發(fā)布的版本,作為本文的實驗版本.并且,根據(jù)對這些應(yīng)用的使用體驗、核心源代碼理解等獲取的信息,我們使用ADAMANT 對這些應(yīng)用逆向地進行了手工IFML 建模.最終,應(yīng)用ADAMANT 的測試功能,基于這些IFML模型,對應(yīng)用進行了相應(yīng)的測試.表2 展示了這些應(yīng)用的基本信息以及IFML 模型信息.

Table 2 The informations of these 5 five apps and their IFML models表2 5 個應(yīng)用的基本信息以及IFML 模型信息

表2 中展示了這5 個應(yīng)用的版本、類型、代碼行數(shù)以及應(yīng)用代碼中Activity 的數(shù)量(Activity 為安卓應(yīng)用中最重要的應(yīng)用組件,一個Activity 粗略地代表應(yīng)用的一個主界面).受文章篇幅所限,文本在此無法給出這些應(yīng)用的IFML 模型的全部信息,在表中僅給出了這些IFML 模型中各類重要IFML 模型元素,即視圖容器、視圖組件、事件、交互流以及表達式的數(shù)量.此外,表中也給出了建立這些IFML 模型所花費的時間.

總體而言,Activity 數(shù)量以及代碼行數(shù)體現(xiàn)了這些應(yīng)用的規(guī)模,而我們建立的IFML 模型的規(guī)模也與應(yīng)用基本保持一致.雖然建立這些IFML 模型花費了4～20 小時不等,但考慮到我們所選擇的均是當(dāng)前具有較長發(fā)展歷史、具有一定規(guī)模的成熟應(yīng)用,相較于它們數(shù)月的開發(fā)時間來說,花費20 小時以內(nèi)從頭建立這些IFML 模型的代價是可以接受的.并且,這些成本僅為初次成本,隨著應(yīng)用的不斷演進,開發(fā)人員僅需要低額的工作量便可在已有IFML 模型上進行修改,因此,整體的建模成本將會被不斷稀釋.然而,該IFML 模型在開發(fā)中的指導(dǎo)作用可有效地分解開發(fā)復(fù)雜度,促使開發(fā)工作高效、系統(tǒng)地進行.并且,基于該IFML 模型進行的測試能夠有效地提高測試效果,并且避免了在應(yīng)用開發(fā)迭代中編寫測試用例的重復(fù)勞作.此外,該IFML 模型也擁有廣泛的應(yīng)用前景,伴隨著自動化程度的提高,基于該IFML 模型的諸如自動化代碼生成的研究也將被推進,因此,可進一步解放人工勞力,提高開發(fā)效率.據(jù)此,我們認為建立IFML 模型所花費的時間是值得的.

5.3 ADAMANT基于模型測試實驗

為了說明IFML 模型在驅(qū)動安卓應(yīng)用開發(fā)中,除了提供設(shè)計和實現(xiàn)上的指導(dǎo)性作用外的廣泛用途,我們還探索了基于IFML 模型對安卓應(yīng)用進行自動化測試這一方法的可行性.通過上述實驗為這5 個應(yīng)用進行了IFML 建模之后,本文還通過ADAMANT 依據(jù)建立的IFML 模型對這些應(yīng)用進行了測試.使用安卓模擬器作為我們的測試設(shè)備,在測試中將模擬器設(shè)備分別設(shè)置為Nexus5X、Nexus S 以及Pixel,將模擬器的安卓版本分別設(shè)置為4.4、5.0 以及5.1,進行了實驗.最終,這些實驗結(jié)果雖然存在一些輕微的差異,但均可正常進行測試,這表明,利用ADAMANT,同一個IFML 模型可廣泛應(yīng)用于不同的安卓設(shè)備以及安卓版本.

為了量化測試效果,本文還詳細列出了設(shè)備設(shè)置為Nexus5X,安卓版本設(shè)置為5.1 的模擬器下ADAMANT的具體測試結(jié)果,見表3.ADAMANT 運行在8G 內(nèi)存、i7 處理器的Win 10 筆記本電腦之上,最終測試實驗結(jié)果見表3.同時,為了對比測試效果,我們將ADAMANT 進行測試所花費的時間記錄下來(表中“執(zhí)行時間”欄),在相同的應(yīng)用上使用安卓最主流、最廣泛使用的隨機事件流工具Monkey 進行實驗,并給定了相同的執(zhí)行時間.

表3 第2 欄表明了該應(yīng)用對應(yīng)的IFML 模型的事件數(shù),由于在測試中是通過模型遍歷,以事件覆蓋為準(zhǔn)則生成測試用例,因此,IFML 模型規(guī)模越大,事件數(shù)越多,ADAMANT 生成的測試用例也越多,執(zhí)行時間也越長.隨后,其3～5 欄表明使用的測試方法、該方法生成的測試用例數(shù)量以及這些用例中總共執(zhí)行的測試操作或事件數(shù)量.第6 欄～第9 欄則表明了用例執(zhí)行的結(jié)果——包含這些用例中執(zhí)行失敗的數(shù)量、這些用例執(zhí)行所達到的代碼行的覆蓋率、執(zhí)行的時間以及在該測試進行中發(fā)現(xiàn)的缺陷或異常.

Table 3 Testing result of test cases for these 5 apps表3 對5 個應(yīng)用的各項測試執(zhí)行結(jié)果

從靜態(tài)代碼覆蓋率來看,ADAMANT 在這5 個應(yīng)用上均達到了50%以上的代碼覆蓋率,且其均值達到了68.18%,相較于Monkey 的均值49.44%,有將近18.74%的代碼覆蓋率的提升.這一巨大的提升,主要體現(xiàn)在以下3個方面:(1)通過ADAMANT 所建立的IFML 模型具有豐富的語義,且在經(jīng)過擴展后可以以表達式的形式來表示各事件執(zhí)行、元素顯示、頁面跳轉(zhuǎn)之間的關(guān)系,因此,能夠生成高度關(guān)聯(lián)性的測試用例.而Monkey 這類隨機測試由于其隨機性,將會出現(xiàn)大量的冗余以及無效事件,因此拉開了測試差距;(2)由于該IFML 模型是手工建立的,因此在該IFML 模型中,使用者能為特定的輸入控件提供候選輸入內(nèi)容,有效的文本輸入大大提升了測試用例的效果;(3)通過本文的擴展,IFML 模型可以建立種類豐富的事件,用戶操作如長按、雙擊、滑動、縮捏等,系統(tǒng)事件如Wifi 連接、數(shù)據(jù)連接等,而這一點在Monkey 上有較大的欠缺,例如它只能支持簡單的點擊以及滑動這兩種用戶操作.

隨后,在測試用例執(zhí)行上,存在一定量的執(zhí)行失敗測試用例,我們將其展示在表3 第6 欄中.對這些失敗的用例進行了人工檢查,其中,大多數(shù)源自于應(yīng)用本身的缺陷,或是應(yīng)用本身的設(shè)計與建模者的認識相悖,其中便存在著應(yīng)用實際的開發(fā)與初始的設(shè)計不一致的情形.此外,執(zhí)行失敗也與外部環(huán)境存在一定關(guān)聯(lián).例如,在OwnCloud 中,由于網(wǎng)絡(luò)波動或是服務(wù)器異常,部分操作可能會超時,最終導(dǎo)致測試用例執(zhí)行失敗.

最后,在缺陷發(fā)現(xiàn)上,ADAMANT 發(fā)現(xiàn)了6 個缺陷,見表4.而Monkey 只發(fā)現(xiàn)了第5 條.其中,第1、2、4、5條缺陷均引發(fā)了應(yīng)用的崩潰;第3 條和第6 條缺陷未引發(fā)應(yīng)用崩潰,但ADAMANT 檢測到了OwnCloud 和Omni-Notes 應(yīng)用的IFML 模型與實現(xiàn)的不一致性.我們通過對比Github 上相關(guān)的缺陷issue,發(fā)現(xiàn)這兩個缺陷均由開發(fā)者確認為實現(xiàn)中的真實錯誤和疏漏.

Table 4 Details of defects found in these 5 apps表4 5 個應(yīng)用中發(fā)現(xiàn)的缺陷信息

綜合來看,ADAMANT 所實現(xiàn)的測試功能,可在較短時間內(nèi)對應(yīng)用進行有效的測試,達到較高的測試覆蓋率,并發(fā)現(xiàn)應(yīng)用中的缺陷,以及在應(yīng)用中與原本設(shè)計存在偏差的部分.因此,鑒于ADAMANT 良好的測試效果,當(dāng)開發(fā)人員通過ADAMANT 建立IFML 模型作為應(yīng)用的設(shè)計時,其測試功能可以幫助開發(fā)人員檢驗實現(xiàn)完成的應(yīng)用是否與原設(shè)計意圖保持一致,以盡可能地減少實現(xiàn)中的偏差所帶來的額外工作量.另外,ADAMANT 也可支持增量式的開發(fā)過程:在應(yīng)用演進中,開發(fā)者可以逐步建立并不斷豐富IFML 模型,此時,ADAMANT 依然可以進行相應(yīng)的測試,從而指導(dǎo)開發(fā)的進行,并且伴隨著IFML 模型的不斷精化,其生成的測試用例也會更加精確、有效.這一過程中,出眾的測試效果以及極低的測試成本能夠抵消IFML 的建模成本,最終極大地提高開發(fā)效率與質(zhì)量.

6 相關(guān)工作

6.1 關(guān)于移動端應(yīng)用設(shè)計開發(fā)建模的研究

近年來,考慮到目前的移動系統(tǒng)和設(shè)備的繁多,為了降低重復(fù)開發(fā)的成本,將模型應(yīng)用于移動應(yīng)用開發(fā)的研究大量涌現(xiàn)[11].Parada 等人[4]直接基于UML 類圖和時序圖提供移動應(yīng)用的高層抽象模型并實現(xiàn)了自動化生成;Balagtas-Fernandez 等人[12]設(shè)計了Mobia 這一圖像化的移動應(yīng)用建模套件進行移動應(yīng)用的模型驅(qū)動開發(fā);也有專門針對數(shù)據(jù)驅(qū)動的應(yīng)用,基于md2這一MVC 結(jié)構(gòu)模型進行移動端跨平臺模型驅(qū)動開發(fā)的研究[5].近年來,也有不少將圖形化領(lǐng)域特定語言(DSL)應(yīng)用于移動應(yīng)用建模的研究,Vaquero-Melchor 等人[13]對復(fù)數(shù)DSL 進行擴展,用于對應(yīng)用的各個方面的信息,如外部交互、移動性以及上下文環(huán)境等進行建模,并整合為一個active DSL.Rieger 等人[14]提出了Münster App Modeling Language(MAML),一種面向非技術(shù)人員的圖形化DSL,該語言以流程的方式描述了數(shù)據(jù)、視圖、業(yè)務(wù)邏輯以及用戶交互.但MAML 僅以關(guān)鍵的字詞代替了流程中視圖的具體展示和事件交互,因此,在表現(xiàn)移動應(yīng)用豐富GUI 時表現(xiàn)能力不足.此外,Vaupel 等人[15,16]通過在模型上增加其抽象層次,從而提供了一種可詳可略的建模方式,使得移動應(yīng)用開發(fā)更加靈活多變.國內(nèi),杜一等人[17]提出了基于E-UIDL 模型的移動應(yīng)用開發(fā)方法,該模型著重于應(yīng)用界面,并以領(lǐng)域模型、抽象用戶界面模型等等諸多子模型來對界面進行描述,提高其可復(fù)用性及可擴展性,但很顯然,這也引起了模型在可用性上的不足.對于本文所用到的IFML 標(biāo)準(zhǔn),也有類似的研究.Brambilla 等人[18]通過建立移動應(yīng)用的IFML 模型,來生成對應(yīng)的HTML5、CSS3 等網(wǎng)頁代碼,最終包裝在移動端安卓與iOS 平臺的應(yīng)用中,并在實際的開發(fā)案例中進行實驗.然而,該研究仍然需要一定的人工參與,且將網(wǎng)頁代碼作為中轉(zhuǎn)產(chǎn)物將會遺失移動平臺獨有的信息.而本文對IFML 進行了安卓端擴展,使得IFML 用于安卓應(yīng)用建模時擁有較高的匹配度,雖未進行具體的代碼自動化生成工作,但本文還對擴展后的IFML 模型進行了形式化定義,這為代碼自動化生成打下了基礎(chǔ).而在這一定義下,文本實現(xiàn)的基于該IFML 模型的自動化測試方法,也能作為判斷設(shè)計與實現(xiàn)一致性的手段,以驅(qū)動開發(fā)、演進工作的進行.

6.2 關(guān)于IFML建模相關(guān)的研究

現(xiàn)有研究工作中,IFML 被廣泛應(yīng)用于眾多領(lǐng)域之中進行建模以及相應(yīng)擴展的研究.例如,Ed-Douibi 等人[19]利用IFML 建立網(wǎng)頁模型,生成符合REST 原則的網(wǎng)絡(luò)應(yīng)用編程接口;Raneburger 等人在文獻[20]中描述了使用IFML 實現(xiàn)獨立多設(shè)備 GUI 生成的機制,并將其與 Model Based Useware-Engineering(MBUE)和 Unified Communica-tion Platform(UCP)進行了簡單的比較;Frajták 等人[21,22]利用IFML 對一般應(yīng)用建模并轉(zhuǎn)化為對應(yīng)的前端測試模型,并最終利用該模型進行了針對前端的自動化測試用例的生成;Brajnik 等人[23]通過對一般應(yīng)用進行IFML 的建模,提出了將應(yīng)用模型中的數(shù)據(jù)流和控制流進行分離的可能性;Laaz 等人[24]則嘗試將IFML 模型與OWL (Web ontology language)實體整合起來,以增強網(wǎng)頁應(yīng)用的用戶接口的展示.這些基于IFML 模型探索代碼生成與測試執(zhí)行自動化的研究,證明了將IFML 應(yīng)用于軟件開發(fā)自動化的可行性和有效性.此外,Huang 等人[25]提供了從安卓應(yīng)用中抽取IFML 模型的方法,該方法也可與本文的工作相結(jié)合,以降低從已有開發(fā)項目中建立IFML 模型的成本.

6.3 關(guān)于安卓終端應(yīng)用自動化測試的研究

目前,針對安卓應(yīng)用的自動化測試工具,在工業(yè)界,諸如Robotium[26]、Appium[27]以及MonkeyRunner[28]之類的自動化測試執(zhí)行工具已經(jīng)較為普及.近年來,學(xué)術(shù)界大量的研究著眼于利用模型來自動化生成測試用例,著名的有,2012 年Amalfitano 等人基于GUIRipper[29]進行安卓端擴展的研究工作AndroidRipper[30].它以動態(tài)執(zhí)行的方式遍歷安卓應(yīng)用,并生成相應(yīng)的GUI 模型,最終實現(xiàn)測試的目的.從此之后,這類自動化構(gòu)建模型生成測試輸入的測試方法逐漸成為學(xué)術(shù)界安卓測試的主流之一:Azim 等人[31]通過綜合使用靜態(tài)分析和動態(tài)執(zhí)行的方式,生成安卓應(yīng)用對應(yīng)的動態(tài)和靜態(tài)活動轉(zhuǎn)移圖(activity transition graph),從而進行針對性的以及廣度優(yōu)先的應(yīng)用系統(tǒng)化遍歷測試;Choi 等人[32]結(jié)合機器學(xué)習(xí)技術(shù)來構(gòu)建模型,并在學(xué)習(xí)中以頁面跳轉(zhuǎn)來實現(xiàn)狀態(tài)變更,從而減少了應(yīng)用的重啟;2015 年,AndroidRipper 的后續(xù)版本MobiGUITAR[33]誕生,它用一個狀態(tài)機模型代替原來無狀態(tài)的GUI 模型,并且在模型遍歷、更新算法上進行了優(yōu)化;Su 等人[34]采用逆向工程靜態(tài)分析和動態(tài)UI 探測來抽取安卓應(yīng)用的隨機模型,然后基于模型生成測試用例加以執(zhí)行,使用Gibbs 抽樣來分析執(zhí)行結(jié)果,并以此提煉原隨機模型,進一步生成更加有效的測試用例.近年來,不少基于程序分析、隨機測試、組合測試等等的測試方法也引起了學(xué)術(shù)界的關(guān)注.Mirzaei 等人[35]提出了通過程序分析技術(shù)獲取對輸入的各種約束,從而削減測試輸入組合的方法,Song 等人[36]提出了通過直接調(diào)用事件處理器的回調(diào)函數(shù)而非基于 GUI 事件的隨機測試方法,Sadeghi 等人[37]則將安卓權(quán)限引入測試之中,并通過混合式的程序分析方法來減少不必要的權(quán)限組合測試.上述這些方法通常獨立于應(yīng)用的開發(fā)工作,而本文基于IFML 模型進行測試,是作為將IFML 應(yīng)用于安卓應(yīng)用設(shè)計建模,并指導(dǎo)應(yīng)用開發(fā)工作的一環(huán).本文的方法立足于IFML 模型的這一前提,因為IFML 模型的存在,其測試效果更佳,也能發(fā)現(xiàn)應(yīng)用設(shè)計和實現(xiàn)不一致的地方,從而提高了將IFML 模型引入安卓應(yīng)用開發(fā)的功效.

7 總結(jié)和展望

在移動平臺,尤其是安卓平臺飛速發(fā)展的今天,為滿足廣大用戶紛繁復(fù)雜的對移動的需求,安卓應(yīng)用的復(fù)雜度逐級攀升.而安卓設(shè)備和系統(tǒng)存在的多樣化和碎片化,使得在安卓應(yīng)用開發(fā)中增加了額外開發(fā)的工作量和難度.針對這一現(xiàn)象,本文根據(jù)安卓應(yīng)用事件驅(qū)動的特性,將IFML 模型引入安卓應(yīng)用的開發(fā)過程,希望開發(fā)者能將應(yīng)用的設(shè)計以IFML 模型的形式進行具象化,降低開發(fā)難度,指導(dǎo)應(yīng)用的開發(fā)工作.然而,目前寬泛的IFML 并不適用于移動/安卓應(yīng)用建模,為此,本文對IFML 標(biāo)準(zhǔn)進行了面向安卓端的擴展,對擴展后的IFML 模型進行了形式化定義,使得無論是基于IFML 模型生成代碼還是執(zhí)行測試等等方法都成為可能.最后,本文實現(xiàn)了相應(yīng)的建模與測試工具ADAMANT,使用它為5 個應(yīng)用建立了IFML 模型,并基于這些IFML 模型進行了自動化測試.其良好的實驗結(jié)果顯示了本文對IFML 進行的安卓端擴展、對IFML 模型進行的形式化定義的有效性,以及將其應(yīng)用于軟件開發(fā)過程中的可行性.

當(dāng)前,該方法處于初步建立的階段,其應(yīng)用于真實的安卓軟件開發(fā)中的有效性還有待檢測.因此,在未來的研究中,我們將在實際的應(yīng)用開發(fā)案例中,將完全人工開發(fā)的方式以及基于該擴展后的IFML 模型的開發(fā)方式,乃至于其他模型驅(qū)動開發(fā)方法進行對比實驗,將應(yīng)用初次開發(fā)所花費的成本以及隨著軟件演進時的持續(xù)成本、產(chǎn)品質(zhì)量等作為衡量標(biāo)準(zhǔn)來評判這一方法在實際開發(fā)中的有效性.

在自動化方面,本文目前僅將IFML 模型應(yīng)用于測試的生成與執(zhí)行.在未來工作中,我們將研究通過IFML模型自動化生成應(yīng)用代碼的方法.由于IFML 模型能夠精確地描述應(yīng)用的GUI 結(jié)構(gòu)以及其中的工作流傳遞,我們初步計劃為通過IFML 模型,自動化地生成應(yīng)用的主體骨架,包含:應(yīng)用中主要的Activity(包含應(yīng)用的GUI 界面以及界面上的控件元素)、控件元素上的各類事件監(jiān)聽器以及事件監(jiān)聽器中各GUI 界面相互跳轉(zhuǎn)的邏輯代碼.這些代碼可來自于安卓應(yīng)用與對應(yīng)擴展后的IFML 模型的資源庫,該資源庫可通過相關(guān)工作中介紹的IFML模型抽取技術(shù),對當(dāng)前開源安卓應(yīng)用進行抽取獲得.隨后,我們可基于該資源庫,通過結(jié)合機器學(xué)習(xí)和模型驅(qū)動開發(fā)技術(shù),來實現(xiàn)這些代碼的自動化生成,或是通過尋找相似IFML 模型片段直接獲得實現(xiàn)代碼.隨后,開發(fā)人員可對未生成的應(yīng)用業(yè)務(wù)邏輯進行補充,形成一個半自動化的開發(fā)方式,降低開發(fā)中的人工成本,提高效率.