運用物理定律的動態的互動式立體圖畫排列系統

全文

(1)國立臺灣師範大學資訊工程研究所. 碩士論文. 指導教授：鄭永斌博士. A 3D Dynamic and Interactive Graph Visualization System Based on Physics Laws. 研究生：李詠銘撰中華民國九十八年六月 1.

(2) 目錄目錄 ........................................................................................... 2 圖目錄 ......................................................................................... 6 程式碼目錄 .................................................................................. 8 摘要 ........................................................................................... 9 CHAPTER 1 緒論 .................................................................. 10 SECTION 1.1 OVERVIEW .................................................................. 10 SECTION 1.2 論文架構 ................................................................ 14 CHAPTER 2 研究背景 .......................................................... 16 SECTION 2.1 DEBUGGER .................................................................. 16 2.1.1 JDB ............................................................................... 16 2.1.2 GDB .............................................................................. 16 2.1.3 DDD .............................................................................. 16 2.1.4 ODB .............................................................................. 16 SECTION 2.2 VISUALIZATION TOOLS ................................................... 16 2.2.1 Graphviz ....................................................................... 17 2.

(3) 2.2.2 BLOOM ......................................................................... 17 2.2.3 Vizz 3D ......................................................................... 18 SECTION 2.3 2D VS 3D .................................................................. 19 CHAPTER 3 XDIVA 架構 ........................................................ 24 SECTION 3.1 COMMAND AGENT ....................................................... 25 SECTION 3.2 WOPM ..................................................................... 27 SECTION 3.3 DIVA UI .................................................................... 28 SECTION 3.4 DIVA VM .................................................................. 29 SECTION 3.5 LAYOUT VM ................................................................ 30 SECTION 3.6 . XDIVA. 的 LAYOUT 系統 .............................................. 30 . SECTION 3.7 . XDIVA. 的 LAYOUT 系統結構 ...................................... 33 . 3.7.1 物件導向設計原則 ..................................................... 33 3.7.2 樣板設計模式 ............................................................. 34 3.7.3 利用樣板設計模式 ..................................................... 34 3.7.4 陳列影響範圍 Layout_influence_area ........................ 36 3.7.5 Layout 的動畫系統 ..................................................... 37 CHAPTER 4 GRAPH LAYOUT .................................................. 40 . 3.

(4) SECTION 4.1 GRAPH DRAWINGS ....................................................... 40 SECTION 4.2 GRAPH 的陳列 .......................................................... 41 SECTION 4.3 . XDIVA. 中的 LAYOUT 需求 .......................................... 43 . CHAPTER 5 GRAPH 的彈簧陳列方法 .................................... 45 SECTION 5.1 物理現象 ................................................................ 45 5.1.1 移動的發生與物理學的計量 ...................................... 45 5.1.2 位移 ............................................................................. 46 5.1.3 速度 ............................................................................. 46 5.1.4 加速度 ......................................................................... 47 5.1.5 資料結構：位置移動狀態 PositionMoveState .......... 47 SECTION 5.2 力的發生與傳導 .................................................... 47 5.2.1 力 ................................................................................. 48 5.2.2 資料結構：力與移動 ................................................. 48 5.2.3 彈簧與虎克定律（Hooke's law） .............................. 49 5.2.4 方法：產生彈簧力 crateSprForceFromVMtoVMs ...... 50 SECTION 5.3 牛頓運動定理 ........................................................ 51 5.3.1 牛頓第一運動定理 ..................................................... 52 . 4.

(5) 5.3.2 牛頓第二運動定理 ..................................................... 52 5.3.3 牛頓第三運動定理 ..................................................... 52 SECTION 5.4 牛頓運動定理的影響 ............................................ 53 5.4.1 牛頓第一運動定理的影響 ......................................... 53 5.4.2 方法：慣性定律‐‐與前移動的結合 ........................... 53 5.4.3 牛頓第二運動定理的影響 ......................................... 54 5.4.4 方法：利用第二運動定理算出彈簧力的加速度 ...... 55 5.4.5 牛頓第三運動定律的影響 ......................................... 55 5.4.6 方法：作用力與反作用力 ......................................... 56 SECTION 5.5 摩擦力 ................................................................... 57 5.5.1 摩擦力加入位置移動狀態 ......................................... 58 5.5.2 動畫與摩擦力 ............................................................. 59 SECTION 5.6 成果 ....................................................................... 61 CHAPTER 6 結論與未來工作 ............................................... 63 SECTION 6.1 結論 ....................................................................... 63 SECTION 6.2 未來工作 ................................................................ 64 REFERENCE ................................................................................. 65 . 5.

(6) 圖目錄圖 2-a DDD 的使用者介面 .......................................................16 圖 2-b ODB ................................................................................16 圖 2-c Graphviz 的 dot 語法與其繪圖結果 .............................17 圖 2-d BLOOM ..........................................................................18 圖 2-e Vizz 3D 的視景圖 ..........................................................19 圖 3-a : xDIVA 的系統架構圖................................................25 圖 3-b :Minerva 和 Command_Agent 之溝通流程圖 ..........27 圖 3-c : DIVA 執行視窗.........................................................28 圖 3-d 在 DIVA 視窗中按右鍵呼叫 Layout 選單 ..................31 圖 3-e 決定陳列範圍的 Dialog................................................31 圖 3-f Spring Layout 的參數設定 Dialog .................................32 圖 3-g 彈簧力已作用在系統之中 ...........................................32 圖 3-h 任何一個變動都將帶來連鎖反應 ................................33 圖 3-i Template Design Pattern ..................................................34 6.

(7) 圖 4-a 左為矩陣表達法，右為圖畫 ........................................42 圖 4-b 節點數量多的 Graph 被 Graphviz 視覺化後的情況 ...42 圖 5-a 「位移」的示意圖 .......................................................46 圖 5-b 彈簧 ...............................................................................50 圖 5-c 彈簧陳列的效果.............................................................62. 7.

(8) 程式碼目錄程式碼 3-1 LayoutVM 的基底類別 ...........................................35 程式碼 3-2 layout 呼叫子類別實作方法 ..............................36 程式碼 3-3 記錄整個物理系統母體的資料結構 ...................36 程式碼 3-4 Animable .................................................................38 程式碼 3-5 動畫中心 ...............................................................38 程式碼 5-1 記錄物件移動狀態的資料結構 ............................47 程式碼 5-2 Link .........................................................................48 程式碼 5-3 doLayout 方法 ........................................................57 程式碼 5-4. 加入摩擦力的位置移動狀態 .............................59 . 程式碼 5-5 animation_behavior 方法 .......................................61 . 8.

(9) 摘要近年來雖然已經有一些軟體視覺化工具可以透過圖形來視覺化程式內部的資料以幫助程式設計師除錯，但它們在實用上還有許多限制，使得軟體視覺化工具無法成為程式設計人員每天使用的工具之一。軟體視覺化除錯工具 xDIVA (eXtreme Debugging Information Visualization Assistant)[1]是一個具備彈性與實用性的工具用來幫助程式設計師進行除錯。xDIVA 使用 3D 的圖形、顏色和動畫來視覺化資訊。. 目前 xDIVA 系統在視覺化資料的過程中尚存在待開發的功能。如何依照人類熟悉的方式陳列視覺化物件(Layout)就是其一。目前 xDIVA 中為視覺化隱喻 (Visualization Metaphors)所做的陳列演算法仍然不夠友善，也沒有足夠的互動性。因此本論文提出在 xDIVA 下，應用樣板設計模式(Template Design Pattern)實作出一個具有彈性架構讓未來的許許多多的陳列演算法可以輕鬆地擴充。在這樣的架構下，本論文也實做了一個可用來排列 Graph 類型的資料結構的陳列演算法，此演算法允許使用者進行積極的互動，其原理是借用物理的一些運動法則來展現具備真實感的動畫。. 9.

(10) Chapter 1 緒論 Section 1.1 Overview 除錯，是程式開發的必經過程。有時甚至占據的時間比撰寫程式還要長。而對於一個初學程式者而言，最常見的除錯方法就是仰賴在程式碼當中插入 printf() 這一類的輸出指令來將變數的值列印在螢幕上或者是檔案中，藉以觀察程式是否符合期望的結果。隨著軟體需求的多樣化和複雜性的提升，程式設計師需要花費比以往更多的心力在維護或開發新功能上。若僅使用簡易的輸出指令來除錯，對大部分的程式設計師來說，得耗費更多時間在除錯上，因此進階的程式開發人員通常會搭配輸出指令和使用除錯器來除錯軟體。除錯器是個複雜的系統程式，一般只具備文字介面。隨著時代的發展，現在的 IDE 都提供一個內建的除錯器來提高可用性。除錯器主要的功能是經由使用者設定中斷點來暫停程式的執行，然後借此觀察程式狀態和變數的資訊。. 舊有靠著插入輸出指令(如 printf())來幫助除錯的習慣是依然存在的。程式設計人員通常這麼做的原因是為了將複雜的資料結構整理後列印在檔案或者螢幕上，來幫助除錯，有經驗的程式設計師會搭配輸出指令和除錯器一起解決問題。但無論是在文字模式下的除錯，或者是整合開發環境下除錯，資訊仍舊是文字模式，當資料量龐大且複雜時，對於除錯的效率提升將有限。 10.

