王詩(shī)宇，劉洪星 ，2，范家佳

1.武漢理工大學(xué) 計(jì)算機(jī)科學(xué)與技術(shù)學(xué)院，武漢 430063

2.武漢理工大學(xué) 交通物聯(lián)網(wǎng)技術(shù)湖北省重點(diǎn)實(shí)驗(yàn)室，武漢 430070

1 引言

為支持市場(chǎng)上存在的多種移動(dòng)平臺(tái)（Android、iOS等），需對(duì)同一移動(dòng)應(yīng)用進(jìn)行多次開發(fā)。對(duì)于同一移動(dòng)應(yīng)用，雖然其界面構(gòu)件、整體布局以及后臺(tái)邏輯處理不需要做出很大的調(diào)整，但必須使用不同的技術(shù)實(shí)現(xiàn)同一用戶界面的不同版本[1]。用戶界面開發(fā)所耗費(fèi)的時(shí)間和其代碼量在整個(gè)應(yīng)用軟件開發(fā)過(guò)程中所占比重較大，是一個(gè)成本高、耗時(shí)的任務(wù)。當(dāng)前大部分移動(dòng)用戶界面開發(fā)方法都是面向運(yùn)行平臺(tái)的，與具體的編程語(yǔ)言密切相關(guān)，以手工編碼為主，這種開發(fā)方式存在開發(fā)效率低、維護(hù)成本高、難以移植等缺點(diǎn)，因此需要研究跨平臺(tái)的用戶界面開發(fā)的有效方法。

模型驅(qū)動(dòng)架構(gòu)[2]（Model Driven Architecture，MDA）是國(guó)際標(biāo)準(zhǔn)化組織OMG制定的具有標(biāo)準(zhǔn)性質(zhì)并被廣泛認(rèn)可的軟件開發(fā)框架，它將軟件開發(fā)的注意焦點(diǎn)從代碼提升到模型這一更高的抽象層次。交互流建模語(yǔ)言（Interaction Flow Modeling Language，IFML）是OMG制定的可視化建模標(biāo)準(zhǔn)，用于表達(dá)軟件應(yīng)用前端的內(nèi)容、用戶交互、行為控制[3]。Brambilla等人在IFML基礎(chǔ)上提出了Mobile IFML，使其能夠描述移動(dòng)應(yīng)用特征[4-5]。

模型驅(qū)動(dòng)的移動(dòng)用戶界面開發(fā)過(guò)程如圖1所示，其中Mobile IFML處于MDA架構(gòu)的M2層[6]，用于表示平臺(tái)無(wú)關(guān)[7]的移動(dòng)用戶界面概念模型（Mobile User Interface Conceptual Model，MUICM）。要得到具體的移動(dòng)用戶界面（Android平臺(tái)用戶界面、iOS平臺(tái)用戶界面、微信小程序用戶界面等），需執(zhí)行模型轉(zhuǎn)換操作，自動(dòng)或半自動(dòng)地生成用戶界面程序代碼。

圖1 模型驅(qū)動(dòng)的移動(dòng)用戶界面開發(fā)過(guò)程

本文以Android 為目標(biāo)平臺(tái)，研究移動(dòng)用戶界面概念模型到Android原生應(yīng)用用戶界面代碼的轉(zhuǎn)換方法與工具。

2 移動(dòng)用戶界面概念模型到代碼的轉(zhuǎn)換

模型到代碼的轉(zhuǎn)換可直接生成目標(biāo)代碼，減少人工編寫的代碼量，大幅度提高開發(fā)效率。在該過(guò)程中需要考慮兩種不同的環(huán)境：模型處理器和目標(biāo)環(huán)境。模型處理器是模型解析器、概念模型和代碼生成器有機(jī)組合的整體；目標(biāo)環(huán)境是為生成最終代碼及其周邊環(huán)境準(zhǔn)備的[8]。模型轉(zhuǎn)換的核心是映射規(guī)則（Mapping Rules）和轉(zhuǎn)換算法（Transformation Algorithm）。映射規(guī)則把模型中的元素映射為目標(biāo)代碼中的具體元素，是模型轉(zhuǎn)換的前提[9]；轉(zhuǎn)換算法負(fù)責(zé)模型處理器的調(diào)度[10]，定義映射規(guī)則的執(zhí)行步驟和順序。

