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

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

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

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

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

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

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

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

包括樹(shù)

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

調(diào)用圖

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

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

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

自上而下的視圖

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

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

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

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

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

自下而上的視圖

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

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

指標(biāo)層

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

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

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

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

審核編輯：郭婷