(11) 軟體視覺化是一門透過使用圖形，或動畫來表達軟體元件的概念或變數的值來解決這個問題的研究。因為軟體開發是一件具有相當程度的抽象性和不可見性的工程。對於理解抽象的事物，人類習慣透過使用圖形和文字的表達來理解，而其中對於圖形的敏感度又遠大於文字，也比較容易印象深刻。軟體工程有許多進展便是利用了這樣的理念，嘗試將軟體視覺化來幫助程式設計師增進理解，最有名的就是 UML(Unified Modeling Language)[4]。UML 使用多種靜態的平面圖，每一種只表達軟體中一個片面的特性。如類別圖來表示類別的關連性，循序圖來表達程式的流程，活動圖來描述程式流程的分歧。UML 的確能在理解過程開始的初期，給予程式設計師一個系統的宏觀架構概念，但程式設計師還是必須去面對所有的細節。必竟軟體是動態的，不是靜態的圖形顯示方式能徹底描述的。. 在軟體視覺化研究的領域有許多可以幫助使用者理解軟體系統的工具，像 CodeCrawler[5]，BLOOM[6]等等。這類的工具可以透過分析靜態的原始碼，將獲得的統計資訊（通常是 software metrics）[7]以樹狀圖，長條圖等非文字模式的圖表將結果呈現在螢幕上。使用者可以透過選擇自己偏好的圖形表達方式來增進對該軟體的了解。但是這類的軟體僅能提供程式設計人員軟體品質的好壞的資訊卻無法視覺化軟體執行當中的動態行為。. 儘管有許多研究致力於軟體的視覺化，但它們只能針對特定的資料和架構做一些統計性的運作，或者只能呈現一部分的視覺化，這類的軟體工具只有在少數 11.

(12) 特殊的案例下才能呈現最佳的效果，一般都用在程式理解和教學用途，但在一般程式專案的開發上則很難發揮功效。因此，我們提供出一個除錯視覺化雛形工具 xDIVA 的研究。目的著眼於視覺化軟體執行期間動態資料，以及處理無窮廣泛的資料種類和 VM (Visualization Metaphor)的映對。xDIVA 導入物件導向的觀念，使得 VM 可以相互溝通，組合，並且能和資料分離以達到最低耦合。而且一個複雜的 VM 可以由許多基礎的 VM 組合而成，每一個都是獨立可取代的。大部分的軟體視覺化工具只能以預先定義的固定幾種呈現視覺化軟體，這些呈現方式通常是由該設計該工具的程設人員完成的，使用者無法對其新增或修改。相對於此，xDIVA 透過 Mapping Engine 的存在讓 VM 和資料及視覺化工具切割開來，未來使用者可以自行在 xDIVA 上新增個人化的 VM。VM 的數量和品質嚴重影響著視覺化工具的實用性，如果一個視覺化工具無法提供足夠數量和品質的 VM，則必定失敗。然而開發 VM 是需要大量時間和金錢。對此 xDIVA 提出 Mapping Engine 的概念，讓視覺化工具和 VM 的設計與實做是可以切開的構想。意即，我們提供一個視覺化工具，而 VM 的開發可以交給第三方擔任。我們的目標是把抽象且複雜的軟體結構及演算法概念利用圖形和動畫呈現出來，來幫助程式設計師更快了解軟體的動態行為。而視覺物體的陳列方式(在 xDIVA 系統中，稱之為 Layout)深深地影響了一個畫面可傳達的資訊多寡、可被理解的程度、以及美觀上的吸引力[2]。而作為一個除錯器的視覺化工具，xDIVA 12.

(13) 系統的陳列方式致力於提昇畫面可被理解的程度，同時為避免因為反覆循環的執行、中斷、檢視觀察等動作行為（很遺憾地，這是除錯難免的過程）形成的倦怠感，我們應更深入地思索如何讓畫面的陳列不再枯燥乏味。. 程式設計師使用視覺化除錯器，大多數的情況下是因為面對了龐大複雜的資料結構與關連性。在 xDIVA 的使用經驗中，物件之間的 Pointer 參考關係大部分的時候會被視覺化為線狀的物體，而各物件之間複雜的 pointer 關係經過視覺化為線狀物後，很自然地就形成了各種類似 Graph 的表達方式。雖然這與資料結構本身的視覺化已然無關，但這樣類似 Graph 的呈現方式會衍生出許多問題，譬如最明顯的──陳列（在 xDIVA 系統中，稱之為 Layout）問題，我們將在第四章詳細說明。. 而 xDIVA 的陳列問題也不只是普通的陳列問題，類似 Graph 的呈現終究也只是類似 Graph，它的節點可能是由任意資料結構所組成，因此 xDIVA 的陳列問題不能受限於任何固定的資料結構，必須同時處理多變的物件並讓它們依照演算法運算出的位置各按其位。此外，xDIVA 致力於完成使用者心目中最好的視覺化呈現，這個理念當然也將展現在陳列系統上，我們不會擅自幫使用者決定最好的陳列，我們僅透過各種互動的方式輔助使用者完成心目中最好的陳列。在我們對 xDIVA 的設計中，使用者可以自由選擇適當的 Layout 演算法重新整理物件位置。在 xDIVA 中的這些 Layout 演算法各有用處，使用者可以依照需求選取 13.

(14) 與調整。. 另外，xDIVA 的 Layout 系統不僅希望達成前述的彈性的 Layout 需求，也希望我們的功能系統建立在彈性的程式架構上，以便未來參與 xDIVA 的開發者能夠輕鬆的應付多變的使用者需求以及發展自己的陳列方法。我們的程式架構將讓往後陳列方法的設計者只需要專注於思考物件之間的「如何變化」的行為，而不用再去考量如何得到正確的連結物件以及變化的範圍。不僅提升了往後在系統中增加一個陳列方法的效率，同時也整理並規範了陳列系統取得物件資訊的途徑，降低各子系統程式碼間的相依性。. 不同於以往的視覺化工具，xDIVA 的陳列系統面對的資料結構千千萬萬。我們不限定每一個陳列方式所面對的資料結構對象，使用者可隨喜好決定，而不必含有特定的資料結構，或者執行任何的資料對應工作。. 本論文將詳細地敘述其中一項 Graph Layout 演算法的實做：一個強調參考關係(Reference)又有生動趣味的物理方式演算法──彈簧演算法。這個演算法應用了古典物理學的虎克定理以及牛頓三大運動定律，讓 VM 物件在 xDIVA 中的互動能夠模擬自然界中彈簧的行為。並藉此演算法說明整個 Layout 的彈性架構。. Section 1.2 論文架構本論文在第二章會先大略的介紹閱讀本論文的相關知識，包含 Debugger、 14.

(15) Ｖisualization Tools 與 Graph Layout 相關的研究。第三章則是說明 xDIVA 的元件以及 xDIVA 的 Layout VM 設計與架構。第四章會詳細的闡述 xDIVA 的 Graph Layout 需求以及我們的解決方法，而第五章則是為這個方法(彈簧陳列)的物理學基礎知識做說明，而第六與第七章則為是這個方法實做技術層面（程式架構與演算法）與動畫系統。最後，我們再於第八章與第九章做出總結。. 15.

(16) Chapter 2 研究背景 Section 2.1 Visualization Tools 對於複雜的事物，人類可以經由圖表和動畫的表示，讓它變的更容易被理解。大部分成熟的工程領域皆具有標準的藍圖來描述它的設計和產品。圖示的確可以幫助人類解決溝通上的問題。軟體系統因為具備有不可見性，所以程式往往相當令人難以理解。Brook[3]的書中有提到，不可見性讓程式設計變成一門相當難的領域。所以，過去幾十年裡，軟體工程的研究一直在尋找方法試圖著用圖形來表示程式。UML 就是在這樣的背景之下，成功的成為軟體工程的重要標準圖形。. 另一方面，近幾年興起的軟體視覺化研究則著重於建構視覺圖案來表達軟體系統的結構，大小及行為。這類的工具依據其對軟體的測量值來做視覺化，可以在開發的初期用來表示軟體品質的好壞，並指出異常的地方以提供為管理的重要依據。. 另一類的視覺化軟體是提供執行期間軟體效能的視覺化，主要用來做效能的測量，例如記憶體的使用，類別和方法所花費的時間。這類的軟體如 BLOOM[5]， JIVE[15]，Jinsight[16]。有些則著重於使用 UML 圖來表示物件間的關係。像 JIVE， JaVis[17]，雖然這類的軟體的意圖皆不同，但目的都是為了幫助程式設計師除錯，以及更了解他們的程式碼。 16.

