楊 蕾 劉正捷(大連海事大學(xué)信息科學(xué)技術(shù)學(xué)院 遼寧 大連 116026)

0 引 言

圖形用戶(hù)界面(GUI)允許用戶(hù)使用輸入設(shè)備，例如在屏幕上進(jìn)行操作，這些操作包括選擇命令、調(diào)用該文件、啟動(dòng)程序或執(zhí)行其他常規(guī)任務(wù)[1]。GUI極大地方便了非專(zhuān)業(yè)用戶(hù)的適當(dāng)行動(dòng)，用戶(hù)不用記住冗雜的命令，可以通過(guò)窗口、菜單進(jìn)行相應(yīng)的操作[2]。文獻(xiàn)[2]對(duì)GUI技術(shù)在國(guó)內(nèi)外的專(zhuān)利申請(qǐng)情況進(jìn)行了統(tǒng)計(jì)，并進(jìn)行相應(yīng)技術(shù)的分析，從中可以看出GUI在國(guó)內(nèi)外發(fā)展是如此迅速。GUI的應(yīng)用領(lǐng)域也非常的多：手機(jī)移動(dòng)端產(chǎn)品、電腦系統(tǒng)、軟件產(chǎn)品等。用戶(hù)界面是否能夠滿(mǎn)足用戶(hù)的需求已經(jīng)成為評(píng)判系統(tǒng)成功與否的重要指標(biāo)，因此為用戶(hù)提供一個(gè)可靠、靈活、簡(jiǎn)單易用的用戶(hù)界面是設(shè)計(jì)人員需要重點(diǎn)關(guān)注的事情。但是，GUI在設(shè)計(jì)過(guò)程中還是存在著許多困難的，文獻(xiàn)[3]中指出在GUI設(shè)計(jì)的過(guò)程中有時(shí)候無(wú)法真正理解到用戶(hù)真正的需求，導(dǎo)致最終系統(tǒng)搭建完成后仍需要花費(fèi)額外的人力物力去迭代改進(jìn)。

在GUI設(shè)計(jì)和開(kāi)發(fā)的過(guò)程，任務(wù)模型占著很重要的位置，文獻(xiàn)[4]中也提到可以用模型搜集用戶(hù)需求和任務(wù)，這樣可以防止盲目開(kāi)發(fā)帶來(lái)的成本以及人力物力上的損失，提高設(shè)計(jì)人員的工作效率，從而設(shè)計(jì)出滿(mǎn)足用戶(hù)需求的GUI系統(tǒng)。然而，現(xiàn)有的任務(wù)模型具有很多的局限性，并不適用于面向數(shù)據(jù)可視化的GUI設(shè)計(jì)，致使生成的界面很難完全滿(mǎn)足用戶(hù)的需求，因此，本文對(duì)WISDOM任務(wù)模型進(jìn)行相應(yīng)的改進(jìn)，并用改進(jìn)后的WISDOM任務(wù)模型分析與設(shè)計(jì)數(shù)據(jù)可視化系統(tǒng)的用戶(hù)界面，采用模型驅(qū)動(dòng)的方式開(kāi)發(fā)數(shù)據(jù)可視化系統(tǒng)的GUI。

1 任務(wù)模型

1.1 用戶(hù)界面設(shè)計(jì)中的任務(wù)模型

在普適計(jì)算的環(huán)境中，用戶(hù)與設(shè)備之間的交互方式越來(lái)越多樣，在交互的過(guò)程中也需要考慮使用設(shè)備所處的環(huán)境，為了順應(yīng)這種多樣化，越來(lái)越多的設(shè)計(jì)人員將模型的方法使用在用戶(hù)界面設(shè)計(jì)以及開(kāi)發(fā)過(guò)程中。任務(wù)模型可以在抽象層次上描述界面，可以通過(guò)模型的轉(zhuǎn)換,使它在不同的平臺(tái)也可以重用[4]。用戶(hù)界面設(shè)計(jì)是基于模型的，它在開(kāi)發(fā)用戶(hù)界面的過(guò)程中使用了任務(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)過(guò)擴(kuò)展UML描述任務(wù)建模的方法，如WISDOM、LOTOS[10]、PETRINET[11]等形式化語(yǔ)言也可以用于任務(wù)建模[7]。雖然形式化語(yǔ)言方便設(shè)計(jì)師建模，但是對(duì)設(shè)計(jì)師自身的專(zhuān)業(yè)能力有一定的要求，而且對(duì)于用戶(hù)來(lái)說(shuō)也是很難理解的，所以會(huì)造成設(shè)計(jì)師與用戶(hù)之間的溝通障礙。

