長期以來，圖片往往比文字更能幫助開發(fā)人員理解復(fù)雜的程序和審查代碼，因此在軟件開發(fā)中程序可視化的使用很普遍。UML 和其他主要圖形形式的設(shè)計符號現(xiàn)在被廣泛接受為溝通軟件設(shè)計各個方面的最佳標準機制。一些基于模型的設(shè)計工具可以直接從圖形表示中生成代碼。在非正式的范圍內(nèi)，開發(fā)人員經(jīng)常畫出流程圖或調(diào)用圖來告知自己或其他人軟件的重要方面。

UML 圖都非常適合設(shè)計，但在開發(fā)過程的后期用于幫助開發(fā)人員理解現(xiàn)有代碼時會遇到兩個重要的缺點。首先，作為設(shè)計抽象，它們（正確地）省略了一些實現(xiàn)細節(jié)，但如果目標是理解完成的軟件，這些細節(jié)通常很重要。其次，設(shè)計圖在實現(xiàn)方面經(jīng)常是陳舊的，導(dǎo)致對實際存在的系統(tǒng)的描述不準確或不完整。

非正式的可視化往往是短暫的，很少進入程序文檔的正式記錄。

很多時候，開發(fā)人員必須使用的唯一工件就是代碼本身。不幸的是，代碼可視化工具在歷史上一直存在圖表混亂和難以擴展到大型程序等問題。然而，正在出現(xiàn)的新工具正在開始解決這些問題。這些工具的主要優(yōu)勢是它們能夠直接從代碼本身生成有用的可視化。因此，它們保證是準確和最新的。

程序結(jié)構(gòu)

程序由許多不同類型的組件之間的龐大而復(fù)雜的依賴網(wǎng)絡(luò)組成。試圖同時顯示所有這些的可視化將太笨重而無用。事實上，沒有單一的理想可視化。相反，對特定任務(wù)最有用的可視化是與執(zhí)行該任務(wù)的工程師使用的心智模型相對應(yīng)的可視化。一些更有用的程序結(jié)構(gòu)如下：

類型層次結(jié)構(gòu)

開發(fā)人員通常發(fā)現(xiàn)了解數(shù)據(jù)類型相互關(guān)聯(lián)的各種方式非常有用。標準的 UML 類圖以一種非常容易理解的形式表示類層次結(jié)構(gòu)，其關(guān)聯(lián)和包含關(guān)系處于比代碼更高的抽象級別。雖然從設(shè)計的角度來看這很好，但程序員通常會發(fā)現(xiàn)查看類型之間的具體關(guān)系更有幫助。

包括樹

C 和 C++ 程序通常會大量使用預(yù)處理器。如果做得好，這可以使程序易于理解，但通常它會插入一個阻礙理解的層。不規(guī)范地使用預(yù)處理器可能會導(dǎo)致依賴纏結(jié)，從而導(dǎo)致構(gòu)建問題并損害可重用性潛力。因此，能夠查看哪些文件包含在哪里可以幫助工程師解開復(fù)雜的依賴關(guān)系。

調(diào)用圖

調(diào)用圖，其中每個節(jié)點代表一個子程序，每條邊表示對另一個子程序的一個或多個調(diào)用，通常被認為是最有助于可視化的程序結(jié)構(gòu)。子程序是方便開發(fā)人員推理的單元，調(diào)用關(guān)系很好地捕獲了數(shù)據(jù)和控制流。即使是一個小程序的調(diào)用圖也可能有數(shù)百個節(jié)點和數(shù)千條邊（見側(cè)邊欄 1），因此人們早就認識到一次可視化整個調(diào)用圖基本上是沒有用的。相反，研究人員專注于將調(diào)用圖可視化為更小、更容易消化的部分。

新的調(diào)用圖技術(shù)和工具