(17) 對於軟體視覺化工具而言，VM 的品質和數量對其實用性有舉足輕重的影響，卻又是一個困難的議題。由於資料的廣泛性和多樣性，宣稱要能夠解決廣泛的資料種類與視覺化映射問題，將是一個極勇敢的挑戰，卻很容易淪為不實用的學術界研究。所以，在考量實用性之下，大部分的視覺化工具都會設定視覺化的範疇。以 Graphviz[18] 為例，他只能視覺化有向圖，如 graph, tree。DDD 也選擇有向圖為主要的表達方法。然而，程式的狀態是反覆多變的。舉例來說， {(2,7),(6,9),(3,2)}可以代表任何有可能的意義，可能是一組的 2 維座標，也可能代表矩形的長寬高，除非資料的來龍去脈被告知，否則視覺化工具做錯誤的解釋可能比做安全的解釋還糟糕。所以，像 DDD 這類的工具都選擇以文字模式來表示，因為這是最安全的表示方法。然而，捨棄更有效的視覺化方式是令人婉惜的，這就是 xDIVA 想解決的問題，讓視覺化除錯更進一步。. 2.1.1 BLOOM BLOOM[5]是一套用來幫助程式設計師視覺化 C++和 JAVA 靜態資訊的工具，特色是可以允許使用者自訂 Visual browser 來視覺化軟體。BLOOM 透過將 C++ 或 JAVA 的程式碼以 XML 格式轉成 BLOOM 所需的資料之後，再經過分析配對，選擇適用的視覺模式表示出來，並提供選單讓使用者設定視覺化後圖形的大小和位置等。. 17.

(18) 不過 BLOOM 主要是用來視覺化軟體的靜態特質，如類別的大小，數量等統計資料，原則上是偏向軟體測量，跟 xDIVA 所要強調的 debug 功能並不相同。 BLOOM 提供數種 3 維空間的圖，在視覺化的過程當中，BLOOM 會自動去選擇判斷合適的結果來呈現。由於，最後所產生的結果只顯示了許多顏色的區塊，使用者必須先去熟悉每個圖的表示方式，才能懂得其所表達的結果(如下圖 2-a BLOOM)。再者，由於 BLOOM 只提供了固定的幾種模式，加上又是由系統自動配對結果顯示的，很有可能顯示出來的結果會導致不明。. 圖 2-a BLOOM. 2.1.2 Vizz 3D 跟 BLOOM 相似的是，Vizz 3D[20]也是用來做軟體度量的視覺化工具，經過分析靜態的原始碼，可以在 3D 畫面上繪出該軟體的各個表向。它可以透過使用. 18.

(19) JAVA 3D 或者是 OpenGL 來當它的繪圖引擎，將資料視覺化在一個 3D 環境上。 Vizz 3D 透過 VizzAnalyzer 取得資訊後，使用其專屬的 Visualization Metaphor 和排列演算法來繪製畫面。. 圖 2-b Vizz 3D 的視景圖是 Vizz 3D 的一個視景圖 (view)，用來表達類別和套件的關系圖。粉紅色半透明的圓球代表一個套件，而其中的每一個小圓球各代表一個類別。紅線代表類別和類別之間具有直接藕合關系。. 圖 2-b Vizz 3D 的視景圖. Section 2.2 Graph Layout 2.2.1 Graphviz Graphviz[18]是一套表達抽象資料結構的視覺化工具，可以在指令模式，網路端服務或者適用的圖形化介面下執行。使用者透過編輯 Graphviz 內建的 dot 、. 19.

(20) neato、或 dotty language 能以圖，節點及邊三種方式組合呈現出結果。以 Graphviz 的 dot language[19]為例，它存在相當嚴謹的排列演算法，dot 會按照程式碼內容將圖以整齊樣貌呈現，對於再複雜的圖，也不會有重疊的節點。. 但由於 Graphviz 仍屬於 2D 平面的視覺化工具，一旦資料量變得相當龐大的時後，畫面將會充斥著節點與邊線，對於使用者觀看時，在了解整個圖的架構或內容上，是非常沒有效率的。下表達 Graphviz 以 dot 程式語法和其繪製出來的結果。. 圖 2-c Graphviz 的 dot 語法與其繪圖結果. 2.2.2 Prefuse Prefuse[27]是一群軟體視覺化工具的集合總稱，它的特色是其視覺化結果具有豐富的互動性。而 Prefuse 的運作形式主要是以提供 Java 語言的 framework 為主，包含了針對各種資料結構的多種視覺化陳列方式，其中在 graph 的陳列上， Prefuse 也有多種擁有動畫效果的生動陳列方式可以選擇（圖 2-d）。. 20.

(21) Prefuse 使用 Java 語言開發，使用 Java 的 2D graphics library，可以輕易的轉換到 Java Swing 應用程式或者 Java web applets。Prefuse 是採用 BSD 授權的自由軟體，可以自由的使用於商業與非商業用途。. 圖 2-d Prefuse 的其中兩種陳列方法（左為 GraphView，右為 timeViz）. Section 2.3 2D VS 3D 使用 2D 來做軟體視覺化在某些情況下無疑是滿足的。但當資料開始變得複雜與龐大後，2D 的環境就明顯有點不足。3D 環境提供額外的一個維度來排序資料。而且透過轉移視角，將重要的元件放在肉眼的焦點上。不重要的物件可以暫時從肉眼中隱藏，或者放在較遠處。由於軟體動態性，導致 2D 的靜態圖無法全面呈現軟體的全貌。即使成功如 UML 也只能使用大量的圖形去描述一個片段的程式行為。. 因此 xDIVA 架構在 OGRE[21]這個 Open source 的 3D 引擎上。OGRE 是高. 21.

(22) 階物件導向的 3D 引擎，比起較低階的 OpenGL 和 DirectX 具有較低的設計門檻，可以降低相當多的程式開發時間。OGRE 提供相當多的特效，有助於增進視覺化的多樣性，提升視覺化的品質，來提供我們做出品質優良的 VM。另一個 xDIVA 使用 3D 的理由是為了使用動畫。3D 引擎皆可用來顯示一段及時的動畫，而不是單純的靜態物件。如前所述，軟體是具有動態行為的。在我們的想法裡，用靜態視覺化來表達動態的行為是缺乏的。. 3D 引擎具通常具有強大的互動和導覽性，藉由旋轉視角，漸進式地拉近拉遠自由自在的觀看可以獲得對系統整體架構的概念，相對的，2D 介面在這一點上就比較弱。使用者也可以 3D 環境裡輕鬆的展開或收合一個結構，觀看有興趣的部分，不但可以簡化畫面，也有助於程式設計師理解複雜的程式。. 但是，光使用 3D 還是不夠的，我們還必須處理資料和圖形的映對，因為程式和資料結構在各領域的多變和複雜性，讓單一視覺化要涵蓋所有程式設計師的興趣是不可能的。這也說明了為何理論上視覺化工具應該可以對軟體開發有很大的助益，但是視覺化工具卻還沒有能夠成為程式設計師每天必用的工具。以著名的 AT＆T 圖形視覺化 (graph visualization) 工具 Graphviz[18]為例，使用者想要利用 Graphviz 來將 graph 資料視覺化時，必須另外撰寫額外的程式碼將某個時間點的 graph 資料結構轉成 dot format。Graphviz 不嘗試去解決困難的圖形和資料. 22.

(23) 映對的問題，而將這部分留給使用者來解決。. 23.

(24) Chapter 3 xDIVA 架構 xDIVA 是建構在 windows 系統下的視覺化工具，xDIVA 主要由兩個部分組成，視覺化系統 DIVA 和其圖形化除錯前端 Minerva。DIVA 和其圖型化除錯前端 Minerva 的溝通是透過網路交換訊息。因為 Minerva 是由 JAVA 所撰寫完成，使得程式設計師可以在 Linux 系統下除錯程式，將視覺化結果呈現在 Windows 平台上。. 下圖是 xDIVA 的架構圖，xDIVA 具有相當多個重要元件，第一個是 Watched Object Pool Module(WOPM)，WOPM 儲存所有 DIVA 已視覺化的變數，指標，和物件。這些資料由 Minerva 取得，當中斷點改變時會改變其值。Minerva 負責通知 DIVA 程式狀態的改變，一個複雜的程序在這時後啟動來確保 WOPM 和除錯器的資料同步。. 用來處理同步的程序，就是圖 3-a : xDIVA 的系統架構圖中 Command Agent 元件，舉例來說，當接受到 visualize p 這個指令的時後，Command Agent 會送出一連串的指令向 Minerva 要求 p 的資訊，當資訊取得後，Command Agent 則在 WOPM 上建立一個物件。在 visualization metaphor 和 WOPM 之間有個重要的元件叫 mapping engine，它負責維持 WOPM 裡的物件和 VM 的映射，也允許使用者手動設定如何映射。 24.

