Section 2.1 Visualization Tools
對於複雜的事物，人類可以經由圖表和動畫的表示，讓它變的更容易被理解。
大部分成熟的工程領域皆具有標準的藍圖來描述它的設計和產品。圖示的確可以 幫助人類解決溝通上的問題。軟體系統因為具備有不可見性，所以程式往往相當 令人難以理解。Brook[3]的書中有提到，不可見性讓程式設計變成一門相當難的 領域。所以，過去幾十年裡，軟體工程的研究一直在尋找方法試圖著用圖形來表 示程式。UML 就是在這樣的背景之下，成功的成為軟體工程的重要標準圖形。
另一方面，近幾年興起的軟體視覺化研究則著重於建構視覺圖案來表達軟體 系統的結構，大小及行為。這類的工具依據其對軟體的測量值來做視覺化，可以 在開發的初期用來表示軟體品質的好壞，並指出異常的地方以提供為管理的重要 依據。
另一類的視覺化軟體是提供執行期間軟體效能的視覺化，主要用來做效能的 測量，例如記憶體的使用，類別和方法所花費的時間。這類的軟體如 BLOOM[5]，
JIVE[15]，Jinsight[16]。有些則著重於使用 UML 圖來表示物件間的關係。像 JIVE，
JaVis[17]，雖然這類的軟體的意圖皆不同，但目的都是為了幫助程式設計師除錯，
以及更了解他們的程式碼。
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 所需的資料之後，再經過分析配對，
選擇適用的視覺模式表示出來，並提供選單讓使用者設定視覺化後圖形的大小和 位置等。
18
不過 BLOOM 主要是用來視覺化軟體的靜態特質，如類別的大小，數量等 統計資料，原則上是偏向軟體測量，跟 xDIVA 所要強調的 debug 功能並不相同。
BLOOM 提供數種 3 維空間的圖，在視覺化的過程當中，BLOOM 會自動去 選擇判斷合適的結果來呈現。由於，最後所產生的結果只顯示了許多顏色的區塊，
使用者必須先去熟悉每個圖的表示方式，才能懂得其所表達的結果(如下圖 2-a
BLOOM)。再者，由於 BLOOM 只提供了固定的幾種模式，加上又是由系統自動 配對結果顯示的，很有可能顯示出來的結果會導致不明。
圖 2-a BLOOM
2.1.2 Vizz 3D
跟 BLOOM 相似的是，Vizz 3D[20]也是用來做軟體度量的視覺化工具，經過 分析靜態的原始碼，可以在 3D 畫面上繪出該軟體的各個表向。它可以透過使用
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 、
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）。
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 是高
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 不嘗試去解決困難的圖形和資料
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 的映射，也允許使用 者手動設定如何映射。
25
以下我們將對 xDIVA 的各個元件逐一做介紹。
圖 3-a : xDIVA 的系統架構圖
Section 3.1 Command Agent
當使用者決定視覺化一個變數 p 以後，他在 Minerva 上下達一個指令 Visualize p。Minerva 透過向除錯器(JDB 或者是 GDB)取得 p 的訊息，然後開始 密集的與 DIVA 的 Command Agent 溝通，將 DIVA 所需的資訊透過網路傳到
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 溝通的流程圖。
27
圖 3-b :Minerva 和 Command_Agent 之溝通流程圖
Section 3.2 WOPM
WOPM 是單純的資料結構，利用 TABLE 以及 Linked List 的方式，將所有 透過 Command Agent 收集到的變數值，型態等內容儲存起來，並且記錄其中的
WOPM 是單純的資料結構，利用 TABLE 以及 Linked List 的方式，將所有 透過 Command Agent 收集到的變數值，型態等內容儲存起來，並且記錄其中的