2.1 概念模型文件結(jié)構(gòu)

Mobile IFML 提供了一組基本構(gòu)件（Construct）和連接規(guī)則（Connection Rules）。其中，MUICM元素表示MUICM 的頂層模型元素，可直接或間接包含其他所有模型元素；Screen（屏幕容器）元素是移動(dòng)用戶界面的基本單元，用來(lái)描述界面組件的嵌套關(guān)系，可自身嵌套也可容納其他界面組件；List（列表）元素是一種視圖組件，表示移動(dòng)用戶界面中的列表組件，必須嵌套于屏幕容器，可容納粒度更小的視圖組件；SelectionField（選擇域）元素表示移動(dòng)用戶界面中允許用戶在一組選項(xiàng)中選擇其中一個(gè)或多個(gè)的區(qū)域，其余元素定義見文獻(xiàn)[3-4]。

借助Mobile IFML 表示得到的移動(dòng)用戶界面概念模型基本構(gòu)件遵循MVC（Model-View-Controller）軟件設(shè)計(jì)模式[3]。概念模型的邏輯結(jié)構(gòu)表現(xiàn)為XML形式[11]，如圖2所示。其中，、等為XML 節(jié)點(diǎn)；“muicm：Screen”“muicm：Form”等為節(jié)點(diǎn)類型；name、isHome 等為節(jié)點(diǎn)屬性。把類型為“muicm：Screen”的節(jié)點(diǎn)簡(jiǎn)稱為Screen 節(jié)點(diǎn)，把類型為“muicm：SimpleField”的節(jié)點(diǎn)簡(jiǎn)稱為SimpleField節(jié)點(diǎn)，其他節(jié)點(diǎn)采用類似簡(jiǎn)稱。

圖2 概念模型的XML表示

概念模型文件整體呈現(xiàn)為樹形結(jié)構(gòu)，以圖2的概念模型為例，其樹形結(jié)構(gòu)如圖3 所示。在樹形結(jié)構(gòu)中，XML 節(jié)點(diǎn)與概念模型元素對(duì)應(yīng)，節(jié)點(diǎn)屬性與概念模型元素屬性對(duì)應(yīng)。如MUICM節(jié)點(diǎn)與模型中的MUICM元素對(duì)應(yīng)；Screen 節(jié)點(diǎn)與模型中的Screen 元素對(duì)應(yīng)，該節(jié)點(diǎn) name、isHome 屬性與 Screen 元素的 name、isHome 屬性對(duì)應(yīng)；SimpleField節(jié)點(diǎn)與模型中的SimpleField元素對(duì)應(yīng)，該節(jié)點(diǎn) name 屬性與 SimpleField 元素 name 屬性對(duì)應(yīng)。根據(jù)組件粒度大小的不同可將樹形結(jié)構(gòu)分為不同層次，每層出現(xiàn)的節(jié)點(diǎn)類型來(lái)自于特定的元素類型集合，用M1表示第一層節(jié)點(diǎn)類型集合，M2表示第二層節(jié)點(diǎn)類型集合，M3 表示第三層節(jié)點(diǎn)類型集合，以此類推。以M1和M2為例，對(duì)集合進(jìn)行簡(jiǎn)單說(shuō)明，M1={MUICM}，表示樹形結(jié)構(gòu)的根（Root）節(jié)點(diǎn)類型只能是MUICM；M2={Screen，MViewComponent，OtherAction，CameraAction，MicrophoneAction，DataBindingGroup，NotificationEvent，MSensorEvent，MResourceEvent，NavigationFlow，Data-Flow}，表示樹形結(jié)構(gòu)的第二層節(jié)點(diǎn)類型來(lái)源于M2 集合中的元素類型。圖3中樹形結(jié)構(gòu)的高度為四層，第一層僅包含MUICM 根節(jié)點(diǎn)，第二層包含Screen 節(jié)點(diǎn)，第三層包含 Form 節(jié)點(diǎn)，第四層包含 SimpleField、Label、SubmitEvent 等節(jié)點(diǎn)。從理論上來(lái)說(shuō)，概念模型的樹形結(jié)構(gòu)可以無(wú)限高，但結(jié)合實(shí)際移動(dòng)應(yīng)用中用戶界面的層次結(jié)構(gòu)，屏幕容器的直接嵌套層數(shù)不宜過(guò)多，本研究將屏幕容器的直接嵌套層次限制為三層，整個(gè)樹形結(jié)構(gòu)的高度最多為六層。