(25) 以下我們將對 xDIVA 的各個元件逐一做介紹。. 圖 3-a : xDIVA 的系統架構圖. Section 3.1 Command Agent 當使用者決定視覺化一個變數 p 以後，他在 Minerva 上下達一個指令 Visualize p。Minerva 透過向除錯器(JDB 或者是 GDB)取得 p 的訊息，然後開始密集的與 DIVA 的 Command Agent 溝通，將 DIVA 所需的資訊透過網路傳到. 25.

(26) 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 清除。下圖 3-b :Minerva 和 Command_Agent 之溝通流程圖為 Command Agent 和 Minerva 溝通的流程圖。. 26.

(27) 圖 3-b :Minerva 和 Command_Agent 之溝通流程圖. Section 3.2 WOPM WOPM 是單純的資料結構，利用 TABLE 以及 Linked List 的方式，將所有透過 Command Agent 收集到的變數值，型態等內容儲存起來，並且記錄其中的關係。每一筆資料就是一個 wop_entry。大致上分成 primitive，array，object， reference 幾種 entry。每筆 wop_entry 至少包含以下內容 : 1.Boolean Top : 記錄此變數是否為起始 entry，或者是一個子 entry。 2.String Name : 變數的名字，如果沒有名字，則記錄其 hash code。. 3.Value. : 變數的值或者是變數的記憶體位置。. 27.

(28) 4.WOP_Entry*. Parent : 為一指標，如果不是起始 entry，則會指向其 parent. entry。. Section 3.3 DIVA UI 圖 3-c 是 DIVA 的執行畫面，DIVA 是建構在 Ogre 這個開放原始碼的 3D 引擎上，DIVA 透過 Diva Manager，管理所有繪製 3D 環境上的 VM。透過 Input Manager 管理使用者的鍵盤和滑鼠輸入，並將事件傳到對應的 VM 上，使用者可以透過點取一個 VM 去展開或者收合該 VM，或者拖移該 VM 的位置。右下角有 3 個按鈕分別是 Step，Next，Continue，使用者也可以透過點選這 3 個按鈕來跟 Minerva 溝通藉以改變中斷點的位置。. 圖 3-c : DIVA 執行視窗 28.

(29) Section 3.4 DIVA VM VM(Visualization Metaphor)，用圖形來表視資料的視覺化隱喻。面對軟體的龐大和複雜性，要定義一套完全的 VM 來視覺化所有的變數幾乎是不可能的事。所以最好的方法就是，讓 VM 可以很輕易的被修改以配合使用者的需求。為了讓 VM 可以輕易的被製作並修改，就必須讓 VM programming 的工作單純化。VM 設計師只需專注在 VM 的設計上，而不須在意整個 visualization tool 如何運作，資料如何取得，如何和 debugger 溝通，記憶體空間這些細微的瑣事。 DIVA 的 VM 是可由事件驅動的物件，像經由滑鼠拖曳和壓下。當事件發生後，VM 會以預先定義的行為來反應。舉例來說，當一個代表指標的 3D 物件被壓下後，我們可以選擇突顯它所指到的地方，並將畫面帶到該物件上。而為了完成這個功能，每個 VM 都繼承自某個基底類別，並包含這些方法 VMpicked()， VMdragged，VMvalueUpdated()等等。經過長久的研究，我們將基礎的 VM 定義為以下四種。其中本論文敘述的重點在於 Layout VM。. 1. Primitive type VM. 2. Reference type VM. 3. Composite VM 29.

(30) 4. Layout VM. Section 3.5 Layout VM Layout VM 是用來做 3D 空間重新排列用的。Layout VM 是用來呼叫所有的 VM 做排列的演算法。xDIVA 中，Layout VM 是透過右鍵來呼叫(通常是點擊樹的根節點或者是 graph 的初始節點)。舉例來說，使用者拖曳某個己在 xDIVA 視覺化的二元樹的節點導致排列不整齊後，透過從新觸發 Layout VM 可以將這顆樹做從新排列。. 計算 VM 碰撞也是 Layout VM 的一環，例如當有一個 VM 產生的 3D 位置上已具有另外其他 VM 的存在的時後，Layout VM 會將原來在 xDIVA 上的 VM 碰撞開來，讓新增的 VM 產生在預定的位置上，以避免同時有兩個 VM 重疊在一起的情形。. 本論文所要說明的，便是 Layout VM，關於 Layout VM 的規格及演算法的各項細節，我們將在後續的章節闡述。. Section 3.6 xDIVA 的 Layout 系統以下簡介本論文完成的 Layout 系統規格，詳細的演算法以及程式結構在後面的章節再作說明。首先，使用者可以通過對畫面上的 VM 物件點右鍵，呼叫出 Layout 選單。(如下圖) 30.

(31) 圖 3-d 在 DIVA 視窗中按右鍵呼叫 Layout 選單. 當使用者選擇了一種 Layout 之後，會先跳出一個 Dialog，讓使用者決定這次 Layout 的範圍，可以選擇想要產生關聯的 Pointer 變數名稱，要 Layout 的關係的層數，以及要以被動參考或者主動參考的關係產生效果。. 圖 3-e 決定陳列範圍的 Dialog. 決定好範圍之後，會跳出第二個 Dialog，這個 Dialog 是每個 Layout 特有的 Dialog，以 Spring Dynamic Layout 來說，會出現一個 Dialog 讓使用者決定彈簧 31.

(32) 的長度以及摩擦力與彈力係數。. 圖 3-f Spring Layout 的參數設定 Dialog. 當使用者決定好各種參數後，Layout 就被啟動了，以 Spring Layout 為例， xDIVA 系統上的 VM 物件之間將會按照使用者設定的參數產生彈簧力的物理系統，使用者可以透過與這個物理系統互動去了解資料結構之間關係的全貌。. 圖 3-g 彈簧力已作用在系統之中. 32.

(33) 圖 3-h 任何一個變動都將帶來連鎖反應. Section 3.7 xDIVA 的 Layout 系統結構 3.7.1 物件導向設計原則 xDIVA 具備與以往視覺化工具不一樣的特質。當面對無窮盡資料種類的視覺化問題時，xDIVA 的解決問題方法是學習人類的智慧。當面對無窮盡的建築物形狀時，人類先製造所謂的基本磚塊，然後建立基礎元件間的介面，再透過組合來完成工程。這種智慧可以分成 2 種設計原則來解釋，正交(Orthogonality)和合成(Composability)。首先，確立基礎的 VM 型別(有點像是設計基本磚塊種類)。再來分析如何提供一個介面來組合 VM 使其彼此溝通。促成 composability 的重要先決條件是資料與視覺化程式不能有任何的耦合(coupling)。. xDIVA 投入相當的時間和力氣在處理物件導向架構的設計，就是為了達成. 33.

(34) 正交性和組合性。在此架構下，VM 將可獨立運作或和其他 VM 合作組合出更複雜的 VM，且相依的 VM 是可以被替代的；而在 xDIVA 的觀念中，Layout 便是一種 VM 種類，它一樣必須俱備可獨立運作以及與其他 Layout VM 合作的能力。. 3.7.2 樣板設計模式樣版設計模式(Template Design Pattern)將一個演算法的骨架定義在一個方法中，而演算法本身會用到的一些方法則是定義在次類別中。樣板方法讓次類別在不改變演算法架構的情況下，重新定義演算法中的某些步驟。. 圖 3-i Template Design Pattern. 3.7.3 利用樣板設計模式我們使用樣版設計模式建立 xDIVA 的 Layout VM 架構，所有的 Layout VM. 34.

(35) 都繼承至一個基底的類別。如下列的程式碼 3.1，其中 layout 方法定義所有 Layout 演算法的骨架，而將其中計算 VM 新位置的部分交由次類別 doLayout 去實作，它可以讓未來 Layout VM 的設計者套用自己不同的運動方法來達到更多新穎的移動效果。除了個別演算法的部份，樣本設計模式也讓一般的 Layout VM 設計者不用再耗費心力製作所有 Layout VM 都會共用的部分。這些部分都會由基底的物件來進行實做。. 程式碼 3-1 LayoutVM 的基底類別. 其中，layout 這個方法會呼叫子類別實作的 initialFactors 與 doLayout：. 35.

