劉 旭

(SAP中國研究院 商務(wù)智能部，上海 201203)

代碼依賴與軟件架構(gòu)緊密相關(guān)，代碼各模塊的相互依賴直接反映了高內(nèi)聚及低耦合的設(shè)計目標.在軟件開發(fā)過程中和軟件維護階段，對于代碼依賴的分析有助于降低不必要和不合理的依賴，適時重構(gòu)軟件以維護軟件架構(gòu)的穩(wěn)定性，減少程序錯誤，提高開發(fā)效率和降低維護成本[1].然而，隨著現(xiàn)代軟件代碼量的膨脹，代碼間的依賴關(guān)系日趨復(fù)雜，傳統(tǒng)的依靠開發(fā)人員經(jīng)驗進行代碼依賴檢查的方式效率較低，智能化的軟件開發(fā)嘗試在軟件開發(fā)過程中引入數(shù)據(jù)驅(qū)動的思想以改善開發(fā)體驗[2]，提高開發(fā)效率.

軟件架構(gòu)的設(shè)計，實現(xiàn)和維護最終依靠架構(gòu)師，開發(fā)和測試人員完成，而視覺是人類接受信息最主要的渠道.軟件可視化利用信息可視化和可視分析的方法進行軟件數(shù)據(jù)展示和分析，發(fā)掘數(shù)據(jù)的非結(jié)構(gòu)化信息.利用可視化方式對代碼依賴數(shù)據(jù)進行分析，有助于技術(shù)人員更快地發(fā)現(xiàn)依賴關(guān)系的變化，還可發(fā)現(xiàn)關(guān)系中蘊含的模式[3].針對代碼依賴設(shè)計并實現(xiàn)功能完善的可視化系統(tǒng)，重點是需要分析代碼依賴數(shù)據(jù)的特點，選取既能夠降低視覺復(fù)雜度，又便于進行交互的可視化形式.目前相關(guān)的工作多集中在對代碼依賴數(shù)據(jù)的提取和分析，對可視化部分的研究較少，已有的數(shù)據(jù)可視化分析強調(diào)統(tǒng)計結(jié)果，多使用傳統(tǒng)的散點圖，折現(xiàn)圖等統(tǒng)計圖表.本文的重點在于如何針對依賴數(shù)據(jù)本身使用不同的現(xiàn)代可視化形式，并改善其交互效果.

1 代碼依賴及軟件可視化

在現(xiàn)代軟件的開發(fā)中，無論使用過程式，函數(shù)式還是面向?qū)ο蟮能浖K組織方式，最終程序的執(zhí)行必然包括一系列方法的調(diào)用過程，這意味著代碼之間的依賴關(guān)系廣泛存在于軟件源代碼中.典型的代碼依賴一般存在于函數(shù)之間，文件之間和對象之間.在面向?qū)ο蟮拈_發(fā)方式中，繼承和方法調(diào)用是比較常見的對象之間產(chǎn)生依賴的原因.代碼依賴不可避免，但在軟件系統(tǒng)代碼量越來越龐大的今天，冗余的和破壞系統(tǒng)架構(gòu)的代碼依賴會增加代碼理解和維護的難度.開發(fā)，測試和維護過程中對于代碼依賴的自動化檢查已經(jīng)成為大型軟件系統(tǒng)研發(fā)的常見手段，最終目標是提高軟件代碼質(zhì)量.

軟件開發(fā)過程傳統(tǒng)上主要基于開發(fā)人員的經(jīng)驗進行.為了改進開發(fā)效率，需要引入數(shù)據(jù)驅(qū)動的方式，首要任務(wù)是充分利用開發(fā)過程中產(chǎn)生的各種數(shù)據(jù)，包括代碼依賴數(shù)據(jù).軟件可視化試圖在軟件工程領(lǐng)域應(yīng)用信息可視化與可視分析的發(fā)展成果，即結(jié)合人類視覺和計算機結(jié)構(gòu)化信息處理的優(yōu)勢[4]，使用人機交互的方式從數(shù)據(jù)中得出結(jié)論.