由于調(diào)用圖在程序理解中的重要性以及可視化它們所涉及的挑戰(zhàn)，它們一直是許多研究的主題。特別是，已經(jīng)開發(fā)出新技術(shù)來幫助控制調(diào)用圖的復(fù)雜性。本節(jié)介紹了在提供高級可視化功能的靜態(tài)分析工具中實現(xiàn)的一些機制。

自上而下的視圖

調(diào)用圖的自上而下視圖有助于回答用戶問題，例如“該程序的高級組件是什么，它們的屬性和關(guān)系是什么？”

為了在程序理解的背景下解決這個問題，工具設(shè)計者從諸如谷歌地圖之類的地理地圖程序中汲取靈感。隨著用戶放大，更多細節(jié)開始顯現(xiàn)：首先是城市，然后是城鎮(zhèn)、村莊，最后是個別建筑物。顯示的細節(jié)級別與縮放級別相關(guān)聯(lián)。

程序由組件組成，這些組件本身又由較小的組件組成，依此類推，形成層次結(jié)構(gòu)；雖然直接調(diào)用關(guān)系是在低級子程序之間，但它可以投射到包含這些子程序的高級組件。在調(diào)用圖的自上而下視圖中，最高級別的項目是目錄。這些可以包含子目錄和文件的某種組合，然后這些文件將包含子程序。因此，從一個框到另一個框的邊僅表示包含在第一個框內(nèi)的子程序調(diào)用了包含在第二個框內(nèi)的子程序。

事實證明，這種方法在幫助開發(fā)人員更深入地了解程序方面非常有效。

在左側(cè)窗口中，用戶選擇了從組件find到組件gnulib的邊。此聚合邊緣匯總的函數(shù)調(diào)用顯示在右側(cè)的窗格中。右側(cè)窗口說明當用戶放大查看單個功能時會顯示更多細節(jié)。此縮放級別進一步說明了一個重要特性：開發(fā)人員能夠?qū)⒁晥D與代碼本身相關(guān)聯(lián)非常重要。因此，選擇其中一個函數(shù)會導(dǎo)致顯示該函數(shù)的源代碼。

自下而上的視圖

通常，開發(fā)人員會希望采用自下而上的方法。這有助于用戶回答諸如“這個過程做什么，它如何適應(yīng)程序的結(jié)構(gòu)，以及它是如何被調(diào)用的？”之類的問題。

例如，假設(shè)某個程序在特定功能中崩潰。為了找到崩潰的原因并計劃修復(fù)，開發(fā)人員可能會首先關(guān)注該單個函數(shù)，然后探索它的鄰近區(qū)域以查看它調(diào)用和調(diào)用的其他函數(shù)。以前在白板上手動完成，一個工具可以自動處理繪圖和布局的苦差事。

指標層

通過添加層來顯示各種指標的價值，可以增加可視化的實用性。圖 1 顯示了一個示例。這顯示了一個特別有用的可視化 - 樹狀圖。在樹狀圖中，節(jié)點的面積與度量標準成正比——通常是對項目大小進行編碼的度量標準。然后將子節(jié)點平鋪在頂級節(jié)點內(nèi)。通常不顯示邊緣。在這個例子中，每個項目的顏色強度編碼了靜態(tài)分析工具發(fā)出的代碼漏洞警告的數(shù)量。

圖 1：中型程序（大約 200 KLOC）的樹形圖。顏色的強度表示在每個部件中檢測到的靜態(tài)分析警告的數(shù)量。

從這個角度來看，很容易挑選出風(fēng)險最大的程序組件。樹形圖對于顯示深度嵌套的結(jié)構(gòu)非常有效，并且也非常適合前面討論的縮放范例，其中更多細節(jié)在更高的放大倍率下顯示。

當開發(fā)人員以交互方式使用它們來平移和放大和縮小，甚至添加和刪除節(jié)點和邊緣時，這些可視化是最有用的。如果沒有足夠的響應(yīng)，與這樣的界面交互可能會非常令人沮喪。顯示數(shù)百個節(jié)點和數(shù)千條邊可能是一個挑戰(zhàn)。

審核編輯：郭婷