(36) 程式碼 3-2. layout 呼叫子類別實作的 initialFactors 與 dolayout. 而 initialFactors 可以去初始化不同子類別需要的參數，doLayout 則是使用子類別之中不同的陳列演算法，如此達成了方便未來設計者的多樣化程式結構。. 3.7.4 陳列影響範圍 Layout_influence_area 要完成一個陳列方法，我們一定要先能夠定義陳列方法的範圍，在本論文中，便是 xDIVA 的 Layout 系統的陳列範圍，我們定義這個資料結構如下：. 程式碼 3-3 記錄整個物理系統母體的資料結構. 這個資料結構用來記錄整個 Layout 行為的母體，它記錄了整個 Layout 行為. 36.

(37) 的影響範圍（即畫面中可以被影響的 VM 物件）以及它們的二元關係（注意，這不一定是它們的 pointer 參考關係）。這個資料結構整理了 VM 物件之間的二元關係，我們可以藉由這個資料結構去找到陳列範圍內任一個物件可以關聯到的所有物件（getVMsLinkedByVM），也可以找到所有關聯到這個物件的所有物件（getVMsLinkToVM）。也藉由這個彈性的資料結構設計，我們最終完成這樣一個盡可能允許 Layout 設計者自由發揮想像力的架構。我們沒有限制一個 Layout 方法將要以何種關係關聯（可以不是 pointer 的參考關係）以及用何種方式呈現（不一定是位置的移動，也可以視大小或者顏色等等）。我們在 Layout_influence_area 中僅僅記錄物件的關係與實體，其中的關係可以是變數值相同或者指向同一個實體等等，只要設計者能夠利用程式說明它們「具有連結關係」，就能夠在 Layout 系統中達成各種互相影響的效果。而演算法部分設計者不只可以移動 VM 物件的位置，它可以對 VM 物件做出任何系統允許的改變（譬如改變物件大小或者顏色等）。. 3.7.5 Layout 的動畫系統動畫系統可以為一個 Layout 帶來動感以及視覺上的樂趣，在某些需要藉由時間軸表達含意的陳列方法上尤為重要。為了完成彈簧的動畫（雖然不是必要，. 37.

(38) 但如果彈簧沒有動畫，樂趣就少了很多），我們也在 DIVA 中建構了簡單的動畫系統。在目前的 DIVA 中，如果一個 Layout 設計者希望它的 Layout 也能有動畫效果，那麼他的 Layout VM 可以實做一個名稱是 Animable 的 Interface：. 程式碼 3-4 Animable. 其中 animation_behavior 方法是由動畫中心（程式碼 3-5 動畫中心）在每個 Frame 產生時會負責呼叫的方法，因此 Layout 設計者可以在這裡設計自己的動畫行為，不會一次性的被系統執行而過。. 程式碼 3-5 動畫中心. 動畫中心是一個管理所有實作 Animable 的類別物件的管理者。在每一個 Frame 產生時，它會藉由 animate 這個方法去執行所有向它註冊的動畫。因此， 38.

(39) 要使用動畫之前，你必須讓動畫中心知道你的存在，要向動畫中心註冊，可以在實作 Animable 的子類別的建構函式中加入一行程式碼向動畫中心註冊：. animationCenter::getInstance()->addAnimation(this);. 另外，在 animate 方法的傳入參數中有一個 avgFrameTime，它是平均畫面更新時間(Average Frame Time)，單位是秒，我們可以利用它管理動畫的速度，不至於因為系統或主機速度而影響了動畫速度。. 39.

(40) Chapter 4 Graph Layout Section 4.1 Graph Drawings Graph 是在電腦科學領域中重要的資料結構。，它能夠標示集合之中各元素之間的關係（Relation）與路徑（Path）。而 Graph 的表達方式也有很多種，例如矩陣、集合符號、圖畫（Drawing）等等，如。. 圖 4-a 左為矩陣表達法，右為圖畫. 其中圖畫表示方式最不容易良好地以自動化方法產生[22][23][24]，但卻是人類最容易理解的 Graph 表達方式。因為同樣的 Graph 在不同的需求與思考方式下需要的（被認為好的）陳列方式也不同[22][24]，我們無法事先預想出最好的圖畫陳列，更何況還要藉由事先被設計好的的電腦演算方式產生。. 而在電腦科學中，關於 Graph 的繪圖演算法相當多，判斷所謂的好與不好牽涉到很多不同的觀察角度與層面，但共同的瓶頸在於一旦資料數量龐大便有畫面雜亂且運算時間特別長的情況出現[22][25]；但很幸運地，在 xDIVA 系統的 3D 40.

(41) 環境之下我們比其它視覺化工具多出了額外一維的空間優勢。. Section 4.2 Graph 的陳列有很多的研究與工具相關於 Graph 的陳列[26]。以著名的工具 Graphviz[18] 為例，Graphviz 是一個可客製化的圖形編譯器，一種能夠完整呈現有向圖的視覺化工具。它可以在指令模式、網路端服務或者圖形化介面下執行。Graphviz 能以圖(graph)、節點(node)以及邊(edge)三種方式組合呈現出結果。Graphviz 擁有自己專用的敘述語言(DOT language)[19]，且使用十分嚴謹的排列演算法。使用者必須了解 DOT 的檔案格式與語法，Graphviz 會依照語法將資料以美觀與整齊的樣貌呈現，其演算法著眼於讓每個節點都不會重疊，而線也儘量不會跨過節點。. 在使用 Graphviz 來幫我們做排版之前，程式設計師必須要先針對想要排列的資料轉換成 DOT 語言，也就是說使用者必須自行處理資料內容與 graph 的基本元素 node 或 edge 之間的映射 (mapping)。假如圖形非常的複雜或是節點數量非常多的時候，因為 Graphviz 是屬於二維的視覺化工具，畫面中極有可能會佈滿了點跟邊(圖 4-b )，對於使用者在觀看時，在了解圖的架構或內容上，必須要多花一點時間。. 這樣的結果在某些應用是不盡人意的，但盤斷一個圖畫陳列方式的好壞與各種觀察角度和需求有關。有些研究也指出最好的陳列方式其實會依使用者習慣與. 41.

(42) 美感而有所不同[22]，因此本論文選擇更重視使用者的互動[23]，讓使用者可以參與陳列的行為，能夠自行調整視覺化物件陳列的方式。. 圖 4-b 節點數量多的 Graph 被 Graphviz 視覺化後的情況. 不同於 Graphviz 一次將物件陳列位置計算出來的靜態方式，我們也可以利用某些機制使資料與資料（或使用者）之間漸進式的互動與溝通，以動畫的方式讓物件一步步移動到合適的位置，譬如在 Java 上許多人使用的 Prefuse（2.2.2）。這樣的動態方式不僅可以避免因為資料太過複雜而使陳列演算法的運算時間過長，也不會產生一成不變的陳列結果（如圖 4-d）。. 然而欲使用 Prefuse，使用者仍然必須將自己的資料依照其 framework 之介面格式殖入，並且需要自行撰寫部分程式碼，在使用的便利性與彈性上稍有不足。. 42.

(43) 圖 4-c 同一個 Graph 在 Prefuse 中互動產生不同的結果. Section 4.3 xDIVA 中的 Layout 需求在 xDIVA 的使用經驗中，物件之間的 Pointer 參考關係大部分的時候會被視覺化為線狀的物體，而各物件之間複雜的 pointer 關係經過視覺化為線狀物後，. 43.

(44) 很自然地就形成了各種類似 Graph 的表達方式。在 xDIVA 的設計中，當這些資料結構中有新的物件被參考到時或者物件在 xDIVA 中視覺化的位置改變(可以想像為 Graph 的結構改變)時，使用者可以自由選擇適當的 Layout 演算法重新決定它們位置。在 xDIVA 中的這些 Layout 演算法各有用處，使用者可以依照需求選取。而本論文論述的是其中一項 Graph Layout 演算法：彈簧陳列。將在之後的章節再仔細的說明. 在工具的使用經驗中，使用者使用起來越輕鬆、直覺、方便是最好的。最起碼是讓使用者不需要花費太多時間去閱讀說明文件（這樣通常會大大地降低使用意願）。. 我們採取的方式是讓使用者能夠利用滑鼠拖曳（Drag）動作去拖拉 xDIVA 畫面上的物件（可以想像為 Graph 上的 Vertex）。雖然單純地只移動被拖拉的物件也可能是一種設計方式，但實用性顯然不高。而且對使用者而言，需要一個一個 vertex 進行拖拉動作以達到他所期望的排列未免太耗時費力。另一方面，Layout 作為 xDIVA 的一個子系統[1]，應具有其特色及達到幫助使用者理解的作用。因此，我們在單純的物件拖曳行為上加入了更直覺性的變化，可以幫助使用者理解各 Vertex 間的關係並且省去個別移動的時間。接下來，我們便開始介紹彈簧陳列。. 44.