圖1 信息可視化流程

圖1 顯示的是信息可視化的一般流程[5].可視化的最終實現(xiàn)目標是可顯示，通常還帶有交互性的圖形.在數(shù)據(jù)的富集和增強階段主要對數(shù)據(jù)進行標準化，聚合，過濾，去除不需要進行可視化的維度.可視化映射的重點是視覺編碼，也就是如何從數(shù)據(jù)映射到位置，顏色等屬性.視覺編碼和布局算法往往和選取的具體可視化形式有關(guān).在數(shù)據(jù)分析已經(jīng)完成的情況下，可視化被作為數(shù)據(jù)挖掘的結(jié)果呈現(xiàn)方式，但在可視分析逐漸被視為大數(shù)據(jù)分析的重要方法的情況下[6]，高度交互性的可視化不僅是分析的結(jié)果，也是分析的手段，可以用于數(shù)據(jù)的再次獲取和分析.軟件可視化的關(guān)鍵在于使用適當?shù)碾[喻和交互設(shè)計，幫助技術(shù)人員進行分析推理，發(fā)掘隱藏在軟件數(shù)據(jù)中的模式，從而改善開發(fā)過程[7].

2 原型系統(tǒng)dpViz的設(shè)計

隨著智能化的發(fā)展和數(shù)據(jù)量的膨脹，在企業(yè)軟件開發(fā)中越來越強調(diào)敏捷[8]，軟件研發(fā)的迭代周期越來越短.具有高度適應(yīng)性和完善開發(fā)框架支持的B/S模式逐漸成為信息系統(tǒng)應(yīng)用的主流，對于JavaScript，Python 等腳本語言的依賴與日俱增[9].JavaScript 是2017年GitHub 上最為流行的程序設(shè)計語言，廣泛應(yīng)用于前端和后端的企業(yè)軟件開發(fā)，擁有龐大的代碼基礎(chǔ).JavaScript 早期版本不具有模塊(module)的實現(xiàn)，ES6 雖然引入了內(nèi)置的模塊實現(xiàn)，但此標準出現(xiàn)較晚，目前大量的jQuery 等JavaScript 軟件項目多使用RequireJS 等第三方模塊加載器定義和管理模塊[10]，將每個文件定義為一個模塊，在模塊的開始部分定義模塊之間的依賴關(guān)系.

圖2 JavaScript模塊之間的依賴

圖2 是一個使用RequireJS 定義的JavaScipt模塊之間的代碼依賴示意圖，代碼示例取自jQuery.可以看到有的模塊同時依賴于幾個模塊，也有的模塊同時被其他幾個模塊依賴.模塊之間的依賴從結(jié)構(gòu)上說是一個有向圖[11]，但是在企業(yè)軟件開發(fā)實踐中，開發(fā)人員最關(guān)心的是如何快速定位依賴關(guān)系存在于哪兩個模塊之間，具體的依賴方向一般結(jié)合項目架構(gòu)和開發(fā)經(jīng)驗判斷，也可以由軟件開發(fā)者在修改代碼文件時查看，使用無向圖表示的代碼依賴已經(jīng)可以滿足大部分檢查代碼依賴的需要.

本文試圖實現(xiàn)的原型系統(tǒng)dpViz 以JavaScript 為目標語言，以RequireJS 定義的模塊為代碼依賴的單元.目標是以無向圖的方式可視化各單元之間的依賴關(guān)系，可視化形式需要帶有交互性以便于進一步分析.原型系統(tǒng)dpViz 針對代碼的靜態(tài)分析結(jié)果，和一般的信息可視化系統(tǒng)類似，同樣遵循數(shù)據(jù)獲取，數(shù)據(jù)結(jié)構(gòu)化處理，可視化布局和渲染等基本步驟.圖3 是使用SAP PowerDesigner 繪制的dpViz 組件圖.

圖3 dpViz 組件圖

從組件圖可以看到，dpViz 系統(tǒng)中各模塊之間的依賴較少，數(shù)據(jù)傳遞比較清晰，在獲取模塊依賴的原始數(shù)據(jù)之后，數(shù)據(jù)的結(jié)構(gòu)化和可視化都可以歸為可視化數(shù)據(jù)挖掘領(lǐng)域，可視化形式的確定是設(shè)計重點.開發(fā)人員最關(guān)注的代碼模塊依賴信息無疑是哪些模塊之間有聯(lián)系，模塊位于何處，這些聯(lián)系有什么特點.由于理論上任何兩個模塊之間都可能有依賴，模塊間的依賴關(guān)系具有典型的網(wǎng)絡(luò)數(shù)據(jù)特點，同時，模塊在文件系統(tǒng)中位于不同的路徑，路徑層次與功能模塊有關(guān)，模塊的層次關(guān)系也需要被顯示.在信息可視化系統(tǒng)的設(shè)計中，經(jīng)常組合使用多種不同的可視化形式以滿足用戶需要.dpViz的可視化形式選取了在信息可視化領(lǐng)域較為成熟的力導(dǎo)向(Force-Directed)節(jié)點連接圖[12]和層次邊聚合圖(Hierarchical Edge Bundles)[13].這兩種圖形對于網(wǎng)絡(luò)關(guān)系的可視化布局有不同的優(yōu)化方式.

3 原型系統(tǒng)dpViz的可視化布局

網(wǎng)絡(luò)數(shù)據(jù)可以借鑒圖論中常用的鄰接矩陣等方式進行可視化表示，但是節(jié)點連接圖可能是最為重要和常用的[14]，很多布局設(shè)計也參考節(jié)點連接圖，這是因為視覺系統(tǒng)對于位置這一視覺編碼最為敏感.節(jié)點連接圖使用較小的圖形表示每個節(jié)點，節(jié)點之間的關(guān)系用連接線表示.代表節(jié)點的圖形可以相同，也可以分別有不同的顏色或形狀以表示更多維度的信息.節(jié)點連接圖的缺點是當節(jié)點數(shù)量和連接線變多時，連接線和節(jié)點很容易互相交疊在一起，使圖形變得難以分辨.設(shè)計較好的布局算法可以減少這種情況.

力導(dǎo)向布局算法可能是最為常用的節(jié)點連接圖布局算法，其基本思想是將網(wǎng)絡(luò)數(shù)據(jù)中的節(jié)點對應(yīng)為現(xiàn)實中的帶同種電荷的小球，節(jié)點之間的連線對應(yīng)于彈簧，而畫圖的區(qū)域?qū)?yīng)于現(xiàn)實中的平面.當給定小球的初始狀態(tài)和彈簧長度之后，根據(jù)胡克定律，以彈簧連接的小球之間存在互相吸引或排斥的彈力，而各個帶同種電荷的小球之間存在庫侖斥力，因此這些小球會在這些力的作用下進行運動，一些小球會靠近，而一些小球會分開，這個過程會不斷重復(fù)下去.在平面存在摩擦力的情況下，力導(dǎo)向算法中的小球最后會逐漸趨于一個平衡位置，平衡位置的小球和彈簧即構(gòu)成獲得的布局.