圖3 概念模型樹形結(jié)構(gòu)

概念模型樹形結(jié)構(gòu)是n(n≥0)個(gè)節(jié)點(diǎn)的有限集合。當(dāng)n>0 時(shí)，有且僅有一個(gè)名稱為MUICM的根節(jié)點(diǎn)；根節(jié)點(diǎn)MUICM 作為對(duì)樹形結(jié)構(gòu)的組織，不進(jìn)行轉(zhuǎn)換；當(dāng)n>1 時(shí)，除根節(jié)點(diǎn)以外的其余節(jié)點(diǎn)可以分為m(m>0)個(gè)互不相交的有限集合T1,T2,…,Tm，其中每一個(gè)集合本身也是一個(gè)樹形結(jié)構(gòu)，稱為根節(jié)點(diǎn)的子樹，是模型轉(zhuǎn)換研究的重點(diǎn)；父節(jié)點(diǎn)和子節(jié)點(diǎn)之間代表一種嵌套關(guān)系，父節(jié)點(diǎn)容納子節(jié)點(diǎn)，子節(jié)點(diǎn)嵌套于父節(jié)點(diǎn)；對(duì)于嵌套于同一父節(jié)點(diǎn)的子節(jié)點(diǎn)，先出現(xiàn)的子節(jié)點(diǎn)優(yōu)先級(jí)較高。

2.2 目標(biāo)代碼文件結(jié)構(gòu)

Android構(gòu)建用戶界面的方式有三種：（1）使用XML布局文件控制用戶界面；（2）在Java 代碼中控制用戶界面；（3）使用XML布局文件和Java代碼混合控制用戶界面。最后一種構(gòu)建方式將變化小、行為比較固定的組件放在XML布局文件中進(jìn)行管理，變化較多、行為較復(fù)雜的組件交給Java代碼進(jìn)行管理。

本文采用第三種方式構(gòu)建用戶界面。對(duì)于MUICM的視圖層（View）元素，生成XML標(biāo)簽，并在Java代碼中獲取該界面組件；對(duì)于MUICM的控制層（Controller）和模型層（Model）元素，生成Java 類和方法并與相關(guān)界面組件關(guān)聯(lián)，實(shí)現(xiàn)用戶與特定界面組件的交互、界面跳轉(zhuǎn)等功能。

2.3 映射規(guī)則

映射規(guī)則的左側(cè)是移動(dòng)用戶界面概念模型元素，右側(cè)是包含元數(shù)據(jù)的最終用戶界面代碼段，可分為四類，結(jié)合實(shí)例對(duì)不同類型的映射規(guī)則進(jìn)行說(shuō)明，如圖4所示。

圖4 映射規(guī)則實(shí)例

（1）直接映射：模型元素直接映射為目標(biāo)代碼中的元素，如模型中的Label元素可映射為Android代碼中的TextView元素。

（2）屬性相關(guān)映射：針對(duì)同一模型元素，根據(jù)其屬性不同映射為目標(biāo)代碼中的不同元素，如SelectionField元素，對(duì)其數(shù)據(jù)類型為Boolean 的isMultiSelection 屬性進(jìn)行判斷，若為真，則映射為CheckBox 元素，否則映射為RadioButton元素。

（3）用戶交互相關(guān)映射：針對(duì)同一模型元素，根據(jù)用戶交互結(jié)果映射為目標(biāo)代碼中的不同元素，如Simple-Field 元素，根據(jù)用戶選擇的目標(biāo)元素類型可映射為EditText元素、AutoCompleteTextView元素或MultiAuto-CompleteTextView元素。

（4）父元素類型相關(guān)映射：針對(duì)同一模型元素，根據(jù)其是否有某類型的父元素映射為目標(biāo)代碼中的不同元素，如Screen 元素，若其有類型為Screen 的父元素則映射為Fragment元素，否則映射為Activity元素。

2.4 轉(zhuǎn)換算法

