面向數據可視化GUI設計的WISDOM任務模型構建

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

0 引 言

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

在GUI設計和開發的過程，任務模型占著很重要的位置，文獻[4]中也提到可以用模型搜集用戶需求和任務，這樣可以防止盲目開發帶來的成本以及人力物力上的損失，提高設計人員的工作效率，從而設計出滿足用戶需求的GUI系統。然而，現有的任務模型具有很多的局限性，并不適用于面向數據可視化的GUI設計，致使生成的界面很難完全滿足用戶的需求，因此，本文對WISDOM任務模型進行相應的改進，并用改進后的WISDOM任務模型分析與設計數據可視化系統的用戶界面，采用模型驅動的方式開發數據可視化系統的GUI。

1 任務模型

1.1 用戶界面設計中的任務模型

在普適計算的環境中，用戶與設備之間的交互方式越來越多樣，在交互的過程中也需要考慮使用設備所處的環境，為了順應這種多樣化，越來越多的設計人員將模型的方法使用在用戶界面設計以及開發過程中。任務模型可以在抽象層次上描述界面，可以通過模型的轉換,使它在不同的平臺也可以重用[4]。用戶界面設計是基于模型的，它在開發用戶界面的過程中使用了任務模型，是一種新方法，最早的任務模型是HTA模型[5]。它使用層次分析的方式描述任務活動，是任務模型的基石[6]?，F如今，基于HTA方法已經優化衍生出其他的任務分析模型，如GOMS[7]、CTT[8]、TKS[9]等。隨著UML成為面向對象設計方法的主流，也涌現了一些經過擴展UML描述任務建模的方法，如WISDOM、LOTOS[10]、PETRINET[11]等形式化語言也可以用于任務建模[7]。雖然形式化語言方便設計師建模，但是對設計師自身的專業能力有一定的要求，而且對于用戶來說也是很難理解的，所以會造成設計師與用戶之間的溝通障礙。

HTA模型是以結構化方式用任務層級描述任務之間的關系[5]，它早已被廣泛用于分析用戶任務，是基于系統的設計。HTA模型將人機交互的過程比作成一種序列或者是對話，這個原因導致模型的可用性并不好，因為在搭建任務模型的過程中可能會有更有效的方式去達到最初的任務目標[12]。HTA方法所描述的任務操作屬于隱性的，設計人員在使用的過程中不能明顯地看出任務過程中任務之間的關聯。只能表示順序、選擇和循環這三種時序關系。

GOMS模型是描述任務在實踐過程中是如何執行的一種認知任務模型[7]。建模的過程首先需要確定好一個目標，然后將目標進行逐個分解，當完成目標的方法出現多種路徑時，可以根據所處的情境，通過選擇規則選擇一個最優解。該模型只能表示順序、選擇、并行和循環這幾種時序關系。

TKS模型假設一個人已經掌握了相關的特定任務的知識，用戶執行特定的任務為一個TKS，TKS保存在任務的知識結構中，當觸發相關的TKS任務時，它就會立刻被激活[13]。但它沒有考慮到用戶所處的環境不同，還會受外界環境的干擾，模型不能根據特殊環境而進行相應的改變。

CTT(Councer Task Tree)模型將暫態關系進行定義，每個暫態關系均有圖形符號一一對應[14]。暫態關系是指執行順序和執行結束的定義，以及在任務執行過程中的任意一個子任務之間的關系。但其只能做一些簡單的統計,不能評估系統的性能,還沒有自動生成代碼的工具。

WISDOM模型[15]繼承并優化了CTT方法的時序關系表示形式，符合UML的規范，可以用現有的UML相關的編輯器進行建模，也可以將用戶界面任務方面的建模與表示模型和領域模型聯系起來。

通過比較分析，表1給出了各種方法的表示形式、支持的時序關系、適用范圍、相關的建模工具?？紤]到各種模型的優缺點以及本文所要研究的課題，最終選用了WISDOM模型來設計數據可視化的GUI界面，為了讓WISDOM模型更好地適用于GUI設計，因此對WISDOM模型進行了相應改進，為設計人員提供更好的適用于GUI設計的任務建模方法。