HTA模型是以結(jié)構(gòu)化方式用任務(wù)層級(jí)描述任務(wù)之間的關(guān)系[5]，它早已被廣泛用于分析用戶(hù)任務(wù)，是基于系統(tǒng)的設(shè)計(jì)。HTA模型將人機(jī)交互的過(guò)程比作成一種序列或者是對(duì)話(huà)，這個(gè)原因?qū)е履Ｐ偷目捎眯圆⒉缓?，因?yàn)樵诖罱ㄈ蝿?wù)模型的過(guò)程中可能會(huì)有更有效的方式去達(dá)到最初的任務(wù)目標(biāo)[12]。HTA方法所描述的任務(wù)操作屬于隱性的，設(shè)計(jì)人員在使用的過(guò)程中不能明顯地看出任務(wù)過(guò)程中任務(wù)之間的關(guān)聯(lián)。只能表示順序、選擇和循環(huán)這三種時(shí)序關(guān)系。

GOMS模型是描述任務(wù)在實(shí)踐過(guò)程中是如何執(zhí)行的一種認(rèn)知任務(wù)模型[7]。建模的過(guò)程首先需要確定好一個(gè)目標(biāo)，然后將目標(biāo)進(jìn)行逐個(gè)分解，當(dāng)完成目標(biāo)的方法出現(xiàn)多種路徑時(shí)，可以根據(jù)所處的情境，通過(guò)選擇規(guī)則選擇一個(gè)最優(yōu)解。該模型只能表示順序、選擇、并行和循環(huán)這幾種時(shí)序關(guān)系。

TKS模型假設(shè)一個(gè)人已經(jīng)掌握了相關(guān)的特定任務(wù)的知識(shí)，用戶(hù)執(zhí)行特定的任務(wù)為一個(gè)TKS，TKS保存在任務(wù)的知識(shí)結(jié)構(gòu)中，當(dāng)觸發(fā)相關(guān)的TKS任務(wù)時(shí)，它就會(huì)立刻被激活[13]。但它沒(méi)有考慮到用戶(hù)所處的環(huán)境不同，還會(huì)受外界環(huán)境的干擾，模型不能根據(jù)特殊環(huán)境而進(jìn)行相應(yīng)的改變。

CTT(Councer Task Tree)模型將暫態(tài)關(guān)系進(jìn)行定義，每個(gè)暫態(tài)關(guān)系均有圖形符號(hào)一一對(duì)應(yīng)[14]。暫態(tài)關(guān)系是指執(zhí)行順序和執(zhí)行結(jié)束的定義，以及在任務(wù)執(zhí)行過(guò)程中的任意一個(gè)子任務(wù)之間的關(guān)系。但其只能做一些簡(jiǎn)單的統(tǒng)計(jì),不能評(píng)估系統(tǒng)的性能,還沒(méi)有自動(dòng)生成代碼的工具。

WISDOM模型[15]繼承并優(yōu)化了CTT方法的時(shí)序關(guān)系表示形式，符合UML的規(guī)范，可以用現(xiàn)有的UML相關(guān)的編輯器進(jìn)行建模，也可以將用戶(hù)界面任務(wù)方面的建模與表示模型和領(lǐng)域模型聯(lián)系起來(lái)。

通過(guò)比較分析，表1給出了各種方法的表示形式、支持的時(shí)序關(guān)系、適用范圍、相關(guān)的建模工具?？紤]到各種模型的優(yōu)缺點(diǎn)以及本文所要研究的課題，最終選用了WISDOM模型來(lái)設(shè)計(jì)數(shù)據(jù)可視化的GUI界面，為了讓W(xué)ISDOM模型更好地適用于GUI設(shè)計(jì)，因此對(duì)WISDOM模型進(jìn)行了相應(yīng)改進(jìn)，為設(shè)計(jì)人員提供更好的適用于GUI設(shè)計(jì)的任務(wù)建模方法。

表1 方法表示形式、時(shí)序關(guān)系、適用范圍、建模工具

續(xù)表1

