為了組成任意的視覺化而設計與實做的UBVM

全文

(1)國立臺灣師範大學資訊工程所碩士論文. 指導教授：鄭永斌博士. Design and Implementation of Ultimate Basic Visualization Metaphors for Composing Arbitrary Visualization. 研究生：許光軒撰中華民國九十九年一月.

(2) 目錄圖片目錄 ...................................................................................................................3 表格目錄 ...................................................................................................................5 摘要...........................................................................................................................6 Chapter 1 緒論....................................................................................................9 Section 1.1 研究動機 ....................................................................................9 1.1.1 問題描述 ..................................................................................10 1.1.2 xDIVA 的目標 ..........................................................................12 Section 1.2 論文架構 ..................................................................................14 Chapter 2 研究背景 ..........................................................................................15 Section 2.1 除錯器(Debugger) ....................................................................15 Section 2.2 軟體視覺化(Software Visualization).........................................19 2.2.1 視覺化隱喻(Visualization Metaphor)........................................20 2.2.2 2.2.3 2.2.4 Section 2.3. Lens ..........................................................................................21 LIVE .........................................................................................23 jGRASP ....................................................................................24 3D 視覺化.................................................................................26. Chapter 3 xDIVA ..................................................................................................28 Section 3.1 Minerva.....................................................................................28 Section 3.2 DIVA.........................................................................................31 Section 3.3 由 Mapping Nodes 所組成的世界 ............................................34 Chapter 4 設計與實做 UBVM..........................................................................39 Section 4.1 資料與 VM 間的對映...............................................................39 Section 4.2 最基本的建構元件-UBVM .....................................................42 Section 4.3 UBVM 的實做..........................................................................46 Section 4.4 創造新的 VM 而不用撰寫程式碼 ...........................................48 Chapter 5 範例..................................................................................................55 Section 5.1 老鼠走迷宮 ..............................................................................55 Section 5.2 折線圖 ......................................................................................58 Section 5.3 圈叉遊戲 ..................................................................................61 Section 5.4 背包問題(Knapsack Problem)...................................................63 Section 5.5 Convex Hull ..............................................................................66 Chapter 6 結論及未來展望 ..............................................................................69 Section 6.1 結論 ..........................................................................................69 Section 6.2 未來展望 ..................................................................................69 Reference .................................................................................................................71 2.

(3) 圖片目錄圖圖圖圖圖圖圖圖圖圖圖圖圖圖圖圖圖圖圖圖圖圖圖圖圖圖圖圖圖圖圖圖圖圖圖圖. 1 debugger 的監視視窗...................................................................................9 2 三維向量(a,b,c)..........................................................................................11 3 圓餅圖 .......................................................................................................12 4 debugger 的架構圖 ....................................................................................15 5 KDbg 的執行視窗 .....................................................................................17 6 DDD 的執行視窗 ......................................................................................18 7 DDD 透過 gnuplot 所繪製的 1 維和 2 維陣列 ..........................................18 8 顏色與文字視覺化效果的對比 .................................................................21 9 Lens 的系統架構圖....................................................................................21 10 Lens 的執行視窗 .......................................................................................22 12 LIVE 執行 circle linked list 的例子 ...........................................................23 13 jGRSAP 的執行視窗 .................................................................................25 14 jGRSAP 執行 binary tree 的例子 ...............................................................25 15 xDIVA 的系統架構圖 ................................................................................28 16 Minerva 的執行視窗..................................................................................29 17 Minerva 的 RUN Dialog 與 Config Dialog...............................................30 18 DIVA 的執行視窗......................................................................................32 19 Mapping Dialog..........................................................................................34 20 Math mapping node 以及輸入運算式的視窗.............................................36 21 String_composer mapping node 以及輸出格式的視窗 ..............................37 22 Clock mapping node ...................................................................................38 23 The Observer pattern ..................................................................................41 24 最基本的立方體 UBVM............................................................................47 25 Port Setting Dialog .....................................................................................48 26 Composer Dialog........................................................................................49 27 由 pyramid 及 cylinder UBVM 所組合的 arrow VM .................................50 28 在 Composer Dialog 中用 pyramid 及 cylinder UBVM 組出 arrow VM ....51 29 Composer Dialog 中的參數設定................................................................51 30 二元樹在 DIVA 中的視覺化 .....................................................................52 31 二元樹中資料與 VM 的對映關係.............................................................53 32 使用 VMclone mapping node 去計算二元樹中左右子樹的位置 ..............54 33 老鼠走迷宮的視覺化範例.........................................................................55 34 在 Composer Dialog 中組合出 mouse_obj 的 mapping node .....................57 35 老鼠走迷宮的資料與 VM 對映方式.........................................................57 36 在 Composer Dialog 中利用 mouse_obj 組合出 Mouse mapping node......58 38 2D 折線圖的視覺化範例...........................................................................59 3.

(4) 圖圖圖圖圖圖圖圖. 39 40 41 42 43 44 45 46. 圖 47. 在 Composer Dialog 中組合出 Bone mapping node...................................60 2D 折線圖的資料與 VM 對映方式 ...........................................................61 圈叉遊戲的視覺化範例.............................................................................62 在 Composer Dialog 中組合出 tictactoe_obj mapping node .......................63 背包問題的視覺化範例(圓餅圖) .............................................................64 背包問題以圓餅圖視覺化的資料與 VM 對映方式..................................65 convex hull 的視覺化範例 .........................................................................66 在 Composer Dialog 中組出 convexhull_dot(左圖)及 convexhull_line(右圖) .........................................................................................................67 convex hull 的資料與 VM 對映方式 .......................................................68. 4.

(5) 表格目錄表格 1. 背包問題範例中水果的編號、單價與重量表 ........................................64. 5.

(6) 摘要對於複雜的事物，人類習慣透過圖表或是動畫的方式，使它變的容易理解。對於軟體來說，由於軟體具有不可見性，也就是在軟體完成之前，程式設計人員是無法看出軟體的架構以及軟體內部的狀態。此外，軟體行為因為是動態的，所以更加深了軟體理解的困難度。因此，如何將軟體視覺化，幫助程式開發者能更瞭解程式內部的行為，一直是軟體工程研究的課題。雖然近年來已經有一些視覺化工具可以透過圖形來視覺化程式內部的資料以幫助程式設計師除錯，但它們在實用上還有許多限制，無法滿足使用者對於視覺化多樣的需求。所以，時自今日，很多程式設計者還是習慣安插額外程式碼(例如：printf)去進行軟體除錯。軟體視覺化遇到最大的問題就是資料的多樣性，以及每個人對於資料解釋的不同。目前的視覺化研究都只能針對特定型態的資料進行視覺化，而無法應付未知的資料型態。此外，視覺化的方式也是事先套好的，每一種資料型態對映的視覺化都是固定的，缺乏變化性。甚至，使用者還必須為了視覺化，去學習那套工具所定義的特殊語言，然後在需要視覺化的程式片段安插特定的程式碼，讓工具知道何時該視覺化。本篇論文主要是探討如何透過本實驗室所開發的視覺化除錯工具—xDIVA[1]，讓使用者以符合自己理想的視覺化去視覺化變數和資料結構。為了應付各種不同的資料結構，以及解決傳統視覺化方法，如 model view，observer pattern ，所面臨的困境，所以我們準備了 11 種最基本的 VM(Visualization 6.

(7) Metaphor)[2]，並且導入物件導向的概念，讓資料與 VM 之間做到去除耦合 (decoupling)。每個基礎的 VM 都可獨立運作且可被替換，或是互相配合組成複雜的 VM。因此使用者可依照需求，在我們所提供的介面(Mapping Dialog)(圖 19) 中，藉由選擇和拖曳的方式，自由的組合這些基本的 VM，建構出合乎理想的新的 VM，而且不需要撰寫任何的程式碼。. 7.

(8) ABSTRACT While understanding complicated subjects, humans are used to draw graphics to help their understanding because visual perception is a powerful tool of humans. Software is hard to understand because it is “ invisible”and “ dynamic” . So, software engineering researchers have devoted a lot of efforts to visualize software. The major problem of software visualization is that a wide variety of data types and interpretations from data to visualizations are arbitrary. In this paper, we attempt to address this problem by using a visualization tool call xDIVA. In order to support arbitrary visualization, we design and implement 11 ultimate basic visualization metaphors (UBVMs). These UBVMs are developed on an object-oriented framework so that they are interactive, composable and decoupled from data. A complicated visualization can be composed from basic ones, each of which is independently replaceable. User can create new visualization metaphors depend on different demands by using new mapping system we offered and without programming.. 8.

(9) Chapter 1 Section 1.1. 緒論. 研究動機. 在軟體開發的過程當中，除錯是一個不可避免的階段。如果設計階段設計不良，通常除錯所要花費的時間就要更長。一般常用的整合開發環境(IDE)都會提供一個內建的除錯器，只不過這類除錯器，通常只具命令列模式的文字介面，比較不容易上手。為了提高實用性，較貼心的開發環境會將除錯器包裝成視窗化介面(watch view)，如圖 1。. 圖 1. debugger 的監視視窗. 除錯器主要是透過設定中斷點來暫停程式的執行，然後藉此來觀察程式狀態。. 9.