(45) Chapter 5 Graph 的彈簧陳列方法彈簧陳列方法（Spring Layout VM）是本論文提出的一種陳列方式，它將物件之間的「關係」模擬為自然界中的彈簧，不但可以避免物件之間的碰撞，它也遵守虎克定理以及牛頓三大運動定律，讓 xDIVA 畫面中的移動事件能夠達到透過關係而互相牽引移動的效果。此外，我們也加入了動畫效果，可以清楚的觀察到在彈簧陳列啟動時，各物件的簡協運動和其它的彈簧行為。. Section 5.1 物理現象 5.1.1 移動的發生與物理學的計量誠如前一章節所言，我們期許 xDIVA 的使用者能夠在 xDIVA 的 Layout 系統的輔助下經由自己的想法去移動畫面中的物件，輕鬆簡單的達到自己心目中的排列方式。. 當使用者拖拉畫面上的一個可移動的物件時，該物件想當然耳，將會移動。但我們希望這個移動事件發生時，我們可以為使用者做的更多：也許使用者希望畫面中與該物件有參考關係（二元關係）的物件可以一起被移動，如此物件的關係可以一目了然，更迅速的了解資料並省去一一進行拖拉的心力。或者，也許使用者希望物件之間彼此不要重疊，我們也可以在移動物件的過程中幫助使用者避. 45.

(46) 免之。當然，我們不預設使用者需要任何多餘的功能，使用者可以任意啟動或者關閉這些輔助功能。. 為了達成這些物件移動的相關功能，我們必須更深入解析物件的移動。在本論文中，我們將使用物理學的計量方式去分析物件的移動。. 5.1.2 位移. 圖 5-a 「位移」的示意圖. 在物理學上，位移指的是目前點（目前位置）與參考點（舊位置）的差異，是一個向量。位移的大小等於參考點到目前點的直線距離，方向從參考點指向目前點。. 5.1.3 速度當參考點是物體的舊位置時，位移向量表示出物體運動的狀況：向量由舊位置指向目前位置。這種用法能夠定義物體的速度向量與加速度向量。在物理學上，我們通常使用ｖ代表速度。位移隨時間的變化率即是速度，或者說是，單位時間內的位移。 46.

(47) 5.1.4 加速度如同位移與速度的關係。我們可以將加速度解釋為「速度隨時間的變化率」或者，單位時間內的速度變化。在物理學上，我們通常使用ａ代表加速度。. 5.1.5 資料結構：位置移動狀態 PositionMoveState 很顯然的，以上的物理現象都可以關聯到 VM 物件位置移動的變化。因此，我們也需要利用一個型別去說明「位置移動」，當然，它必須能夠表達一個移動的方向與大小：. 程式碼 5-1 記錄物件移動狀態的資料結構. 這個資料結構是用來記錄物件移動的狀態，Vector3 代表三維的向量型態，其中變數 direction 為這個移動的方向，是一個單位向量；vel 是速度的量度，即移動的快慢，單位時間內移動量的大小。而這個資料結構的變化即可表達加速度。. Section 5.2 力的發生與傳導利用上一節的物理計量方式，我們可以分析在 xDIVA 畫面中所有的物體移. 47.

(48) 動。而在這一節，我們要了解移動中的物體間相互的作用關係。. 5.2.1 力在物理學上，力（Force，物理上的簡寫為 F）是指物體之間的相互作用或相互牽引的作用。力會改變一個自由物體的運動狀態，即改變自由物體速度的大小或方向。. 由此我們可以得知，當一個物體的移動狀態改變（速度向量改變，即有加速度），它必然是受到力的作用了。我們更可以推論：使用者拖拉 xDIVA 畫面中的物件而改變該物件的移動狀態，便是一種對該物件施力的行為。而這個力還可以透過二元關係去傳導，去影響其它物件的運動狀態。. 5.2.2 資料結構：力與移動有了移動狀態之後，我們當然還需要記錄這個移動狀態的來源（力）以及承受運動狀態的主體，我們使用一組力的連結（即施力者與受力者）來表示：. 程式碼 5-2 Link. 其中 fromVM 是這一個連結(Link)中的施力者，因某種因素產生加速度而施. 48.

(49) 力於另一端物件的 VM 物件，而 toVM 便是再另一端受力的 VM。我們單純將其解讀為一個力的施力者與受力者。然後，我們就可以將一個移動處理的整體表示成：. pair<Link*, PositionMoveState*>. 便詳細記錄了一個力（施力者與受力者）和這個力作用在目前受力者所造成的移動狀態。而一群移動的發生就可以用使用 C++ STL 的 map 去管理：. map<Link*, PositionMoveState*> anis;. anis 代表的是動畫 animations，因為速度與移動需要不間斷、平滑的處理，這種行為是動畫行為，我們必須交由動畫系統去處理。. 接下來，我們將說明本論文所實做出的一種力的產生與傳導方式：彈簧（虎克定律），也是 xDIVA 目前提供的一種力的傳導方式。. 5.2.3 彈簧與虎克定律（Hooke's law）提到虎克定律就會想到彈簧(圖 5-b 彈簧)，因為虎克定律應用最常見的例子就是彈簧。在彈性限度內，彈簧的彈力 F 和彈簧的長度變化量 x 為線性關係，即是著名的虎克定律： F = − kx. 49.

(50) k 是彈簧的彈力係數，由彈簧材料與外形所決定，數值越大則彈簧越難以變動其長度（由另一面來看，同樣的長度變動可以產生更多的力），負號則代表彈簧所產生的力與其伸長或壓縮的方向相反。. 圖 5-b 彈簧. 在本論文中，彈簧將成為我們探討的力的傳導工具，我們假設 xDIVA 畫面中各物件之間的二元關係為彈簧，這些彈簧都有一個初始的長度（使用者可以自行設定），單使用者拖拉畫面中任何一個物件時，物件隨著滑鼠游標而移動，而因為物件的移動而造成的彈簧一端長度改變（其值可推算並量化使用者拖拉物件的「力」），所造成的彈力將會影響二元關係裡的另一端的物件使之移動，造成一環又一環的牽動，形成力的傳導。. 5.2.4 方法：產生彈簧力 crateSprForceFromVMtoVMs 首先 createSprForceFromVMtoVMs 這個方法永有兩個傳入參數，第一個是彈簧力產生的主體，是施力者；第二個參數則是被施力者（受力者），可以為多個。由方法名稱我們可以知道這個方法是要計算出施力者對受力者們的彈簧力 50.

(51) （其大小、造成的移動狀態）。這些力的基本將按照上一節提到的虎克定律產生，因此，我們必須先計算出彈簧兩端（施力者與受力者）的距離來了解彈簧的長度變化：（其中 vm 為施力者，infVM 為受力者） //計算目前的長度為新長度 float newL = computeDistance(vm->Position, infVM->Position); //新長度與彈簧長度的差距決定力的大小 float dL = newL - _spring_length;. 在知道了力的大小之後，我們還需要知道力的作用方向（移動方向）：. //兩個位置向量的差就是移動方向 Vector3 dV = vm->getPosition()－ infVM->getPosition(); //除以向量長度，得到方向的單位向量 Vector3 direct = Vector3(dV.x/newL, dV.y/newL, dV.z/newL);. 如此我們可以得到這個受影響的 VM 它應該產生的移動速度以及方向，如果配合牛頓第二運動定理（章節 5.4.4），我們就可以產生一個 PositionMoveState 配合兩個 VM 將這個移動加入 anis 參與動畫。. Section 5.3 牛頓運動定理在我們利用虎克定理量化使用者的拖拉行為對系統施加的「力」後，為了計算出各物件相對應的速度變化或移動，我們還需要了解「力」如何影響物體運動，以及自然界中的力如何將展現。. 51.

(52) 古典力學的靈魂人物伊薩克 · 牛頓（ Sir Isaac. Newton）(右圖)對此議題提出了三個在物理學上具有重要地位的運動定理，即著名的為「牛頓三大運動定理」。本論文將依照牛頓三大運動定理讓 xDIVA 系統能夠模擬自然界中的彈簧與低速運行的物體間的互動，以下三個小節將簡要的說明牛頓三大運動定理。. 5.3.1 牛頓第一運動定理牛頓第一運動定理指物體運動具有保持原來運動狀態的性質，又稱慣性定律。在所受外力之和為零的狀態下，運動中物體保持等速直線運動狀態，靜止物體總則保持靜止狀態。. 5.3.2 牛頓第二運動定理牛頓第二運動定律「物體的加速度 a 與物體所受之力 F 成正比，與物體的質量 m 成反比」的現象。而加速度的方向與所受力的方向相同。符合下列公式：. 5.3.3 牛頓第三運動定理牛頓第三運動定律又稱為作用力和反作用力定律。其意義是，任何力都必有反作用力，且作用力與反作用力的大小相等，方向相反，並作用在一直線上。 52.