表1 方法表示形式、時序關系、適用范圍、建模工具

續表1

1.2 WISDOM任務模型

WISDOM是在CTT的基礎上創建出來的具有UML語義的一種任務模型[15]。通過約束擴展機制將UML和CTT進行整合，令UML也可以在用戶界面建模的過程中適用，使用UML中的約束機制來表示任務之間的時序關系。約束在模型中表示元素之間的語義約束，它規定條件和命題必須是true[16]。在CTT模型中，使用擴展的LOTOS運算符表示任務之間的順序、選擇、并行等多種時序關系[17]。表2中展示出了CTT模型中涉及到的關系名稱，WISDOM模型延用了CTT中部分常用關系，通過現有UML表示法將CTT中的元素和任務關系引入UML2.0中，利用了UML類的約束、關聯和依賴定義的衍型來表達其結構關系[18]。

表2 新增的關系名稱、符號、釋義

續表2

WISDOM中關聯類的表現形式及相應的語義如表3所示。

表3 關聯類的表現形式及相應的語義

WISDOM中任務之間的時序關系是通過關聯之間來約束的，有三種約束模式及相應的語義如下。

{xor}：任務集合T是一個任務的有限集合，T={t1,t2,…,tn}；執行t1{xor}t2=(t1∧t2)∨(t1∧t2)。

{sequence}：任務集合T是一個任務的有限集合，T={t1,t2,…,tn}；?i∈{1,2,…,n}，ti+1只能等ti執行完成之后才能執行。

{deactivate}：任務集合T是一個任務的有限集合，T={t1,t2,…,tn}；?i∈{1,2,…,n}，ti+1可以在ti運行過程中激活并執行，此時ti立即被終止。

任務類及其語義如下。

{abstract task}：需要復雜活動且性能不能單獨分配的任務。

{user task}：用戶不與系統交互的情況下執行的任務。

{application task}：應用程序完全執行的任務。

{interaction task}：用戶與系統交互執行的任務。

雖然CTT語義嚴密但只能進行一些簡單設計且對用戶界面中其他模型的支持不足[18]，而WISDOM任務模型的建立可以使UML也可以對用戶界面進行建模，恰恰彌補了CTT的不足，通過將CTT關系符號優化改進并與UML的關聯類相適配，最終可以成功將CTT中時序關系表達形式映射到WISDOM任務模型中，具體映射形式如圖1所示。

2 WISDOM任務模型在GUI設計中的優化與改進

由于WISDOM任務模型須應用在系統的GUI設計中，原有的模型并不適用于GUI設計，所以需要對現有的WISDOM任務模型進行相應的優化，為了更加準確地適用于后續的GUI設計中，給出如下的定義。

任務類中需要增加的內容：

定義1{system task}：系統完全執行的任務。

定義2{view task}：為實現某一交互任務，系統需要提供的視圖界面。

關聯類中需要增加的內容：

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

定義4<

>: 表示呈現給用戶的元素，即用戶可以感知但不能進行相應操作。

定義5<>：表示原子操作任務，即不可分解的任務，表示用戶執行的操作。

WISDOM任務模型是屬于軟件工程的一種方法，所以其開發過程符合軟件生命周期：需求、分析、設計、實現四個階段[18]。定義了系統開發過程中的具體步驟以及每一階段所需建立的內部模型與外部模型，以模型為驅動的方法進行GUI與核心應用模塊的開發[19]。所以在GUI設計過程中WISDOM模型也需要進行相應的改進，下面將按照軟件的生命周期進行描述。

2.1 需 求

(1) 獲取用戶需求：采用觀察、問卷、訪談等方法獲取與用戶需求相關的數據。

(2) 需求分析：使用UML用例圖表現用戶與GUI交互過程中的需求。