轉(zhuǎn)換算法的工作實(shí)質(zhì)是讀取模型文件，解析得到所有模型元素；讀取映射規(guī)則文件，解析得到所有映射規(guī)則；對(duì)于每一個(gè)模型元素，調(diào)用與之匹配的映射規(guī)則進(jìn)行轉(zhuǎn)換，得到目標(biāo)元素，生成最終用戶界面代碼。本文設(shè)計(jì)的MUICM到Android用戶界面代碼轉(zhuǎn)換算法如下所示。

輸入：MUICM文件。

輸出：目標(biāo)代碼文件。

步驟1 對(duì)XML 結(jié)構(gòu)描述的概念模型文件進(jìn)行解析，獲得概念模型根節(jié)點(diǎn)MUICM。

步驟2 獲取概念模型中所有類型為Screen 的直接子節(jié)點(diǎn)集合S(v)，如果S(v)為空集，則結(jié)束，否則，執(zhí)行步驟3。

步驟3 獲取S(v)中的第一個(gè)節(jié)點(diǎn)v。

步驟4 生成以該節(jié)點(diǎn)name 屬性值為文件名稱的Java文件和XML文件。

步驟5 獲取v的所有類型非Screen 的直接子節(jié)點(diǎn)E(e)，如果E(e)為空集，則轉(zhuǎn)向步驟11，否則，執(zhí)行步驟6。

步驟6 獲取E(e)的第一個(gè)節(jié)點(diǎn)e。

步驟7 獲取與該節(jié)點(diǎn)匹配的映射規(guī)則集合MR，按照如下判斷進(jìn)行轉(zhuǎn)換：（1）若映射規(guī)則集中規(guī)則的個(gè)數(shù)為1，則直接進(jìn)行轉(zhuǎn)換，生成目標(biāo)類或目標(biāo)標(biāo)簽；（2）若映射規(guī)則集中規(guī)則的個(gè)數(shù)大于1，則根據(jù)映射規(guī)則中定義的條件進(jìn)行匹配，若能匹配，則進(jìn)行轉(zhuǎn)換，生成目標(biāo)類或目標(biāo)標(biāo)簽。

步驟8 在得到目標(biāo)類或目標(biāo)標(biāo)簽的基礎(chǔ)上，添加相關(guān)代碼細(xì)節(jié)信息，寫入步驟4 生成的Java 文件和XML文件中。

步驟9 獲取e的所有子節(jié)點(diǎn)集合E(e)，若E(e)為空集，則執(zhí)行步驟10，否則轉(zhuǎn)向步驟6。

步驟10 獲取e的下一個(gè)兄弟節(jié)點(diǎn)ev，若ev為空，則執(zhí)行步驟11，否則轉(zhuǎn)向步驟7。

步驟11 獲取v的所有類型為Screen的直接子節(jié)點(diǎn)集合S(v) ，若S(v) 為空集，則執(zhí)行步驟12，否則轉(zhuǎn)向步驟3。

步驟12 獲取v的下一個(gè)兄弟節(jié)點(diǎn)bv，若bv為空，則結(jié)束，否則轉(zhuǎn)向步驟4。

在代碼生成之前，用戶可對(duì)移動(dòng)用戶界面概念模型進(jìn)行手動(dòng)非實(shí)時(shí)驗(yàn)證。如：同一Screen元素包含的元素name屬性唯一等。轉(zhuǎn)換算法根據(jù)源模型元素之間的邏輯關(guān)系和層次對(duì)生成目標(biāo)代碼中的元素進(jìn)行組合，保證代碼中各元素之間的組成關(guān)系符合其源模型元素在概念模型中的關(guān)系和約束，真正地實(shí)現(xiàn)概念模型到目標(biāo)代碼的整體轉(zhuǎn)換，而不僅僅是單一的元素映射。轉(zhuǎn)換算法中補(bǔ)充的代碼段嚴(yán)格遵循Android 中XML 和Java 語(yǔ)言的規(guī)范，模型的合法性以及補(bǔ)充代碼的規(guī)范性等均保證了目標(biāo)代碼的良構(gòu)（well-formed）和有效（valid），即生成的目標(biāo)代碼結(jié)構(gòu)符合Android 用戶界面代碼中XML 和Java語(yǔ)言的一系列結(jié)構(gòu)規(guī)則。同時(shí)，結(jié)構(gòu)正確的代碼可以通過(guò)上下文有關(guān)性質(zhì)的檢查，包含類型檢查、一致性檢查、相關(guān)名字檢查、名字作用域分析檢查等。經(jīng)過(guò)轉(zhuǎn)換得到的目標(biāo)代碼，可構(gòu)建出基本的具體移動(dòng)用戶界面，用戶可進(jìn)行界面組件的添加和細(xì)化、界面布局的調(diào)整以及邏輯層代碼的填充完善，得到最終移動(dòng)用戶界面。