在算法的具體實現(xiàn)過程中，一般會在物理模型的基礎(chǔ)上進行改進[15].由于結(jié)點距離較遠時，由胡克定律所確定的彈簧引力太強，可以使用對數(shù)法則c1×log(d/c2)來確定彈簧的引力，其中d是結(jié)點之間的距離，c1 與c2 都是常數(shù).在計算庫侖斥力時，由于庫侖力與距離的平方成反比，故可以使用c3/d2計算，其中d為結(jié)點間距離，c3 為常數(shù).算法對結(jié)點位移的計算也可以簡化，并且設(shè)置一定的迭代次數(shù)來完成布局.使用偽代碼表示的算法如下:

算法中的c1，c2，c3，c4 都是常數(shù)，一個常用的經(jīng)驗值是c1=2，c2=1，c3=1，c4=0.1.由于每兩個結(jié)點之間的斥力都需要被考慮，計算結(jié)點之間的斥力造成的位移需要的時間為O(n2)，而計算邊的引力給結(jié)點帶來的位移需要的時間為O(e)，如果此算法共進行k次迭代計算，那么需要的時間為O(k×(n2+e))，其中n為結(jié)點數(shù)，e為邊數(shù).圖4 是使用SAP Lumira的布局算法生成的典型力導(dǎo)向布局節(jié)點連接圖.可以看到，如果布局時給定的彈簧長度都是一致的，最后獲得的布局結(jié)果中，有連接的節(jié)點之間的連線長度會趨于均勻，而電荷之間斥力的存在會使無連接線的節(jié)點之間趨于分散，這樣節(jié)點的分布也會比較均勻，同時使整個圖形呈現(xiàn)對稱性.這種對稱性的特點是其他的布局方式難以保證的.