(53) Section 5.4 牛頓運動定理的影響 5.4.1 牛頓第一運動定理的影響由於自然界物體有保持原運動狀態的特性，當所受之作用力改變時，在改變其運動狀態的同時必須考慮其原本之移動狀態的影響，而不是直接改變其運動狀態。原運動狀態的速度向量不會消失，將與新的速度向量做結合，其結合的方式為單純的向量相加：. 其中. 為該物體在指定時間點ｔ的最後運動狀態，. 為其原本之運動狀態。. 是目前作用力在物體上造成的速度，其值可藉由牛頓第二運動定理推導而出。. 5.4.2 方法：慣性定律--與前移動的結合在前一個小節中，我們為任兩個關聯的 VM 物件以它們的距離計算出彈簧力的影響，但為了不讓移動狀態（anis）不斷的增加，我們限制一個參考關係只能產生一個移動狀態，如果這個參考關係是第一次產生移動狀態，那就直接加入 anis。但如果同一個參考關係產生了第二個移動狀態，根據慣性定律，我們不能捨去前一個移動狀態，我們必須將兩個移動狀態作結合，這個結合很簡單，就是前一個小節的向量加法： 53.

(54) 以速度向量表示，實際上這些向量可能是作用力在某個時間點作用在物體上時的瞬間速度，也可能是已經消失的作用力所殘留的運動速度。我們在動畫之中僅僅關注物體在上一個動畫頁面與下一個動畫頁面的位移量，因此上述的向量加法中的速度皆是指作用力在每個動畫頁面產生的時間點上作用於物體的瞬間速度，是作用力在上一個動畫頁面中的速度，加上下一個動畫頁面產生時由演算法運算出的瞬間加速度而成。. 5.4.3 牛頓第二運動定理的影響. 如果我們將這個公式與虎克定理做結合，即： F = ma = - kx 經過簡單的數學轉換，我們可以得到彈簧型長度變化為 x 時，其受到來自彈簧的加速度 a 為： a = - kx / m 由於加速度(a)為單位時間內的速度(v)變化量，我們可以得知在某個時間點 t 時，力對物體所產生的速度變化 v 等於加速度 a 乘以經過的時間 t。最後，我們得出在某個時間點 t 時，彈力對物體所產生的速度變化 v 為： 54.

(55) v = at = (- kx/m) t = - kxt /m 到這裡為止，我們將物體的移動與彈簧力的作用關係大致上解析完成，我們已經可以運算出系統內物件在每個時間點的速度，並藉此決定它們在下一個應該擺放的位置。但我們不能因此而疏忽了，因為還有一個我們尚未考慮的定理。. 5.4.4 方法：利用第二運動定理算出彈簧力的加速度前面的章節中，我們已經得出虎克定律產生的力的量度大小，現在我們要將力的大小轉換為移動量的大小。牛頓第二運動定理告訴我們一個力作用的加速度大小與作用物體的質量有關，我們假設在彈簧系統中的 vm 物件都具有相同的質量 M，而得出加速度為下列結果。（雖然看似無意義，但是請注意，可能在未來的某些應用下，我們可能會將質量Ｍ對應到 vm 物件的變數而產生不同的效果） //計算目前的長度為新長度 float newL = computeDistance(vm->Position, infVM->Position); //新長度與彈簧長度的差距決定力的大小 float dL = newL - _spring_length; //牛頓第二運動定律,加速度依照F=kx=ma 的物理公式算出 float a = _spring_factor * dL / M;. 5.4.5 牛頓第三運動定律的影響作用力與反作用力定理在理解上較前面更抽像一點，沒有好的方法去用數學算式表達。在此，我們僅針對 xDIVA 中的彈簧力系統裡的物件行為去作反作用. 55.

(56) 力的應用說明。. 當 xDIVA 中一個物件發生移動造成彈簧的長度改變量為 x 時，這個物件使彈簧產生了大小為 kx 的回復力，由於使用者拖拉的物件為固定端，我們視為這個物體以 kx 大小的拉力去拉扯彈簧另一端的物件。在這個情況發生的同時，依據反作用力定律，另一端的物件也以吸同大小的力拉扯這個被移動的物件，由於被使用者拖拉的物件為固定端，因此我們僅僅看見另一端的物件被彈簧改變了其運動狀態。但，如果使用者不再拖拉這個物件，或者這個物件的移動非使用者拖拉所造成（簡而言之，其不為固定端），則它應受到另一端同樣大小為 kx 的拉力，即兩端的物體互相拉扯，且拉扯的力度相同方向相反。值得注意的是，以上說明的只是我們以兩個物件作用的觀點去探討作用力與反作用力而可以得到的一個簡易的結果。. 如果我們要更進一步的了解這個反作用力的來源，可以以彈簧的觀點來看，彈簧兩端的物體互相拉扯其實可以視為彈簧的回復力欲將彈簧回復原本的長度而拉扯兩端的物體，其中更加複雜的物理作用我們就不再討論，在這裡我們只關心與物件的移動有關的作用。. 5.4.6 方法：作用力與反作用力在使用者啟動彈簧陳列後，我們就會打開 xDIVA 的動畫機制，開始運算 56.

(57) Layout 範圍內的 VM 物件與其關聯物件的距離和彈簧長度的差異，產生彈力。在使用者啟動彈簧陳列的同時，系統會呼叫彈簧陳列的 doLayout 這個方法：(以下程式碼為簡化過的版本，我們捨去了程式碼中不重要的瑣碎部分，請注意紅色部分與註解). 程式碼 5-3 doLayout 方法. 在這個方法中我們可以看到：在針對一個 vm 物件計算其造成的彈簧力（身為施力者）後，我們會再加上因為牽引這個 vm 物件而產生的反作用力（身為受力者）計算。. Section 5.5 摩擦力即使最後停止對整個物理系統停止施力，物體的運動狀態指是保持不變，並. 57.

(58) 不能能夠回歸靜靜止，這樣的的結果通常不不是使用者者需要的（這這樣子物件件很容易跑出出畫面外外）。因此我我們必須加加入一種特殊殊的力—— —摩擦力。摩擦力，是是一種存在在於物體接觸觸面間一種種阻止物體運運動的作用用力。任何兩兩種物質質都可以有有摩擦力，不不一定是兩兩種固體。我我們假設在在 xDIVA 的的三度空間中中布滿了了某種物質質，使用者可可以自行決決定它產生的的摩擦力，甚至是沒有有摩擦力。. 摩擦力有有兩個特性，，其一是永遠遠與物體的的移動方向相相反，其二二是力的大小小永遠不不變。這說明明了摩擦力力是一種單純純的阻止物物體運動的作作用力，永永遠產生與物物體移動動方向相反反的加速度使使物體減速速，直到物體體靜止。其其大小為：. μ是摩擦擦面的係數，FN 為物體體對接觸面面的正向力，在本系統統中其為重量量，更可可以簡化為為質量，由於於我們不需要要更仔細的的去量化，所所以，我們們在此對 xD DIVA 的 Layout L 系統統的摩擦力做做一個總結結：移動中的的物件在有摩摩擦力的情情況下，將會會持續受到一一個與移動動方向相反的的加速度度，直到物件件停止不動動。摩擦力存存在本論文文的意義便是是這個阻止止物件持續運運動的反反向加速度度，而其大小小由使用者者決定。. 5.5.1 摩擦擦力加入位位置移動狀狀態前面說過過，摩擦力存存在本論文的的意義便是是這個阻止物物件持續運運動的反向加加速 58.

(59) 度。所以很顯然的，摩擦力也算是位置移動狀態的一環，雖然它在現實生活中的意義是一種作用力。. 程式碼 5-4 加入摩擦力的位置移動狀態. Vector3 代表三維的向量型態，其中變數 direction 為這個移動的方向，是一個單位向量；vel 是速度的量度，即移動的快慢；而 resist 則為阻止運動的力（摩擦力）所造成的反向加速度大小。. 5.5.2 動畫與摩擦力在 doLayout 這個方法（程式碼 5-3 doLayout 方法）執行之後，會產生很多的物件移動，在 anis 裡將會有資料出現，而動畫執行緒每隔一段時間就會呼叫 animation_behave 這個方法按照移動狀態裡的資料去移動物件。我們可以看到在這個程式碼（程式碼 5-5 animation_behavior 方法）中，系統將保存在 anis 裡的移動狀態都執行了一次，並且每移動一個物件就呼叫 doLayout 去從新計算移動狀態並計算摩擦力的影響，慢慢的使移動中的物件趨向靜止。 59.

(60) 60.

(61) 程式碼 5-5 animation_behavior 方法. Section 5.6 成果依照第五章的方法，我們運用第三章說明的彈性程式架構成功的建構出了一個符合虎克定律的彈簧力系統，其中物件的運行方式遵守牛頓三大運動定理。. 當使用者啟動彈簧陳列之後，他可以立即看到各物件之間的彈簧將它們推遠或拉近，漸漸地摩擦力將所有的物件靜止在自然的位置。使用者只要變動其中一個彈簧系統中物件的位置，依照其拖曳滑鼠的速度與方向，將會造成不同的彈簧 61.