3 基于模板的模型轉(zhuǎn)換

模板（template）可以看作是目標(biāo)代碼的原型，與目標(biāo)代碼相似度較高，可讀性較強(qiáng)。模板化的代碼生成器包含三個(gè)主要組件：模板、語(yǔ)境和生成器。模板是目標(biāo)文本文件的源文本，包含動(dòng)態(tài)部分和靜態(tài)部分，其中動(dòng)態(tài)部分由標(biāo)注表示，標(biāo)注會(huì)調(diào)用語(yǔ)境對(duì)象生成元素；語(yǔ)境是動(dòng)態(tài)數(shù)據(jù)的源，即生成模板所需的數(shù)據(jù)模型，本文中的語(yǔ)境為移動(dòng)用戶界面概念模型；生成器是結(jié)合模板和語(yǔ)境生成最終結(jié)果的工具，控制模板生成程序的執(zhí)行。對(duì)不同的語(yǔ)境使用同樣的模板，可生成對(duì)應(yīng)的輸出結(jié)果。本文采用基于模板的代碼生成語(yǔ)言，構(gòu)建模板化代碼生成器，對(duì)上述映射規(guī)則和轉(zhuǎn)換算法進(jìn)行實(shí)現(xiàn)。

3.1 基于Acceleo的代碼模板

Acceleo[12]是 OMG的M2T（MOF Model to Text）規(guī)范[13]的標(biāo)準(zhǔn)實(shí)現(xiàn)，是一個(gè)基于MDA 的開源自動(dòng)代碼生成器，作為Eclipse 插件集成于Eclipse IDE 中。符合元模型類型（UML、ECore、用戶自定義的元模型等）的模型都可以作為Acceleo 的輸入，得到符合目標(biāo)編程語(yǔ)言的任意代碼文件，如C、Java、Python等。Acceleo由多個(gè)成為模塊（module）的文件構(gòu)成。其中，模塊以輸入模型遵從的元模型的URI 作為參數(shù)，由模板構(gòu)成；模板是文本產(chǎn)生式規(guī)則（text production rules）的序列（sequence）；文本產(chǎn)生式規(guī)則是靜態(tài)文本（static text）、注釋（comments）、表達(dá)式（expressions）、模板調(diào)用（template invocation）和塊（block）的序列。本文按照Acceleo 的語(yǔ)法規(guī)則定義了映射規(guī)則和配置文件模板。映射規(guī)則模板包含MUICM 中各元素模板，如Screen 元素模板等，是映射規(guī)則的實(shí)現(xiàn)，可包含子模板也可嵌套于其他模板中。

本研究定義的模板較多，本文重點(diǎn)介紹映射規(guī)則模板，限于篇幅，僅展示其中一個(gè)。以圖4 中的第二種映射規(guī)則為例，展示SelectionField元素模板，如圖5所示，第11行對(duì)該元素isMultiSelction屬性判斷，第12～16行用于生成CheckBox控件，第18～22行用于生成RadioButton控件。模板中的表達(dá)式是文本產(chǎn)生式規(guī)則的動(dòng)態(tài)部分，如 aSelectionField.isMultiSelection、[aSelectionField.name.toLowerCase（）/]，與輸入的概念模型密切相關(guān)，主要是對(duì)模型特定元素特定屬性的動(dòng)態(tài)獲取，該部分會(huì)在執(zhí)行時(shí)替換為輸入模型元素的相關(guān)屬性值。

3.2 代碼生成執(zhí)行過(guò)程