圖4 典型的力導(dǎo)向節(jié)點連接圖

力導(dǎo)向算法基于物理模型，物理特性保證了迭代結(jié)果收斂，所以此算法的行為容易預(yù)測和理解，代碼的實現(xiàn)也較容易，并且可以方便地擴展到三維空間.交互性也是力導(dǎo)向算法的明顯優(yōu)點.在布局的生成過程中，用戶可以看到結(jié)點集是怎樣從混亂的初始狀態(tài)展開成為比較具有可讀性的布局的，在繪制完成之后，還可以拖動一個或多個結(jié)點偏離平衡位置，看結(jié)點如何返回原位.力導(dǎo)向布局的這個特性讓它很適合用于繪制動態(tài)生成的數(shù)據(jù)的節(jié)點連接圖.但是，力導(dǎo)向算法在連接線較多的情況下，線和節(jié)點容易交叉，影響視覺效果.布局過程將改變圖中節(jié)點的位置，并且節(jié)點的位置在布局完成前不可預(yù)知，這使得力導(dǎo)向算法難以用于節(jié)點位置相對固定的場合.力導(dǎo)向算法的時間代價也較高.如果以n代表節(jié)點的數(shù)目，一般情況下，力導(dǎo)向算法需要n次迭代才能得到較穩(wěn)定的結(jié)果，即使不考慮邊的引力計算，力導(dǎo)向算法需要的時間復(fù)雜度仍為O(n3)，在結(jié)點較多的情況下，這樣的時間性能并不理想.

為了規(guī)避此布局的缺點，可以在實際使用的節(jié)點連接圖中加入過濾功能，減少顯示的節(jié)點和連接線的數(shù)量.在選中某個節(jié)點之后，用戶一般只會對于跟此節(jié)點關(guān)系密切的節(jié)點感興趣，例如在代碼依賴關(guān)系中，開發(fā)人員一般最關(guān)心的只是跟自己開發(fā)的那個模塊有關(guān)系的模塊.一種常用的過濾方法是對于某個選中節(jié)點，僅顯示該節(jié)點本身，子節(jié)點和二級子節(jié)點(子節(jié)點的子節(jié)點).圖5(a)是一個力導(dǎo)向布局的節(jié)點連接圖(局部)，其中高亮的節(jié)點僅有兩個子節(jié)點，但節(jié)點個數(shù)較多，布局密集，視覺效果不佳.圖5(b)是過濾后的結(jié)果(局部)，很容易從中看出依賴于高亮節(jié)點的子節(jié)點和二級子節(jié)點.

圖5 節(jié)點連接圖的過濾