1.2 WISDOM任務(wù)模型

WISDOM是在CTT的基礎(chǔ)上創(chuàng)建出來(lái)的具有UML語(yǔ)義的一種任務(wù)模型[15]。通過(guò)約束擴(kuò)展機(jī)制將UML和CTT進(jìn)行整合，令UML也可以在用戶(hù)界面建模的過(guò)程中適用，使用UML中的約束機(jī)制來(lái)表示任務(wù)之間的時(shí)序關(guān)系。約束在模型中表示元素之間的語(yǔ)義約束，它規(guī)定條件和命題必須是true[16]。在CTT模型中，使用擴(kuò)展的LOTOS運(yùn)算符表示任務(wù)之間的順序、選擇、并行等多種時(shí)序關(guān)系[17]。表2中展示出了CTT模型中涉及到的關(guān)系名稱(chēng)，WISDOM模型延用了CTT中部分常用關(guān)系，通過(guò)現(xiàn)有UML表示法將CTT中的元素和任務(wù)關(guān)系引入U(xiǎn)ML2.0中，利用了UML類(lèi)的約束、關(guān)聯(lián)和依賴(lài)定義的衍型來(lái)表達(dá)其結(jié)構(gòu)關(guān)系[18]。

表2 新增的關(guān)系名稱(chēng)、符號(hào)、釋義

續(xù)表2

WISDOM中關(guān)聯(lián)類(lèi)的表現(xiàn)形式及相應(yīng)的語(yǔ)義如表3所示。

表3 關(guān)聯(lián)類(lèi)的表現(xiàn)形式及相應(yīng)的語(yǔ)義

WISDOM中任務(wù)之間的時(shí)序關(guān)系是通過(guò)關(guān)聯(lián)之間來(lái)約束的，有三種約束模式及相應(yīng)的語(yǔ)義如下。

{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)行過(guò)程中激活并執(zhí)行，此時(shí)ti立即被終止。

任務(wù)類(lèi)及其語(yǔ)義如下。

{abstract task}：需要復(fù)雜活動(dòng)且性能不能單獨(dú)分配的任務(wù)。

{user task}：用戶(hù)不與系統(tǒng)交互的情況下執(zhí)行的任務(wù)。

{application task}：應(yīng)用程序完全執(zhí)行的任務(wù)。

{interaction task}：用戶(hù)與系統(tǒng)交互執(zhí)行的任務(wù)。

雖然CTT語(yǔ)義嚴(yán)密但只能進(jìn)行一些簡(jiǎn)單設(shè)計(jì)且對(duì)用戶(hù)界面中其他模型的支持不足[18]，而WISDOM任務(wù)模型的建立可以使UML也可以對(duì)用戶(hù)界面進(jìn)行建模，恰恰彌補(bǔ)了CTT的不足，通過(guò)將CTT關(guān)系符號(hào)優(yōu)化改進(jìn)并與UML的關(guān)聯(lián)類(lèi)相適配，最終可以成功將CTT中時(shí)序關(guān)系表達(dá)形式映射到WISDOM任務(wù)模型中，具體映射形式如圖1所示。

2 WISDOM任務(wù)模型在GUI設(shè)計(jì)中的優(yōu)化與改進(jìn)

由于WISDOM任務(wù)模型須應(yīng)用在系統(tǒng)的GUI設(shè)計(jì)中，原有的模型并不適用于GUI設(shè)計(jì)，所以需要對(duì)現(xiàn)有的WISDOM任務(wù)模型進(jìn)行相應(yīng)的優(yōu)化，為了更加準(zhǔn)確地適用于后續(xù)的GUI設(shè)計(jì)中，給出如下的定義。

任務(wù)類(lèi)中需要增加的內(nèi)容：

定義1{system task}：系統(tǒng)完全執(zhí)行的任務(wù)。

定義2{view task}：為實(shí)現(xiàn)某一交互任務(wù)，系統(tǒng)需要提供的視圖界面。

關(guān)聯(lián)類(lèi)中需要增加的內(nèi)容：

定義3<>：表示從用戶(hù)端接收到的信息，即用戶(hù)可以操作的信息。

定義4<

>: 表示呈現(xiàn)給用戶(hù)的元素，即用戶(hù)可以感知但不能進(jìn)行相應(yīng)操作。

