吳昊
摘要:基于模型的用戶界面開發(fā)方法是解決多設備環(huán)境下用戶界面開發(fā)問題的一個常用方法。然而,當前主要的開發(fā)方法中存在著多種問題。本文提出的基于模型的用戶界面開發(fā)方法,主要包括領域模型、任務模型和界面模型,對應于MVC模式中領域模型、控制模型和視圖模型。由于在模型設計階段隱含了交互式系統(tǒng)的體系結構,因而不僅能保證系統(tǒng)的有用性和可用性,而且模型向界面工具箱編碼的轉化簡單直接。從而有效的解決了一些主要的開發(fā)方法中存在的問題。
關鍵詞:基于模型的用戶界面開發(fā);多設備用戶界面;MVC模式;卡梅隆參考框架;人機交互
中圖分類號:TP311.5
文獻標識碼:A
DOI:10.3969/j.issn.1003-6970.2015.08.002
0 引言
隨著普適計算、云計算等新型計算模式的發(fā)展,計算設備呈現(xiàn)出日益多樣性、異構化的特征。手動為具有不同交互特點的設備開發(fā)不同的用戶界面版本,難以開發(fā)出風格一致且具有相同的可用性的用戶界面,也帶來了巨大的工作量和商業(yè)成本。目前,克服這一困難普遍認可的方法是基于模型的用戶界面開發(fā)(MBUID),也就是使用模型從高層抽象出用戶界面的特征,然后再將其映射為各種不同平臺上的最終界面,達到自動或者半自動的生成用戶界面的目的。這一方法是當前人機交互中的一個研究和應用熱點。
通過對目前存在的大量的MBUID方法的研究發(fā)現(xiàn),大多數(shù)MBUID側重于界面呈現(xiàn)給用戶的外觀方面即表示、行為模型的抽象及轉換,而忽視了或者較少提及功能核心以及功能核心和界面之間的通信控制部分對界面構建的影響,而就本質(zhì)而言,用戶界面對構建運行時系統(tǒng)是不充分的。因而,一方面,在系統(tǒng)設計階段,系統(tǒng)的體系結構和用戶界面模型之間存在著較大的間隔。另一方面,在代碼設計時,自動生成的用戶界面難以很自然的和有著一定體系結構的用戶界面工具箱(如Java Swing,asp.net,QT等)融為一體。從而交互式系統(tǒng)的有用性和可用性難以得到全面有效的保證。
本文以流行的體系結構模式MVC為例,提出將其與在MDUID中得到廣泛應用的卡梅隆參考框架結合起來進行用戶界面的開發(fā)方法,其核心思想是在模型設計階段就充分考慮最終實現(xiàn)時界面工具箱的體系結構,從而能夠很好的解決上述問題。
1 相關工作
使用基于模型的方法開發(fā)交互式系統(tǒng),通過一系列模型來抽象和構建用戶界面的相關部分,避免在設計階段過多介入設備和環(huán)境的技術細節(jié),而集中于設計用戶界面的語法部分,可以提高用戶界面的生產(chǎn)效率和質(zhì)量。Dygimes是一個可以為移動設備和嵌入式系統(tǒng)自動生成用戶界面的運行時環(huán)境,采用了用戶為中心的方法,類似于我們的方法,使用并發(fā)任務樹(CTT)從任務規(guī)格開始設計用戶界面。TERESA是一種轉換方法,同我們的方法類似,根據(jù)卡梅隆參考框架構建,并遵從一個正向的工程過程。TansformiXML是一個基于屬性圖文法的UsiXML工具,該工具對于不同的使用上下文在同一抽象層次對模型進行轉換。然而這些方法除了存在具有一個陡峭的學習曲線、模型過于繁雜難以維護、不易支持不斷變化的用戶界面需求等問題外,一個比較突出的問題是缺乏一個與功能核心良好集成的機制。本文的方法旨在對上述問題的解決作以探索性研究。
多數(shù)基于模型的方法都使用用戶界面描述語言(UIDL)作為工具描述其構建的模型,例如TERESA和TransformXML。UIDL是模型自動轉換的基礎。本文作者開發(fā)了一個用戶界面描述語言MDUIDL,該UIDL是本文提出的開發(fā)方法使用工具之一。
2 開發(fā)方法的框架
一個好的交互式系統(tǒng)首先要提供完整的功能,完全滿足用戶的需求,才能成為一個有用的系統(tǒng)。另外還要具有美觀易用的界面,使用戶具有良好的用戶體驗,才能保證商業(yè)上的成功。有用性和可用性二者缺一不可。為了保證有用性,應從用戶的需求出發(fā),以用戶為中心,構建出充分考慮界面、功能及二者之間的通信與控制的體系結構。為了保證可用性,一般從用戶的任務出發(fā),依據(jù)用戶使用系統(tǒng)時需要完成的目標導出用戶將如何使用界面,完成界面的觀與感的設計。但是二者在開發(fā)中應該是渾然一體的,不能割裂開來。否則,將會導致生產(chǎn)出有用性完整但是可用性差或者可用性高但有用性不完整的系統(tǒng),或者因為界面和功能核心無法高效連接而產(chǎn)生笨拙低效甚至失敗的系統(tǒng)。
本文提出的MBUID方法的框架如圖1所示,其核心是模型集合,包含三種主要的模型:領域模型對功能核心進行建模,它相當于MVC中的模型部分;任務模型對用戶任務建模,在實現(xiàn)中表現(xiàn)為對領域模型和界面模型之間的交互進行控制,相當于MVC中的控制部分。為了簡化程序設計,本方法的特色之一是對任務模型中常用的功能構建相應于編程語言的類庫;界面模型對用戶界面建模,分為抽象模型和具體模型,相當于MVC中的視圖部分。具體模型經(jīng)MDUIDL代碼生成引擎轉化為相應的最終界面。模型集合中的大部分模型都可以用我們開發(fā)的用戶界面描述語言MDUIDL表示。
模型集合中包含了卡梅隆參考框架的所有模型,但突出了領域模型和任務模型的重要性,同時和MVC模式無縫的集成在一起。此外,該方法還有有以下特點:集中考慮交互式系統(tǒng)的體系結構,同時顧及領域模型、用戶任務模型和用戶界面模型的開發(fā)并周密設計三者之間的關系與連接,從而充分的保證系統(tǒng)的有用性和可用性;熟悉該方法的開發(fā)者可以從這三種模型的任何一個開始開發(fā)系統(tǒng),沒有順序上的限制,甚至可以并行開發(fā),都能保證設計出一個功能和界面無縫結合的系統(tǒng);由于從設計時采用了MVC體系結構,系統(tǒng)從設計到實現(xiàn)的過渡是自然的,可以方便的把設計時的說明性模型自動或者半自動的轉化為系統(tǒng)的功能部分。
3 開發(fā)方法的設計
3.1 領域模型設計
領域模型對功能核心進行建模,它相當于一個功能核心適配器(Adapter),把功能核心和用戶界面需要交互的數(shù)據(jù)包裝起來。領域模型用MDUIDL的EDL部分表示。
3.2 任務模型及編程語言類庫設計
任務建模的主要目的是抽象出為了實現(xiàn)用戶目標而需要執(zhí)行的邏輯活動(任務)、這些活動之間的關系以及活動所操控的領域數(shù)據(jù)和界面元素。我們利用ConcurTaskTree( CTT)作為任務的標記方法。CTT認為在高級層次上任務是目標,低級層次上任務是交互,而且它支持設計任意復雜程度的應用。從任務角度分析應用系統(tǒng),可以在隨后的設計活動中維持系統(tǒng)的可用性。
與一般基于CTT的界面開發(fā)中從CTT導出用戶界面模型的方式有所不同,我們的方法中,任務模型除了表征任務及任務之間的關系外,它還作為未來交互式系統(tǒng)的一個有機部分,在MVC結構的程序中指導著控制器的生成,負責領域模型和界面模型之間的對話與控制。這樣,使得模型集合到最終系統(tǒng)的生成有著直接的映射關系。為此,我們對CTT進行了必要的擴充,在CTT的非葉節(jié)點加入狀態(tài)元素。該元素中登記了領域模型中的數(shù)據(jù)類型或者界面模型中的元素類型的實例,從而建立起兩者之間的連接關系。當CTT中的葉子節(jié)點(應用任務、交互任務)被激活時,它用中序遍歷查找到其上層祖先節(jié)點中的狀態(tài)元素,從而操控狀態(tài)元素連接的領域數(shù)據(jù)或者界面元素。
為了簡化程序的設計和編寫,我們把擴充的CTT任務模型到編程語言的映射中常用的功能設計成編程語言類庫。目前實現(xiàn)了Java語言的編程類庫,其結構如圖2所示。其中,抽象任務是其它任務的父類,它包含其它任務的共有操作。組合任務是任務樹中的非葉子節(jié)點,起著組織管理作用。它對任務的組織是依據(jù)CTT規(guī)定的八種時序關系對應而來,擁有八個相應的子類。這些子類負責對任務樹中其后代節(jié)點進行管理,例如,T1和T2為EnalbeTask的后代,則只有當T1發(fā)出teminate信號后,T2才能進行activate操作。組合任務可以和用戶界面里的一個容器部件關聯(lián)起來,表明該任務和這個容器有著通信關系。它還可以包括狀態(tài)元素。應用任務一般涉及和領域模型進行數(shù)據(jù)交互,而交互任務和界面模型中的元素有著對應關系。應用任務和交互任務都可以和界面里的一個具體交互元素(如按鈕,標簽等)關聯(lián)起來。
3.3 界面模型設計
界面模型描述界面的外觀和行為。它可以分為抽象界面模型和具體界面模型。
3.3.1 抽象界面模型
抽象界面模型不涉及界面的交互模態(tài)、用戶偏好、平臺類型和編程語言等使用上下文,是用戶界面的抽象表示。它分類界面元素的交互類型,并把它們根據(jù)一定的結構組織起來。在我們的工作中,定義了八種交互類型:輸入、輸出、選擇、修改、創(chuàng)建、銷毀、開始和結束。抽象界面模型表現(xiàn)為一個森林結構。森林中的每棵樹的非葉節(jié)點都用一個Group節(jié)點來表示,葉子節(jié)點為某種交互類型。抽象用戶界面模型用MDUIDL的AIDL描述。
3.3.2 具體界面模型
具體界面模型描述了在某種使用上下文中的用戶界面模型。它從抽象界面模型轉化而來,其轉化規(guī)則用MDUIDL的SIDL表示。SIDL類似于一個樣式表,它把AIDL的結構和交互類型具體化為具有一定組織特征的工具箱級的界面元素。例如一個OUT交互類型可以轉化為HTML中的一行文本,或者Java Swing中的一個JLabel。轉化后的具體界面模型用MDUIDL的DIDL表示,DIDL可以進一步轉化為最終的界面。
3.4 三個模型之間的連接
三個模型之間可以兩兩進行連接。連接關系主要通過任務模型的狀態(tài)元素完成(領域模型直接和界面模型連接除外)。例如,領域模型和任務模型中的某個應用任務進行連接時,在該應用任務的父節(jié)點上產(chǎn)生一個狀態(tài)元素,領域模型中的數(shù)據(jù)和這個狀態(tài)元素任何一方變化時,都將導致對方產(chǎn)生相應的變化和操作。另外,在設計階段,一個模型中的元素可以導致其它模型中元素的生成。例如,任務模型中的一個交互任務已經(jīng)確定,它可以引起界面模型中的一個元素產(chǎn)生。這種生成關系自動引起生成和被生成元素之間的連接。連接和生成關系使得不僅從宏觀上方法的應用框架展現(xiàn)出MVC模式的結構,而且,從微觀上來說,模型的具體元素之間也存在著MVC模式的結構,從而向界面工具箱的轉化更為簡單和直接。
任務模型在建模階段,它的CTT元素一般和界面模型中的抽象界面模型連接。這種連接關系在任務模型轉化為語言類庫中的類時,與抽象界面模型轉化為具體界面模型同步保持。最后在生成交互式系統(tǒng)時,語言類庫中的類被自動或者手動的嵌人工具箱的控制器中,而相應的具體界面模型的元素則自動或者半自動的轉化為最終的用戶界面的單元,成為MVC結構中的視圖元素。
4 開發(fā)方法的實例與評估
為了驗證開發(fā)方法的有效性,我們使用該方法基于jdk7.0開發(fā)了一個圖書管理系統(tǒng)。作為演示,圖3給出了設計管理員或者普通用戶登錄后臺圖書管理系統(tǒng)時,登錄界面的領域模型、任務模型和抽象界面模型。其中領域模型封裝了登錄類型、用戶名和密碼。任務模型實質(zhì)上是一個并發(fā)任務樹,圖中非葉節(jié)點的右邊注明了它所要轉化為編程語言類庫的類。界面模型的容器節(jié)點和交互類型節(jié)點和任務模型的節(jié)點一一關聯(lián)起來。圖4和圖5分別是該模型圖的Java Swing和JSP的實現(xiàn)??梢钥闯鲇捎谠谀P驮O計中隱含了系統(tǒng)的體系結構,引入了并發(fā)任務樹,一方面能夠很好的保證系統(tǒng)的有用性和可用性,另一方面說明性的模型可直接轉化為可執(zhí)行的功能模塊。
5 結束語
我們提出的MBUID方法,不僅具有易學易用、模型類型較少、使用起來相當靈活的特點,而且能夠全面考慮一個交互式系統(tǒng)的各個側面,有效的解決了當前MBUID方法中存在的一些問題。通過我們的實踐證明,該方法能保證系統(tǒng)的有用性和可用性,模型設計和代碼實現(xiàn)能夠緊密結合。未來的工作中,我們將開發(fā)支持工具,提高使用該方法開發(fā)系統(tǒng)的自動化程度。