層次邊聚合圖(Hierarchical Edge Bundles)在節(jié)點連接圖的基礎(chǔ)上嘗試用另一種方式來降低連接線的視覺復(fù)雜度，即聚合有一定關(guān)系的連接線成為線束，避免過多的連接線交叉[16].層次邊聚合圖在環(huán)形區(qū)域中用扇環(huán)顯示節(jié)點，不同層次的扇環(huán)代表節(jié)點之間的層次關(guān)系，節(jié)點之間的相對位置是固定的.根節(jié)點繪制在最外層(根節(jié)點必然是圓環(huán)，故往往省略根節(jié)點)，需要繪制連接線的節(jié)點都排布為葉節(jié)點，這樣連接線都將繪制在環(huán)形區(qū)域的邊緣.在扇環(huán)內(nèi)部用樣條繪制連接線表示葉節(jié)點之間的關(guān)系，樣條曲線的控制點位置跟父節(jié)點的位置有關(guān).這樣繪制的樣條曲線將根據(jù)節(jié)點位置的不同分別聚合成為若干線束[17].具有同一祖先的葉節(jié)點，其連接線會比較容易聚攏在一起，而關(guān)系較遠的節(jié)點，對應(yīng)的連接線會比較分散.線束的布局可以從一定程度上代表節(jié)點的層次關(guān)系，扇環(huán)的大小和顏色和連接線的顏色可以顯示更多維度的信息.圖6(a)是初始的節(jié)點連接圖，圖6(b)是轉(zhuǎn)換后的層次邊聚合圖，可以看到節(jié)點層次關(guān)系通過類似于Treemap (樹圖)的內(nèi)隱方式表達，減少了連接線的數(shù)量[18].

圖6 生成層次邊聚合圖

從設(shè)計上來看，層次邊聚合圖針對的還是網(wǎng)絡(luò)關(guān)系的數(shù)據(jù)，其思路是將節(jié)點連接圖中的網(wǎng)絡(luò)關(guān)系從語義上區(qū)分為兩種不同性質(zhì)的聯(lián)系:節(jié)點之間普遍存在的層次連接和僅存在于葉節(jié)點之間的網(wǎng)絡(luò)連接，將層次連接用扇環(huán)之間的層次關(guān)系表示，而葉節(jié)點之間的網(wǎng)絡(luò)連接用聚合線束表示.一般的網(wǎng)絡(luò)關(guān)系可以看作是這種網(wǎng)絡(luò)關(guān)系的特例，只需把所有節(jié)點看做是一個虛擬的根節(jié)點的葉節(jié)點，也可以使用這種布局方式繪制.

在JavaScript 項目的源代碼模塊組織結(jié)構(gòu)中，代碼模塊往往放置于不同的文件夾下，不同的文件夾代表了軟件架構(gòu)中不同的功能模塊.在這種情況下，代碼模塊之間具有網(wǎng)絡(luò)關(guān)系，而模塊與其所處的各層文件夾之間具有層次關(guān)系，各層文件夾可以被繪制為父節(jié)點，用父節(jié)點的顏色表示子節(jié)點的數(shù)量.在節(jié)點個數(shù)和節(jié)點之間連接線很多的情況下，可以考慮聚合葉節(jié)點的連接到最末一級或更高層次的父節(jié)點，將選定的父節(jié)點作為葉節(jié)點顯示，用連接線的顏色深度反映聚合的連接數(shù)量，這樣可以進一步減少連接線的數(shù)量.圖7(a)和圖7(b)顯示了聚合前后層次邊聚合圖的變化，可以看到父節(jié)點之間的關(guān)系更加清晰.

圖7 聚合葉節(jié)點

4 原型系統(tǒng)dpViz的實現(xiàn)