在映射規(guī)則模板和配置文件模板的基礎(chǔ)上，按照?qǐng)D6 所示的執(zhí)行過(guò)程實(shí)現(xiàn)最終代碼的自動(dòng)或半自動(dòng)生成。激活器（activator）對(duì)代碼生成器的生命周期進(jìn)行控制，包括代碼生成器的啟動(dòng)（start）和停止（stop）；代碼生成器（code generator）負(fù)責(zé)對(duì)執(zhí)行過(guò)程的調(diào)度，是轉(zhuǎn)換算法的實(shí)現(xiàn)，通過(guò)指定源模型文件、目標(biāo)代碼文件路徑，配置模塊文件，設(shè)置運(yùn)行參數(shù)列表完成其初始化，構(gòu)建代碼生成所需環(huán)境，為生成目標(biāo)文件做準(zhǔn)備。首先，代碼生成器以一種深度優(yōu)先遍歷和廣度優(yōu)先遍歷結(jié)合的方式依次讀取模型解析器解析出的模型元素；然后，調(diào)用模塊文件，文本產(chǎn)生式規(guī)則中的文件（file）塊生成初始的目標(biāo)文件，循環(huán)（for）塊根據(jù)滿足條件的元素個(gè)數(shù)，零或多次執(zhí)行循環(huán)體中的模板，條件（if）塊根據(jù)條件的真假?zèng)Q定是否執(zhí)行條件中的模板；調(diào)用Acceleo 提供的函數(shù)獲取模型元素，如eContents（）函數(shù)返回當(dāng)前元素的直接子元素序列，ancestor（）函數(shù)返回當(dāng)前元素的父元素序列，在此基礎(chǔ)上獲取與該元素相關(guān)的信息，并根據(jù)模型元素匹配文件中的模板，寫入目標(biāo)文件。靜態(tài)文本原樣寫入目標(biāo)文件，注釋不做任何處理，Java 服務(wù)在查詢（query）塊中進(jìn)行注冊(cè)并在模板中進(jìn)行調(diào)用，保證用戶與模型轉(zhuǎn)換過(guò)程的交互，獲取用戶交互結(jié)果，寫入目標(biāo)文件；最后，得到目標(biāo)代碼文件。

圖5 SelectionField元素模板

圖6 代碼生成執(zhí)行過(guò)程

4 工具實(shí)現(xiàn)與實(shí)驗(yàn)

為了支持上述代碼生成過(guò)程，本文基于Eclipse 平臺(tái)[14]實(shí)現(xiàn)了一個(gè)支持移動(dòng)用戶界面開發(fā)的輔助工具。下面基于該工具，結(jié)合實(shí)例，展示模型驅(qū)動(dòng)的移動(dòng)用戶界面開發(fā)方法和執(zhí)行效果。

4.1 移動(dòng)用戶界面開發(fā)工具

移動(dòng)用戶界面開發(fā)工具的目標(biāo)，是輔助開發(fā)者進(jìn)行界面的設(shè)計(jì)與實(shí)現(xiàn)。該工具框架分為四層，分別為Eclipse基礎(chǔ)平臺(tái)、Eclipse集成開發(fā)環(huán)境、基礎(chǔ)工具框架、應(yīng)用層，如圖7 所示。以Eclipse 作為基礎(chǔ)平臺(tái)，依托EMF（Eclipse Modeling Framework）、GMF（Graphical Modeling Framework）、OCL（Object Constraint Language）、Acceleo和RCP（Rich Client Platform）插件組成一個(gè)集成開發(fā)環(huán)境，開發(fā)圖形化編輯窗口，實(shí)現(xiàn)概念模型的可視化創(chuàng)建；開發(fā)模型處理器，實(shí)現(xiàn)概念模型到用戶界面代碼的轉(zhuǎn)換；配置彈出菜單[15]，調(diào)用模型轉(zhuǎn)換功能，支持模型驅(qū)動(dòng)的移動(dòng)用戶界面開發(fā)。

圖7 移動(dòng)用戶界面開發(fā)工具框架

4.2 運(yùn)行實(shí)例

移動(dòng)用戶界面開發(fā)工具的主界面如圖8 所示。應(yīng)用該工具進(jìn)行界面開發(fā)的具體步驟如下：