(3) 找出各個用例中的對象及對象之間的關聯，畫出GUI用例圖。

2.2 分 析

挖掘建立內部分析模型 、GUI交互模型類。具體方式為：

(1) 輸入需求階段利用UML畫出的類圖。

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

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

(4) 找出任務類與實體類之間的關聯，建立內部模型與外部模型的聯系。

2.3 設 計

設計階段分為GUI設計和系統內部設計。內部設計需要遵照UML的相關設計規則，利用WISDOM任務分析模型建立相關模型后，進一步使用UML中的其他圖來建立內部相關行為。具體方式為：

(1) 繪制對話模型。將分析階段提煉出的{user task}用CTT模型的形式呈現出來，表示它們之間的交互情況，利用樹的形式表達出來，其中任務之間的邏輯關系分為父任務與子任務，將父子之間的時序關系相應地表示出來。

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

2.4 實 現

利用編譯手段以及相應的配置將GUI應用程序移植到系統中。

3 案例研究

大數據時代的到來讓越來越多的人開始使用數據可視化幫助設計人員分析數據。數據可視化將繁雜的數據轉化成易于辨識的圖形，以更加直觀的形式幫助人們理解數據，增強了分析數據的可讀性?，F如今數據可視化系統多種多樣，但好多設計出來的系統都是面向專業人士以及企業的，對于用戶來說學習成本較高且并未很好地滿足用戶需求，所以如何設計出面向普通用戶使用、滿足用戶需求、呈現什么樣的圖形界面是現如今我們需要著重解決的事情。所以本節利用優化后的WISDOM任務模型幫助解決這個問題。

3.1 獲取需求

數據可視化的圖形界面是用戶與系統數據進行信息交互的平臺，通過訪談的形式確立最終GUI需求提供的主要功能有：導入數據文件，系統設置，數據概覽，條件篩選，粗/細粒度，保護功能，溝通對話，動態呈現，幫助引導，即用即存。如圖2所示，將需求分析階段的成果用用例圖來表示，以方便后續操作。

圖2 GUI用例圖

3.2 分 析

將需求階段獲取的用例圖進行進一步細分，這里以導入數據文件為例。導入數據文件的需求包括導入數據文件的形式以及查找數據文件的存儲位置。其中導入數據文件的形式包括導入新的數據和導入已創建工作簿；查找數據文件存儲位置是在選擇導入文件形式后篩選不同形式的數據存儲文件。如圖3所示，最左邊表示的是{user task}，其次是{system task}、{view task}和{task}。{user task}和{system task}是需求分析階段的成果，表示導入數據文件時用戶和可視化系統的交互流程。用戶和系統交互的過程中，很容易辨別出交互過程中數據可視化系統需要呈現給用戶的{view task}以及需要進行人機交互的{task}類。其中虛線剪頭表示系統在交互的過程中需給用戶呈現的界面。{view task}和{task}的連接表示用戶在此視圖界面中所執行的任務。

圖3 導入數據用例分析

3.3 設 計

圖4為對話模型，其中：葉子節點表示原子任務，即不能再進行分解的任務；根節點表示目標任務。該對話模型通過樹的形式實現了導入數據文件時任務之間存在的邏輯關系。圖5為導入數據文件的表示模型，定義<>為視圖切換，<>為視圖包含與被包含的關系，<>為用戶在此視圖中所執行的操作。

圖4 導入數據對話模型

圖5 導入數據用例表示模型

3.4 實 現

利用PHP+MySQL等編譯手段，最終導入數據文件的GUI界面如圖6所示。

4 結 語

通過對WISDOM任務模型的介紹與改進，讓其適應GUI的設計，并且通過對數據可視化的GUI設計來論證方法的可行性。實踐表明，面向數據可視化GUI設計的WISDOM任務模型引用UML的用例圖以及特有的語義關系，并通過一系列的映射來生成最終的GUI界面，可以很好地幫助設計人員了解用戶需求，提高了設計的完整性和設計人員的工作效率。