定義5<>：表示原子操作任務(wù)，即不可分解的任務(wù)，表示用戶(hù)執(zhí)行的操作。

WISDOM任務(wù)模型是屬于軟件工程的一種方法，所以其開(kāi)發(fā)過(guò)程符合軟件生命周期：需求、分析、設(shè)計(jì)、實(shí)現(xiàn)四個(gè)階段[18]。定義了系統(tǒng)開(kāi)發(fā)過(guò)程中的具體步驟以及每一階段所需建立的內(nèi)部模型與外部模型，以模型為驅(qū)動(dòng)的方法進(jìn)行GUI與核心應(yīng)用模塊的開(kāi)發(fā)[19]。所以在GUI設(shè)計(jì)過(guò)程中WISDOM模型也需要進(jìn)行相應(yīng)的改進(jìn)，下面將按照軟件的生命周期進(jìn)行描述。

2.1 需 求

(1) 獲取用戶(hù)需求：采用觀察、問(wèn)卷、訪談等方法獲取與用戶(hù)需求相關(guān)的數(shù)據(jù)。

(2) 需求分析：使用UML用例圖表現(xiàn)用戶(hù)與GUI交互過(guò)程中的需求。

(3) 找出各個(gè)用例中的對(duì)象及對(duì)象之間的關(guān)聯(lián)，畫(huà)出GUI用例圖。

2.2 分 析

挖掘建立內(nèi)部分析模型 、GUI交互模型類(lèi)。具體方式為：

(1) 輸入需求階段利用UML畫(huà)出的類(lèi)圖。

(2) 找出每一用例中的<>、<>、<>三類(lèi)，確定類(lèi)的屬性、操作、類(lèi)之間的關(guān)系。

(3) 區(qū)分需求階段UML用例圖的{user task}和{system task}，找出{task}()和{view task}()。

(4) 找出任務(wù)類(lèi)與實(shí)體類(lèi)之間的關(guān)聯(lián)，建立內(nèi)部模型與外部模型的聯(lián)系。

2.3 設(shè) 計(jì)

設(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中的其他圖來(lái)建立內(nèi)部相關(guān)行為。具體方式為：

(1) 繪制對(duì)話(huà)模型。將分析階段提煉出的{user task}用CTT模型的形式呈現(xiàn)出來(lái)，表示它們之間的交互情況，利用樹(shù)的形式表達(dá)出來(lái)，其中任務(wù)之間的邏輯關(guān)系分為父任務(wù)與子任務(wù)，將父子之間的時(shí)序關(guān)系相應(yīng)地表示出來(lái)。

(2) 繪制表示模型。表示模型指用戶(hù)界面的最終呈現(xiàn)。同理，將分析階段提煉出的{view task}用CTT模型的形式呈現(xiàn)出來(lái)，利用定義好的<>、<>、<>等關(guān)系表示視圖之間存在的關(guān)系，同時(shí)在每個(gè)視圖下方用<>表示用戶(hù)的原子操作任務(wù)，這樣可以明確表示出用例模型和對(duì)話(huà)模型之間的映射關(guān)系。

2.4 實(shí) 現(xiàn)

利用編譯手段以及相應(yīng)的配置將GUI應(yīng)用程序移植到系統(tǒng)中。

3 案例研究

大數(shù)據(jù)時(shí)代的到來(lái)讓越來(lái)越多的人開(kāi)始使用數(shù)據(jù)可視化幫助設(shè)計(jì)人員分析數(shù)據(jù)。數(shù)據(jù)可視化將繁雜的數(shù)據(jù)轉(zhuǎn)化成易于辨識(shí)的圖形，以更加直觀的形式幫助人們理解數(shù)據(jù)，增強(qiáng)了分析數(shù)據(jù)的可讀性?，F(xiàn)如今數(shù)據(jù)可視化系統(tǒng)多種多樣，但好多設(shè)計(jì)出來(lái)的系統(tǒng)都是面向?qū)I(yè)人士以及企業(yè)的，對(duì)于用戶(hù)來(lái)說(shuō)學(xué)習(xí)成本較高且并未很好地滿(mǎn)足用戶(hù)需求，所以如何設(shè)計(jì)出面向普通用戶(hù)使用、滿(mǎn)足用戶(hù)需求、呈現(xiàn)什么樣的圖形界面是現(xiàn)如今我們需要著重解決的事情。所以本節(jié)利用優(yōu)化后的WISDOM任務(wù)模型幫助解決這個(gè)問(wèn)題。