系統(tǒng)的實現(xiàn)首先需要考慮到模塊依賴數(shù)據(jù)的獲取和處理.在基于數(shù)據(jù)的應(yīng)用系統(tǒng)中，原始數(shù)據(jù)往往都是不規(guī)范的，會有很多空值，錯誤值，數(shù)據(jù)的規(guī)范化需要占用大量的系統(tǒng)資源[19].但是由于dpViz 系統(tǒng)需要的代碼依賴數(shù)據(jù)來自于代碼本身，可以通過程序化的方式獲取，這樣獲取的原始數(shù)據(jù)會比較容易規(guī)范化.dpViz 使用的方式是使用Java 語言讀取選定路徑下的JavaScript 文件，從JavaScript的define中解析出其依賴的模塊.在獲取依賴關(guān)系之后，可以進行一些基本的數(shù)據(jù)處理，例如排除重復(fù)的依賴項，將路徑中的”./”和”../”進行適當替換.處理完成之后獲得的基本對應(yīng)關(guān)系可以使用Java Swing中的JTable 控件來展示為圖8所示的二維表格(以jQuery 代碼為例)，便于用戶瀏覽和更改數(shù)據(jù).

圖8 用表格瀏覽依賴關(guān)系

數(shù)據(jù)結(jié)構(gòu)化處理和可視化部分是dpViz 系統(tǒng)的核心功能，dpViz 這部分的實現(xiàn)使用JavaScript 結(jié)合SVG 完成.JavaScript的執(zhí)行性能已經(jīng)可以滿足大型企業(yè)應(yīng)用的需要[20]，SVG 作為Web 矢量圖形的標準，以其跨平臺特性在可視化開發(fā)領(lǐng)域受到廣泛應(yīng)用[21]，為底層圖形的繪制提供了完善的支持[22].對于選定可視化形式布局的實現(xiàn)是系統(tǒng)的關(guān)鍵.使用SVG 進行開發(fā)可以使用的第三方庫有很多，其中的D3 作為數(shù)據(jù)驅(qū)動方式的可視化庫，已經(jīng)實現(xiàn)了很多數(shù)據(jù)處理和布局功能，合理利用D3 可以明顯提高可視化布局的開發(fā)效率.

在dpViz 可視化部分的具體實現(xiàn)中，先使用Java 將模塊依賴數(shù)據(jù)存儲為JavaScript 文件，寫入文件系統(tǒng)，然后使用JavaScript 在Web中載入這些數(shù)據(jù)文件，將二維數(shù)組方式存儲的數(shù)據(jù)結(jié)構(gòu)化為具有網(wǎng)絡(luò)結(jié)構(gòu)的JavaScript 數(shù)據(jù)對象，再根據(jù)數(shù)據(jù)對象進行布局并繪制.對于力導(dǎo)向節(jié)點連接圖的布局，在d3.layout.force中有完整實現(xiàn)，可以參考其算法并加以改進.層次邊聚合圖分為扇環(huán)和連接線兩部分.扇環(huán)的布局可以參考d3.layout.partition 函數(shù)實現(xiàn).扇環(huán)本身不是SVG 原生支持的基本形狀，需要使用path 繪制，具體過程可借助d3.svg.arc 完成.層次邊聚合圖的連接線可在扇環(huán)的布局確定之后，使用d3_svg_lineBasis 函數(shù)完成.

可視化的布局和繪制完成之后，還需要實現(xiàn)交互性功能以便于可視分析.由于在實際進行數(shù)據(jù)分析的時候節(jié)點往往較為密集，高亮鼠標盤旋或選中的某些圖形元素是交互性的基本要求.節(jié)點較多時，文字標簽往往只能縮略，高亮狀態(tài)下需要顯示完整標簽.對于力導(dǎo)向節(jié)點連接圖，需要允許用戶拖放各個節(jié)點改變布局效果，從而可以通過不同的布局方式分析數(shù)據(jù)特點，還需要實現(xiàn)僅顯示選中節(jié)點的子節(jié)點和二級子節(jié)點的過濾功能，便于針對特定節(jié)點進行進一步分析.層次邊聚合圖在可視分析中較實用的是調(diào)整連接線的聚合程度，鼠標拖放的旋轉(zhuǎn)和葉節(jié)點的聚合效果.這些都可以通過數(shù)據(jù)的過濾和布局的更新實現(xiàn).

圖9 使用dpViz 對某系統(tǒng)模塊可視分析

