一個通用的對映編輯器支持任意解釋資料與視覺化結果之間的關係
72
0
0
全文
(2) 目錄 圖表目錄........................................................................................................................ 4 摘要................................................................................................................................ 6 Chapter 1 緒論........................................................................................................ 8 Motivation ...................................................................................................... 8 Section 1.1 ........................................................................................................ 8 1.1.1. 問題描述........................................................................................ 9 1.1.2. xDIVA 的目標 ............................................................................. 10 Section 1.2 論文架構...................................................................................... 14 Chapter 2 研究背景.............................................................................................. 15 Section 2.1 2.1.1. 2.1.2. 2.1.3. 2.1.4. Section 2.2 2.2.1. . Debugger ...................................................................................... 15 JDB .............................................................................................. 16 GDB ............................................................................................. 17 DDD ............................................................................................. 17 ODB ............................................................................................. 19 軟體視覺化(Software Visualization) .......................................... 20 視覺化隱喻(Visualization Metaphor) ......................................... 22 . 2.2.2. 2.2.3. 2.2.4. Section 2.3 Section 2.4 . Graphviz ....................................................................................... 22 BLOOM ....................................................................................... 23 VIZZ 3D....................................................................................... 25 2D VS 3D ..................................................................................... 26 Why visualization tools are not used in a programmer’s daily life 27 Chapter 3 xDIVA ...................................................................................................... 29 Section 3.1 Platform........................................................................................ 29 3.1.1. Command Agent .......................................................................... 31 3.1.2. WOPM ......................................................................................... 32 3.1.3. DIVA UI ....................................................................................... 33 3.1.4. DIVA VM ..................................................................................... 34 Section 3.2 Minerva ........................................................................................ 38 3.2.1. User Interface ............................................................................... 39 3.2.2. Network........................................................................................ 40 3.2.3. Record Processor ......................................................................... 41 3.2.4. Debugger Bridge .......................................................................... 42 3.2.5. Command Center ......................................................................... 43 3.2.6. 和 DIVA 的溝通命令 .................................................................. 44 2.
(3) Chapter 4 Mapping Engine ....................................................................................... 47 Section 4.1 資料與 VM 的 mapping .............................................................. 47 Section 4.2 Mapping GUI ............................................................................... 50 Section 4.3 Mapping Node ............................................................................. 51 Section 4.4 Mapping in xDIVA ...................................................................... 53 Section 4.5 Create arbitrary mappings from a drag-and-drop GUI ................ 54 Section 4.6 Compose arbitrary VM from UBVMs in your dialog ................. 58 Chapter 5 Auxiliary Mapping Node ......................................................................... 63 Section 5.1 An example by using math mapping node ................................... 64 Section 5.2 An overview of math node ........................................................... 65 Chapter 6 結論及未來展望.................................................................................. 68 Section 6.1 結論.............................................................................................. 68 Section 6.2 未來展望...................................................................................... 68 Reference ..................................................................................................................... 70 . 3.
(4) 圖表目錄 圖 圖 圖 圖 圖 圖 圖 圖 圖 圖 圖 圖 圖 圖 圖. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 . debugger 的監視視窗............................................................................ 8 三維向量(a,b,c) ................................................................................... 12 左：圓餅圖 右：(a,b)位置的都市人口為 c ..................................... 12 debugger 的架構圖.............................................................................. 16 DDD 的執行視窗 ................................................................................ 19 ODB 的執行視窗 ................................................................................ 20 顏色與文字視覺化效果的對比.......................................................... 22 DOT 語法及繪製結果 ........................................................................ 23 BLOOM 的視覺化結果 ...................................................................... 24 VIZZ 3D 套件類別關系圖................................................................. 25 Call graph from a medium size system ................................................ 26 xDIVA 的系統架構圖 ......................................................................... 30 Minerva 和 Command_Agent 之溝通流程圖.................................. 32 DIVA 執行視窗 .................................................................................. 34 . 圖 圖 圖 圖 圖 圖 圖. 16 17 18 19 20 21 22 . 圖 圖 圖 圖 圖 圖 圖 圖 圖 圖 圖 圖 圖. 51 23 f 為 x、y 的對映關係 ......................................................................... 52 24 Port setting dialog…....…………………....………………...……….53 25 上：Mapping 的操作 下：Mapping 的視覺化結果 ......................... 54 26 以一般的除錯器處理二元樹.............................................................. 55 27 在 Minerva 除錯二元樹的例子 .......................................................... 56 28 利用球體 UBVM 與 Laser Reference VM 組合而成的二元樹 .................... 56 29 建立二元樹的視覺化.......................................................................... 57 31 直接使用 UBVM................................................................................ 59 32 重用方塊 UBVM 來視覺化灰階像素。........................................... 59 33 將方塊 UBVM 包裝成另外一個 VM ................................................ 60 34 利用組合的方式製作二元樹 VM ...................................................... 61 35 利用另一種組合的方式製作二元樹 VM .......................................... 61 36 左 利用 Math Mapping Node 處理平均值的例子 右輸入任意的方程式. Laser Reference VM ............................................................................ 36 Minerva 執行視窗 ............................................................................... 38 Minerva run dialog 及 configure dialog ............................................ 40 DIVA 透過 Minerva 和 Debugger 溝通流程圖 .................................. 43 Command Center 和 Debugger 溝通活動圖 ...................................... 44 三個資料結構...................................................................................... 49 Mapping Dialog ................................................................................... 51 左上：Mapping Dialog 中 Mapping Node 右下：放大的 Mapping Node. 4.
(5) 圖 37 圖 38 圖 39 . 64 Math Mapping Node 處理平均值的視覺化結果 ............................... 65 Math Mapping Node 內部的字串處理 ............................................... 66 1+2*3 經過 Parse 轉換後的樹狀結構................................................ 67 . 5.
(6) 摘要 近年來雖然已經有一些軟體視覺化工具可以透過圖形來視覺化程式內部的 資料以幫助程式設計師除錯，但它們在實用上還有許多限制，使得軟體視覺化工 具無法成為程式設計人員每天使用的工具之一。因此我們提出一個軟體視覺化除 錯工具 xDIVA[1]來幫助程式設計師進行除錯。xDIVA 使用 3D 的圖形、顏色和 動畫來視覺化除錯資訊。讓使用者以理想的視覺化（Visualization Metaphor(VM)) 來視覺化變數和資料結構。 本篇論文中主要探討的是如何讓使用者可以依據自己的解釋處理資料與視 覺化之間的對映(mapping)關係，由於使用者可能會對資料做任意的解釋，而我 們不可能一一為每一種資料型態實作出使用者所期待的 VM。如果一個工具面對 一種新的視覺化，就要進行程式撰寫，測試，與除錯，這樣的工具其可用性是存 疑的。因此，我們的目標是提供一個介面讓使用者可以輕鬆且直覺的建立任意的 VM，而這樣的 VM 是不需要撰寫任何的程式碼(如果需要撰寫程式碼，則必然牽 涉到了編譯、除錯等問題)，只需要簡單的拖曳和選擇即可達成。 除此之外，這些 VM 也可以在 Mapping Dialog 直接使用，透過 Mapping Dialog 的存在能將資料與 VM 之間做到去除耦合(decoupling)，解決傳統視覺化方法， 如 model view，observer pattern，所面臨的困境。另外，Mapping Dialog 提供一 個簡易的操作介面讓使用者自行決定資料與 VM 之間的對映關係並且加以組合 VM。經由 VM 之間的組合，一個複雜的 VM 可以由許多基礎的 VM 組合而成， 6.
(7) 以達到可組合性以及視覺化彈性。 在處理資料對映到視覺化的過程中，為了能做到任意的視覺化，必然會需要 處理一些資料之間相依的關係(例如位置、大小等等)。因此我們也設計了一個可 以處理任意數學方程式的對映，使用者可以藉由輸入方程式以處理資料之間相依 的關係。藉由以上這些彈性的對映設定，大大的提升了 VM 的擴充速度，我們 不需要再仰賴撰寫程式碼的方式增加 VM，而是可以利用組合的方式輕易的達成。 如此一來，xDIVA 的實用性更進一步，絕大部分新的 VM 的建構可以在不用撰 寫任何程式的情況下完成。. 7.
(8) Chapter 1 Section 1.1. 緒論. Motivation. 除錯，是程式開發的必然過程，有時所占據的時間甚至比寫程式還長。一般 整合開發環境(IDE)都會提供一個內建的除錯器。除錯器是複雜的系統程式，通 常只具命令列模式的文字介面。由於命令列模式比較不容易上手，許多 IDE 都 將除錯器包裝於視窗化介面以提高可用性(圖 1)。. 圖 1. debugger 的監視視窗. 雖然除錯器是程式設計人員重要的工具，但是藉由插入輸出指令(printf，cout) 來除錯的舊習慣卻依然存在。傳統的除錯器限制程式設計師只能以文字模式視覺 化單一變數或結構。當程式設計師想要了解物件與結構間複雜的關係時，他只能 8.
(9) 選擇在適當的地方插入額外的程式碼，以他所偏好的視覺化方式來顯示變數與資 料結構。但無論是在文字模式抑或是在整合開發環境下除錯，資訊仍舊是以文字 的方式加以呈現，當資料量龐大且複雜時，對於除錯的效率提升將有限。. 1.1.1. 問題描述 軟體視覺化[3]正是為了要解決這樣的問題而提出的研究。因為軟體是抽象 且複雜的，而人類在理解「抽象化」的過程一向都是不太愉快的經驗。一個用來 增加理解抽象事物的方法，就是利用圖形來把抽象事物更加具體的呈現，也就是 利用「視覺化」來幫助理解。 延伸到軟體的開發上（例如針對程式或演算法），嘗試著將這些抽象且複雜 的概念以圖形呈現幫助使用者理解的技術中，UML[4]就是一個著名的例子。但 是 UML 畢竟只是靜態的平面圖，每種圖只能表達片面的特性，例如用類別圖 (class diagram)表示類別關連性，用循序圖(sequential diagram)表示程式行為的流 程，以活動圖(activity diagram)來描述程式流程的分歧等等。UML 確實是能幫助 使用者更有效率地理解軟體的多個面向，給予程式設計師一個系統的整體架構概 念。但是當軟體日漸龐大與複雜，UML 通常只能對軟體作片面而且簡化的描述， 例如 UML 其實著重於軟體架構層面的描述，而選擇忽略描述細部的資料結構細 節。但是軟體是複雜的動態結構體。嘗試用靜態的視覺化技術來描述動態的物體， 先天上就會有一些不足。在軟體視覺化研究的領域有許多可以幫助使用者理解軟 9.
(10) 體系統的工具，像 CodeCrawler[5]，BLOOM[6]等等。這類的工具可以透過分析 靜態的原始碼，將獲得的統計資訊（通常是 software metrics）[7]以樹狀圖，長 條圖等非文字模式的圖表將結果呈現在螢幕上。使用者可以透過選擇自己偏好的 圖形表達方式來增進對該軟體的了解。但是這類的軟體僅能提供程式設計人員軟 體品質的好壞的資訊，比較不著重視覺化軟體執行當中的動態行為。 儘管有許多研究致力於軟體的視覺化，但它們只能針對特定的資料和架構做 一些統計性的運作，或者只能呈現一部分的視覺化，這類的軟體工具只有在少數 特殊的案例下才能呈現最佳的效果。而能夠視覺化軟體的動態行為，如將特定演 算法以動畫呈現，一般都只能用在教學用途，在一般程式專案的開發上則很難發 揮功效。. 1.1.2. xDIVA 的目標 我們稱將資料以圖形視覺化的元件或程式為視覺化隱喻(VM，Visualization Metaphor)[2]。由於程式以及資料結構在各個應用領域的多變和複雜性，任何工 具想透過單一視覺化來涵蓋所有程式設計師的興趣是不可能的。 因 此 ， 我 們 提 出 一 個 除 錯 視 覺 化 雛 形 工 具 xDIVA(eXtreme Debugger Information Visualization Assistant)的研究。目的著眼於視覺化軟體執行期間動態 資料，以及處理無窮廣泛的資料種類和 VM (Visualization Metaphor)的對應。 xDIVA 導入物件導向的觀念，使得 VM 可以相互溝通，組合，並且能和資料分 10.
(11) 離以達到最低耦合。換言之，一個複雜的 VM 可以由許多基礎的 VM 組合而成， 每一個都是獨立可取代的。 嘗試解決資料與 VM 之間對映的相關研究一直是軟體視覺化研究上的老問 題，主要都是為了降低資料與 VM 之間的耦合度，並提高 VM 的重用性。在一 些最近的研究中，以除錯為主的視覺化工具，如 JIVE[8][9]會將從除錯器得到的 資料轉換成物件跟流程模型，再將模型對映成類似 UML 圖的視覺化，Javis[10] 也是屬於這一類。或是如 Jeliot3[11]將程式碼利用直譯器轉換成中間碼再視覺化， 但是這樣的就喪失了資料之間的關係，其次，當程式語言更新時，直譯器勢必要 更新，這是此類方法在維護上的缺點。 大部分軟體視覺化研究都會提供簡單與固定的對映關係，但是絕大部分並不 能 解 決 我 們 稱 為 資 料 視 覺 化 的 任 意 詮 釋 (Arbitrary Interpretation of Data Visualization)的問題，以一個 class x 為例： class X { int a ; int b ; int c; } 這樣的一個資料的視覺化的解釋其實是任意的。例如它可以是一個 3 維的向 量(圖 2)； 11.
(12) 圖 2. 三維向 向量(a,b,c). 也可以解 解釋是一個公 公司的三種 種產品收入來 來源(圖 3 左)；甚至 左 X 是一個城 城市 的資 資料，(a,b) 可以是一個 個都市的座 座標，而 c 則是都市的 的人口(圖 3 右)。. 圖 3. 左：圓餅 餅圖. 右：(a,b)位置的 的都市人口為 為c. 從以上的 的例子可以得 得到一個結 結論，除非資 資料的來龍去 去脈被告知 知，否則視覺 覺化 工具 具做錯誤的 的解釋可能比 比做安全的 的解釋還糟糕 糕。也就是說 說，全自動 動的視覺化是 是很 困難 難，而且不安 安全的。這 這其實也說明 明了，直覺 覺上視覺化工 工具應該可 可以給予程式 式設 計人 人員很大的 的輔助，但是 是為何電腦科 科學發展至 至今，這種夢 夢想卻沒有 有辦法實現。所 以， ，像 DDD(D Data Displaay Debuggeer)[12]這類 類的工具都選 選擇退到最 最安全的視覺 覺化 ──以 以文字以及 及數字來表示。然而，文 文字與數字 字雖然能夠呈 呈現資料的 的最原始型態 態， 12.
(13) 但是卻捨棄了人類先天具有的視覺化能力。 有些工具面對資料與視覺化物件的對映，則選擇了另外一條路─在建立視覺 化的過程中，使用者必須自己撰寫額外的視覺化程式碼如 Graphviz[13]，雖然看 似是讓視覺化更加的自由，但是使用者卻需要花時間去學習以及自己轉換資料結 構成為 Graphviz 能接受的 meta-format。 基於以上的理由，我們[1]設計一個處理資料與視覺化對映關係的介面稱之 為 Mapping Engine。xDIVA 透過 Mapping Engine 來解決資料和 VM 之間的對映 關係以及 VM 與 VM 組合的問題。Mapping Engine 允許使用者手動來設定資料 所對映的視覺化結果，或者交由 xDIVA 替使用者自動選擇一套預設的視覺化結 果。而主動的替使用者選擇一套視覺化結果是有風險的。因此只是單純利用文字 的方式視覺化出變數資料，這種方式聽起來沒有什麼特別的地方，但是它也是實 用和創新之間的一種折衷辨法。所以一套文字的視覺化被執行並且被設定成 xDIVA 的視覺化結果，當這些文字的視覺化結果不符合使用者所預期的話還可 以自行去修改對映關係。 xDIVA 希望讓使用者能自行建立資料與視覺化之間的關係。為了達成這樣 的目標，必然要有各式各樣有不同特性的 VM 可以供不同應用領域的使用者選 擇。但是如此多樣性的 VM，如果需要的時候還必須一一進行程式撰寫，則實用 性會令人質疑。 我們以蓋房子為例子來說明本論文提出的方法如何解決資料與視覺化之間 13.
(14) 的任意對映。人類再建造房子時，利用幾種基本形狀的磚塊，以及標準的介面， 可以蓋出不同形狀的房子。我們將這些就像是最基本形狀的磚塊定義為 Ultimate Basic VM(UBVM)，例如方塊、圓球等。因為視覺化的需求就算再怎麼樣豐富與 多變，最後呈現在使用者眼前最直觀的還是可以從這些基本的 VM 組合出來。 在這篇論文中我們將探討如何提供一個組合的機制讓使用者可以自由將資 料對映到 VM，而這個組合機制是透過簡單的拖曳和選擇就可以得到使用者所想 要的視覺化。在一個新的應用領域，如果沒有使用者所預期的 VM，使用者也可 以在我們這一套系統上，利用各式各樣基礎的 UBVM 自行加以組合成新的 VM， 而且不需要撰寫任何程式碼。當然，這個組合必須非常簡單與輕鬆，代價必須極 低，否則使用者只會放棄使用。. Section 1.2. 論文架構. 首先在第二章，會先介紹一些閱讀本論文的相關知識，包括 Debugger，和 一些 software visualization 相關的 related work。第三章則是對 xDIVA 的元件做簡 單的介紹。如何處理資料與視覺化結果之間的對映在第四章的 Mapping Engine 做介紹。第五章會介紹 xDIVA 中如何處理任意的數學方程式。最後在第六章做 一個總結。. 14.
(15) Chapter 2 Section 2.1. 研究背景. Debugger. Jonathan B. Rosenberg 曾定義除錯器是用來幫助程式設計師追蹤程式並將錯 誤從中移除的系統程式。程式設計師使用除錯器在指定行號上設定中斷點讓程式 暫時停止執行，藉以觀察程式狀態及變數值的變化來尋找程式的錯誤。如果錯誤 不在此處，還可以繼續讓它執行下去。在一個程式的開發過程當中，程式設計師 通常花相當多的時間在除錯上。一個好的除錯器可以幫助程設人員縮短開發程式 時所需花的時間和精力。軟體除錯在軟體開發的生命週期中，扮演著很重要的一 環，擔當著負責尋找，分析及修正錯誤的角色。Adam kolawa[14]說過，在軟體 的開發過程中，有 60% - 70%是在做程式的除錯，但事實上，對於大部分的軟體 而言，超過 80%的時間在除錯是常有的事。換句話說，軟體開發的過程當中，所 花的時間絕大部分都在除錯。因此，程式設計師希望能有好的除錯器來幫助他除 錯，讓除錯時間變得更短更有效率. 15.
(16) 圖 4. debugger 的架構圖. 以一般除錯器而言，大部分的操作方式皆是採用一步一步執行的方式，或者 是設定中斷點，執行至中斷點後繼續執行，亦可查看指定變數的值。但現在有些 除錯器也提供逆向執行的功能[15][16][17]，可以回覆至上一個中斷點或執行狀態， 但是這一類的除錯器由於要記錄太多系統資訊，所以在實用場合上很少見。 Debugger 的製作相當不容易，因為和底層的作業系統相依性非常高， 圖 4 中顯示出了典型的 debugger 架構。我們會在以下的段落介紹幾種常見 的除錯器。. 2.1.1. JDB JDB 是昇陽公司開發的 JAVA 語言的除錯器，是個簡單的文字模式針對 JAVA 類別的除錯器，使用者可以透過在指定的類別檔中設定中斷點以暫停程式的執行， 16.
(17) 並透過 print，dump，fields，locals 等指令來察看變數和類別狀態。因為是文字 介面的除錯器，使用起來相當不便。許多整合開發平台都會將 JDB 納入為元件， 市面上的 ECLIPSE 或 JBuilder 皆有內建的 JDB。. 2.1.2. GDB GDB 全名為 GNU Debugger，是 GNU 系統上標準的除錯器[18]。GDB 是具 有高度移攜性的除錯器，可以按照需求來調修與重新編譯，如今許多的類 UNIX 作業系統上都可以使用 GDB。現在 GDB 能支援相當多的語言除錯，包括 C，C++， FORTRAN。GDB 允許使用者在指定檔案中的指定行號上設定中斷點，當程式執 行到中斷點時會暫時停止執行，使用者可以透過 print，ptype，whatis 等指令來 觀察特定變數的資料。也可以透過監看式來觀察程式是否符合使用者的期望。 GDB 是文字介面的除錯器，功能雖然十分強大，但對於新進入程式設計領域的 開發人員上，要使用它還是相當不便利。而有些 IDE 內建的 GDB 的圖形使用介 面(GUI)，來提高可用性，如以下的 DDD。. 2.1.3. DDD DDD 是一個免費的文字介面除錯器前端（front-end）[12]，可以支援 GDB， DBX，WDB，Ladebug，XDB，Perl debugger，bash debugger，或者是 Python debugger 17.
(18) 等除錯器。提供執行期間的視覺化給除錯人員來了解程式內部的行為。DDD 以 它可以互動的介面而有名，指標的資料可以在 DDD 上被表示成由節點和有向線 來組成。節點由一個正方框組成，可以顯示其結構變數資料，如 圖 5. DDD 的執行視窗。陣列也被表示成如表格的樣子。在某些特殊情. 況下，像一個 2 維的 int 陣列，DDD 也能將資料傳送到 gnuplot 來繪製 3D 曲線 圖。DDD 可以視覺化顯示出 debug 的資料結構而不需在原程式添加任外額外的 程式碼。 只是由於 DDD 的呈現方式只有固定的幾種模式，主要是有向圖例如圖 (graph)，樹(tree)等資料結構，無法合適的套用在所有程式的資料結構中，且只能 以 2D 平面圖繪出。一旦資料結構變得複雜化便會使畫面看起來相當凌亂，反而 不容易去監看程式在圖中的變化. 18.
(19) 圖 5. DDD 的執行視窗. 2.1.4. ODB ODB(the omniscient Debugger)[15]，透過紀錄所有變數的指定和分派 ODB 可以做到讓除錯像在操作錄放影機一樣，可以讓使用者從任意的觀看點正向或逆 向單步執行，和傳統的除錯器只能從頭到尾一步一步的執行，並不能逆向的回到 上一行不同。因為 ODB 採用了 time stamp 的觀念，記錄了整個程式執行過程中 的歷史紀錄，因此可以隨時隨地的回到任何一個過去執行過的狀態，隨時觀察到 每個程師設計人員想要觀看的值或錯誤。ODB 可以顯示程式中關於 thread，stack， 以及被選取的物件相關訊息。但由於其龐大的事件記錄功能，對於較大的專案在 19.
(20) 效能上，可能會有點問題。雖然 ODB 提供了雙向執行的功能增加了許多便利性， 但由於 ODB 屬於文字模式，一旦程式變得龐大複雜時，仍然不容易有效率的找 到程式的錯誤所在。. 圖 6. Section 2.2. ODB 的執行視窗. 軟體視覺化(Software Visualization). 對於複雜的事物，人類可以經由圖表和動畫的表示，讓它變的更容易被理解。 大部分成熟的工程領域皆具有標準的藍圖來描述它的設計和產品。圖示的確可以 幫助人類解決溝通上的問題。軟體系統因為具備有不可見性，所以程式往往相當 令人難以理解。Brook[3]的書中有提到，軟體的不可見性讓程式設計變成一門相 當難的領域。所以，過去幾十年裡，軟體工程的研究一直在尋找方法試圖用圖形 20.
(21) 來表示程式。UML 就是在這樣的背景之下，成功的成為軟體工程的重要標準圖 形。 另一方面，近幾年興起的軟體視覺化研究則著重於建構視覺圖案來表達軟體 系統的結構，大小及行為。這類的工具依據其對軟體的測量值來做視覺化，可以 在開發的初期用來表示軟體品質的好壞，並指出異常的地方以提供為管理的重要 依據。 另一類的視覺化軟體是提供執行期間軟體效能的視覺化，主要用來做效能的 測量，例如記憶體的使用，類別和方法所花費的時間。這類的軟體如 BLOOM[6]， JIVE[8][9]，Jinsight[19]。有些則著重於使用 UML 圖來表示物件間的關係。像 JIVE[8][9]，Javis[10]，雖然這類的軟體的意圖皆不同，但目的都是為了幫助程式 設計師除錯，以及更了解他們的程式碼。 對於軟體視覺化工具而言，VM 的品質和數量對其實用性有舉足輕重的影響， 卻又是一個困難的議題。由於資料的廣泛性和多樣性，宣稱要能夠解決廣泛的資 料種類與視覺化對映問題，將是一個極勇敢的挑戰，卻很容易淪為不實用的學術 界研究。所以，在考量實用性之下，大部分的視覺化工具都會設定視覺化的範疇。 以 Graphviz[9]為例，他只能視覺化有向圖，如 graph, tree。DDD[12]也選擇有向 圖為主要的表達方法。然而，程式的狀態是反覆多變的，除非資料的來龍去脈被 告知，否則就像前面資料視覺化的任意詮釋所提到的，視覺化工具做錯誤的解釋 可能比做安全的解釋還糟糕。所以，像 DDD 這類的工具都選擇以文字模式來表 21.
(22) 示，因為這是最 最安全的表 表示方法。然而 然 ，捨棄更 更有效的視覺 覺化方式是 是令人惋惜的 的， 這就 就是 DIVA 想解決的問 想 問題，讓視覺 覺化除錯更 更進一步。. 2.22.1. 視覺 覺化隱喻 喻(Visualiization Metapho M or) 大部分的 的視覺化工具 具使用一組 組圖案，圖形 形和顏色，透 透過使用者 者的常識和經 經驗 來進 進行視覺化 化。舉例來說 說，運用資料 料夾和檔案 案櫃的圖形來 來表達檔案 案系統，就是 是一 種視 視覺化隱喻 喻。好的 VM M 可以幫助 助使用者了 了解資料，有 有時候僅僅 僅是簡單的改 改變 形狀 狀和顏色，或使用另一 一種圖示法 法，就可以讓 讓資料更簡 簡易的被了解 解。例如 piie 形 圖， ，或者長條 條圖為例，一 一個 pie 形圖 圖可以簡單 單的表達出資料在整體 體中占的比 比例， 是長 長條圖所無 無法做到的。 。另一個例 例子則是如圖 圖 7，一群 群有位置關係 係的 booleaan 變 數， ，以顏色來區 區分將比使 使用文字描述 述更容易了 了解分布的情 情況。這部 部分是人類視 視覺 系統 統在認知上 上的重要利器 器。. 圖 7. 顏色與 與文字視覺 覺化效果的對 對比. 2.22.2. Graaphviz Graphvizz[13]是一套 套表達抽象資 資料結構的 的視覺化工 工具，可以在 在指令模式，網 22.
(23) 路端服務或者適用的圖形化介面下執行。使用者透過編輯 Graphviz 內建的 dot 、 neato、或 dotty language 能以圖，節點及邊三種方式組合呈現出結果。以 Graphviz 的 dot language[20]為例，它存在相當嚴謹的排列演算法，dot 會按照程式碼內容 將圖以整齊樣貌呈現，對於再複雜的圖，也不會有重疊的節點。 但由於 Graphviz 仍屬於 2D 平面的視覺化工具，一旦資料量變得相當龐大 的時後，畫面將會充斥著節點與邊線，對於使用者觀看時，在了解整個圖的架 構或內容上，是非常沒有效率的。 下圖 8，表達 Graphviz 以 dot 程式語法和其繪製出來的結果。. 圖 8. DOT 語法及繪製結果. 2.2.3. BLOOM BLOOM[6]是一套用來幫助程式設計師視覺化 C++和 JAVA 靜態資訊的工具， 特色是可以允許使用者自訂 Visual browser 來視覺化軟體。BLOOM 透過將 C++ 或 JAVA 的程式碼以 XML 格式轉成 BLOOM 所需的資料之後，再經過分析配對， 23.
(24) 選擇適用的視覺模式表示出來，並提供選單讓使用者設定視覺化後圖形的大小和 位置等。 不過 BLOOM 主要是用來視覺化軟體的靜態特質，如類別的大小，數量等 統計資料，原則上是偏向軟體測量，跟 DIVA 所要強調的 debug 功能並不相同。 BLOOM 提供數種 3 維空間的圖，在視覺化的過程當中，BLOOM 會自動去選擇 判斷合適的結果來呈現。由於，最後所產生的結果只顯示了許多顏色的區塊，使 用者必須先去熟悉每個圖的表示方式，才能懂得其所表達的結果(圖 9)。再者， 由於 BLOOM 只提供了固定的幾種模式，加上又是由系統自動配對結果顯示的， 很有可能顯示出來的結果會導致不明。. 圖 9. BLOOM 的視覺化結果. 24.
(25) 2.2.4. VIZZ 3D 跟 BLOOM 相似的是，VIZZ 3D[21]也是用來做軟體度量的視覺化工具，經 過分析靜態的原始碼，可以在 3D 畫面上繪出該軟體的各個表向。它可以透過使 用 JAVA 3D 或者是 OpenGL 來當它的繪圖引擎，將資料視覺化在一個 3D 環境上。 VIZZ 3D 透過 VizzAnalyzer 取得資訊後，使用其專屬的 Visualization Metaphor 和排列演算法來繪製畫面。 圖 10 是 Vizz3D 的一個視景圖(view)，用來表達類別和套件的關系圖。粉紅 色半透明的圓球代表一個套件，而其中的每一個小圓球各代表一個類別。紅線代 表類別和類別之間具有直接耦合關系。. 圖 10 VIZZ 3D 套件類別關系圖. 25.
(26) Section 2.3. 2D VS 3D. 使用 2D 來做軟體視覺化在某些情況下無疑是滿足的。但當資料開始變得複 雜與龐大後，2D 的環境就明顯有點不足(圖 11)。3D 環境提供額外的一個維度來 排序資料。而且透過轉移視角，將重要的元件放在肉眼的焦點上。不重要的物件 可以暫時從肉眼中隱藏，或者放在較遠處。由於軟體動態性，導致 2D 的靜態圖 無法全面呈現軟體的全貌。即使成功如 UML 也只能使用大量的圖形去描述一個 片段的程式行為。. 圖 11. Call graph from a medium size system. 因此 xDIVA 架構在 OGRE[8]這個 Open source 的 3D 引擎上。OGRE 是高階 物件導向的 3D 引擎，比起較低階的 OpenGL 和 DirectX 具有較低的設計門檻， 可以降低相當多的程式開發時間。OGRE 提供相當多的特效，有助於增進視覺化 的多樣性，提升視覺化的品質，來提供我們做出品質優良的 VM。. 26.
(27) 另一個 xDIVA 使用 3D 的理由是為了使用動畫。3D 引擎皆可用來顯示一段 及時的動畫，而不是單純的靜態物件。如前所述，軟體是具有動態行為的。在我 們的想法裡，用靜態視覺化來表達動態的行為是缺乏的。 3D 引擎具通常具有強大的互動和導覽性，藉由旋轉視角，漸進式地拉近拉 遠自由自在的觀看可以獲得對系統整體架構的概念，相對的，2D 介面在這一點 上就比較弱。使用者也可以 3D 環境裡輕鬆的展開或收合一個結構，觀看有興趣 的部分，不但可以簡化畫面，也有助於程式設計師理解複雜的程式。. Section 2.4. Why visualization tools are not used in a. programmer’s daily life 因為程式和資料結構在各領域的多變和複雜性，讓提供有限與固定式的視覺 化工具要涵蓋所有程式設計師的興趣是不可能的。這也說明了為何理論上視覺化 工具應該可以對軟體開發有很大的助益，但是視覺化工具卻還沒有能夠成為程式 設計師每天必用的工具。以著名的 AT＆T 圖形視覺化 (graph visualization) 工 具 Graphviz[13]為例，使用者想要利用 Graphviz 來將 graph 資料視覺化時，必須 另外撰寫額外的程式碼將某個時間點的 graph 資料結構轉成 dot format。Graphviz 不嘗試去解決困難的圖形和資料映對的問題，而將這部分留給使用者來解決。我 們將在之後的章節一步一步的闡述如何達到這個目標──處理資料與視覺化結果 之間對映的問題。 27.
(28) 28.
(29) Chapter 3 Section 3.1. xDIVA. Platform. xDIVA 是建構在 windows 系統下的視覺化工具，xDIVA 主要由以下 2 個部 分組成，如圖 12： z. 資訊視覺化子系統 DIVA. z. 圖形化除錯器前端子系統 Minerva. DIVA 和 Minerva 的溝通是透過網路交換訊息。因為 Minerva 是由 JAVA 所撰寫 完成，使得程式設計師可以在 Linux 系統下除錯程式，將視覺化結果呈現在 windows 平台上。將在後面章節中逐步介紹。. 29.
(30) 圖 12. xDIVA 的系統架構圖. DIVA 是 xDIVA 資訊視覺化子系統，負責從除錯器端(Minerva)取得程式變數 的數值以進行的使用者要求的視覺化，除了能夠將除錯資訊正確的視覺化展示外， 還必須擁有簡單的使用者介面讓使用者能夠進行調整（譬如資訊與 VM 如何對 應、數量龐大時如何排列等） 。DIVA 使用 3D 方式顯示物件與場景超越過往以文 字顯示與 2D 視覺化除錯資訊的瓶頸，可以用更多角度觀察資料,並且可達到 2D 不可能的資料排列方式。 DIVA 具 有 相 當 多 個 重 要 元 件 ， 第 一 個 是 Watched Object Pool Module(WOPM)，WOPM 儲存所有 DIVA 已視覺化的變數，指標，和物件。這 些資料由 Minerva 取得，當中斷點改變時會改變其值。Minerva 負責通知 DIVA 程式狀態的改變，一個複雜的程序在這時後啟動來確保 WOPM 和除錯器的資料 同步。 用來處理同步的程序，就是圖 12 中的 Command Agent 元件，舉例來說，當 接受到 visualize p 這個指令的時後，Command Agent 會送出一連串的指令向 Minerva 要求 p 的資訊，當資訊取得後，Command Agent 則在 WOPM 上建立一 個物件。在 visualization metaphor 和 WOPM 之間有個重要的元件叫 mapping engine，它負責維持 WOPM 裡的物件和 VM 的對映，也允許使用者手動設定如 何對映。. 30.
(31) 3.1.1. Command Agent 當使用者決定視覺化一個變數 p 以後，他在 Minerva 上下達一個指令 Visualize p。Minerva 透過向除錯器(JDB 或者是 GDB)取得 p 的訊息，然後開始 密集的與 DIVA 的 Command Agent 溝通，將 DIVA 所需的資訊透過網路傳到 Command Agent。Command Agent 收集到所需的資訊以後，在 WOPM 上建立一 個 wop_entry 來儲存該變數的資訊。一個 wop_entry 是用來儲存一個變數的所需 資訊。 如果 p 是一個具有 n 個元素的一維陣列，當我們觀看陣列所有的元素，在 DIVA 上展開陣列，此時 Command Agent 將會透過網站再次和 Minerva 溝通來取 得 p[0]，p[1]..p[n]的值，並建立 n 個 wop_entry，並將這 n 個 wop_entry 設為 p 的子 entry。 當程式的中斷點移動後，Minerva 會告知 Command Agent 程式的狀態有改變， 此時 Command Agent 會對所有的 wop_entry 資料向 Minerva 全部從新詢問一次， 來取得最新的資訊。最後，當使用者停止該程式的執行後，Command Agent 會將 所有的 wop_entry 清除。下 圖 13 為 Command Agent 和 Minerva 溝通的流程圖。. 31.
(32) 圖 13. Minerva 和 Command_Agent 之溝通流程圖. 3.1.2. WOPM WOPM 是單純的資料結構，利用 TABLE 以及 Linked List 的方式，將所有 透過 Command Agent 收集到的變數值，型態等內容儲存起來，並且記錄其中的 關係。每一筆資料就是一個 wop_entry。大致上分成 primitive，array，object， reference 幾種 entry。每筆 wop_entry 至少包含以下內容 : z. Boolean Top ：記錄此變數是否為起始 entry，或者是一個子 entry。. z. String Name ：變數的名字，如果沒有名字，則記錄其 hash code。 32.
(33) z. Value：變數的值或者是變數的記憶體位置。. z. WOP_Entry*. Parent：為一指標，如果不是起始 entry，則會指向其 parent. entry。. 3.1.3. DIVA UI 圖 14 是 DIVA 的執行畫面，DIVA 是建構在 Ogre 這個開放原始碼的 3D 引 擎上，DIVA 透過 Diva Manager，管理所有繪製 3D 環境上的 VM。透過 Input Manager 管理使用者的鍵盤和滑鼠輸入，並將事件傳到對應的 VM 上，使用者可 以透過點取一個 VM 去展開或者收合該 VM，或者拖移該 VM 的位置。 右下角有 3 個按鈕分別是 Step，Next，Continue，使用者也可以透過點選這 3 個按鈕來跟 Minerva 溝通藉以改變中斷點的位置。. 33.
(34) 圖 14. DIVA 執行視窗. 3.1.4. DIVA VM VM(Visualization Metaphor)，用圖形來表視資料的視覺化隱喻。面對軟體的 龐大和複雜性，要定義一套完全的 VM 來視覺化所有的變數幾乎是不可能的事。 所以最好的方法就是，定義一套基本 VM 讓使用者可以藉此自行組合 VM 而不 需要撰寫任何的程式碼以達到最大的彈性。 而我們希望讓 VM programming 的工作單純化。VM 設計師只需專注在 VM 的設計上，而不須在意整個 visualization tool 如何運作，資料如何取得，如何和 debugger 溝通，記憶體空間這些細微的瑣事。DIVA 的 VM 是可由事件驅動的物 34.
(35) 件，像經由滑鼠拖曳和壓下。當事件發生後，VM 會以預先定義的行為來反應。 舉例來說，當一個代表指標的 3D 物件被壓下後，我們可以選擇突顯它所指到的 地方，並將畫面帶到該物件上。而為了完成這個功能，每個 VM 都繼承自某個 基底類別，並包含這些方法 VMpicked(點選)、Vdragged(拖曳)和 VMlueUpdated(更 新)等等，我們的目標是每個 VM 只需要處理在 3D 上所呈現的部分。 每種 VM 都會在以下做詳細的介紹。 1.. Ultimate Basic VM(UBVM). 2.. Reference VM. 3.. Container VM. 4.. Layout VM. 3.1.4.1.. Ultimate Basic VM(UBVM). 在前面曾提到不經由程式碼的撰寫從 UBVM 製造出新的 VM。所謂的 UBVM，就像是各式各樣的基礎磚塊。利用這些互斥的基本視覺化單位，我們期 待只要使用者可以想到的視覺化都可以經由這些 UBVM 組合出來。也因此程式 設計師不需以撰寫程式碼的方式增加 VM，即使是特異化的 VM 也可以利用拖曳 及組合的方式達成，各個應用領域也可以以輕鬆的方式自行建構屬於該領域的視 覺化 VM。. 35.
(36) 3.11.4.2.. Referen nce VM. 在程式設 設計當中，物 物件間最常見 見的關係就 就是 2 元關係 係了。其中 中最常見的就 就是 由指 指標所建立 立的 2 元關係 係，但不僅 僅只於如此。 。舉例來說，{(a,b),(c,,d)}，物件 a 和 物件 件 b 就是 2 元關系。它 它可以由一個 個叫 pair 的類別來完成 的 成，這個類 類別有 2 個指 指標 來指 指向 a 和 b 這 2 個物件 件。在 DIVA A 當中，任 任何和 2 元關 關係有關的 的 VM 都必須 須能 套用 用到這個例 例子。Binary--Relation VM V 就是為了 了來視覺化 化一個指標或 或者一個參 參考， 我們 們稱他為 Reference VM M。. 圖 15. Laser Refeerence VM. m 是 Reference VM 的一種(圖 的 15)，體是一 一個 3D 的 的球體。當使 使用 Laser_rtvm 者嘗 嘗試使用 Laser_rtvm L 視覺化一個 個指標變數 數 v 以後， ，他的建構 構子從 Mapping Enggine 接收一 一個叫 p 的 VM，p V 是透 透過 proxy pattern 製作 作出來的一 一個代理 VM M， 是預 預定用來視 視覺化*v，但 但此時我們 們還尚不知道 道*v 的值。 。當使用者 者對 v 展開取 取得 *v 的值以後， 的 p 會被代替 替成另外一個 個具實體的 的 VM。使用 用 Laser_rtvvm 來視覺化 化一 個指 指標時，它 它持續不斷的 的射出一條 條雷射光從 3D 3 圓球到 p 所指的物 物件，其間 p 會 持 續 不 斷 的 呼 叫 他 所 指 的 VM 的 getPossition() ， 來 取 得 最 新 的 位 置 。 當 36.
(37) VMvalueUpdated()事件發生後，首先，讓 3d 圓球體發光，接著呼叫 VManimation()， 然後，指向新的 VM 的新的雷射光就此射出。. 3.1.4.3.. Container VM. Container VM 其實也是屬於 UBVM 的一種。但是它主要的目的是作為一個 容器，將內部所有的 VM 包起來給予一個透明的外框，並且保留每個 VM 之間 的互相依存關係(如位置、大小)。而處理 VMpick 的事件則是傳遞給內部的 VM 加以處理。. 3.1.4.4.. Layout VM. Layout VM 是用來做 3D 空間重新排列用的。Layout VM 是用來呼叫所有的 VM 做排列的演算法。在 DIVA 中，Layout VM 是透過右鍵來激發(通常是點擊樹 的根節點或者是 graph 的初始節點)。舉例來說，使用者拖曳某顆已在 DIVA 視覺 化的二元樹的節點導致排列不整齊後，透過從新觸發 Layout VM 可以將這顆樹 做從新排列。 計算 VM 碰撞也是 Layout VM 的一環，當有 1 個 VM 產生的 3D 位置上已 具有另外其他 VM 的存在的時後，Layout VM 會將原來在 DIVA 上的 VM 碰撞開 來，讓新增的 VM 產生在預定的位置上，以避免同時有 2 個 VM 重疊在一起的 情形。 37.
(38) Section 3.2. Minerva. Minerva 是 xDIVA 的除錯器 GUI 前端，在使用上與一般 GUI 介面的 debugger 並沒有太多差異。基本的功能是使用者可以瀏覽程式碼，設定中斷點，執行除錯， 以文字模式顯現出變數。最大的差別在於允許程式設計師將除錯資訊送到 DIVA 加以視覺化。目前可支援 GDB 和 JDB，透過擴充可允許程式設計師在 Minerva 上除錯任意程式語言所撰寫的程式碼。圖 16 為 Minerva 的截圖. 圖 16. Minerva 執行視窗. Minerva 是由 J2SE 所完成的，所以允許使用者在 Linux 或者是 Windows 平 台上執行欲除錯的程式，而結果則透過網路傳到 DIVA 上繪製出 VM。Minerva 38.
(39) 由以下幾個主要元件所組構成。 z. User Interface. z. Network. z. Record Processor. z. Debugger Bridge. z. Command Center. 3.2.1. User Interface 使用者界面是由 Java 的 swing 元件所撰寫完成，最上面的 Menu Bar 和 Tool Bar 提供了相當多和一般 IDE 相同的功能，包括開讀檔，尋找字串，和除錯程式， 中斷點的移動等指令。其中和一般 IDE 最大不同的是它具有視覺化變數和在 DIVA 上展開及收合變數的指令。 使用者透過在左邊的行號列設定中斷點，讓程式在使用者期望的行數暫時停 止執行。正中間則是顯示程式碼的視窗，目前支援對 C 和 JAVA 的關鍵字，字串， 註解，前置處理器命令變色。關鍵字變色的模組是和顯示程式碼的視窗元件是分 開的，等到程式載入後，按照檔案的副檔名來決定顏色的變化要用那一種語言的 變色系統。 其他還有 2 個重要的彈跳視窗，一個是執行視窗(圖 17 左)，用來選定程式 執行的執行檔路徑，classpath，和傳入參數。Easy Run 則會自動替使用者設定路 39.
(40) 徑。另一個是設定視窗(圖 17 右)，可以設定系統 JDB 和 GDB 的路徑，以及 DIVA 所在主機的 IP 和跟 DIVA 通訊的 PORT，另外也可以設定 Minerva 的外觀，目前 提供 4 種外觀風格和 2 種按鈕風格。 當程式執行後，可以透過將滑鼠停留在變數上以取得目前變數當前的資訊。 而最下面的 Output 視窗，則是用來告知使用者程式的輸出和一些編譯錯誤或執 行錯誤的警告訊息。. 圖 17. Minerva run dialog 及 configure dialog. 3.2.2. Network 網路模組是用來和 DIVA 交換訊息用，Minerva 將從 JDB 或者是 GDB 的除 錯訊息經過包裝後，透過 Minerva 透過 Minerva UI Thread 和 Minerva Server Thread 來跟 DIVA 交換訊息，交換訊息的模式則如同如上一章 Command_Agent 所提。 40.
(41) 當使用者決定 Visualize 一個變數 p 的時後，會先透過 Minerva UI Thread 傳送此 訊息給 DIVA。Minerva UI Thread 主要是來傳送 Minerva 欲主動通知 DIVA 要視 覺化變數或展開陣列物件變數的元件。另一個 Minerva Server Thread 則是當使用 者決定視覺化一個變數後，DIVA 會傳送一系列的命令來詢問該變數的值，這些 命令全部是透過 Minerva Server Thread 和 DIVA 的 Command_Agent 溝通。 取得變數資料的溝通命令分成 3 種， z. ”ask”用來取得變數型態和記憶體位置資訊。. z. ”show”用來取得變數的值。. z. ”struct”用來取得類別物件下的屬性名稱。. 詳細命令格式會在以下章節介紹。. 3.2.3. Record Processor 用來保存使用者的設定，程式的執行路徑，以及中斷點設定記錄和開檔記錄。 使用者的設定最重要的就是指定 DIVA 的 IP 和 PORT，這些設定必須能被儲存起 來以供下次開啟時讀入。而中斷點紀錄則是當一個程式設計師在 Minerva 上為某 個檔案設定過的中斷點記錄希望能被保存起來，在下次載入這個檔案後，能為該 檔案自動設定中斷點。如果該檔案的存取紀錄比設定中斷點的時間晚，則會自動 設定中斷點，以警告訊息來告知使用者中斷點紀錄已過期。執行紀錄能在下次執 行同一檔案時，自動幫助使用者設定 classpath 和主要類別路徑，或者是執行檔 的路徑。最後開檔紀錄和其他的 IDE 一樣，只是載入上次開啟且未被關閉的檔 41.
(42) 案. 3.2.4. Debugger Bridge 除錯橋接器是 Minerva 和除錯器溝通的橋樑，定義一系列和除錯器溝通的介 面。Minerva 透過橋接器寫入命令給除錯器，然後接收除錯器回傳的輸出訊息。 Minerva 使用 java.lang.Process 類別來啟動系統中己存在的除錯器(jdb 或 gdb)，並 以 Minerva 中的物件─jdbBridge 或 gdbBridge 和其溝通。舉例來說，如果使用者 嘗試在 DIVA 上視覺化一個 java 的變數 p，則 Command Center 透過 jdb bridge 向 jdb 寫入 print p 來取得 p 的值，再由 Command Center 的 Message Collector 收集 jdb 的回傳輸出。jdbbridge 解析輸出字串之後，經由包裝傳到送 DIVA 的 Command Agent。假設使用者欲視覺化一個 JAVA 的變數 p，對 DIVA 下達 visualize p 的指 令，如第三章所述，DIVA 會透過 Command_Agent 來傳送 ask p 以取得 p 的記憶 體位置和變數型態。Minerva 會透過和 jdb 溝通來取得變數資料，詳細和除錯器 的溝通順序圖如下，為什麼需要再透過 Command Center 當中間介面傳遞訊息的 原因，就在下一節介紹。. 42.
(43) 圖 18. DIVA 透過 Minerva 和 Debugger 溝通流程圖. 3.2.5. Command Center 如同前面所提，Minerva 是設計來針對任意程式語言除錯的 IDE，Minerva 透過和系統中已存在的除錯器溝通來取得除錯資訊，並將結果回報給 DIVA。因 此，Minerva 未來將包含不只一種除錯器，所以我們需要一個根據 proxy pattern[22] 設計的 Command Center 將使用者透過使用者界面下達的命令透過中間介面來傳 送給正確的除錯橋接器，再透過橋接器和除錯器溝通以取得結果。除此， 43.
(44) Command Center 亦具有一個 Message Collector(一條常駐執行的執行緒)來收集除 錯器的輸出訊息，將訊息傳給正確的除錯橋接器解析。Minerva 的除錯架構活動 圖如下所示。. 圖 19. Command Center 和 Debugger 溝通活動圖. 3.2.6. 和 DIVA 的溝通命令 先前有提到 DIVA 是透過取得 Minerva 傳送的資料來視覺化變數，DIVA 主 44.
(45) 要透過 3 個命令來取得變數的資訊，分別是 ask，struct，show。以下介紹 3 個命 令的主要規格。 z. ask [變數名稱]：Minerva 回傳 <VARNAME> 變數名字 <VARTYPE> 變數. 型態 <ADDR> 變數所占的記憶體位置。如果是像 java 這類無法取得變數記憶 體位置的語言，<ADDR>欄可以回答 none。 z. struct [變數名稱]：Minerva 回傳 <VARNAME> 變數名稱 <ATTQUN> 屬性. 數量 <VARNAME> 屬性 1 名稱 <VARTYPE> 屬性 1 型別 <VARNAME> 屬性 2 名稱 <VARTYPE> 屬性 2 型別 … <VARNAME> 屬性 n 名稱 <VARTYPE> 屬性 n 型別。 z. show [變數名稱]：Minerva 回傳 <VARNAME> 變數名稱 <VALUE> 變數值. <ENDLINE>。如果是物件，指標或陣列變數，<VALUE>欄為變數的記憶體位置， 如果是一般基礎型別變數，<VALUE>欄為變數真正的值。 z. 另外有一些特殊指令，<start>和<end>分別是傳送詢問指令前和指令後會傳. 送的訊息，目的在於做資料的同步。<STEP>，<CONT>，<NEXT>命令是當使用 者在 DIVA 介面按下移動中斷點的按鈕後，會告知 Minerva 要移動中斷點用。 <OVER>則是 DIVA 告知 Minerva 程式已關閉，Minerva 端可以中斷連線。 z. Minerva 也會主動丟<OVER>和<RESET>給 DIVA，<OVER>代表除錯器執. 行結束，DIVA 可以清楚畫面上的所有 VM。<RESET>代表除錯器從新啟動，DIVA 會將 WOPM 所有的 entry 逐一對 Minerva 做詢問來取得最新資訊，<UPDATE> 45.
(46) 是中斷點移動，當 DIVA 收到此命令後，會進行跟<RESET>相同的行為。. 46.
(47) Chapter 4 Section 4.1. Mapping Engine. 資料與 VM 的 mapping. 如緒論中所提到的，如何處理資料和 VM 之間的對映一直是軟體視覺化這 個研究領域裡面最大的問題所在。當一個程式設計師在使用任何視覺化工具時， 以目前的進展，一則選擇妥協於視覺化工具所提供的視覺化，或者是直接放棄使 用。在前面的章節，敘述了我們的解決的方法是提供組合的機制讓使用者輕鬆的 建構出他們想要的視覺化。要能夠達成這樣的目標，首先資料和 VM 之間要能 達到退耦(decoupling)，也就是 VM 單純描述一種視覺化的呈現，而不跟資料有 耦合(coupling)。反過來講如果資料跟 VM 之間有太多的耦合會有什麼問題呢？ 這樣的 VM 只能視覺化某一種特定的資料結構，也就是我們必須為了各式各樣 的資料型態去撰寫各式各樣的 VM。很明顯的，這樣的工具是沒用的。我們藉由 將資料跟 VM 退耦，使得 VM 具有高靈活性及重用性便於面對各式各樣的資料 形態。 有許多種解決 decoupling 的方式，一種常用的方式是由使用者自行敘述資料 所對應的視覺化。這一類的軟體視覺化工具採用將資料先轉換成 meta-format 來 紀錄資料。AT&T 的 Graphviz[13]就是如此。在 Graphviz 當中想要視覺化資料的 時候，必須先將資料轉換成 Graphviz 所能接受的 meta-format。也就是說 Graphviz 利用 meta-format 解決與任意型態資料間的耦合。 但是，面對資料的多樣性，我們不可能為每一種情況一一撰寫轉譯器。舉例 47.
(48) 來說，如果有一個視覺化 2 元樹的 VM，它接受 3 個引數： z. int value. z. Object *leftChild. z. Object *rightChild 此時如果程式設計師欲拿來以此 VM 視覺化的資料是具有 4 個屬性值：. z. int value. z. Object *leftChild. z. Object *rightChild. z. boolean isTraced 則該程式設計師必須自己編寫一個轉譯器來將 isTraced 這個屬性暫時遮蔽，. 來符合 2 元樹的視覺化。當程式設計師欲視覺化的資料是具有 5 個屬性值： z. int x. z. int y. z. int value. z. Object *leftChild. z. Object *rightChild 則該程式設計師同樣必須另外編寫一個轉譯器來遮蔽 x 跟 y 以符合 2 元樹. VM 的需求。這種 meta-format 的方式，的確能達到資料和 VM 分離的效果，但 有 2 樣令人詬病的缺點。 48.
(49) 1.. 程式是多變性的，但我們不可能一一為每種資料結構撰寫轉譯器. 2.. 使用者必須先學習該語言的 meta-format 的編寫格式 除此之外，軟體視覺化這個領域中有另一個研究也是處理資料與視覺化之間. 的對映關係稱為 model-view。首先必須要定義資料與 model 的關係，例如一個圖 形的 model 內部會包含很多個節點、線。每個節點會有不同的屬性(顏色，形狀 等)；線則會有虛線、實線等等。而視覺化結果則是以 model 為基礎加以實作， 例如將節點畫成圓形、線畫成虛線。所以大多數以 model-view 實作的軟體視覺 化工具都以處理 software-metric(軟體度量)為主，因為資料已經經過收集跟組織 成這樣的工具所需要的結構。 而在除錯的情況下，資料型態是任意的，如果我們以 model-view 的方法處 理資料與視覺化之間的對映關係要如何做呢？通常這類的工具會利用 pattern language 的方式定義資料對映到 model，也就是必須符合工具所預期的資料結構 才可以轉成 model。以圖 20 為例，這個三個資料結構最大的差別在於 class AAA 以及 class BBB 內部的資料也是一樣的型態，但是 class CCC 卻多了 DDD 的資料 型態，因為不符合 pattern，所以不能轉成 model 以進行視覺化。. 圖 20. 三個資料結構. 49.
(50) 以 model-view 實作的軟體視覺化工具的確是可以做到自動化的對映，而且 也不需要撰寫任何的程式碼，但是視覺化的前提是資料要能夠符合 model ，並 沒有組合的概念，無法呈現任意的，複雜的視覺化。除此之外，當面對各式各樣 的資料形態時，並沒有辦法保證每一個特殊的例子都符合預期的資料型態以轉換 成 model 進行視覺化。因此，也限制了這個研究主要應用在教學之中，或特定的 領域。 我們希望 xDIVA 的 mapping 是可以不需讓程式設計師撰寫額外程式碼而是 透過簡易的拖曳和選擇就可以得到使用者想要的視覺化，使用起來越輕鬆、直覺、 方便是最好的。最起碼是讓使用者不需要花費太多時間去閱讀說明文件（閱讀說 明文件通常會大大地降低使用意願） 。因此，我們設計出一個簡易操作的 Mapping GUI。. Section 4.2. Mapping GUI. 圖 21 是 xDIVA 處理資料與視覺化之間對映關係的介面。在 Dialog 中間的 Attribute List 是使用者目前想要視覺化的變數，右邊的 Mapping Area 是處理資料 對映到最終視覺化結果的區域，左邊的 Toolbar 則是可供選擇的 VM 或是具特殊 功能的 Mapping Node，例如可以輸入任意數學方程式的 math node。. 50.
(51) 圖 21. Mapping Dialog. 例如我們在左邊的 Toolbar 點選了 CUBE_UBVM(方塊 UBVM)，則在右邊的 Mapping Area 則會多出一個 CUBE_UBVM。我們稱在 Mapping Area 上的物件為 Mapping Node(對映節點)，如 圖 22 左上，我們會在下個章節詳細介紹 Mapping Node。. 圖 22. 左上：Mapping Dialog 中 Mapping Node 右下：放大的 Mapping Node. Section 4.3. Mapping Node. 圖 22 右下是 Mapping Node 的內部基本構造的放大圖，Mapping Node 顧名 思義是處理對映關係的節點。而什麼是 mapping(對映)呢？在數學和相關技術領 51.
(52) 域而言，mapping 就是 function(函式)的別名。圖 23 就是一個 function 主要表達 x 與 y 之間的對映關係 f。. 圖 23. f 為 x、y 的對映關係. 而在 xDIVA 中，Mapping Node 代表的就是對映關係 f，如上一個章節所提 到的 Mapping Node 的輸出結果並不一定是 VM，而是在使用者點選 Toolbar 中的 物件並且這個物件以 Mapping Node 的方式呈現在 Mapping Area 中的同時，我們 就已經決定好 Mapping Node 的內部關聯到的是 VM 抑或是其他結構(例如可以處 理任意數學方程式，或是可以放任意個數的 VM 或變數)。 在這樣的設計之下， Mapping Node 依照其內部結構的不同，內部的屬性自 然也有所不同。以圖 22 右下 Mapping Node 的結構放大圖，若其內部結構是 VM， 因為 VM 是將資料對映到視覺化，所以其內部屬性幾乎都與 3D 呈現有關，例如 名稱、3D 座標(x,y,z)、長寬高以及 3D 的旋轉量；而如果內部結構是處理任意數 學方程式的 Mapping Node，其屬性則必定是變數(因為數學方程式主要處理的是 整數、浮點數的問題)。 使用者可以將變數關聯到屬性，一旦這些屬性被關聯到變數後，則 Mapping Node 內部結構的基本屬性就會隨著這個變數的值而改變。這些屬性是可以展開 或隱藏起來讓使用者將變數關聯屬性 (圖 24 左)。 52.
(53) 此外為了解決各式各樣的互相依存的關係(如位置、大小，或是複數個 VM 排 列的方式等)，我們也允許依照 Mapping Node 內部結構的不同，右邊可以輸出其 屬性，使用者一樣可以選擇要打開的特定屬性(圖 24 右)。以 VM 為例，它除了 可以輸出其基本屬性之外，甚至可以輸出 VM 本身；而任意數學方程式則必然 是輸出變數。. 圖 24. Section 4.4. Port Setting Dialog. Mapping in xDIVA. 當一個變數在 Minerva 中被視覺化之後，該變數的資料會透過網路傳遞到 DIVA。當 DIVA 接收了一個視覺化的要求之後，會跳出 Mapping Dialog(圖 25 上)讓使用者自行決定要如何組合 VM 來視覺化該變數。這個例子中使用者點選 了 CUBE_UBVM(方塊 UBVM)，顧名思義這個 VM 在 DIVA UI 呈現的視覺化是 53.
(54) 一個方塊，在我們將變數 int ivar 關聯到 int* _vm_rx 也就是 CUBM_UBVM 在 3D 空間中的座標 x 之後，CUBM_UBVM 的座標 x 的值就是 int ivar 的值。圖 25 下 就是這樣的操作之後的視覺化結果。. 圖 25. Section 4.5. 上：Mapping 的操作. 下：Mapping 的視覺化結果. Create arbitrary mappings from a. drag-and-drop GUI 從上面可以看到，我們設計了一個簡單的介面，讓使用者可以輕鬆的拖曳和 選擇以做到資料與視覺化之間的對映。但是，光是允許資料和 VM 的對映是不 54.
(55) 足以做到任意的視覺化，xDIVA 最強大的地方在於我們藉由讓使用者自行決定 輸出哪些 3D 屬性(右)將 VM 和 VM 之間透過組合來產生更大的 VM 以處理任意 的視覺化。因為 xDIVA 的 VM 是具有高度組合性的。組合性是一種系統的設計 原理，用來處理元件的內部關系。高組合性的系統提供元件的重組性，可以經過 選擇和重組來滿足特殊的使用者需求。元件若可重組便具一個重要的特質，就是 具自身組合性。換言之，元件可以獨立被使用，或和其他的元件合作，但相依元 件可以被置換。 以一個應用除錯二元樹的例子來說明。今天使用者在使用一般的除錯器的情 況下，一般我們只能得到圖 26 下這樣的 Memory Layout，在不被告知的情形下， 很難與圖 26 做視覺化的聯想。就像前面所提到的，人類對於圖型的敏感度遠大 於文字，我們希望能利用人類的這個特性來進行除錯以提高除錯的效率。. 圖 26. 以一般的除錯器處理二元樹. 圖 27 左就是將除錯的過程以 xDIVA 來加以處理，在這個例子中，中斷點 已經停在 60 行，而我們想要視覺化 root 這個變數。圖 27 右就是 root 這個資料 55.
(56) 結構的內部結構，它包含 3 個屬性值(boolean travel、bt left、bt right)。分別代表 目前有沒有被拜訪過，當 travel 為 true 表示有被拜訪過，為 false 表示沒有，此 外還有兩個指標指向其左右子節點 left、right，如圖 28。雖然 xDIVA 沒有為二 元樹專門製作的 VM(當然我們也不想這麼作)，但是我們可以利用球體 UBVM 與 Reference VM 組合出我們所想要的視覺化。. 圖 27. 在 Minerva 除錯二元樹的例子. 圖 28 利用球體 UBVM 與 Laser Reference VM 組合而成的二元樹 56.
(57) 圖 29. 建立二元樹的視覺化. 為了解決 VM 之間依存的關係，我們允許每一個 VM 可以輸出自身的屬性， 如位置、大小等，讓別的 VM 進行特別的運算。圖 29 中，我們將 travel 這個變 數連結到球體 UBVM 中點選後會呈現值的屬性，使用者可以在 DIVA UI 上點選 VM 得知他是 true 還是 false，left 以及 right 節點連結到 Laser Reference VM，它 會持續不斷的射出一條雷射光從白球到所指到的物件(如圖 28)。為了處理球體 UBVM 與 Laser Reference VM 之間的位置關係，我們以圖 30 說明，左下角的(x,y) 位置是 boolean 變數的球體其(直徑/2,直徑/2)，而右下角則是(直徑/2，-直徑/2)。 我們將球體 UBVM 的 sizex（x 軸方向的大小）輸出，利用可以處理任意數 學公式的 Math Node 計算這兩個座標再將值連結到 Laser Reference VM 的 x、y 的位置使得兩 laser reference VM 剛好放置於求體的左下角，與右下角。最後將 這三個 VM 連結到之前提到的 Container VM。Container VM 是一個容器，將所 有連進來的 VM 給予一個透明的外框，當然它也不會改變內部 VM 之間的互相 依存關係。其結果就如同圖 28 所顯示的。 57.
(58) 當然這樣的對映全部都是可以儲存起來，並且在下一次自動運作於新產生的 物件。使用者不用每一次重先建構這個對映。. 圖 30. Section 4.6. Binary Tree 之間的互相依存關係. Compose arbitrary VM from UBVMs in your. dialog 在前面曾提到不經由程式碼的撰寫從 UBVM 製造出新的 VM。為了甚麼要 做這樣的設計呢？有各式各樣的 VM，而這些 VM 組合的方式幾乎有無限多種， 我們要能夠事先知道使用者會使用哪一種視覺化，並事先準備好是不切實際的， 而其實用性也會讓人懷疑。因此我們提供一個包裝的方式，讓使用者可以自行將 VM 組合出各式各樣的 VM，並且讓這些 VM 能夠被重用於未來的視覺化工作上， 當然在這樣的過程中是不需要撰寫任何的程式碼。 58.
(59) 以下我們用 RGB 像素的範例來描述我們的設計。圖 31 是使用立方體的 UBVM 為範例： int value_R ; int value_G ; int value_B ;. 圖 31. R G B. Ultimate Cube VM. 直接使用 UBVM. 在這個範例中使用者打開方塊 UBVM 的基本顏色屬性，然後將三個變數連 結到這三個顏色屬性。藉由這樣的連結，使用者可以將一個 cube 用來作為彩色 像素的視覺化之用。相關的應用領域有影像處理等等。如果，使用者寫的程式是 灰階的影像處理程式，實際上 Cube UBVM 還是可以重用。使用的方式如圖 32：. int grey_value ;. R G B. 圖 32. Ultimate Cube VM. 重用方塊 UBVM 來視覺化灰階像素。. 這樣子的重用，理論上在使用 xDIVA 一段時間之後，運用一點想像力，是 可以輕易做到的。但是我們不能期待所有 xDIVA 的使用者皆有足夠的想像力或 能夠認真的熟讀 xDIVA 的說明文件。一般使用者期待的是能夠直接找到一個灰 階像素的 VM 直接使用。如果為了這樣的需求，我們就必須用透過撰寫程式碼 新增一個灰階像素的 VM，那就違反了 xDIVA 當初設計的初衷。我們希望的是 59.
(60) 特異化或新的 VM 可以由 UBVM 以及既有的 VM 當中組合出來，而且這件事情 不需要撰寫任何的程式碼，因為任何程式碼的撰寫都會牽涉到除錯，測試，新增 到系統中的等等麻煩的問題。 我們提供的是類似圖 33 所展示的一個簡單的包裝功能。我們可以將方塊 UBVM 包裝成一個新的 VM 用來視覺化灰階像素，然後給予命名為灰階 VM 。 在包裝完成之後，使用者可以直接搜尋到這個 VM，無須任何想像力地直接使用 它。在這個過程中，我們沒有寫到任何一行的程式碼。 Grey-pixel VM int. R G B. 圖 33. Ultimate Cube VM. 將方塊 UBVM 包裝成另外一個 VM. 再以上面的二元樹作為例子(圖 28)，如果這樣的 VM 使用很頻繁的話，我 們也可以利用這個介面將該對映包裝成一個新的 VM。圖 34 內部處理的細節與 圖 29 最大的差別在於，這裡運用了一些特別的 mapping node 叫做 Clone Mapping Node。Cone Mapping Node 作為未來傳進來的 VM 分身，有點類似程 式語言副程式的參數，讓後續的對映可以藉由存取這個 Mapping Node 而存取到 未來傳進來的 VM 的各項性質。. 60.
(61) 圖 34. 利用組合的方式製作二元樹 VM. 而組合二元樹也不是唯一的。以圖 35 為例，使用者也可以利用三個都是 VM Clone Mapping Node 的方式達成，這樣的拖曳方式只是抽象的決定三個 VM(我們都不知道會是什麼 VM)之間的互相依存關係會排列成如圖 30 的格式。 使用者可以依循一定的規則組合出各式各樣的 VM，而這些 VM 內部的組合方式 可能不盡相同，但卻可能產生相同的視覺化結果──組合 VM 的介面是相當有 彈性的。. 圖 35. 利用另一種組合的方式製作二元樹 VM 61.
(62) 在這樣的拖曳及設定之後，我們就可以製造出一個全新的二元樹 VM 加以 使用。藉由這樣子的設計，新的 VM 都可以在不用撰寫程式碼的條件下，不斷 地從 UBVM 以及既有的 VM 延伸出來。. 62.
(63) Chapter 5. Auxiliary Mapping Node. 在不斷地研究與改進過程中，我們發現除了 VM 之外還有一些必要的 Mapping Nodes 在這個過程中不斷地被構思出來。目前為止 xDIVA 的 Mapping Nodes 總共有以下幾種： z VM Node 處理變數與 VM 的中間物件 z Math Node 可以輸入任意數學方程式的 Mapping Node z Wop collector Node 用來連結複數個變數的 Mapping node z Vm collector Node 用來連結複數個 VM 的 Mapping node z Clone Node Clone Mapping Node 指的是某個 VM 在這個任意組合 VM 介面中的分身 z Container Node 用來配置所有相關位置已經設定好的多個 VM，然後給予這些 VM 一個透明的外 殼 而這邊主要介紹的就是可以處理任意數學方程式的 Math Node，是本論文的 一個主要實做成果。 63.
(64) Section 5.1. An example by using math mapping node. 而 Math Mapping Node 可以應用的地方很多，即使是在日常生活中，數學也 是隨處可見。例如 xDIVA 中當需要參考不同的 VM 相對位置、形狀的時候，很 多時候不是直接輸出其屬性即可，常常會需要做一些額外處理：直徑/2=半徑、 三角函數等。 例如在除錯的過程中，一個物件有四個屬性(int a、int b、int c、int d)，而今 天我們感興趣的並不是每個屬性的值，而是這四個屬性的平均值。我們就可以利 用 Math Mapping Node 處理。 如左，Math Mapping Node 就像是一個容器，我們可以連結不限個數的變數， 並利用右鍵選單的＂key the arithmetic＂可輸入方程式。而右的$0~$3 代表是連進 來的變數，當然在這個地方也可以直接輸入整數以及浮點數，而 Math Mapping Node 的輸出結果則連結到方塊 UBVM 的 Z 方向(前後)的大小以及點選會呈現/ 關閉連結到的值的屬性可以得到的視覺化結果。. 圖 36 左 利用 Math Mapping Node 處理平均值的例子 右輸入任意的方程式. 64.
(65) 圖 37. Math Mapping Node 處理平均值的視覺化結果. 在 xDIVA 中並不是只有 VM，除此之外我們也預期要提供各式各樣輔助用 的 Mapping Node，讓使用者可以自行運用以組合出他所想要的視覺化結果。. Section 5.2. An overview of math node. 由於數學方程式中運算元的多樣化，要為每一種運算元(如加、減、乘、除 等)實作一個 Mapping Node 並不是一個好的作法。這樣導致為了處理一個簡單的 方程式就需要相當多的 Mapping Nodes 一起合作，直接導致的後果就是使得 Mapping Area 因為放置了過多的 Mapping Node 而顯得混亂。 因此我們希望處理數學方程式的部分能做到輸入一個字串，而我們會進行判 斷這個字串是否符合數學方程式的規則，如果不是，則告知使用者，如果是，則 65.
(66) 進行這個字串所對應的方程式的處理。 為了能做到以上這點，Math Mapping Node 內部就必須有 Compiler(編譯器) 幫助處理，如圖 38。很明顯的一開始這條字串是無意義的。. 圖 38. Math Mapping Node 內部的字串處理. 我們首先要做的是將字串逐字的組合成一個一個有意義的字，例如 1+2+3 就會變成 1、+、2、+、3，這就是 Scanner 主要處理的部分。Scanner 將字串切成 一個一個的子字串，主要比較的是各式各樣的運算元(如+、-、*、/等)跟判斷整 數、浮點數、以及變數。 但是光是這樣並不足以處理各式各樣運算的關係，例如 1+2*3 到底是 1+2 之後*3 還是 2*3 之後+1(當然第二個才是正確的例子)。我們還需要定義一組正規 的語法規範，將這些字串轉換成樹狀結構，當真正需要運算的時候再進行處理(因 為除錯的過程中，變數的值是會改變的)。因此我們將這一組字串交給 Parser 處 理，Parser 內部是以 LL(1)實作。當這一個一個的子字串處理的過程中，若不符 合語言規範則告知使用者這不是一個正確的方程式，如果符合則輸出樹狀結構的 root 節點(根節點)，圖 39 就是 1+2*3 轉換後的樹狀結構。當真正需要運算時， 66.
(67) 我們可以利用 Recursive(遞迴)演算法取得方程式的運算結果。. 圖 39. 1+2*3 經過 Parse 轉換後的樹狀結構. 67.
(68) Chapter 6 Section 6.1. 結論及未來展望. 結論. 新 VM 的產生無須撰寫任何程式碼是一項很重要的突破。藉由 UBVM 及組 合任意 VM 的介面，使用者不再受限於必須以撰寫程式碼的方式增加新的 VM， 而是藉由拖曳與連結加以組合。也因為完全不需要程式碼的撰寫，編譯與除錯， 讓 VM 的設計更具彈性與擴充性。 即使使用者立即需要一組某個領域上應用的 VM，我們也可以在短時間內利 用組合的方式加以製造這些 VM，透過我們的設計，體現了 VM 的重用性、組合 性。 透過 Mapping Engine 的存在，讓資料和 VM 能夠 decoupling，Mapping Engine 允許使用者組合 VM 來增加 VM 的重用性和靈活性。 除此之外，Mapping Engine 提供一個方便的使用者介面讓使用者能輕鬆的選 擇資料和 VM 的對映關係，而不用學習及撰寫額外的視覺化程式碼。. Section 6.2. 未來展望. 之後的研究還會新增一些具有特異屬性的 Mapping Node，例如有計數器功 能的 Node、處理動畫的 Node 等。藉由將屬性從 VM 中抽離而形成的 UBVM， 與可以處理任意數學方程式的 Math Node，利用組合任意 VM 的介面可以處理更 68.
(69) 多的視覺化。. 69.
相關文件
隨著朝陽建校滿十週年，營建工程系也 10 歲大了，在歷任系主任的帶領下，營建系已經頗 有規模。目前本系仍維持結構工程、大地工程、營建管理三個領域的師資，共有 19
使我們初步掌握了電壓、電流和電阻三者之間的關係。我
並藉由適當工具與資訊，去描述、模擬、解釋與 預測各種現象，發揮數學思維方式的特長，做出
你是否同意，及至 2000 年，中華人民共和國在 1980 年代的改革開放改善了與 亞洲其他國家的關係？就中華人民共和國與亞洲任何一個國家的關係，解釋你 的觀點。. 建議答題方向
其實這個問題並不新鮮，有的學者已經進行過探討。 [註 2]
不過以上所提的內容幾乎都會被現在的智慧型手機取 代，因此我們覺得這些功能能夠運用在一個沒有網路
通過蒐集學生在各方面(包 括學習 過程和結果 )的學習 顯證，然後詮釋資料，判斷 學生的表現，藉以向學生、.
由於 DEMATEL 可以讓我們很有效的找出各準則構面之因果關係，因此國內外 有許多學者皆運用了 DEMATEL