步驟1 界面需求分析，分析待開發(fā)移動(dòng)應(yīng)用界面的主要組件、界面支持的事件、界面之間的跳轉(zhuǎn)關(guān)系以及應(yīng)用所需權(quán)限。

步驟2 概念建模，將步驟1中的組件、事件、界面跳轉(zhuǎn)及權(quán)限抽象成界面開發(fā)工具支持的模型元素，并在圖形化編輯器中進(jìn)行概念建模。

步驟3 模型轉(zhuǎn)換，對(duì)步驟2中建立的概念模型執(zhí)行轉(zhuǎn)換，模型中的部分元素需要通過(guò)用戶交互決定目標(biāo)元素，生成目標(biāo)代碼。

步驟4 利用相關(guān)開發(fā)工具（如Android Studio），對(duì)生成的目標(biāo)代碼進(jìn)行人工調(diào)整和優(yōu)化，包括添加業(yè)務(wù)邏輯代碼，調(diào)整界面布局，最后進(jìn)行編譯。編譯完成后的軟件項(xiàng)目可在模擬器上調(diào)試，也可打包成安裝程序文件在Android設(shè)備上實(shí)際運(yùn)行。

本節(jié)基于實(shí)現(xiàn)的移動(dòng)用戶界面開發(fā)工具開發(fā)圖書管理App。該應(yīng)用提供登錄、注冊(cè)、展示書籍列表等功能。圖8中的圖形化編輯窗口展示了注冊(cè)、登錄和主界面的概念模型，通過(guò)點(diǎn)擊彈出菜單調(diào)用模型轉(zhuǎn)換功能，完成用戶界面代碼的生成，運(yùn)行結(jié)果如圖9所示。

圖8 開發(fā)工具主界面

圖9 生成用戶界面實(shí)例

在該實(shí)例中，根據(jù)204 行XML 代碼半自動(dòng)地生成適配于Android平臺(tái)的界面代碼，其中XML代碼行數(shù)為622 行，Java 代碼行數(shù)為657 行，調(diào)整后的應(yīng)用包含661行XML代碼，835行Java代碼。借助該工具對(duì)具有不同組件的界面進(jìn)行多次開發(fā)實(shí)驗(yàn)，結(jié)果表明，代碼生成率即自動(dòng)生成代碼行數(shù)占最終總代碼行數(shù)的比率均在80%左右。由于概念模型不涉及控件具體位置及界面布局的元素，暫不能生成該部分代碼，需要手動(dòng)添加；模型中對(duì)業(yè)務(wù)邏輯部分元素的引用是獨(dú)立的，暫不能實(shí)現(xiàn)該部分代碼的復(fù)用。模型驅(qū)動(dòng)的移動(dòng)用戶界面開發(fā)方法縮短了得到應(yīng)用初始版本的時(shí)間，提高了開發(fā)效率。

5 總結(jié)與展望

針對(duì)現(xiàn)階段移動(dòng)用戶界面重復(fù)開發(fā)的問(wèn)題，本文以移動(dòng)用戶界面概念模型為基礎(chǔ)，定義了概念模型到Android 用戶界面代碼的映射規(guī)則，借助基于模板的代碼生成語(yǔ)言對(duì)映射規(guī)則進(jìn)行實(shí)現(xiàn)；設(shè)計(jì)并實(shí)現(xiàn)了模型轉(zhuǎn)換算法，以深度和廣度優(yōu)先遍歷算法結(jié)合的方式對(duì)模型元素進(jìn)行遍歷，匹配映射規(guī)則；開發(fā)了一個(gè)支持該模型轉(zhuǎn)換的移動(dòng)用戶界面開發(fā)工具原型，用戶利用該工具先設(shè)計(jì)用戶界面概念模型（平臺(tái)無(wú)關(guān)模型），之后，該工具可自動(dòng)或半自動(dòng)地將概念模型轉(zhuǎn)換成Android用戶界面代碼。

目前，該開發(fā)工具只支持概念模型到Android 平臺(tái)代碼的轉(zhuǎn)換，對(duì)概念模型到iOS 平臺(tái)、微信小程序等用戶界面代碼的轉(zhuǎn)換還未實(shí)現(xiàn)，這是本文下一步需要進(jìn)行的工作。