3.1 獲取需求

數(shù)據(jù)可視化的圖形界面是用戶(hù)與系統(tǒng)數(shù)據(jù)進(jìn)行信息交互的平臺(tái)，通過(guò)訪談的形式確立最終GUI需求提供的主要功能有：導(dǎo)入數(shù)據(jù)文件，系統(tǒng)設(shè)置，數(shù)據(jù)概覽，條件篩選，粗/細(xì)粒度，保護(hù)功能，溝通對(duì)話(huà)，動(dòng)態(tài)呈現(xiàn)，幫助引導(dǎo)，即用即存。如圖2所示，將需求分析階段的成果用用例圖來(lái)表示，以方便后續(xù)操作。

圖2 GUI用例圖

3.2 分 析

將需求階段獲取的用例圖進(jìn)行進(jìn)一步細(xì)分，這里以導(dǎo)入數(shù)據(jù)文件為例。導(dǎo)入數(shù)據(jù)文件的需求包括導(dǎo)入數(shù)據(jù)文件的形式以及查找數(shù)據(jù)文件的存儲(chǔ)位置。其中導(dǎo)入數(shù)據(jù)文件的形式包括導(dǎo)入新的數(shù)據(jù)和導(dǎo)入已創(chuàng)建工作簿；查找數(shù)據(jù)文件存儲(chǔ)位置是在選擇導(dǎo)入文件形式后篩選不同形式的數(shù)據(jù)存儲(chǔ)文件。如圖3所示，最左邊表示的是{user task}，其次是{system task}、{view task}和{task}。{user task}和{system task}是需求分析階段的成果，表示導(dǎo)入數(shù)據(jù)文件時(shí)用戶(hù)和可視化系統(tǒng)的交互流程。用戶(hù)和系統(tǒng)交互的過(guò)程中，很容易辨別出交互過(guò)程中數(shù)據(jù)可視化系統(tǒng)需要呈現(xiàn)給用戶(hù)的{view task}以及需要進(jìn)行人機(jī)交互的{task}類(lèi)。其中虛線剪頭表示系統(tǒng)在交互的過(guò)程中需給用戶(hù)呈現(xiàn)的界面。{view task}和{task}的連接表示用戶(hù)在此視圖界面中所執(zhí)行的任務(wù)。

圖3 導(dǎo)入數(shù)據(jù)用例分析

3.3 設(shè) 計(jì)

圖4為對(duì)話(huà)模型，其中：葉子節(jié)點(diǎn)表示原子任務(wù)，即不能再進(jìn)行分解的任務(wù)；根節(jié)點(diǎn)表示目標(biāo)任務(wù)。該對(duì)話(huà)模型通過(guò)樹(shù)的形式實(shí)現(xiàn)了導(dǎo)入數(shù)據(jù)文件時(shí)任務(wù)之間存在的邏輯關(guān)系。圖5為導(dǎo)入數(shù)據(jù)文件的表示模型，定義<>為視圖切換，<>為視圖包含與被包含的關(guān)系，<>為用戶(hù)在此視圖中所執(zhí)行的操作。

圖4 導(dǎo)入數(shù)據(jù)對(duì)話(huà)模型

圖5 導(dǎo)入數(shù)據(jù)用例表示模型

3.4 實(shí) 現(xiàn)

利用PHP+MySQL等編譯手段，最終導(dǎo)入數(shù)據(jù)文件的GUI界面如圖6所示。

4 結(jié) 語(yǔ)

通過(guò)對(duì)WISDOM任務(wù)模型的介紹與改進(jìn)，讓其適應(yīng)GUI的設(shè)計(jì)，并且通過(guò)對(duì)數(shù)據(jù)可視化的GUI設(shè)計(jì)來(lái)論證方法的可行性。實(shí)踐表明，面向數(shù)據(jù)可視化GUI設(shè)計(jì)的WISDOM任務(wù)模型引用UML的用例圖以及特有的語(yǔ)義關(guān)系，并通過(guò)一系列的映射來(lái)生成最終的GUI界面，可以很好地幫助設(shè)計(jì)人員了解用戶(hù)需求，提高了設(shè)計(jì)的完整性和設(shè)計(jì)人員的工作效率。