楊 蕾 劉正捷(大連海事大學(xué)信息科學(xué)技術(shù)學(xué)院 遼寧 大連 116026)
圖形用戶界面(GUI)允許用戶使用輸入設(shè)備,例如在屏幕上進(jìn)行操作,這些操作包括選擇命令、調(diào)用該文件、啟動(dòng)程序或執(zhí)行其他常規(guī)任務(wù)[1]。GUI極大地方便了非專業(yè)用戶的適當(dāng)行動(dòng),用戶不用記住冗雜的命令,可以通過窗口、菜單進(jìn)行相應(yīng)的操作[2]。文獻(xiàn)[2]對GUI技術(shù)在國內(nèi)外的專利申請情況進(jìn)行了統(tǒng)計(jì),并進(jìn)行相應(yīng)技術(shù)的分析,從中可以看出GUI在國內(nèi)外發(fā)展是如此迅速。GUI的應(yīng)用領(lǐng)域也非常的多:手機(jī)移動(dòng)端產(chǎn)品、電腦系統(tǒng)、軟件產(chǎn)品等。用戶界面是否能夠滿足用戶的需求已經(jīng)成為評判系統(tǒng)成功與否的重要指標(biāo),因此為用戶提供一個(gè)可靠、靈活、簡單易用的用戶界面是設(shè)計(jì)人員需要重點(diǎn)關(guān)注的事情。但是,GUI在設(shè)計(jì)過程中還是存在著許多困難的,文獻(xiàn)[3]中指出在GUI設(shè)計(jì)的過程中有時(shí)候無法真正理解到用戶真正的需求,導(dǎo)致最終系統(tǒng)搭建完成后仍需要花費(fèi)額外的人力物力去迭代改進(jìn)。
在GUI設(shè)計(jì)和開發(fā)的過程,任務(wù)模型占著很重要的位置,文獻(xiàn)[4]中也提到可以用模型搜集用戶需求和任務(wù),這樣可以防止盲目開發(fā)帶來的成本以及人力物力上的損失,提高設(shè)計(jì)人員的工作效率,從而設(shè)計(jì)出滿足用戶需求的GUI系統(tǒng)。然而,現(xiàn)有的任務(wù)模型具有很多的局限性,并不適用于面向數(shù)據(jù)可視化的GUI設(shè)計(jì),致使生成的界面很難完全滿足用戶的需求,因此,本文對WISDOM任務(wù)模型進(jìn)行相應(yīng)的改進(jìn),并用改進(jìn)后的WISDOM任務(wù)模型分析與設(shè)計(jì)數(shù)據(jù)可視化系統(tǒng)的用戶界面,采用模型驅(qū)動(dòng)的方式開發(fā)數(shù)據(jù)可視化系統(tǒng)的GUI。
在普適計(jì)算的環(huán)境中,用戶與設(shè)備之間的交互方式越來越多樣,在交互的過程中也需要考慮使用設(shè)備所處的環(huán)境,為了順應(yīng)這種多樣化,越來越多的設(shè)計(jì)人員將模型的方法使用在用戶界面設(shè)計(jì)以及開發(fā)過程中。任務(wù)模型可以在抽象層次上描述界面,可以通過模型的轉(zhuǎn)換,使它在不同的平臺也可以重用[4]。用戶界面設(shè)計(jì)是基于模型的,它在開發(fā)用戶界面的過程中使用了任務(wù)模型,是一種新方法,最早的任務(wù)模型是HTA模型[5]。它使用層次分析的方式描述任務(wù)活動(dòng),是任務(wù)模型的基石[6]。現(xiàn)如今,基于HTA方法已經(jīng)優(yōu)化衍生出其他的任務(wù)分析模型,如GOMS[7]、CTT[8]、TKS[9]等。隨著UML成為面向?qū)ο笤O(shè)計(jì)方法的主流,也涌現(xiàn)了一些經(jīng)過擴(kuò)展UML描述任務(wù)建模的方法,如WISDOM、LOTOS[10]、PETRINET[11]等形式化語言也可以用于任務(wù)建模[7]。雖然形式化語言方便設(shè)計(jì)師建模,但是對設(shè)計(jì)師自身的專業(yè)能力有一定的要求,而且對于用戶來說也是很難理解的,所以會造成設(shè)計(jì)師與用戶之間的溝通障礙。
HTA模型是以結(jié)構(gòu)化方式用任務(wù)層級描述任務(wù)之間的關(guān)系[5],它早已被廣泛用于分析用戶任務(wù),是基于系統(tǒng)的設(shè)計(jì)。HTA模型將人機(jī)交互的過程比作成一種序列或者是對話,這個(gè)原因?qū)е履P偷目捎眯圆⒉缓茫驗(yàn)樵诖罱ㄈ蝿?wù)模型的過程中可能會有更有效的方式去達(dá)到最初的任務(wù)目標(biāo)[12]。HTA方法所描述的任務(wù)操作屬于隱性的,設(shè)計(jì)人員在使用的過程中不能明顯地看出任務(wù)過程中任務(wù)之間的關(guān)聯(lián)。只能表示順序、選擇和循環(huán)這三種時(shí)序關(guān)系。
GOMS模型是描述任務(wù)在實(shí)踐過程中是如何執(zhí)行的一種認(rèn)知任務(wù)模型[7]。建模的過程首先需要確定好一個(gè)目標(biāo),然后將目標(biāo)進(jìn)行逐個(gè)分解,當(dāng)完成目標(biāo)的方法出現(xiàn)多種路徑時(shí),可以根據(jù)所處的情境,通過選擇規(guī)則選擇一個(gè)最優(yōu)解。該模型只能表示順序、選擇、并行和循環(huán)這幾種時(shí)序關(guān)系。
TKS模型假設(shè)一個(gè)人已經(jīng)掌握了相關(guān)的特定任務(wù)的知識,用戶執(zhí)行特定的任務(wù)為一個(gè)TKS,TKS保存在任務(wù)的知識結(jié)構(gòu)中,當(dāng)觸發(fā)相關(guān)的TKS任務(wù)時(shí),它就會立刻被激活[13]。但它沒有考慮到用戶所處的環(huán)境不同,還會受外界環(huán)境的干擾,模型不能根據(jù)特殊環(huán)境而進(jìn)行相應(yīng)的改變。
CTT(Councer Task Tree)模型將暫態(tài)關(guān)系進(jìn)行定義,每個(gè)暫態(tài)關(guān)系均有圖形符號一一對應(yīng)[14]。暫態(tài)關(guān)系是指執(zhí)行順序和執(zhí)行結(jié)束的定義,以及在任務(wù)執(zhí)行過程中的任意一個(gè)子任務(wù)之間的關(guān)系。但其只能做一些簡單的統(tǒng)計(jì),不能評估系統(tǒng)的性能,還沒有自動(dòng)生成代碼的工具。
WISDOM模型[15]繼承并優(yōu)化了CTT方法的時(shí)序關(guān)系表示形式,符合UML的規(guī)范,可以用現(xiàn)有的UML相關(guān)的編輯器進(jìn)行建模,也可以將用戶界面任務(wù)方面的建模與表示模型和領(lǐng)域模型聯(lián)系起來。
通過比較分析,表1給出了各種方法的表示形式、支持的時(shí)序關(guān)系、適用范圍、相關(guān)的建模工具??紤]到各種模型的優(yōu)缺點(diǎn)以及本文所要研究的課題,最終選用了WISDOM模型來設(shè)計(jì)數(shù)據(jù)可視化的GUI界面,為了讓W(xué)ISDOM模型更好地適用于GUI設(shè)計(jì),因此對WISDOM模型進(jìn)行了相應(yīng)改進(jìn),為設(shè)計(jì)人員提供更好的適用于GUI設(shè)計(jì)的任務(wù)建模方法。
表1 方法表示形式、時(shí)序關(guān)系、適用范圍、建模工具
續(xù)表1
WISDOM是在CTT的基礎(chǔ)上創(chuàng)建出來的具有UML語義的一種任務(wù)模型[15]。通過約束擴(kuò)展機(jī)制將UML和CTT進(jìn)行整合,令UML也可以在用戶界面建模的過程中適用,使用UML中的約束機(jī)制來表示任務(wù)之間的時(shí)序關(guān)系。約束在模型中表示元素之間的語義約束,它規(guī)定條件和命題必須是true[16]。在CTT模型中,使用擴(kuò)展的LOTOS運(yùn)算符表示任務(wù)之間的順序、選擇、并行等多種時(shí)序關(guān)系[17]。表2中展示出了CTT模型中涉及到的關(guān)系名稱,WISDOM模型延用了CTT中部分常用關(guān)系,通過現(xiàn)有UML表示法將CTT中的元素和任務(wù)關(guān)系引入U(xiǎn)ML2.0中,利用了UML類的約束、關(guān)聯(lián)和依賴定義的衍型來表達(dá)其結(jié)構(gòu)關(guān)系[18]。
表2 新增的關(guān)系名稱、符號、釋義
續(xù)表2
WISDOM中關(guān)聯(lián)類的表現(xiàn)形式及相應(yīng)的語義如表3所示。
表3 關(guān)聯(lián)類的表現(xiàn)形式及相應(yīng)的語義
WISDOM中任務(wù)之間的時(shí)序關(guān)系是通過關(guān)聯(lián)之間來約束的,有三種約束模式及相應(yīng)的語義如下。
{xor}:任務(wù)集合T是一個(gè)任務(wù)的有限集合,T={t1,t2,…,tn};執(zhí)行t1{xor}t2=(t1∧t2)∨(t1∧t2)。
{sequence}:任務(wù)集合T是一個(gè)任務(wù)的有限集合,T={t1,t2,…,tn};?i∈{1,2,…,n},ti+1只能等ti執(zhí)行完成之后才能執(zhí)行。
{deactivate}:任務(wù)集合T是一個(gè)任務(wù)的有限集合,T={t1,t2,…,tn};?i∈{1,2,…,n},ti+1可以在ti運(yùn)行過程中激活并執(zhí)行,此時(shí)ti立即被終止。
任務(wù)類及其語義如下。
{abstract task}:需要復(fù)雜活動(dòng)且性能不能單獨(dú)分配的任務(wù)。
{user task}:用戶不與系統(tǒng)交互的情況下執(zhí)行的任務(wù)。
{application task}:應(yīng)用程序完全執(zhí)行的任務(wù)。
{interaction task}:用戶與系統(tǒng)交互執(zhí)行的任務(wù)。
雖然CTT語義嚴(yán)密但只能進(jìn)行一些簡單設(shè)計(jì)且對用戶界面中其他模型的支持不足[18],而WISDOM任務(wù)模型的建立可以使UML也可以對用戶界面進(jìn)行建模,恰恰彌補(bǔ)了CTT的不足,通過將CTT關(guān)系符號優(yōu)化改進(jìn)并與UML的關(guān)聯(lián)類相適配,最終可以成功將CTT中時(shí)序關(guān)系表達(dá)形式映射到WISDOM任務(wù)模型中,具體映射形式如圖1所示。
由于WISDOM任務(wù)模型須應(yīng)用在系統(tǒng)的GUI設(shè)計(jì)中,原有的模型并不適用于GUI設(shè)計(jì),所以需要對現(xiàn)有的WISDOM任務(wù)模型進(jìn)行相應(yīng)的優(yōu)化,為了更加準(zhǔn)確地適用于后續(xù)的GUI設(shè)計(jì)中,給出如下的定義。
任務(wù)類中需要增加的內(nèi)容:
定義1{system task}:系統(tǒng)完全執(zhí)行的任務(wù)。
定義2{view task}:為實(shí)現(xiàn)某一交互任務(wù),系統(tǒng)需要提供的視圖界面。
關(guān)聯(lián)類中需要增加的內(nèi)容:
定義3<>:表示從用戶端接收到的信息,即用戶可以操作的信息。
定義4<
定義5<
WISDOM任務(wù)模型是屬于軟件工程的一種方法,所以其開發(fā)過程符合軟件生命周期:需求、分析、設(shè)計(jì)、實(shí)現(xiàn)四個(gè)階段[18]。定義了系統(tǒng)開發(fā)過程中的具體步驟以及每一階段所需建立的內(nèi)部模型與外部模型,以模型為驅(qū)動(dòng)的方法進(jìn)行GUI與核心應(yīng)用模塊的開發(fā)[19]。所以在GUI設(shè)計(jì)過程中WISDOM模型也需要進(jìn)行相應(yīng)的改進(jìn),下面將按照軟件的生命周期進(jìn)行描述。
(1) 獲取用戶需求:采用觀察、問卷、訪談等方法獲取與用戶需求相關(guān)的數(shù)據(jù)。
(2) 需求分析:使用UML用例圖表現(xiàn)用戶與GUI交互過程中的需求。
(3) 找出各個(gè)用例中的對象及對象之間的關(guān)聯(lián),畫出GUI用例圖。
挖掘建立內(nèi)部分析模型 、GUI交互模型類。具體方式為:
(1) 輸入需求階段利用UML畫出的類圖。
(2) 找出每一用例中的<
(3) 區(qū)分需求階段UML用例圖的{user task}和{system task},找出{task}()和{view task}()。
(4) 找出任務(wù)類與實(shí)體類之間的關(guān)聯(lián),建立內(nèi)部模型與外部模型的聯(lián)系。
設(shè)計(jì)階段分為GUI設(shè)計(jì)和系統(tǒng)內(nèi)部設(shè)計(jì)。內(nèi)部設(shè)計(jì)需要遵照UML的相關(guān)設(shè)計(jì)規(guī)則,利用WISDOM任務(wù)分析模型建立相關(guān)模型后,進(jìn)一步使用UML中的其他圖來建立內(nèi)部相關(guān)行為。具體方式為:
(1) 繪制對話模型。將分析階段提煉出的{user task}用CTT模型的形式呈現(xiàn)出來,表示它們之間的交互情況,利用樹的形式表達(dá)出來,其中任務(wù)之間的邏輯關(guān)系分為父任務(wù)與子任務(wù),將父子之間的時(shí)序關(guān)系相應(yīng)地表示出來。
(2) 繪制表示模型。表示模型指用戶界面的最終呈現(xiàn)。同理,將分析階段提煉出的{view task}用CTT模型的形式呈現(xiàn)出來,利用定義好的<
利用編譯手段以及相應(yīng)的配置將GUI應(yīng)用程序移植到系統(tǒng)中。
大數(shù)據(jù)時(shí)代的到來讓越來越多的人開始使用數(shù)據(jù)可視化幫助設(shè)計(jì)人員分析數(shù)據(jù)。數(shù)據(jù)可視化將繁雜的數(shù)據(jù)轉(zhuǎn)化成易于辨識的圖形,以更加直觀的形式幫助人們理解數(shù)據(jù),增強(qiáng)了分析數(shù)據(jù)的可讀性。現(xiàn)如今數(shù)據(jù)可視化系統(tǒng)多種多樣,但好多設(shè)計(jì)出來的系統(tǒng)都是面向?qū)I(yè)人士以及企業(yè)的,對于用戶來說學(xué)習(xí)成本較高且并未很好地滿足用戶需求,所以如何設(shè)計(jì)出面向普通用戶使用、滿足用戶需求、呈現(xiàn)什么樣的圖形界面是現(xiàn)如今我們需要著重解決的事情。所以本節(jié)利用優(yōu)化后的WISDOM任務(wù)模型幫助解決這個(gè)問題。
數(shù)據(jù)可視化的圖形界面是用戶與系統(tǒng)數(shù)據(jù)進(jìn)行信息交互的平臺,通過訪談的形式確立最終GUI需求提供的主要功能有:導(dǎo)入數(shù)據(jù)文件,系統(tǒng)設(shè)置,數(shù)據(jù)概覽,條件篩選,粗/細(xì)粒度,保護(hù)功能,溝通對話,動(dòng)態(tài)呈現(xiàn),幫助引導(dǎo),即用即存。如圖2所示,將需求分析階段的成果用用例圖來表示,以方便后續(xù)操作。
圖2 GUI用例圖
將需求階段獲取的用例圖進(jìn)行進(jìn)一步細(xì)分,這里以導(dǎo)入數(shù)據(jù)文件為例。導(dǎo)入數(shù)據(jù)文件的需求包括導(dǎo)入數(shù)據(jù)文件的形式以及查找數(shù)據(jù)文件的存儲位置。其中導(dǎo)入數(shù)據(jù)文件的形式包括導(dǎo)入新的數(shù)據(jù)和導(dǎo)入已創(chuàng)建工作簿;查找數(shù)據(jù)文件存儲位置是在選擇導(dǎo)入文件形式后篩選不同形式的數(shù)據(jù)存儲文件。如圖3所示,最左邊表示的是{user task},其次是{system task}、{view task}和{task}。{user task}和{system task}是需求分析階段的成果,表示導(dǎo)入數(shù)據(jù)文件時(shí)用戶和可視化系統(tǒng)的交互流程。用戶和系統(tǒng)交互的過程中,很容易辨別出交互過程中數(shù)據(jù)可視化系統(tǒng)需要呈現(xiàn)給用戶的{view task}以及需要進(jìn)行人機(jī)交互的{task}類。其中虛線剪頭表示系統(tǒng)在交互的過程中需給用戶呈現(xiàn)的界面。{view task}和{task}的連接表示用戶在此視圖界面中所執(zhí)行的任務(wù)。
圖3 導(dǎo)入數(shù)據(jù)用例分析
圖4為對話模型,其中:葉子節(jié)點(diǎn)表示原子任務(wù),即不能再進(jìn)行分解的任務(wù);根節(jié)點(diǎn)表示目標(biāo)任務(wù)。該對話模型通過樹的形式實(shí)現(xiàn)了導(dǎo)入數(shù)據(jù)文件時(shí)任務(wù)之間存在的邏輯關(guān)系。圖5為導(dǎo)入數(shù)據(jù)文件的表示模型,定義<
圖4 導(dǎo)入數(shù)據(jù)對話模型
圖5 導(dǎo)入數(shù)據(jù)用例表示模型
利用PHP+MySQL等編譯手段,最終導(dǎo)入數(shù)據(jù)文件的GUI界面如圖6所示。
通過對WISDOM任務(wù)模型的介紹與改進(jìn),讓其適應(yīng)GUI的設(shè)計(jì),并且通過對數(shù)據(jù)可視化的GUI設(shè)計(jì)來論證方法的可行性。實(shí)踐表明,面向數(shù)據(jù)可視化GUI設(shè)計(jì)的WISDOM任務(wù)模型引用UML的用例圖以及特有的語義關(guān)系,并通過一系列的映射來生成最終的GUI界面,可以很好地幫助設(shè)計(jì)人員了解用戶需求,提高了設(shè)計(jì)的完整性和設(shè)計(jì)人員的工作效率。