dpViz 已經(jīng)作為企業(yè)級軟件代碼依賴的可視分析工具試用，其分析結(jié)果對軟件開發(fā)工作顯示出實用價值.圖9 是將dpViz 用于分析某商務(wù)智能系統(tǒng)模塊過程中所生成的力導(dǎo)向節(jié)點連接圖和層次邊聚合圖 (為保護知識產(chǎn)權(quán)，圖中隱藏了文本標簽).從圖中容易看出，圖9(a)和圖9(c)的部分是模塊化較好的部分，這兩個部分節(jié)點較密集，但與其他部分依賴關(guān)系較少.圖9(b)的部分節(jié)點多而密集，連接線也很多，模塊化程度較差.圖9(d)是兩個與其他部分無關(guān)聯(lián)的孤立的文件，很可能是系統(tǒng)試驗性開發(fā)中留下的無用文件，應(yīng)該清除，通過進一步檢查源程序證明了這一點.圖9(e)的部分與其他模塊依賴較多，通過提高該部分的代碼性能和可讀性夠有效改善整個系統(tǒng)的代碼質(zhì)量.在可視分析過程中，可以發(fā)現(xiàn)力導(dǎo)向節(jié)點連接圖和層次邊聚合圖顯示出互補性.力導(dǎo)向節(jié)點連接圖交互性較好，允許用戶拖放改變布局，但在節(jié)點和連接線很多的情況下布局較慢，視覺復(fù)雜度高.層次邊聚合圖布局較快，對連接線較多的情況處理很好，但在交互性分析方面表現(xiàn)較差.

5 總結(jié)與展望

現(xiàn)代軟件代碼仍然主要由開發(fā)人員編制，而人傾向于反復(fù)在同一個地方犯錯，靜態(tài)代碼分析與檢測一直是消除軟件錯誤的重要方法[23].可視化以其高度的人機交互性，逐漸從海量數(shù)據(jù)的分析結(jié)果進化為分析手段.作為靜態(tài)軟件代碼可視化的一個重要組成部分，代碼依賴關(guān)系的可視化可以極大提高開發(fā)人員對于軟件系統(tǒng)的理解，提高軟件開發(fā)，測試和軟件再工程的效率.dpViz 作為代碼依賴可視化的嘗試，盡管使用的可視化形式還比較有限，支持的程序設(shè)計語言種類也較單一，但完整地設(shè)計并實現(xiàn)了代碼依賴可視化的各模塊，使用了力導(dǎo)向節(jié)點連接圖和層次邊聚合圖這兩種現(xiàn)代可視化形式，并創(chuàng)造了節(jié)點過濾和葉節(jié)點聚合功能，增加了圖形的交互性，系統(tǒng)的試用驗證了企業(yè)軟件開發(fā)效率的提升.

對于dpViz的改進，主要的方向可以是從代碼依賴特征入手，創(chuàng)造和改進更有效的可視化形式和交互方式.從軟件度量的角度看，代碼模塊包含的信息很多，針對大量高維網(wǎng)絡(luò)數(shù)據(jù)節(jié)點設(shè)計有效可視化方式一直是信息可視化的難點.對于不同的代碼模塊類型和不同的依賴方式，以及循環(huán)依賴，間接依賴等特殊依賴關(guān)系的可視化也是軟件開發(fā)過程中非常實用的軟件可視化功能.軟件生命周期是一個時間上動態(tài)的過程，通過軟件倉庫挖掘可以得到代碼依賴關(guān)系不斷變化和發(fā)展的數(shù)據(jù)，如何使用可視化工具分析這些數(shù)據(jù)的特點和趨勢也是有待解決的問題[24].隨著軟件開發(fā)社區(qū)的發(fā)展，代碼依賴的范圍并不局限于單個工程項目內(nèi)部，跨項目的代碼依賴可視化可能需要與單個項目不同的實現(xiàn)方法和目標.希望dpViz 對于代碼依賴可視化的努力能夠為進一步研究和系統(tǒng)實現(xiàn)提供思路.