(62) 長度變化，產生的彈簧力將會帶給彈簧系統不同的能量與不同的變動方式。. 圖 5-c 彈簧陳列的效果(連環圖的時間順序為左至右，上到下). 圖 5-c 彈簧陳列的效果(連環圖的時間順序為左至右，上到下)裡，我們將一個節點往畫面的左上方拖拉，這個節點帶動了與它連結的節點，其中彎曲的線也說明了這些節點帶有簡協運動的移動軌跡。. 62.

(63) Chapter 6 結論與未來工作 Section 6.1 結論我們在 xDIVA 之中建構了彈性的 Layout 系統，並實作出用於 Graph 陳列並含有動畫呈現的彈簧陳列法。這個陳列法可以做為未來 xDIVA 陳列設計者的參考樣本，它示範了如何使用動畫與彈性架構，以及如何運用物理方法。. 與傳統的靜態的 Graph 陳列相比，彈簧陳列法更注重與使用者的互動，在節點素量龐大的情況下，彈簧陳列法不會為了一次性地讓 Graph 完美陳列而耗費大量時間，也讓使用者有了更多的空間去自行調整。並且，使用者可以利用彈簧力牽引想要同時移動的節點，當一個 Graph 擁有複雜的結構甚至是擁有許多各自獨立的子 Graph 時，一個滑鼠拖曳就能清楚的了解節點之間的路徑關係。另外，彈簧陳列方式在文中被歸類為 Graph 的陳列方式僅因方便說明與了解。在 xDIVA 之中，即使使用者的 pointer 參考關係（或者其他連結方式）不被視覺化為線狀物體，彈簧陳列仍然是可以作用的，其演算法沒有指定的資料形式，符合 xDIVA 的正交性的設計概念（斷絕與資料結構的相依性）。利用動畫在節點之間加入物理應用可以更生動地協助使用者了解各種類 Graph 的視覺化物件，提升吸收資訊的速度。彈簧力不一定是最好的方法，我們. 63.

(64) 期待 xDIVA 的 Latout 系統能夠提供更多的選擇以因應更多的需求，也期望未來 xDIVA 的 Layout VM 設計者能夠設計出更有助於理解、更有趣的 Layout 方法。 xDIVA 的 Layout 系統仍在發展階段，希望本論文的彈性架構能夠幫助 Layout 系統的成長，讓未來的開發者能夠在我們建立的彈性程式結構上更順利的實現自己的演算方式。最後，我們希望 xDIVA 成為一個具備實用性與創新技術的軟體工程工具。未來將視研究的結果，把 xDIVA 以 open source 的形式推廣到學術界以及產業界。對於學術研究及其他應用方面預期之貢獻。. Section 6.2 未來工作 xDIVA 的 Layout 系統仍然有一些缺乏彈性的部分，最明顯的便是我們使用的 Dialog，目前 Layout 系統使用的 Dialog 並不是動態的，這將造成未來設計者的不便。在 xDIVA 的 Layout 系統的規畫裡，我們不準備讓 Layout 設計者為了自己的陳列方法必須做出自己的 Dialog （這代表設計者必須了解一點 Win32 SDK），而提高了設計者的門檻。譬如圖 3-e 決定陳列範圍的 Dialog），我們只提供了關於物件之間參考關係的選項。但是陳列範圍不一定是以參考關係作為依據，如果設計者不希望使用參考關係做為陳列的連結，那麼就需要自己另外去作 Dialog 了。未來，我們將會把這些 Dialog 設計為彈性的，動態的讀取設計者定義的敘述資料而改變。. 64.

(65) Reference [1] Yung-Pin Cheng, Jih-Feng Chen, Ming-Chieh Chiu,Nien-Wei Lai, and Chien-Chih Tseng. xDIVA: A debugging visualization system with composable visualization metaphors. In Proceedings of ACM SIGPLAN International Conference on Object-Oriented Programming, Systems, Languages, and Applications, 2008, Nashville, USA. [2] T. Biedl ,McGill University. J. Marks,MERL. K.Ryall University of Virginia. S.Whitesides, McGill University. Graph Multidrawing: Finding Nice Drawings Without. Defining. Nice. TR-98-15 October 1998. MITSUBISHI. ELECTRIC RESEARCH LABORATORIES CAMBRIDGE RESEARCH CENTER. . [3] F. P. Brooks, No Silver Bullet – essence and accidents of software engineering, Proceedings of the IFIP Tenth World Computing Conference, Page: 1069-1076, 1996 [4] http://en.wikipedia.org/wiki/Unified_Modeling_Language [5] Steven P. Reiss, An Overview of Bloom, Department of Computer Science Brown University [6] M. Lanza, CodeCrawler – An Extensible and Language Independent 2D and 3D Software Visualization Tool, In Tools for Software Maintenance and Reengineering, page: 74 – 94, RCOST / Software Technology Series, Franco Angeli, 2005 [7] http://en.wikipedia.org/wiki/Software_metrics 65.

(66) [8] J. B. Rosenberg, How Debuggers Work: Algorithms, Data Structure, and Architecture, ISBN: 0-471-14966-7, John Wiley & Sons, 1996 [9] A.. Kolawa,. Parasoft,. The. Evolution. of. Sofrware. Debugging,. http://www.parasoft.com/jsp/products/article.jps?articleID=490 [10] B. Lewis, Debuggin backwards in time, in M. Ronsse, K. De Bosschere (eds), proceedings of the Fifth International Workshop on Automated Debugging, 2003 [11] H. Agrawal R. A. DeMillo and E. H. Spafford, An Execution-Backtracking Approach to Debugging, IEEE Software (1991), Page: 21-26, 1991 [12] P. Crescenzi, C. Demetrescu, I. Finocchi and R. Petreschi, Reversible Execution and Visualization of Programs with LEONARDO, Journal of Visual Languages & Computing, 11 (2000), pages: 125-150,2000 [13] R. M. Stallman, R. Pesch and S. Shebs, Debuggin with GDB: The GNU Source-Level Debugger, Copyright (C) 1988-2006 Free Software Foundation, Inc.http://www.gnu.org/software/gdb/documentation [14] The. Data. Display. Debugger. (ddd),. available. on. http://www.gnu.org/software/ddd [15] Steven P. Reiss and Manos Renieris, Demonstration of jive and jove: Java as it happens. In ICSE ’05: Proceedings of the 27th international conference on Software engineering, New York,NY,USA,2005 ACM Press [16] Wim De Pauw, Erik Jensen, Nick Mitchell, Visualization the Execution of Java Programs, IBM T.J. Watson Research Center 66.

(67) [17] Katharina Mehner. Javis: A uml-based visualization and debugging environment for concurrent java programs. In Software Visualization, pages 163–175, 2001. [18] Graphviz, http://www.graphviz.org/ [19] Emden Gansner and Eleftherios Koutsofios and Stephen North, Drawing Graphs with DOT, 2006 [20] J. Carlsson, Optimisation of a Graph Visualization Tool: Vizz3D [21] Projects using OGRE, http://www.ogre3d.org/wiki/index.php/Projects_using_ogre [22] T. Biedl ,McGill University. J. Marks,MERL. K.Ryall University of Virginia. S.Whitesides, McGill University. Graph Multidrawing: Finding Nice Drawings Without. Defining. Nice. TR-98-15 October 1998. MITSUBISHI. ELECTRIC RESEARCH LABORATORIES CAMBRIDGE RESEARCH CENTER. . [23] Tyson R. Henry Scott E. Hudson Department of Computer Science University of Arizona, Tucson AZ 85721 * . Interactive Graph Layout. UIST’91 Hilton Head, South Carolina, Pages 55-64. [24] David P. Dobkin *, Alejo Hausner t, Princeton University, Princeton, NJ 08544, dpd,[email protected]. Emden R. Gansner, Stephen C. North, AT&T Laboratories,. Florham. Park,. NJ. 07932,{erg,north}@research.att.com.. Uncluttering Force-Directed Graph Layouts. [25] Toshiyuki MASUI, Software Research Laboratories,SHARP.Corporation2613-1 Ichinomoto-cho, Tenri, Nara 632, Japan. Evolutionary Learning of Graph Layout Constraints from Examples. UIST ’94 Marina del Rey, California. Page 67.

(68) 103-108. [26] JOSEP D´IAZ, JORDI PETIT AND MARIA SERNA, Universitat Polit`ecnica de Catalunya. A Survey of Graph Layout Problems. ACM Computing Surveys, Vol. 34, No. 3, September 2002, pp. 313–356. [27] Prefuse, information visualization toolkit, http://prefuse.org/. 68.

(69)