(10) 雖然 IDE 已經幫我們提供了視窗化的介面，不過都是以文字模式去呈現單一變數或結構，除錯效果上仍受到一些限制。例如：程式設計者若要瞭解物件或結構之間的關係時，還是只能插入額外的程式碼，以自己所偏好的視覺化方式來顯示變數與資料結構。有經驗的程式設計師通常會靠輸出與列印變數(如 cout 、printf）來搭配除錯器一起解決問題，這樣做，雖然比單靠除錯器來的有效率，不過，在面對龐大或複雜的資料時，仍然需要耗費大量時間與心力去除錯，顯得有些力不從心。. 1.1.1. 問題描述. 自從軟體被發明以來，軟體視覺化[3]一直是軟體工程研究相當重要的課題。因為軟體是抽象而且複雜的動態結構，所以，利用「視覺化」來幫助我們理解，似乎是很直觀而且比較有效的方式。如何處理資料和 VM 間的對映一直是軟體視覺化這個研究領域裡面很頭痛的問題。尤其程式以及資料結構在各個應用領域的多變和複雜性，以及使用者針對資料結構的詮釋各有不同，因此，想要靠固定對映的單一視覺化的模式去滿足程式設計師的需求，是不夠的。在本篇論文中，VM 指的是視覺化隱喻(VM， Visualization Metaphor)[2]，也就是將資料以圖形視覺化的元件或是程式。部分軟體視覺化工具都只提供簡單且固定的對映關係，這並不能解決我們對於資料視覺化的任意詮釋的問題，以一個 class x 為例： 10.

(11) class X { int a ; int b ; int c; } 針對不同的應用領域，X 可以有各式各樣的解釋。例如：它可能是一個 3 維的向量，如圖 2。. 圖 2. 三維向量(a,b,c). 或者，它可能代表的是某 X 公司當年度三種產品 a,b,c 的收入，如圖 3。甚至，它也可能代表一條 2D 平面上的線段 ax+by=c 的三個係數。. 11.

(12) 圖 3. 圓餅圖. 由以上的例子不難發現，除非資料的用途很明確，否則透過視覺化工具自動對映所產生的結果，可能會牛頭不對馬嘴，根本不是使用者想看到的。所以有些視覺化工具，例如 DDD(Data Display Debugger)[9]，就會選擇最安全的視覺化── 以文字以及數字來表示，而捨棄了更有效的視覺化。. 1.1.2. xDIVA 的目標. xDIVA(eXtreme Debugger Information Visualization Assistant)是一個本實驗室所研發的視覺化雛形工具，主要著重在視覺化軟體執行期間的動態資料，以及處理各式各樣的的資料種類和 VM 之間的對映。事實上，視覺化的對映選擇，應該基於使用者既有的某些知識與經驗，而且也只有程式設計者本身才能決定什麼樣的視覺化最符合他的需求。例如，一般有修過資料結構的程式設計師，可能會習慣以圓圈來代表樹的節點，以線條代表節點之間的關連的視覺化方式。xDIVA 為了讓使用者能自行建立資料與視覺化之間的對映，設計出一個處理資料與視覺化對映關係的介面稱之為 Mapping Engine。 12.

(13) 此介面可允許使用者手動來設定資料所對映的視覺化結果，或者由 xDIVA 替使用者自動選擇一套預設的視覺化結果，若不滿意，再去手動修改對映關係。為了滿足不同應用領域的使用者都能找到符合心目中理想的視覺化，勢必少不了要有各式各樣不同特性的 VM 供使用者選擇。直覺上，VM 的數量越多，使用者越容易找到想要的對映。不過，我們當然不可能針對每一種資料結構，都撰寫相對映的 VM，這樣不僅費時費力，VM 也缺乏重用性，軟體實用度和可靠度也很低，因為要一直不斷的修改。解決這個問題的好方法，其實來自於人類古老的智慧，我們以造橋為例子來說明。人類在建造橋樑時，懂得利用幾種基本形狀的建材，以及標準的介面，透過組合去蓋出各式不同的橋，而不會直接一體成型，這也就是所謂的合成性 (composability)。基於這樣的概念，xDIVA 導入物件導向的觀念，讓 VM 間可以相互溝通、組合，並且能和資料分離以達到最低耦合(coupling)。換句話說，一個複雜的 VM 可由許多基礎的 VM 組合而成，每一個都是獨立可取代的。這裡說的基礎的 VM 就像是最基本形狀的建材，本篇論文中我們將它們定義為 Ultimate Basic VM(UBVM)，例如方塊、圓球等。這樣的設計大大提升了 VM 的重用性，使用者也不需要撰寫任何的程式碼或者是規則語言(rule-like language) 就可以從既有的 VM 材料庫中，組合出符合期望的視覺化結果。本篇論文中我們將探討 UBVM 的設計理念以及實做，還有用例子說明如何利用各式各樣基礎的 UBVM 自行加以組合成新的 VM，而且不需要撰寫任何的 13.

(14) 程式碼。xDIVA 的最終目標，是希望程式設計人員只要經由一個簡單的 GUI 介面，藉由滑鼠的選擇及拖曳，組合現有的 VM，即可建構出使用者想要的視覺化。因此，資料與 VM 間的視覺化對映將不再受到限制，唯一的限制是程式設計師對於視覺化的想像力。. Section 1.2. 論文架構. 首先在第二章，會先介紹一些閱讀本論文的相關知識，包括 Debugger，和一些 software visualization 相關的 related work。第三章則是對 xDIVA 做簡單的介紹。如何設計與實作基礎的 VM 以及如何利用基礎 VM 組合出新的 VM 將在第四章的 Design and Implementation of UBVM 做介紹。第五章則會用一些例子說明 xDIVA 怎樣幫助我們視覺化，最後在第六章做一個總結。. 14.

(15) Chapter 2 Section 2.1. 研究背景. 除錯器(Debugger). 尋找及修復錯誤，或稱為” 除錯” (debugging)，已經是軟體開發過程必經的階段。電腦先驅 Maurice Wilkes[11]在 1940 年代曾描述說，他餘生的大部分時間，將花在尋找他所寫程式中的錯誤。當軟體日趨龐大且複雜的同時，除錯也變的越來越困難。因此，出現了 debugger 這樣的系統程式，用來幫助程式設計者逐步執行程式碼，藉由觀察程式狀態及變數值的變化來尋找程式中的錯誤。少了 debugger，程式設計者就只能透過新增列印指令的方式，在有可能出錯的程式片段將變數的值輸出至螢幕或是檔案裡，然後進行除錯，非常的沒有效率。 debugger 的製作相當困難，因為必須透過作業系統以及硬體架構的支援，而且和程式語言也具有相依性。圖 4 是一個典型的 debugger 架構。程式語言的種類相當多，通常都有各自相對映的 debugger，甚至有的 debugger 也支援不只一種程式語言。. 圖 4. debugger 的架構圖 15.

(16) 常見的除錯器包含 GDB 以及 JDB。GDB[12]是由 Richard Stallman 在 1968 針對 GNU 系統所寫的一個 debugger。因為 GDB 具有可攜性，所以後來在許多 Unix-like 系統上也可以使用，而且它支援程式語言相當多，例如：Ada、C、C++、 Fortran…等。GDB 是一個命令列模式(command line interface)的 debugger，也就是一切除錯的過程，都要透過下指令的方式來與 debugger 做互動。例如：list 指令可以列印程式本文，print 指令可以印出運算式的值，break 加上列號或函數名稱可以設定中斷點。對於已經習慣命令列模式的資深程式設計師，使用這樣的工具當然沒有太大問題，不過對於新進的菜鳥程式設計師，可能就還要花費一段時間去學習各個指令的功能，沒有辦法很快上手。為了讓使用上更為便利，圖形使用者界面 (graphical user interface)開始被導入 debugger 中，也就是 debugger front-end。使用者透過 debugger front-end 的 GUI(graphical user interface)與後端的 debugger 溝通，而不用下任何的指令。GDB 因為可使用在許多不同的 unix 系統上，所以針對不同的作業系統，也各自有對映的 debugger front-end 可供使用。例如：KDbg 是使用在 KDE 的作業環境上， Nemiver 是使用在 GNOME 的作業環境上，而 Xxgdb 則是使用在 X-window 環境上。圖 5 是 KDbg 的執行視窗。不過最廣泛使用的 debugger front-end，還是 DDD[9]。. 16.

(17) 圖 5. KDbg 的執行視窗. DDD 是一個 open-source source 的 debugger front-end，可以支援多種 debugger debugger，例如：GDB，DBX，WDB，JDB JDB，XDB，Perl debugger 和 Python debugger 等。不過它最出名的地方在於它可與使用者互動然後將資料結構以圖形的方式的呈現過它最出名的地方在於它可與使用者互動，然後將資料結構以圖形的方式的呈現出來。DDD 在整個視覺化過程中，都是透過視窗選擇與使用者互動，完全不用在整個視覺化過程中完全不用在程式中新增任何的程式碼。。舉例來說，一個指標物件在 DDD 中會用方塊和有向線來表示它，方塊內顯示的是變數的資料方塊內顯示的是變數的資料，使用者可經由右鍵所跳出的視窗選使用者可經由右鍵所跳出的視窗選擇顯示更細部的資料。而陣列陣列物件則是以表格的方式去呈現。圖 6 是 DDD 的執行視窗，Data Window 就是資料圖形化的視窗。透過呼叫外部的數學繪圖程式就是資料圖形化的視窗透過呼叫外部的數學繪圖程式 gnuplot，DDD 也能將 2 維陣列以 3D 曲面的方式呈現，圖 7 是 DDD 透過 gnuplot 所繪製的 1 維和 2 維陣列。不過可惜的是不過可惜的是，DDD 所能呈現的資料格式相當有限所能呈現的資料格式相當有限，視覺化也都是固定的模式，所以大部分還所以大部分還是用於有向圖，例如:圖(graph)，，樹(tree) 17.

(18) 等資料結構上，而無法套用在任意的資料結構中。. 圖 6. 圖 7. DDD 的執行視窗. DDD 透過 gnuplot 所繪製的 1 維和 2 維陣列. 另一個常見的除錯器是 JDB。JDB 是由 Sun Microsystems 公司所研發的，可支援的程式語言是 Java 。JDB 和 GDB 一樣也是命令列模式(command line interface)的 debugger，常用的指令包含 print，dump，threads，stop 等。因為使 18.

(19) 用上的方便，一般常用的 IDE，如 JBuilder、ECLIPSE 及 WSAD(WebSphere Studio Application Developer)，都有內建 JDB 以及圖形化使用者視窗介面供使用，而不用另外安裝 debugger front-end。. Section 2.2. 軟體視覺化(Software Visualization). 視覺化的圖片及其中之間的關聯性，遠比條列式的文字還要符合人們心靈運作的方法，也能夠更迅速地傳遞大規模的多樣資訊。軟體工程先驅 Brook[13]曾提到，不可見性令程式設計變成是相對困難的一門工程領域。因此，在軟體領域中，我們更需要有視覺化的輔助來幫助我們更瞭解軟體行為內部的運作。大部分成熟的工程領域都有標準的藍圖去描述它的設計以及產品，不過軟體因為是動態的，所以儘管軟體工程的研究一直試圖尋找如何用圖形來描述軟體系統，最後也只有 UML(Unified Modeling Language)[4]成為軟體工程的重要標準圖形。不過，因為 UML 是靜態的圖形，所以僅能幫助使用者從不同面向去瞭解軟體的大架構，而無法真正的顯示出軟體的動態行為及內部資料的改變。隨著軟體快速發展，軟體專案的規模越來越大，程式碼也以百萬行做計算，軟體的品質好壞以及效能成了管理者需要把關的重要課題。在軟體發展的過程中，越早發現程式碼中的 bug，或是設計上的缺失，及早處理，越能降低因為除錯所帶來的大量的人力與時間成本。因此，有一派主流的軟體視覺化主要是針對這樣的需求所設計的。例如：BLOOM[6]，JIVE[7][8]，JOVE[14]，Jinsight[15]， 19.

(20) VIZZ 3D[16]。這類軟體主要透過分析靜態的程式碼，得到 software metrics[5]的資料，然後將它給視覺化出來。而視覺化的過程中，可以讓使用者依照個人偏好去選擇幾種預設的視覺化方式。另一類的軟體視覺化主要針對的是程式內部的行為，這也是程式設計者主要關心的。只不過因為前面所述資料對映的老問題，大部分這類的軟體都只針對幾種特定的資料結構去進行視覺化。因此，這類工具很少用在商業用途，大多用於教學上，例如：資料結構和演算法。這類軟體包括：DDD[9]，Graphviz[10]， Lens[17]，LIVE[18]，jGRASP[19]。其中，DDD 針對指標和陣列提供有向圖的視覺化，而 Graphviz 也只提供有向圖的視覺化，例如 tree 及 graph。本篇論文所使用的工具 xDIVA 也是屬於這一類的，不過 xDIVA 的目標，是希望能夠解決任意資料對映的問題，讓視覺化除錯向前邁進一大步，而更具實用性。. 2.2.1. 視覺化隱喻(Visualization Metaphor). 在視覺化的過程中，” 隱喻” 是我們常用的一種方法。例如：假設今天我們設計了一個計算功能的軟體，為了讓使用者更容易理解，我們就會設計一個計算機樣子的圖示來代表它，這就是一個隱喻。使用者一看到這個圖示，馬上會知道這是一個什麼樣的產品。我們稱將資料以圖形視覺化的元件或程式為視覺化隱喻 (VM，Visualization Metaphor)[2]，在我們每天所使用的作業系統中，運用資料夾和檔案櫃的圖形來表達一個檔案系統就是使用了這樣的方法。VM 通常具有一些 20.

(21) 屬性，例如：大小、顏色、透明度等透明度等。透過改變 VM 的屬性，使用者能更輕易的使用者能更輕易的瞭解到資料的分布及變化。以下面以下面圖 8 為例，人類從左圖很難一眼看出有幾個人類從左圖很難一眼看出有幾個圓圈是代表 true，幾個圓圈是代表幾個圓圈是代表 false。但是對於右圖用顏色來做區分，，卻很容易的就可以看出。. 圖 8. 2.2.2. 顏色與文字視覺化效果的對比. Lens. Lens[17]是早期的一套 debugger-based debugger 的視覺化工具，主要特色是它試圖將 debugger-based 的系統和演算法視覺化的系統給整合成一個新的系統和演算法視覺化的系統給整合成一個新的系統。Lens Lens 是在 X Window 環境上所開發的，使用的環境上所開發的 debugger 是 dbx，整合的演算法視覺化整合的演算法視覺化系統是 XTango[20]，支援的程式語言為支援的程式語言為 C。圖 9 為 Lens 的系統架構圖的系統架構圖。. 圖 9. Lens 的系統架構圖 21.

(22) Lens 系統是由 client-server 架構所組成，視覺化的方法主要是採用互動式的事件標記模型 (event annotation model)，也就是由負責使用者介面的 Parent Preocess 在程式碼中安插視覺化事件的標記，然後當程式執行到有標記的程式碼時，由 Child Process 呼叫 dbx 執行中斷，將所獲得的變數資料傳回給 Parent Preocess，經過一些 dialogs 讓使用者設定視覺化的物件後，再透過 XTango 將動畫給呈現出來。Lens 的優點是能快速的產生出視覺化的物件而不需撰寫額外的程式碼，而且針對複雜的資料結構，例如：Array、Linked List、Binary Tree 也有提供範例(Template)加速視覺化的過程。不過 Lens 只有三、四種最基本的 VM 可和資料結構作對映，所以視覺化的彈性度較低，而且對於視覺化物件間的 layout 問題也並未做特別的處理，比較適用於教學用途上一些簡單的演算法的視覺化。圖 10 為 Lens 的執行視窗。. 圖 10. Lens 的執行視窗 22.

(23) 2.2.3. LIVE. LIVE(Language-Independent Visualization Environment)[18]是一套針對教學用途而開發的視覺化軟體，主要的目的是希望藉由視覺化幫助程式初學者更瞭解資料結構的變化與程式碼之間的關聯。LIVE 也針對初學者對於不同程式語言間語法不熟悉所造成的語意誤解提供了改善方法，也就是它支援多種語言，LIVE 目前所支援的是 Java 和 C++。 LIVE 所能視覺化的 VM 與 DDD 差不多，就是一些基本型態的變數(例如：布林值、整數、浮點數、字串) 還有指標，不過它還可以視覺化簡單的迴圈和遞迴。圖 11 是 LIVE 的執行視窗，圖 12 是 LIVE 執行 circle linked list 的例子。. 圖 11. 圖 12. LIVE 的執行視窗. LIVE 執行 circle linked list 的例子. 23.

(24) LIVE 視覺化的步驟是讓使用者先在右邊視窗定義一個簡單的資料結構，然後左邊視覺化的視窗就會產生一個對映的 VM，之後透過按右鍵所提供的幾個預設的功能，使用者可在左邊立即看到視覺化的結果，同時系統自動在右邊程式碼視窗自動產生從原始狀態至目前狀態所需增加的程式碼片段。由此可知，LIVE 的視覺化其實和一般的視覺化步驟是顛倒過來的，使用者不用事先撰寫程式碼，然後經由設立中斷點的方式來視覺化程式片段，而是先產生視覺化物件，再去觀察系統所自動產生的程式碼片段之變化。這樣的視覺化最大的缺點顯而易見，就是缺乏彈性。所有的視覺化功能都是固定寫死的，這樣才能產生對映的程式碼。 VM 的擴充性也很有限，因為所有視覺化功能都是針對特定的 VM 去進行開發的，若新增不同類型的 VM，可能功能又要另外撰寫。. 2.2.4. jGRASP. jGRASP[19]是另一套針對教學用途開發的視覺化軟體，不過它僅支援 Java。在 jGRSAP 中，將 VM 稱為一個 viewer，不同的資料結構，都有其不同對映的 viewer。jGRASP 的特色除了支援的 VM 類型(包含支援 Tree、List、Map)較豐富之外，最主要是它試圖將 VM 與資料結構做自動的對映，也就是由 jGRASP 依據程式碼去判斷資料類型，自動產生對映的 viewer。圖 13 是 jGRSAP 的執行視窗，圖 14 是 jGRSAP 執行 binary tree 的例子。. 24.

(25) 圖 13. 圖 14. jGRSAP 的執行視窗. jGRSAP 執行 binary tree 的例子 25.

(26) jGRASP 解決資料與 VM 間自動對映的方法是利用資料結構識別子(Data Structure Identifier)，也就是由系統去搜尋資料結構的關鍵字，然後去比對特定資料結構常用的識別字。例如，binary tree 的資料結構，通常會將左子樹命名為 left，右子樹命名為 right。不過這樣的猜測方式，有可能面臨一對多的難題，舉例來說，一個資料結構有 left 和 right 兩個指標，有可能是 binary tree，也可能是 double linked list。所以，自動配對成功的機率有限，並未真正解決資料與 VM 間對映的問題，只能滿足教學上特定的例子。. Section 2.3. 3D 視覺化. 上一節介紹了幾種視覺化軟體，它們都是使用 2D 的方式來做視覺化。不過近年來，越來越多的視覺化軟體採用 3D 的方式來做視覺化，例如：VIZZ 3D[16]、還有像 GEF3D[21]這樣的 3D visualization 的 framework。使用 3D 來做視覺化真的比較好嗎？其實不一定。如果只是簡單的資料結構或是資料量很小時，其實 2D 的視覺化就已經足夠了，3D 的視覺化並沒有太大的差別。不過，若面對的是複雜的資料結構或是資料量龐大時，3D 的優勢就會顯露出來了。3D 的環境比 2D 多出一個維度，我們可以善用這一個維度來幫助我們將資料排列成最符合使用者心目中理想的視覺化，這也是 2D 的視覺化所辦不到的。在 3D 環境裡，使用者擁有縮放、展開、收合以及旋轉 3D 物件的基本互動性，這些對於程式設計者理解一個複雜的資料結構時有很大的幫助。例如：程式 26.

(27) 設計者面對大量資料時，只需要展開他有興趣的部分，其餘部分就讓它們收合起來。或者也可選擇將鏡頭拉近至所要觀察的部分，讓整個螢幕焦點只呈現使用者目前感興趣的物件，其他部分則都暫時隱藏於螢幕之外，當使用者想要觀察另外的物件時，再將鏡頭拉遠移動至想要觀察的部分後，再拉近放大物件。此外，旋轉視角的功能也讓空間的利用度大大提升，配合比 2D 多出的一個維度，物件不僅可以水平、垂直排列，甚至還可以縱向排列，藉由轉換視角或旋轉物件，對物件的觀察將不再有死角。為了提供最大的視覺化彈性，本實驗室所開發的視覺化除錯工具—xDIVA 架構在 OGRE[22]這個 open source 的 3D 引擎上。 OGRE 是一個高階物件導向的 3D 引擎，我們用它來製作各式各樣的 VM，不僅僅是為了要縮短程式開發的時間，更希望能藉助 3D 引擎即時的動畫能力，以及它所提供的豐富特效，使我們更真實的呈現軟體的動態行為。. 27.

(28) Chapter 3. xDIVA. xDIVA 主要由除錯器前端 (Minerva) 以及視覺化子系統(DIVA) 所組成。圖 15 為 xDIVA 的系統架構圖。. 圖 15 xDIVA 的系統架構圖接下來我們將針對這兩個子系統做一個簡介，讓使用者熟悉整個操作環境以及初步瞭解視覺化的整個流程。. Section 3.1. Minerva. Minerva 是由 Java 所開發的除錯器前端 GUI 介面，選擇 Java 作為開發的程 28.

(29) 式語言主要是考量到 Java 的跨平台能力。Minerva 的基本功能與一般除錯器前端差不多，包含讓使用者可以瀏覽程式碼，以及設定中斷點，執行除錯，以文字模式顯示變數值。不過最特別的地方是，它比一般除錯器前端多了”visualize”這個按鈕(類似眼睛的圖示)，它允許程式設計師將除錯資訊送到 DIVA 子系統進行視覺化。Minerva 目前可以支援的除錯器為 GDB 以及 Java 的 JDB，不過考量到未來能擴充支援更多的除錯器，所以 Minerva 並不直接與後端的除錯器做溝通，而是透過根據 bridge pattern[23]所設計的 Command Center 將使用者經由使用者界面所下達的命令，透過中間介面傳遞給正確的除錯橋接器(Debugger Bridge)，目前是 JDB Bridge 或是 GDB Bridge，再透過橋接器和除錯器做溝通並將結果回傳回來。Minerva 的主要執行視窗如圖 16 所示。. 圖 16. Minerva 的執行視窗 29.

(30) 在開始進行除錯之前，還是有些環境變數必須先做設定。Minerva 共有兩個設定的視窗，分別是圖 17 中的 RUN Dialog 以及 Config Dialog。. 圖 17. Minerva 的 RUN Dialog 與 Config Dialog. RUN Dialog 主要功能是設定程式執行的執行檔路徑，classpath 以及傳入參數。為了初學者使用方便，特別提供”Easy Run”功能，可自動替使用者設定路徑。因為 Minerva 與 DIVA 間的溝通是透過網路，所以另外一個 Config Dialog 主要功能是設定有關網路的資料，例如：xDIVA 所在主機的 IP 以及與 DIVA 溝通的 port。另外，Config Dialog 也兼具設定 debugger 的路徑，以及改變 Minerva 的外觀樣式與按鈕風格的功能。 Minerva 子系統中包含了一個重要的元件叫做 Minerva Server Thread。我們用一個例子來看它在視覺化過程中所扮演的角色。假設今天使用者想要視覺化一個變數 p，則會先透過前端的 Minerva UI 將這個訊息透過網路傳給 DIVA，接著 DIVA 會傳送一系列的命令來詢問 p 的值，而這些命令就是透過 Minerva Server 30.

(31) Thread 和 DIVA 子系統的 Command_Agent 做溝通，將視覺化所需要的變數資料傳遞回去。Minerva 取得變數資料的溝通命令一共有 3 種，分別是： . “ask”：可用來取得變數型態和記憶體位置資訊。. . “show”：可用來取得變數的值。. . “struct”：可用來取得類別物件下的屬性名稱以及資料型態，例如：展開陣列物件底下的所有元素。. Section 3.2. DIVA. DIVA 是一個以 Ogre[22]這個開放原始碼的 3D 引擎所建構出的 3D 視覺化環境，圖 18 是 DIVA 的執行視窗。DIVA 的主要工作是將從除錯器端(Minerva)所收集取得的程式變數資料，依照使用者的需求去視覺化，而且提供使用者介面讓使用者能夠手動進行調整（例如：資訊與 VM 間的對映方式、資料數量龐大時的排列方式等）。3D 的環境允許使用者可以任意拉遠、拉近，旋轉角度，調整各種視角去觀察所視覺化的資料，而多一維的景深更讓資料排列方式有了更多元的變化，使用者不必再忍受一成不變的視覺化方式，而能依照自己想要看到的樣式去視覺化除錯資料。 Command Agent 在 DIVA 子系統中扮演十分重要的角色，因為它與所有的元件間都有相關，我們一樣用一個簡單例子來說明 Command Agent 與這些元件在視覺化過程中所負責的功能。假設今天使用者想視覺化 p 這個變數，當使用者在 31.

(32) Minerva 上按下 Visualize 按鈕，輸入 p 這個變數後，Minerva 會發出訊息給 Wop Server Thread，然後由 Command Agent 發出指令和 Minerva 端的 Minerva Server Thread 作密切溝通。當 Command Agent 收集完所需的資訊後，會在 WOPM(Watched Object Pool Module)裡創建出一個 wop(Watched Object Parameter) 物件，這個 wop 物件負責儲存要視覺化變數 p 的所需資訊。當程式中斷點改變時，Minerva 會主動通知 Command Agent 程式的狀態有所改變，此時 Command Agent 會根據 WOPM 中所有的 wop 物件逐一向 Minerva 從新取得最新的資訊。而當使用者停止該程式的除錯後，Command Agent 也會將所有的 wop 物件給清除。. 圖 18 DIVA 的執行視窗 32.

(33) 當 Command Agent 收集完資訊放進 wop 後，整個視覺化尚未完成，因為還缺少了視覺化中最困難的部分—資料與 VM 間的對映。DIVA 主要是透過一套 Mapping Engine 來將 wop 的資料和 VM 做對映，不過使用者並不需要額外為這個對映撰寫任何程式碼，整個對映的過程都會在 DIVA 所提供的 Mapping GUI—Mapping Dialog 中完成。圖 19 是 Mapping Dialog 的執行視窗。使用者只要透過簡單的選擇 VM 的種類以及拖曳滑鼠將 wop 連結到 VM，接下來就是針對 VM 的外型做一些設定(如果是視覺化的必要屬性，都會提供預設值)，整個視覺化就算完成了。如果使用者對於視覺化出來的結果感到不滿意，也可以重複相同的步驟，在 Mapping Dialog 重新選擇合適的 VM 做對映或者是調整 VM 的一些屬性參數，讓視覺化的效果更明顯、更容易觀察。針對複雜或大量的資料結構，DIVA 中也運用了組合的概念，去解決對映的問題，而組合 VM 的方式一樣也只要透過選擇與拖曳就可完成，使用者不必為了這個新組合出的 VM 撰寫任何一行程式碼，關於如何組合的細節會在第四章中做更進一步詳細說明。. 33.

(34) 圖 19 Mapping Dialog. Section 3.3. 由 Mapping Nodes 所組成的世界. 在 xDIVA 中，VM 嚴格上來說並不直接拿來與資料作對映，而是經過封裝後變成一個 mapping node。mapping node 的概念其實就像是一個箱子，然後有一組標準的介面(IN ports 和 OUT ports)可以和外界溝通，所以它不僅僅可以封裝 VM 進去，也可以將一些不屬於標準的 VM、卻是視覺化中常用到的功能給封裝進去，例如：數學運算。整個 xDIVA 其實就是由這些 mapping node 所組合而成的世界，有了這些 mapping node，視覺化就變的有如模組化一般，不同的模組各自負責一個特定的功能，由使用者依需求去挑選適合的模組進行合成。如果今天使用者有了新的功能需求，我們也可以很快速的增加一個實做此功能的 mapping node，而不需要更動到原來的架構。 xDIVA 目前所用到的 mapping node 可以分為 7 種類型，以下分別針對各類型的 mapping node 做一個簡介： . UBVM：負責視覺化功能的 mapping node，相當於傳統視覺化中所使用的 VM，是視覺化中最基本一定要使用到的，也是本篇論文主要的實做成果，在第四章中會有更詳盡的說明。. . UBRVM：指標或是參考(reference)對於程式設計來說，是經常使用的重要資料結構了。而指標的視覺化可以幫助程式者更瞭解兩物件間的二元關係。在 xDIVA 中，想要視覺化兩物件的二元關係並不僅限於一種方式。當兩視覺 34.

(35) 化物件是屬於同一個複合的資料結構(例如：object、struct 或是 array)時，我們可以使用 UBVM 中的 line3D_UBVM 去視覺化。使用者只要在 Mapping Dialog 中將兩視覺化物件的位置與 line3D_UBVM 的起始點和終點的座標做對映，就可輕易完成視覺化。如果兩視覺化物件是屬於不同的資料結構，則適用於這類的 mapping node。UBRVM 可以說是專門為視覺化二元關係所設計的特殊版本的 VM，特別的地方在於 UBRVM 所視覺化的指標物件在展開前，指向的 VM 是未知的，而這項困難挑戰的成功關鍵，主要是透過 mapping engine 巧妙的操控由 proxy pattern [23]所設計的 Proxy VM 所完成。 . Math mapping node：顧名思義就是負責數學運算功能的 mapping node。一個 Math mapping node 可以接受任意數量的 IN port，當變數連結到一個 IN port 後，會自動再新增一個 IN port，之後由使用者輸入所要運算的數學式，這裡使用跳脫字元” $” 來代表變數，變數編號是根據 IN port 個數從編號 0 開始累加。最後透過唯一的 OUT port 將運算結果傳給其他的 mapping node 使用。圖 20 是一個 Math mapping node 的例子以及它輸入運算式的視窗。數學運算對於視覺化有時是不可或缺的，例如：當我們要視覺化一個圓餅圖的比例時，對於 a、b、c 三個整數變數是無法直接與 mapping node 做對映的，我們會需要經過像 a/a+b+c 這樣的運算式去得知 a 所代表的真正的比例。. 35.

(36) 圖 20 . Math mapping node 以及輸入運算式的視窗. Collectors：負責將任意數量的視覺化物件給收集起來的 mapping node。在程式設計中，函數(function)所傳入的變數數量都是固定的，沒辦法動態的去改變，除非利用像 C++中的 STL 物件 vector 將變數給先封裝起來，再傳遞給函數使用。Collector 型態的 mapping node 就是為了解決此問題而設計的，因為使用者每次視覺化所需用到的視覺化物件數量可能都不同，所以我們會利用 vm_collector 這個 mapping node 將視覺化物件給收集起來，然後透過它特有的 OUT port” vms” 傳給像 ubvm_container 這樣具備容器功能的 mapping node，最後再依序去視覺化出來。Collector 物件之所以分成收集和容器兩類的原因主要是為了可以對映不同的 layout，例如目前所提供的 ubvm_2darray 就可以將 mapping nodes 按照使用者所設定的行列數目排成二維陣列。. . String_composer mapping node：用來調整 VM 被點選時所顯示的除錯資訊的 mapping node。過去視覺化軟體在提供除錯資訊時，都是由系統自動幫使用者決定輸出哪些資訊，但是這些並不一定是使用者最需要的。在 xDIVA 中，. 36.

(37) 我們也給予使用者調整視覺化所顯示的除錯資訊的權力。String_composer mapping node 使用上類似 Math mapping node，也是先將變數連結到一組 IN port，然後由使用者透過一個決定輸出格式的視窗，去決定他想看到的資訊的格式。圖 21 是一個 String_composer mapping node 以及輸出格式的視窗。舉例來說：一個彩色的立方體，我們在除錯時，可能會想知道它所對映的 RGB 值是否正確，所以我們會將 RGB 值的變數連結到 String_composer mapping node，再將格式設定為(R $0,G $1,B $2)，最後將 String_composer mapping node 的 OUT port 連結到 VM 的” _vm_clickmsg” 這個 IN port。當這個 VM 被點選時視覺化結果就會顯示像(R 100,G 50,B 35)的訊息。. 圖 21 . String_composer mapping node 以及輸出格式的視窗. Clock mapping node：以動畫方式視覺化時所使用的 mapping node。這個 mapping node 是為了發揮 3D 引擎動畫能力所設計的，圖 22 是一個 Clock mapping node，它一共有四個 IN port，分別是 low、high、increment、 time_interval。舉例來說，如果我們想將立方體的速度變數 speed 用立方體旋 37.

(38) 轉的動畫方式呈現的話，我們可以將初始值設定給 low(例如設定成 0)，然後設定一個最大值給 high(例如設定成 360)，然後將 1/speed 設定給 time_interval，並設定每個時間間隔所要增加的量給 increment(例如設定成 10)，最後將 OUT port 輸出的結果連結到立方體的旋轉參數。這樣設定的用意是告訴系統，每隔 time_interval 的時間，Clock mapping node 中的計數變數(初始值為 low)會增加 increment 的量，並將累計結果輸出至 OUT port，直到到達最大值 high 之後，計算變數會恢復成初始值 low 重新開始累計。系統則定時根據 OUT port 的結果去更新立方體的最新狀態，於是一個會依照速度變數 speed 旋轉的立方體就誕生了。. 圖 22. . Clock mapping node. VMclone mapping node：這個 mapping node 只有在 Composer Dialog 中使用，是專門為了組合 VM 成為新的 VM 所特別設計的。關於 Composer Dialog 與這個 mapping node 的使用方式，在第四章中會有例子做更詳盡的說明。. 38.

(39) Chapter 4 Section 4.1. 設計與實做 UBVM. 資料與 VM 間的對映. 在軟體視覺化的研究領域裡，資料與 VM 間的對映一直是無法有效克服的老問題。因為資料型態的多樣性，以及不同領域的使用者針對相同的資料會有不同的解釋，都造成對映上的困難。雖然，有意義的變數命名有助於我們推測可能的對映方式，但是就如同前面所敘述的，任何自動化的視覺化對映都可能變得很糟糕。過去，雖然有軟體嘗試自動幫使用者產生資料與 VM 間的對映，不過因為這樣的作法會有對映失敗的風險，會造成使用者對軟體的信賴度降低，而造成使用意願不高。目前常用來解決資料與視覺化物件間對映關係的方法，叫做”model-view” 。使用者首先必須針對特定的資料型態，去定義所謂的 model，然後與它相對映的視覺化，也就是 view，才會跟著被創造出來。舉例來說：一個 Graph 的 model，一定會包含兩種資料型態，分別表示節點(node)和線(line)。針對節點和線的視覺化，可以透過參數的方式作某種程度的調整，例如：節點的類型、大小、顏色以及線段的粗細、顏色…等。當使用者想將一組資料視覺化為 graph 時，會先將資料對映到 model 上，然後 view 就會以 model 內部的資料型態以及設定為基礎被實做出來。例如，一般我們會將節點以圓圈來代表，線以實線來代表。基本上，一個 model 所對映的 view 是預先設定的，而參數設定上的差別，則保有了 model 與 view 間對映的彈性，因此可以做到自動化對映，而且也不會有失敗的風險。 39.

(40) 另一個與 model-view 類似的方法，叫做宣告法(declarative approach)。使用者先透過工具所定義 pattern language(或是 declarative language)，將資料結構定義為一個 pattern，然後工具會依據預設的一組視覺化物件去將所對映的 pattern 給視覺化出來。也就是說，pattern 和視覺化物件間的關聯是一對一的，每個視覺化物件都是針對特定的 pattern 所建構的。這個方法的優點也在於資料與 VM 間可做到自動化對映。不論是以 model-view 或是以 declarative approach 所實做出的軟體視覺化工具，最大的問題就是所視覺化的資料必須符合 model 或是 pattern。一旦資料不符合，就無法進行視覺化。因此，使用者可能必須將想要視覺化的資料，先經過收集然後組織或轉譯成工具所需要的架構，才能順利進行視覺化。所以大多數以 model-view 實作的軟體視覺化工具主要的應用都以處理 software-metric(軟體度量)為主，比較偏重於分析面。用於教學用途上時，此類方法也可獲得不錯的效果。既然我們無法預測資料型態的多寡，也不可能針對每一種型態去設計相對映的 VM，那到底要如何去實現任意且複雜的視覺化呢？關鍵可能在於資料和 VM 之間要能達到退耦(decoupling)，也就是 VM 只單純描述一種視覺化的呈現，而不和資料有耦合(coupling)。藉由將資料跟 VM 退耦，單一 VM 將不再只能視覺化某一種特定的資料結構，而是具有高靈活性及重用性，可視覺化多種資料結構。 40.

(41) 解決 decoupling 並不是個新鮮的問題，目前已有很多種解決方式。例如： AT&T 的 Graphviz 是利用 meta-format 的方式去解決與任意型態資料間的耦合，另外，Observer pattern[23] 也是一個嘗試解決此問題的著名方法。不過，底下我們用一個例子來說明 xDIVA 為何不採用 Observer pattern 來解決 decoupling。圖 23 是一個 Observer pattern 的例子。. 圖 23 The Observer pattern 在這個例子中，任何想要視覺化的 ConcreteSubject 物件必定要繼承來自基底類別 Subject 的 interface，而用來視覺化 ConcreteSubject 的 ConcreteObserver 物件也必須要繼承基底類別 Observer 的 interface ，而且必須向所要視覺化的 ConcreteSubject 物件註冊。假設今天某個 ConcreteSubject 物件的狀態被改變了，向它註冊的 ConcreteObserver 物件會被 update()這個 method 所通知，進而觸發 subject->GetState() 去向這個 ConcreteSubject 物件取得最新的狀態去更新視覺化 41.

(42) 的結果。因為 subject 這裡代表的是一個指標(或是 reference)，也就是說， ConcreteObserver 物件的程式碼和 ConcreteSubject 物件之間存在耦合並且和 ConcreteSubject 物件的型態具有相依性，這個相依性限制了單一 ConcreteObserver 物件僅能視覺化它所對映相同型態的 ConcreteSubject 物件，這和我們所希望藉由 VM 重用性以及組合性的概念，去實現任意且複雜的視覺化有所衝突。 xDIVA 為了解決資料與 VM 間對映的問題，設計了一套 mapping engine 以及前端的 Mapping Dialog，VM 的設計上也導入 OO 的概念，程式碼中不會有任何指標與資料產生耦合。我們的目標是希望程式設計師不需要撰寫額外程式碼，只要透過簡易的拖曳和選擇就可以得到他所想要的視覺化，也不需要再額外閱讀相關的說明文件。. Section 4.2. 最基本的建構元件-UBVM. 在緒論中，我們曾經提到合成性(composability)，也就是人類在面對無窮的組合選擇時，懂得先找出最基本的元件，然後設定好這些基本元件間組合的介面，之後便可以依據不同的組合原則，去將這些基本元件組合出更大的元件。一個高合成性的系統提供了元件的重組性，使用者可以經過選擇和重組來滿足不同的需求，這個特性是 xDIVA 想要達成視覺化任意的資料結構的關鍵。而元件間要能獲得可重組的重要因素，就是必須滿足自我滿足性(self-contained)。換言之，元件須可單獨使用，或與其他的元件間互相合作，不過相依元件間不具耦合，要可 42.

(43) 以被置換。在 xDIVA 裡，我們將這些最小、最基本的視覺化單位稱為 UBVM(ultimate basic VM)。不過，我們是如何從眾多的 VM 裡面挑選出這些 UBVM 呢？一部份的原因來自於我們過去的研究經驗，一部份的靈感來自於日常生活中的觀察。舉例來說：一個綠色的長立方體和一個灰階的立方體，其實都不應該當作 UBVM，因為它們都可以由一個更基本的立方體所延伸變化出來。再看另外一個例子：一個平行四邊體和一個橢圓球體，其實也都不適合作為 UBVM 的一員，因為平行四邊體可以經由兩個三角柱體所組合而成，而橢圓球體可由球體變化而來。由這兩個例子，我們不難發現，凡是可以經由更小的元件所組合出的 VM，都不是我們挑選的目標，反過來說，如果一個 VM 已經無法再找出更小的元件來組成它，理論上它就是成為 UBVM 的最佳人選。上面兩個簡單的例子，就已經幫助我們找出了三個 UBVM，分別是立方體、球體和三角柱體。另外，過去其他軟體視覺化工具所使用的 VM 或者是教科書上的範例圖形，也都是我們找尋 UBVM 的好素材。例如：一個二元樹通常會使用圓來代表節點，線來代表指標；一個 graph 通常使用圓來代表節點，線來代表路徑；而一個環形佇列是將佇列排列成環狀體。其實不難發現，只要一些簡單的圖形，就足以視覺化出很多資料結構或是演算法的例子。日常生活中的許多物品，其實也都可以想像成是由一些 3D 元件所組成的，就像是我們在一些 CG 電影或是 3D 遊戲裡面所看到的。譬如：立體的箭頭可以 43.

(44) 由一個圓錐體和一個圓柱體所組成，一張四腳桌子是一個扁平的長立方體和四個圓柱體所組成，戒子、甜甜圈、貝果都是一個環狀體，一塊蛋糕是一個不完整的圓柱體，一個蜂窩是由許多的六角柱體所組成，而一道彩虹是由幾個不完整的環狀體所組成。經由反覆的觀察與整理，目前我們規劃出 11 種 UBVM。當然，這些並不足以組合出所有的 3D 物件，但是，針對我們目前初步所想要視覺化的一些問題和例子，已經綽綽有餘，而這些 VM 也是未來我們挑選和過濾新的 UBVM 的重要依據。以下分別介紹這 11 種 UBVM： 立方體(Cube)： 3D 的正方形，有六個面，長寬高皆相同。可以經由變數的調整，視覺化出各式不同長方體。對於視覺化來說，這是最普遍使用到的 VM。 球體(Sphere)： 3D 的圓形，半徑的大小可以經由變數去調整。常被用來視覺化節點，是視覺化裡不可缺少的 VM。 不完整球體(Partial Sphere)：部分的球體，顯示的比例部分可以透過變數設定(0.1-1.0)，起始角度也可透過變數設定，我們可以用它來視覺化有關於比例的問題。 完整環狀體(Torus)：如甜甜圈一樣的中空環，環的半徑以及中空的半徑可以透過變數調整，是日常生活中常見的 3D 物件。 不完整環狀體(Partial Torus)：部分的甜甜圈，顯示的比例部分可以透過變數設定(0.1-1.0)，起始角度亦可透過 44.

(45) 變數設定，我們也可以用它來視覺化有關於比例的問題。 文字(Text)：可以用來視覺化文字、數字。這是傳統視覺化的主要方式，我們將用它來當作我們視覺化圖形物件的輔助說明。 圓柱體(Cylinder)：圓柱體的半徑及高度可以透過變數改變，厚度較薄的圓柱體可用來視覺化圓餅圖，厚度較厚的圓柱體也可視覺化出類似長條圖的效果。 不完整圓柱體(Pie)：如同切片的蛋糕，顯示的比例部分可以透過變數設定(0.1-1.0)，起始角度也可透過變數設定，同樣用來視覺化有關於比例的問題。雖然和不完整球體、不完整環狀體一樣，都可透過變數設定成完整的圖形，不過基於使用上的方便，以及功能的考量，我們還是將他們分開成不同的 UBVM。 角錐體(Pyramid)：錐體的半徑和高度，以及錐體的邊數(至少 3 邊)都是可變動的參數，可以用來組合成箭頭或是其他的視覺化物件。 多邊柱體(Prism)：和角錐體類似，只是多邊柱體上下兩面都是平面，柱體的半徑和高度，以及柱體的邊數(至少 3 邊)都可隨視覺化需求而調整。 3D 線段(Line3D)：設定起始點的 x,y,z 座標以及終點的 x,y,z 座標，還有線段的粗細，就可在三度空間中畫出一線段，這也是視覺化中不可或缺的 VM。 VM 的開發牽涉到需瞭解一些 3D 繪圖的知識，以及長時間的測試與除錯。 45.

(46) 所以我們希望使用者都不需要煩惱這些問題，只要懂得如何從這些已開發完成的 UBVM 去組合出新的 VM 就好了，也不必再撰寫任何新的程式碼。不過，若使用者覺得現有 VM 真的不敷使用時，我們仍可視需求去設計與開發新的 UBVM。. Section 4.3. UBVM 的實做. 我們實做 UBVM 的方法，是先在 Ogre 中創建出一個由許多三角形所構成的可調整的多邊型(polygon)，也就是幫每個 UBVM 建構出 3D 的模組。然後我們將這個多邊型透過 Ogre 提供的函式轉成 mesh，最後再將 mesh 給封裝進 UBVM 的類別(class)裡，而我們可以經由參數去改變這個 UBVM 的外型及顏色。透過找尋 UBVM 的過程，我們發現到，每個 UBVM 其實都由一組 3D 屬性所控制，而不同種類的 UBVM，其實會有許多類似的 3D 屬性。以圖 24 這個最基本的立方體 UBVM 為例，它的外型會由底下這些屬性所決定。 . _vm_rx, _vm_ry, _vm_rz -- 立方體中心點的三度空間座標。. . _vm_sizex, _vm_sizey, _vm_sizez -- 立方體在 x,y,z 軸上的大小。. . _vm_sizexscale, _vm_sizeyscale, _vm_sizezscale –立方體在 x,y,z 軸上的比例大小(預設值為 1)。. . _vm_r, _vm_g, _vm_b –決定立方體材質的顏色(0.1-1.0)。. . _vm_trans –決定立方體的透明度(0.1-1.0)。 46.

(47) . _vm_yaw, _vm_pitch, _vm_roll, _vm_quat -- 控制立方體對於 x,y,z 軸的旋轉以及角度。. 圖 24 最基本的立方體 UBVM 我們將這些 UBVM 間共同的屬性稱為基本屬性(default properties)，每一個基本屬性對於 VM 來說皆有一個相對映的 IN port，負責將使用者設定的參數給傳遞進來，而且也有一組相對映的 OUT port 可以將此 VM 的屬性參數傳遞給其他 VM 或是 mapping node 使用。為了避免單一 VM 佔用版面過大，IN port 預設值只有開啟必須輸入的，其他都先隱藏，視使用者所需自行開啟。除了立方體之外，其他的 UBVM 都有一些特別的屬性，這些屬性在上一節 UBVM 的介紹中都有列出，這些特別的屬性在 IN port 中則是必要輸入的參數，預設是開啟的。圖 25 是 Port Setting Dialog。. 47.

(48) 圖 25 Port Setting Dialog. Section 4.4. 創造新的 VM 而不用撰寫程式碼. 在前面章節中我們曾提到，xDIVA 希望透過合成性(composability)去克服有限的 VM 卻能對映到任意的資料結構的難題。透過 Mapping Dialog，雖然我們可以將數個 mapping node 組合起來去視覺化資料結構中的變數，不過這個過程卻缺乏了重用以及組織性(compositionality)，這裡的組織性指的是能將 VM 與資料間的對映關係封裝進一個新的 mapping node 中的能力，而這個新的 mapping node 就像是一個新的 composite VM，要可被重複使用去對映不同的資料結構，或是再與其他 mapping node 組合出更複雜的 composite VM。為了達成這個目標，xDIVA 提供了另一個 GUI 介面—Composer Dialog，這部分的實做主要是由去年畢業的學長所完成。使用者只要在 DIVA 主視窗中按下 48.

(49) 右下角的” NewVM” 按鈕，就會跳出如圖 26 的 Composer Dialog。這個介面與 Mapping Dialog 十分類似，不過仔細看紅色圈圈框起來的部分，就可以發現它的主要編輯視窗部分多了一個黑色框框的邊界，這個改變主要是為了搭配一種新型態的 IN port 稱為” gate” 。gate 在左邊的分類視窗歸類為 composite_tools，顧名思義就是為了組合 composite VM 所特別設計的元件，而依據變數資料型態的不同，則有不同對映的 gate，如圖 26 左邊紅色圈圈的部分。簡單來說，邊界所扮演的角色就類似程式語言中函數的範圍(function scope)，而 gate 就像是函數所提供的輸入參數。. 圖 26. Composer Dialog. 舉例來說，如果我們今天想畫出像圖 27 一樣的箭頭，我們會用一個圓的角錐體(pyramid)再搭配上一個圓柱體(cylinder)去組合，組合的方式如圖 28 所示，參數部分只要將角錐體的邊數設為 100 成為一個圓錐體，然後將它的位置移動到圓柱體上方即可。這個例子中我們使用到一個特殊的 mapping node 叫做 49.

(50) wrapper_ubvm，它的功能類似 container_ubvm，是將多個 VM 收集起來，不過透過 wrapper_ubvm 所合成的 VM，將變成一個獨立的個體，內部的子 VM 將不再接收外部的參數去改變形體，也無法與外界做互動。經由 Composer Dialog 所組合出 mapping node 就如同一個基本的 UBVM，只能透過基本屬性(default properties)去控制，所以我們會將所有基本屬性對映到一組相同型態的 gate port，為了節省操作時間，我們可利用圖 29 編輯視窗下方提供的” Default Gates” 按鈕自動幫我們新增一組 gate port。當我們設定好對映關係後，只要如圖 29 輸入新 VM 的名字，以及在 Type 的空格輸入這個 VM 應該歸類為哪一類型的 VM，再按下” SAVE AS” 按鈕，就大功告成了。當我們再次開啟 Mapping Dialog，就可在左邊的分類子視窗中，找到我們新增加的 mapping node。. 圖 27. 由 pyramid 及 cylinder UBVM 所組合的 arrow VM. 50.

(51) 圖 28. 在 Composer Dialog 中用 pyramid 及 cylinder UBVM 組出 arrow VM. 圖 29. Composer Dialog 中的參數設定. Composer Dialog 不僅可以組合 VM，對於重用性高的複雜數學運算，我們也可透過它去組合出新的 Math mapping node，之後就可直接使用，不用重複去設定這些複雜的算式。Composer Dialog 的出現，解決了視覺化複雜資料結構時所可能產生的大量 mapping nodes 會造成使用者在做資料對映時的困難，也讓 VM 與資料的對映方式變的更多元化，我們以圖 30 二元樹的例子來做說明。一般我們要視覺化一個二元樹，我們設定資料與 VM 的對映方式可能會如圖 31 的架構一樣，使用一個圓球 UBVM 來表示布林值，底下接兩個 UBRVM 叫做” Ball laser” 分別指向它的左右子樹。而左右子樹所排列的位置，是透過圓球 UBVM 的位置計算而得，在圖 31 中並未顯示出來。這樣的對映方式對於這個 51.

(52) 例子來說看起來並沒有什麼問題，不過仔細觀察，就可發現它的重用性很差。今天如果使用者不想用圓球來代表布林值，或是想換成別的 UBRVM 來代表左右子樹的指標時，整個對映方式就必須由使用者重新設定，十分浪費時間，因為其實計算位置的邏輯部分都相同。有沒有什麼好的解決辦法呢？在上一章中我們曾提到的 VMclone mapping node，這時就派上用場了。. 圖 30. 二元樹在 DIVA 中的視覺化. 52.

(53) 圖 31 二元樹中資料與 VM 的對映關係如果我們在 Composer Dialog 中使用了 VMclone mapping node 來當作二元樹中計算左右子樹位置的邏輯部分，會如圖 32 所示。左邊的 gate port 傳入三個型態為” vm” 的變數，而右上角虛線的部分是一組 Math mapping nodes，負責依據 vm key 的位置算出左右子樹的 VM 所要擺放的位置。VMclone mapping node 會將所傳入 VM 的所有基本屬性都傳遞進來，而將變數連結至 VMclone mapping node 的效果也等同於連結到原始的 mapping node。經由圖 32 所組合出的新 mapping node，將取代圖 31 中 vm_collector 以及 Container_ubvm 的功能，而且還兼具計算左右子樹位置的功能，而傳入的三個 VM 使用者可以自行替換成合適的 UBVM 與 UBRVM。由此可知，mapping node 的重用性如何，取決於使用者組合 VM 的方法，如何創造重用性最佳的 mapping node，則考驗著使用者的. 53.

(54) 智慧。. 圖 32 使用 VMclone mapping node 去計算二元樹中左右子樹的位置. 54.

(55) Chapter 5. 範例. 這章中我們會以五個常見的小程式或是演算法為例，說明我們將如何利用 xDIVA 去幫助我們進行視覺化除錯。. Section 5.1. 老鼠走迷宮. 老鼠走迷宮是資料結構教課書中的一個例子，我們以一個 4x4 的矩陣為例。首先，迷宮周圍會有牆壁，在矩陣中我們用數字 2 來代表它是不能走的牆壁，另外數字 0 則代表可以走的路，另外在搜尋出口的過程中，走過的路徑我們用數字 1 來代表。假設今天我們將起點設為(1,1)，出口設為(3,2)的話，則我們可針對老鼠走迷宮的結果視覺化如圖 33。綠色實心的部分代表的是牆壁，中間半透明的綠色部分代表的是老鼠走到出口所經過的路徑，如果不是選擇路徑上的路則會是透明的。. 圖 33. 老鼠走迷宮的視覺化範例 55.

(56) 接下來我們來看看要如何才能視覺化出這樣的結果，首先，我們知道整個矩陣在程式執行過程中會有三種不同的數字，也就是 0~2，所以我們針對每個陣列元素，在 Composer Dialog 中設計一個叫做 mouse_obj 的 mapping node，使用到一個 Math mapping node，還有一個立方體的 UBVM，其中 Math mapping node 負責將矩陣中的數字除 2 並轉成 double 型態對映到立方體的綠色及透明度的屬性，如圖 34 所示。之後就像圖 35 一樣，在 Mapping Dialog 中開始將資料與 mapping node 作對映，每一個陣列元素對映到一個我們新組合出的 mouse_obj(在 Mapping Dialog 編輯視窗中 composite VM 會以紫色的 mapping node 顯示)，然後交給 vm_collector 收集所有 mapping node，最後連結到一個 2DARRAY_UBVM，將所有 mapping node 排列成 4x4 的矩陣。不過，我們不難發現圖 35 的對映有點複雜，如果每次視覺化都得重拉這個對映關係，會浪費掉不少時間，還得小心翼翼怕會拉錯。這是因為目前 Mapping Dialog 沒有能力（舊版本有）將一個陣列元素的對映關係複製到所有陣列中的其他元素，所以操作上才會如此繁瑣，這部分將是未來 Mapping Dialog 改進的一個重點。不過，我們可以再將這個對映關係封裝進一個 mapping node，也就是圖 36 中的 Mouse 這個 mapping node。透過我們新組合出的 Mouse 這個 mapping node，整個資料與 VM 的對映關係就變成非常單純，就像圖 37 所示，一個陣列元素對映到一個 Mouse 中的 IN port。Composer Dialog 所帶給使用者的便利性與實用性，在這個例子中也一覽無遺。. 56.

(57) 圖 34. 在 Composer Dialog 中組合出 mouse_obj 的 mapping node. 圖 35. 老鼠走迷宮的資料與 VM 對映方式. 57.

(58) 圖 36. 在 Composer Dialog 中利用 mouse_obj 組合出 Mouse mapping node. 圖 37. Section 5.2. 另一種老鼠走迷宮的資料與 VM 對映方式. 折線圖. 長條圖、圓餅圖及折線圖都是我們經常在統計資料中所用到的圖形，還有像股票走勢圖、心電圖也都是日常生活中使用折線圖的例子。使用折線圖做視覺化能讓使用者快速掌握資料的起伏或是走勢，是一個簡單易懂的視覺化方式。圖 38 就是這個例子想要視覺化的結果，一個 2D 的折線圖。 58.

(59) 圖 38. 2D 折線圖的視覺化範例. 假設今天我們有 4 個點，分別是(-50,0),(-10,50),(20,0),(100,100)，而我們想將這組資料視覺化成圖 38 這樣的折線圖，那我們要如何對映才能視覺化出這樣的結果呢？首先，像圖 38 這樣的折線圖，一定會由三條線及兩個轉折點所構成。當然，我們可以直接使用 3 個 line3D_ubvm 就可視覺化出一個 2D 折線圖，只要將線段起、終點的 z 軸座標設為 0 即可。不過，這樣視覺化出來的折線圖在轉折點的地方其實會有缺口，這是因為當線條有粗細時所無法避免的。所以，如果要像圖 38 中轉折點的地方是平滑的，我們勢必還得再下點功夫。我們將轉折點用灰色的圓球 UBVM 去代表，並將它與一個 line3D_ubvm 的線段在 Composer Dialog 中組成叫做 Bone 的 mapping node，組合的方式如圖 39 所示，其中用到的兩個 Math mapping node 是用來計算確保圓球的大小會隨著線段粗細而同步調整，計算方式為圓球的半徑是線段粗細的一半。. 59.

(60) 有了 Bone 這個 mapping node 後，就可以開始組合平滑的 2D 折線圖了，而且不論折線圖有多長，都沒有問題。例如：圖 38 的折線圖就是使用二個 Bone mapping node 配合一個 line3D_ubvm 所視覺化出來的，而資料與 VM 的對映方式如圖 40。如果今天換成是四條線三個轉折點的曲線圖，則會使用三個 Bone mapping node 配合一個 line3D_ubvm 去做視覺化。當然，使用者如果覺得圖 40 的對映關係有些複雜，也可再包裝成一個新的 mapping node，不過重用性可能就需要由使用者去評估，因為僅適用於三條線二個轉折點的曲線圖之視覺化。. 圖 39. 在 Composer Dialog 中組合出 Bone mapping node. 60.

(61) 圖 40. Section 5.3. 2D 折線圖的資料與 VM 對映方式. 圈叉遊戲. 圈叉遊戲是小朋友經常玩的小遊戲，也是教學用途上常出現的習題，修過資料結構或演算法的人應該不會太陌生。遊戲方式非常簡單，由兩個人分別代表 O 和 X，兩方輪流在九宮格內劃上 O 或 X，先將 3 個 O 或 3 個 X 連成一線(直的、橫的或斜的)的一方就算獲勝，如果兩方都未能連線成功則算平手。我們以一個 X 獲勝的例子來進行視覺化，結果如圖 41。. 61.

(62) 圖 41. 圈叉遊戲的視覺化範例. 其實在視覺化除錯的過程，使用者只要能區別出各 VM 背後所代表的資料結構，就能進行除錯，而不一定真的非得要有很精緻的 VM，VM 的細膩度只是讓視覺化更美觀而已。以這個例子來說，我們只使用綠色圓球 UBVM 及其透明度就能代表 O 和 X 兩種不同的視覺化物件。接下來我們來看看要如何才能視覺化出這樣的結果，首先，因為這遊戲固定會用到 9 個空格，所以通常我們會使用一個一維陣列或是二維陣列去儲存每個格子目前的狀態(也就是為哪一方所有)。以圖 41 來說，實心綠色圓球代表的是 X，半透明的綠色圓球代表的是 O，而其他透明的部分代表的是空格。因此，我們只要針對這個陣列的元素去視覺化，讓它可以對映三種不同的狀態，就可組合出這個 3x3 陣列的 9 宮格。我們一樣先在 Composer Dialog 中定義出一個 tictactoe_obj 的 mapping node，組合方式也很單純，僅用到一個 Math mapping node(用於計算透明度及顏色)以及一個圓球 UBVM，如圖 42 所示。接著，我們只要使用 9 個 tictactoe_obj 去對映九宮格的每一個位置，就可將視覺化給完成。同樣的，如果使用者想要更進一步加速視覺化流程，也可將 9 個 tictactoe_obj 再包成一個 tictactoe 的 mapping node，讓對映更單純。. 62.

(63) 圖 42. Section 5.4. 在 Composer Dialog 中組合出 tictactoe_obj mapping node. 背包問題(Knapsack Problem). 背包問題是一個演算法中常見，關於最佳化的問題，通常會使用動態規劃演算法（Dynamic programming）[24]去解決。也就是給定一個空集合，然後從空集合開始，每增加一個元素就先求出該階段的最佳解，直到所有的元素加入集合中，最後得到的就是最佳解。假設今天我們今天有一個可負重 8KG 的背包要裝水果，而我們希望在背包中裝入負重範圍內可得到之最高總價值的水果。水果的編號、單價與重量如下表所示：. 63.

(64) 0 香蕉. 4KG. NT$4500. 1 蘋果. 5KG. NT$5700. 2 橘子. 2KG. NT$2250. 3 草莓. 1KG. NT$1100. 4 甜瓜. 6KG. NT$6700. 表格 1. 背包問題範例中水果的編號、單價與重量表. 經由這個演算法，我們可以找到最佳解為放入蘋果、橘子與草莓各一個，而總價值為 9050 元。針對這樣的結果，我們可將它給視覺化成圓餅圖，讓我們瞭解背包容量的分配狀況，如圖 43 所示。我們使用不完整的環狀體(Partial Torus) 來視覺化這個圓餅圖，而紅、綠、藍則代表蘋果、橘子與草莓這三種不同的水果，環是完整無缺的則代表整個背包剛好被三種水果給裝滿。. 圖 43. 背包問題的視覺化範例(圓餅圖). 要如何才能視覺化出這樣的結果呢？首先，假設我們使用一個陣列去儲存這 64.

(65) 三種水果的重量，而陣列的最後一個元素存放的是背包的重量 8kg。然後，我們使用四個 Math mapping node 以及三個不完整的環(Partial Torus)的 UBVM 去和資料作對映。這四個 Math mapping node 的功能是要計算出三種水果各佔背包負重的比例，以及不完整環的起始角度。例如：第一個代表蘋果的環，起始角度是 0(預設值)，而比例則是 5/8，由公式” $0/$1*1.0” 轉成 double 型態，傳遞給第一個不完整的環當作比例的參數，同時這個值也是第二個不完整環的起始角度，第三個環的起始角度則由第一個和第二個環的比例加總所算出，使用的公式為” ($0+$1)/$2*1.0” ，最後的對映結果，會如圖 44 所示。如果今天換成是 a,b,c 三個整數要計算比例，我們則會用 a/(a+b+c)、b/(a+b+c)、c/(a+b+c)去分別計算它們的比例。使用者如果對於使用不完整的環去視覺化圓餅圖不習慣的話，也可改採用不完整圓柱體(Pie)或是不完整球體(Partial Sphere)當作 UBVM，會比較類似一般常見的圓餅圖。. 圖 44. 背包問題以圓餅圖視覺化的資料與 VM 對映方式. 65.