軟件分析技術進展

軟件分析技術進展*資助*資助項目：國家重點基礎研究發(fā)展規(guī)劃973項目（No.2023CB320703)；國家自然科學基金委創(chuàng)新研究群體研究科學基金項目（No:60821003）；國家863高技術項目（No.2023AA01Z175)梅宏1王千祥1張路1王戟21.北京大學信息科學技術學院,高可信軟件教育部重點實驗室，北京1008712.國防科技大學計算機學院,并行與分布解決國防科技重點實驗室,長沙410073摘要軟件分析技術的研究已有較長歷史，相關成果也在軟件生命周期的不同階段中得到了廣泛應用。軟件生命周期中不同活動所需要的軟件分析技術既不完全相同，又有許多交疊，且不同的分析技術之間互相影響。文章在討論了軟件分析的基本概念之后，重要從靜態(tài)分析與動態(tài)分析兩個方面介紹了一些重要的軟件分析技術，以及部分相關分析工具。結合軟件的質量問題，文章還探討了一些分析技術與軟件質量屬性的相關性，以便于人們在分析特定的軟件質量屬性時，選取合適的技術與工具。最后，文章展望了軟件分析技術的發(fā)展趨勢。關鍵詞軟件分析，靜態(tài)分析，動態(tài)分析，軟件質量中圖法分類號 TP301引言軟件是一種十分特殊的人工制品：它是人類“智力活動”的產物，是對客觀事物的虛擬反映，是知識的固化與凝練。盡管軟件迄今已有50數年的發(fā)展歷史，但目前人們對于軟件的許多結識還十分有限。例如：對于任何一個給定的軟件，我們能否完全了解它的特性？軟件分析就是一個以軟件特性為關注點的研究領域?！胺治觥保ㄋ讈碚f，是以某種方式將復雜對象分解為更小的部分，以更好地理解該對象的過程。分析技術很早就被應用于數學、邏輯等方面的研究，近代以來逐步被更多的學科（例如：化學、物理等）所大量采用。軟件作為一個新發(fā)展起來的學科，在研究過程中引入分析技術是十分自然的。目前軟件生命周期中的許多活動（分析、設計、實現(xiàn)、測試、部署、維護等）都離不開分析技術。然而，軟件分析的能力是有限的：對于任何一個有一定規(guī)模的軟件，希望獲得關于它的完備描述通常是不現(xiàn)實的[18]。特別是，對于自動分析而言，許多問題是不可鑒定的。其中最典型的例子是停機不可鑒定問題：不存在一個這樣的算法，對于任意的圖靈機以及任意的輸入，可以判斷該圖靈機是否停機[64]。但從軟件分析這么數年所取得的進展可以看出，盡管軟件分析的能力有限，它仍然是軟件領域十分有用的技術：將程序從高級語言向機器語言的翻譯過程需要分析，判斷一個程序是否符合需求規(guī)約需要分析技術，想了解程序是否存在安全漏洞需要分析技術，維護過程更是需要大量的分析技術，等等。本文將軟件分析定義為“對軟件進行人工或者自動分析，以驗證、確認、或發(fā)現(xiàn)軟件性質（或者規(guī)約、約束）的過程或活動”。下面對上述定義中幾個術語進行解釋。一方面是“軟件”：軟件最初重要是指程序，后來逐步擴大到文檔等其它形態(tài)軟件制品。軟件分析也從程序分析發(fā)展到了更大的范圍，例如：對文檔（含需求規(guī)約、設計文檔、代碼注釋等）的分析、對運營程序的分析，等等?！白詣印币彩呛苤匾母拍睿很浖治龅臍v史幾乎與軟件的歷史同樣長：自從有了軟件就有了軟件分析。最初的分析重要是人工進行的，但人工分析往往需要花費大量的時間與精力，因此，后來人們越來越多地關注自動分析。其中，編譯技術的發(fā)展大大帶動了軟件的自動分析技術，目前的許多分析技術都可以在編譯技術中找到基本雛形。所謂“驗證”（Verification），是要回答“軟件制品是否與軟件需求規(guī)約一致”的問題，而“確認”（Validation）則要回答“軟件的特性是否符合用戶需求”的問題。在英文中，人們經常用“Dothethingright”來解釋“驗證”，而用“Dotherightthing”來解釋“確認”。“發(fā)現(xiàn)”（Discover）是指在沒有事先設定軟件某個性質的前提下，通過度析發(fā)現(xiàn)軟件的某種性質。之所以強調“性質”，是由于分析的結果通常表達為軟件是否符合或者具有某種性質（或者規(guī)約、約束），而這種性質不是軟件自身自明的。在本文討論的軟件分析中，分析對象僅限于軟件制品，不涉及對軟件過程、軟件人員與軟件組織等的分析。目前與軟件分析相關的綜述性文獻中，多數只對軟件分析的一個子集進行比較進一步的介紹。例如[1]集中在對源代碼分析的介紹，[2]重要介紹形式化的分析方法，[53]著重從語義的角度介紹程序分析，[54]集中在模型為中心的程序分析上。本文在這些工作的基礎之上，嘗試對軟件分析涉及的重要方法進行盡也許全面的總結、分類。此外，考慮到近年來軟件質量為人們所熱切關注，本文在介紹分析技術之外，特別關注那些與質量相關的分析技術，并結合不同的軟件質量屬性，探討不同的質量屬性適合運用什么類型的分析技術。最后，文章結合軟件形態(tài)、軟件運營環(huán)境等幾個驅動力對軟件分析技術的發(fā)展趨勢進行展望。軟件分析技術軟件分析通常是此外一個更大的軟件生命周期活動（例如：開發(fā)、維護、復用等）的一部分，是實行這些過程的一個重要環(huán)節(jié)：a）在開發(fā)階段，對正在開發(fā)的軟件進行分析，以快速地開發(fā)出高質量的軟件，例如：了解開發(fā)進展、預測開發(fā)行為、消除軟件缺陷、程序變換等等；b）在維護階段，對已經開發(fā)、部署、運營的某個軟件進行分析，以準確地理解軟件、有效地維護該軟件，從而使軟件提供更好的服務；c）在復用階段，對以前開發(fā)的軟件進行分析，以復用其中有價值的成分。上述各過程差異較大，需要的分析技術也多種多樣。這導致目前的軟件分析內容十分豐富，且互相之間的界線也不甚清楚：有些分析過程需要此外某個或某些分析的支持；有些分析針對具體的性質開展，而有些分析方法則可以支持多種性質的分析。軟件分析分類為了對軟件分析有個比較全面的了解，對其進行合理的分類是十分必要的。對軟件分析進行分類的維度有很多。其中，分析對象是最重要的準則之一，即軟件分析是對什么制品進行分析？從大的方面看，軟件分析可以對代碼進行，也可以對模型（需求規(guī)約、設計模型、體系結構等）、文檔甚至注釋進行。代碼可以進一步分為源碼與目的碼，目的代碼又具有靜態(tài)與運營態(tài)兩種存在方式，而運營態(tài)的代碼又可以進一步區(qū)分為離線的運營與在線的運營。除分析對象維度之外，還可以從方法學（結構化軟件、面向對象軟件、面向構件軟件等）、并行限度（串行軟件、并行軟件）等其它維度劃分軟件分析的內容。本文一方面以分析過程“是否需要運營軟件”為準則，將軟件分析技術劃分為靜態(tài)分析技術與動態(tài)分析技術兩大類，然后又在每一大類技術下面做進一步的劃分。圖1是綜合考慮靜態(tài)、動態(tài)分析技術給出的一個分析過程示意圖。圖1靜態(tài)分析與動態(tài)分析的基本過程靜態(tài)分析靜態(tài)分析是指在不運營軟件前提下進行的分析過程。靜態(tài)分析的對象一般是程序源代碼，也可以是目的碼（例如JAVA的bytecode），甚至可以是設計模型等形態(tài)的制品。靜態(tài)代碼分析重要可以應用于如下幾個過程：1）查找缺陷，以消除軟件中存在的缺陷；2）程序轉換，以實行編譯、優(yōu)化等過程；3）后期的演化與維護；4）動態(tài)分析，等等。根據各種分析方法使用的廣泛限度以及分析方法的相近性，本文將重要的代碼靜態(tài)分析劃分為四類：基本分析、基于形式化方法的分析、指向分析與其它輔助分析（見圖2）。其中，基本分析是一些常見的分析，例如語法分析、類型分析、控制流分析、數據流分析等，是多數編譯器都包含的分析過程（詞法分析由于相對簡樸而沒有引入）；而基于形式化方法的分析則在分析過程中大量采用一些數學上比較成熟的形式化方法，以獲得關于代碼的一些更精確或者更廣泛的性質。指向分析多數與指針密切相關，由于在靜態(tài)分析中長期受到較多的關注，因此單獨作為一類。其它輔助分析則包含了一些單獨分析的目的性不是很強，但可認為前面幾類分析提供支持的一些分析方法。需要指出的是，這不是一個嚴格的分類，而僅僅是為了便于人們比較全面地了解靜態(tài)分析，對一些重要的、具有共性的靜態(tài)分析進行歸類而得到的一個結果。圖2重要的靜態(tài)分析技術基本分析1）語法分析（SyntaxAnalysis）。語法分析是按具體編程語言的語法規(guī)則分析和解決詞法分析程序產生的結果并生成語法分析樹的過程。這個過程可以判斷程序在結構上是否與預先定義的BNF范式相一致，即程序中是否存在語法錯誤。程序的BNF范式一般由上下文無關文法描述。支持語法分析的重要技術涉及算符優(yōu)先分析法（自底向上）、遞歸下降分析法（自頂向下）和LR分析法（自左至右、自底向上）等。語法分析是編譯過程中的重要環(huán)節(jié)，也是多數其它分析的基礎：假如一個程序連語法分析都沒有通過，則對其進行其它的分析往往沒故意義。2）類型分析（TypeAnalysis）。類型分析重要是指類型檢查（TypeChecking）。類型檢查的目的是分析程序中是否存在類型錯誤。類型錯誤通常是指違反類型約束的操作，例如讓兩個字符串相乘，數組的越界訪問，等等。類型檢查通常是靜態(tài)進行的，但也可以動態(tài)進行。編譯時刻進行的類型檢查是靜態(tài)檢查。對類型分析的支持限度是劃分編程語言種類的準則之一：對于一種編程語言，假如它的所有表達式類型可以通過靜態(tài)分析擬定下來，進而消除類型錯誤，則這個語言是靜態(tài)類型語言（也是強類型語言）。運用靜態(tài)類型語言開發(fā)出的程序可以在運營程序之前消除許多錯誤，因此程序質量的保障相對容易一些（但表達的靈活性弱一些）。3）控制流分析（ControlFlowAnalysis）。控制流分析的目的是得到程序的一個控制流圖（ControlFlowGraph）?？刂屏鲌D是對程序執(zhí)行時也許通過的所有途徑的圖形化表達。通過根據不同語句之間的關系，特別是考慮由“條件轉移”、“循環(huán)”等引入的分支關系，對過程內的一些語句進行合并，可以得到關于程序結構的一些結果。一個控制流圖是一個有向圖：圖中的結點相應于程序中通過合并的基本語句塊，圖中的邊相應于也許的分支方向，例如：條件轉移、循環(huán)等等，這些都是分析程序行為的重要信息。4）數據流分析（DataFlowAnalysis）。數據流分析試圖擬定在程序的某一點（語句），關于各個變量的使用或者也許取值情況。數據流分析一般從程序的一個控制流圖開始。數據流分析重要有前向分析（ForwardAnalysis）、后向分析（BackwardAnalysis）兩種方法。前向分析的一個例子是可達定義（reachingdefinitions）。它計算對于程序的每一點，也許到達該點的定義的集合。后向分析的一個例子是活躍變量（livevariables）。它計算對于程序的每一點，程序后面的語句也許讀取且沒有再次修改的變量。這個結果對于消除死代碼（deadcode）很有用：假如一個變量在某個階段被定義后，后面的語句一直不會用到這個定義，那么這個定義就是死代碼，應當從程序中刪除。基于格（lattice）與不動點（\o"Fixpoint"fixpoint）理論的數據流分析是目前被廣泛使用的技術：一方面對控制流圖中的每個節(jié)點建立一個數據流等式（equations），并根據分析目的構造一個具有有限高度的格L，然后不斷反復計算每個節(jié)點的輸出，直到達成格的一個不動點。許多編譯器為了進行編譯優(yōu)化而引入了數據流分析技術。由于上述四種基本分析是多數編譯器包含的內容，因此很早就得到了較進一步的研究[62]。這些分析過程尚有一個共同特點是分析的輸入僅僅是軟件代碼，不需要提供圖1中的“系統(tǒng)性質”?；蛘哒f，基本分析技術所需要的“系統(tǒng)性質”都是最基本的性質。例如語法分析相應的“系統(tǒng)性質”就是編程語言的BNF范式，類型分析相應的“系統(tǒng)性質”是預先定義的類型約束，數據流分析相應的“系統(tǒng)性質”是編程語言的基本約定，等等。而下面要講到的形式化分析、指向分析則通常要事先提供待驗證的性質，例如：某個變量的取值是否在某個范圍內、某兩個變量名是否指向相同的內存實例、等等?；谛问交椒ǖ姆治鰹榱颂岣叻治龅臏蚀_度，獲取關于程序的更多性質，許多研究人員借用形式化方法來擴展基本分析技術。代表性技術有模型檢查、定理證明、約束求解、抽象解釋等。1）模型檢查（ModelChecking）。模型檢查用狀態(tài)遷移系統(tǒng)表達系統(tǒng)的行為，用模態(tài)/時序邏輯公式描述系統(tǒng)的性質，然后用數學問題“狀態(tài)遷移系統(tǒng)是否是該邏輯公式的一個模型”來鑒定“系統(tǒng)是否具有所盼望的性質”[32]。模型檢查雖然在檢查硬件設計錯誤方面簡樸明了且自動化限度高，然而被應用在軟件程序分析與驗證時卻存在著難以解決的狀態(tài)空間爆炸問題。此外，由于模型檢查所針對的檢核對象是模型而非程序自身，任何在將程序向模型轉化的過程中所使用的抽象技術以及轉化工作都有也許使模型與程序不一致或者存在偏差，從而導致最終的檢查結果無法準確反映實際程序中存在的錯誤情況。更多關于模型檢查的進一步討論可以參見[32]。支持模型檢查的代表性軟件分析工具為SLAM[23]、MOPS[24]、Bandera[25]和JavaPathFinder2[26]。2）定理證明（TheoremProving）。自動定理證明通過將驗證問題轉換為數學上的定理證明問題來判斷待分析程序是否滿足指定屬性[1]，是眾多分析方法中最復雜最準確的方法。然而，一階邏輯是半可鑒定的，理論分析結果表白，機械化的定理證明過程并不保證停機。此外，為了獲取指定的屬性以實現(xiàn)有效的證明，這些工具都規(guī)定程序員通過向源程序中添加特殊形式的注釋來描述程序的前置條件、后置條件以及循環(huán)不變量。這無疑增長了程序員的工作量，也導致該方法難以廣泛應用于大型應用程序。使用定理證明的代表性軟件分析工具為ESC[27]和ESC/Java[28]。3）約束求解（ConstraintSolving）?；诩s束求解的程序分析技術將程序代碼轉化為一組約束，并通過約束求解器獲得滿足約束的解[48]。初期的研究表白，面向途徑的測試數據生成可以很好地歸結為約束求解問題。后來，學者們又發(fā)現(xiàn)程序中不變式的分析也可以歸結為約束求解問題。最新的研究表白，許多其的程序分析問題也可以歸結為約束求解問題：由于從程序獲得的約束通常采用一階或二階的形式表達，可以進一步將其轉換成約束求解器可解決的形式。支持約束求解的代表性軟件分析工具為SAT/SMTSolver[49]。4）抽象解釋（AbstractInterpretation）。程序的抽象解釋就是使用抽象對象域上的計算逼近程序指稱的對象域上的計算，使得程序抽象執(zhí)行的結果可以反映出程序真實運營的部分信息。抽象解釋本質上是在計算效率和計算精度之間取得均衡，以損失計算精度求得計算可行性，再通過迭代計算增強計算精度的一種抽象逼近方法。通過不斷迭代，抽象解釋最終為程序建立一個抽象模型。假如抽象模型中不存在錯誤，就證明其相應的源程序中也不存在錯誤。具有抽象解釋分析功能的代表性分析工具為Proverif[29]和ASTREE[30]。形式化支持的分析技術在分析軟件的某個性質時，需要一方面對該性質進行形式化的描述，然后將這個描述與軟件制品一起作為輸入提供應分析工具。其中，模型檢查一方面被用于對軟件的模型進行分析，后來有研究人員通過從代碼中提取模型，然后將模型檢查技術應用于代碼分析。定理證明重要對靜態(tài)代碼比較合用。約束求解多用于輸入數據的生成?；诔橄蠼忉尷碚摰男问交椒ㄊ菍Υ笠?guī)模軟件、硬件系統(tǒng)進行自動化分析與驗證的有效途徑之一，已經被廣泛地應用于大型軟件與硬件系統(tǒng)的驗證研究中。指向分析1）別名分析（AliasAnalysis）。別名分析重要用于擬定程序中不同的內存引用（reference）是否指向內存的相同區(qū)域。在編譯過程中，這可以幫助判斷一個語句將影響什么變量。例如，考慮如下的代碼：...;p.foo=1;q.foo=2;i=p.foo+3;...。假如p和q不是別名，那么i=p.foo+3;等價于i=4;假如p和q是別名，那么i=p.foo+3;等價于i=5;這樣就可以對代碼進行等價優(yōu)化。別名分析又可以分為基于類型的分析與基于流的分析。前者重要用于類型安全（typesafe）的語言，后者則重要用于具有大量引用與類型轉換的語言[3]。2）指針分析（PointerAnalysis）。指針分析試圖擬定一個指針到底指向哪些對象或者存儲位置，特別是，在某個語句處是否也許為空。由于受到可鑒定性問題的限制，加上分析過程中時間、存儲等的限制，多數的指針分析方法都在分析過程中進行“近似”或者“簡化”，并導致分析結果精確性不夠。事實上，上面的別名分析與下面的形態(tài)分析、逃逸分析都與指針分析密切相關。3）形態(tài)分析（ShapeAnalysis）。形態(tài)分析重要用于發(fā)現(xiàn)或者驗證程序中動態(tài)分派結構的性質。對于一個具體的程序，形態(tài)分析將為其構造一個形態(tài)圖（shapegraph），用于列出每個指針也許指向的目的，以及目的之間的關系。形態(tài)分析可以認為是指針分析的一種,但比一般的指針分析精確：形態(tài)分析可以擬定一個小一些但是更精確的指向集合。例如在Java程序中，可用來保證一個排序算法對的地對列表進行了排序；在C程序中，可以用來分析一個內存是否被對的地釋放。盡管形態(tài)分析很強大，但往往需要花費較多的時間[4]。4）逃逸分析（EscapeAnalysis）。逃逸分析計算變量的可達邊界。對于一個方法m中的一個變量，假如變量是在調用方法m時創(chuàng)建的，但在m的生命周期之外可以獲得該變量，我們就說這個變量逃逸了方法m。類似地，一個變量逃逸了一個線程t，假如在t之外的一個點能通過一個引用訪問到該變量。逃逸分析傳統(tǒng)上被用于查找一些變量，它們只存在于為它們分派內存的方法或線程的生命周期內：前者允許變量在運營時的棧（stack）上，而不是堆（heap）上分派內存，這樣就可以減少堆的碎片與垃圾回收負載。后者被用于進行優(yōu)化，以避免高成本的異步操作。逃逸分析檢查引用的賦值與使用（assignmentsanduses）以計算每個變量的逃逸狀態(tài)。每個變量可以被賦予3個也許逃逸狀態(tài)中的一個：全局逃逸、參數逃逸或者捕獲。當一個變量是全局可達的（例如被賦值給了一個靜態(tài)域）時，這個變量被標記為全局逃逸；假如變量是通過參數或者被返回給調用者方法，它被標記為參數逃逸；一個不逃逸的變量被標記為捕獲。逃逸分析重要用于效率分析[22]。與基本分析技術相比，指向分析通常與應用程序的某個特定性質密切相關。這類分析一般是以基本分析（特別是數據流分析）為重要分析框架，為了提高分析精度而提出的技術，且分別結合了編程語言的不同特點。例如：別名分析運用的變量引用、形態(tài)分析運用的指針等等。這也導致了這些分析技術分別適合由不同編程語言實現(xiàn)的程序。此外，這些分析技術盡管可以自動進行，但在分析之前通常需要較多的人工介入，例如，指定對哪些變量進行分析、提供對什么性質進行分析等等。其它輔助分析1）符號執(zhí)行（SymbolicExecution）。符號執(zhí)行通過使用抽象的符號表達程序中變量的值來模擬程序的執(zhí)行[14,31]。其特點在于通過跟蹤被模擬的各條執(zhí)行途徑上變量的實際取值，把分析工作局限在實際可達的途徑上，從而使得到的結果更貼近程序實際執(zhí)行情況，并為程序員提供更為準確的與檢出的缺陷相關的上下文信息。但是由于需要窮舉各條也許執(zhí)行的途徑，該技術需要解決的工作量隨著程序規(guī)模的增大而呈指數級別增長。雖然符號執(zhí)行方法可以被應用于大型程序的分析，其分析結果的可靠性仍依賴于所允許的分析時間和對途徑及其數目的選擇等方面。2）切片分析（SlicingAnalysis）。切片分析用于從源程序中抽取對程序中愛好點上的特定變量有影響的語句和謂詞，組成新的程序（稱作切片），然后通過度析切片來分析源程序的行為[42]。計算程序切片的方法重要有兩種：根據數據流方程計算和根據依賴圖關系計算。切片分析技術已被廣泛應用于程序分析、理解、調試、測試、軟件維護等過程[38,39]。3）結構分析（StructureAnalysis）。結構分析的目的是獲得程序的調用關系圖（CallGraph），以展示程序中各個函數之間的調用關系。把程序中每個函數當作一個節(jié)點，再分析每個函數調用了哪些其他函數，并在存在調用關系的函數間建立一條邊，就可以得到調用關系圖。調用關系圖通常用于輔助開發(fā)人員理解程序。對于面向對象程序，程序的結構分析還涉及從程序中獲取類圖（classdiagram）等。除了一些編譯器支持結構分析外，目前軟件開發(fā)過程中的一些工具，例如IBMRationalRose等也可以對以開發(fā)出的代碼進行結構分析。4）克隆分析（CloneAnalysis）。代碼克?。–odeclone）是指軟件開發(fā)中由于復制、粘貼引起的反復代碼現(xiàn)象。研究指出，一般商業(yè)軟件中存在5%至20%的反復代碼[1]。由于克隆代碼的普遍性以及克隆代碼對代碼質量的重要影響，代碼克隆相關研究是靜態(tài)代碼分析領域近年來一個十分活躍的研究分支。重要研究內容涉及：克隆代碼檢測、由代碼克隆引起的代碼缺陷診斷、通過代碼重構來減少代碼克隆、克隆代碼跟蹤、基于代碼克隆的源代碼演化分析等等。代碼克隆分析有十分豐富的實際應用價值，比如缺陷診斷、重構、代碼理解、源代碼演化分析和代碼抄襲檢查等等?？寺〈a可以分為如下四類：1）除空格、回車以及注解之外完全相同的代碼片段；2）除空格、回車、注解以及變量名及常量值替換外，語法結構完全相同的代碼片段；3）除空格、回車、注解以及變量名及常量值替換外，語法結構基本相同，但具有少量語句的增長、刪除或修改的代碼片段；4）兩段或多段代碼具有相同或相似的功能，或者說相似的輸入、輸出條件。其中，最后一類比較特殊，是語義（功能）相似性，其它三類都是文本相似性[5-17]。動態(tài)分析動態(tài)分析是通過運營具體程序并獲取程序的輸出或者內部狀態(tài)等信息來驗證或者發(fā)現(xiàn)軟件性質的過程。與靜態(tài)分析相比，動態(tài)分析具有如下幾方面特點：1）需要運營系統(tǒng)，因此通常要向系統(tǒng)輸入具體的數據；2）由于有具體的數據，因此分析結果更精確，但同時只是對于特定輸入情況精確，對于其它輸入的情況則不能保證。本文從運營信息的獲得途徑與獲得時機兩個方面對動態(tài)分析進行介紹。在信息獲得的時機上，又根據軟件是否已經上線投入使用將軟件的動態(tài)分析劃分為兩大類：離線動態(tài)測試/驗證（OfflineDynamicTesting/Verification）與在線監(jiān)測（OnlineMonitoring）。所謂離線動態(tài)測試/驗證，是指在系統(tǒng)還沒有正式上線時對軟件進行運營、分析，分析過程中可以隨意輸入數據，并盡量模擬實際用戶的操作。所謂在線監(jiān)測，是指在系統(tǒng)已經上線后對軟件系統(tǒng)進行分析，監(jiān)測過程中一般不能隨意輸入數據，所有數據都是真實的。離線動態(tài)測試/驗證、在線監(jiān)測與運營信息獲取之間的基本關系見圖3。圖3動態(tài)分析涉及的重要技術運營信息的獲取途徑從程序的正常輸出中獲取信息每個程序在運營過程中都會產生許多輸出信息。有些輸出是程序運營中間或者結束時輸出的正常結果，有些是一些提醒信息，尚有一些是日記信息。通過將最終得到的實際輸出結果與事先設定的盼望輸出結果進行對比、分析，就可以得到關于軟件的有價值信息。通過插裝代碼獲取信息僅僅通過觀測程序的正常輸出對于了解軟件的運營信息往往是不夠的。例如，軟件運營過程中內部變量的狀態(tài)信息、某個特定類型的實例信息、模塊之間的交互信息等等。這些信息對于發(fā)現(xiàn)缺陷，以及定位缺陷特別重要。獲得這些內部信息的自然方式是在軟件中插裝監(jiān)測代碼（MonitoringCode），通過這些監(jiān)測代碼就可以獲得相應的信息。重要的監(jiān)測代碼插裝方法可以分為如下三類：源碼插裝。這是最自然的插裝方式，即在編寫應用系統(tǒng)時，在需要監(jiān)測的地方直接加上監(jiān)測代碼，例如，增長輸出信息語句、增長日記語句等等。AOP（AspectOrientedProgramming）技術出現(xiàn)之后，人們發(fā)現(xiàn)AOP可以被很好地用于代碼插裝，以有效地分離系統(tǒng)的業(yè)務邏輯與監(jiān)測邏輯[43]。靜態(tài)目的碼插裝。近年來字節(jié)碼插裝技術在Java社區(qū)中十分流行。字節(jié)碼插裝可以在靜態(tài)直接更改中間代碼文獻（例如Java的.class文獻）或在裝載時刻進行字節(jié)碼插裝。字節(jié)碼插裝所具有的執(zhí)行效率高、插裝點靈活、應用范圍廣等特點，使其被廣泛應用于AOP等研究領域，并陸續(xù)出現(xiàn)了BCEL[64]、Javassist[65]、ASM[66]等多種字節(jié)碼操縱工具?；诮厝∑鳎↖nterceptor）的獲取方式。截取器處在調用者和被調用者之間，可以截獲兩者之間傳遞的消息，從而完畢一些特定的解決工作。由于這種獲取方式不需要直接修改目的程序，代碼侵入性較弱，甚至可以在運營階段部署，因此得到了越來越廣泛的使用。Tomcat服務器、EJB3規(guī)范、Spring框架中都有截取器的實現(xiàn)[40]。通過平臺接口獲取信息向目的系統(tǒng)插裝監(jiān)測代碼可以很方便地獲得內部信息。假如底層的運營平臺（操作系統(tǒng)、JVM、中間件、或者數據庫管理系統(tǒng)等）提供很好的支持，則許多信息獲取起來就更加方便。例如，許多研究人員通過開發(fā)特殊的JAVA虛擬機來獲取所需要的監(jiān)測信息。JPF[50]、QVM[51]等就是典型代表。目前標準的JVM自身也提供了許多供調試、監(jiān)測的接口，例如JVMTI[52]等等。離線動態(tài)測試/驗證離線的動態(tài)測試與動態(tài)驗證都需要在離線的情況下運營程序，并獲取、分析運營信息，因此兩者有比較密切的聯(lián)系。不僅如此，為發(fā)現(xiàn)更多的軟件缺陷，離線動態(tài)驗證與動態(tài)測試都需要仔細準備輸入數據。此外，假如將程序的輸出與輸入之間的關系看作一種約束需求，或者在分析測試結果時也收集日記等內部信息的話，兩者就更接近了。從不同之處看，離線動態(tài)驗證一般比測試收集更多的內部信息、關注更多的約束需求，并且往往運用一些輕權（lightweight）的形式化方法來描述這些需求。從研究內容看，離線動態(tài)測試/驗證重要關注三個方面的內容：輸入數據生成、約束描述、運營軌跡分析。輸入數據生成。為了盡也許多地發(fā)現(xiàn)潛在的缺陷，在運營程序之前通常需要一方面靜態(tài)地分析目的程序，根據驗證目的（什么功能、什么約束、等等）輔助用戶生成和選擇輸入數據。約束描述。運用形式化方法描述軟件約束，以便于分析可以自動進行。目前多數動態(tài)驗證研究人員運用線性時序邏輯（LTL:LinearTemporalLogic）來描述。運營軌跡分析。程序運營過程中產生的內部、外部數據也許是大量的，需要測試/驗證目的對數據進行必要的過濾，然后分析這些數據以推斷程序的執(zhí)行軌跡，并進一步判斷程序的執(zhí)行是否遵循程序的約束。在線監(jiān)測與離線動態(tài)驗證相比，在線監(jiān)測有幾個特點：1）系統(tǒng)輸入由實際的真實用戶與系統(tǒng)擁有者共同決定；2）系統(tǒng)擁有者的輸入是受限制的，一些在上線之前可以做的實驗（例如：壓力測試、安全性測試等）此時不能隨意實行，否則就會威脅到系統(tǒng)正常的服務質量；3）監(jiān)測代碼往往就是應用系統(tǒng)的組成部分。這使得在線監(jiān)測與前面介紹的各種分析都非常的不同：前面介紹的分析技術一般都由特定的分析工具支持，分析工具是一種外部輔助工具，在系統(tǒng)上線后，分析工具就與系統(tǒng)分離了。而在線監(jiān)測則也許一直隨著系統(tǒng)的服務過程，并且也許是在系統(tǒng)上線之后，在不同的維護階段增長上去的。有研究人員因此提出了面向監(jiān)測的編程(MOP)[37]。在分析機制上，在線監(jiān)測的分析可以采用內聯(lián)模式（inline）或者外聯(lián)模式（outline）。在內聯(lián)監(jiān)測模式中，監(jiān)測代碼（monitor）與被監(jiān)測程序運營在相同的空間中，因此執(zhí)行效率相對要高，且發(fā)現(xiàn)異常后響應要快。在外聯(lián)監(jiān)測模式中，監(jiān)測代碼運營在獨立的運營空間中，比如此外一臺機器或者CPU。外聯(lián)模式效率要低一些，但可以對多項監(jiān)測內容進行綜合解決，因此可以做更進一步的分析。對于在線系統(tǒng)，假如要監(jiān)測它，就一定會影響它。假如影響過大，就也許給正常的服務過程帶來負面作用。因此，衡量在線監(jiān)測技術的一個重要指標是監(jiān)測開銷，特別是運營開銷。許多監(jiān)測的時間開銷甚至高于程序自身的運營開銷。由于在線監(jiān)測一定會對監(jiān)測對象的運營產生影響，因此監(jiān)測的結果也一定是被影響后系統(tǒng)的表現(xiàn)，而不是被監(jiān)測對象自身的表現(xiàn)。針對這個現(xiàn)象，有些研究人員參照物理學中的測不準原理提出了軟件的測不準原理[34]。需要特別注意的是，在系統(tǒng)上線之后，有價值的監(jiān)測通常不僅僅針對軟件自身，而是針對由軟件、硬件組成的服務系統(tǒng)，甚至涉及與服務系統(tǒng)交互的環(huán)境（用例圖中的Actor）[35]。例如：客戶程序的調用序列、系統(tǒng)的響應時間等等。在這個意義上，在線監(jiān)測不僅僅是努力發(fā)現(xiàn)軟件的缺陷，并且關注服務過程的潛在問題（例如：響應時間是否足夠??？是否發(fā)現(xiàn)可疑的襲擊行為？）。因此，隨著Web服務技術、軟件作為服務（SaaS：SoftwareasaService）的推廣，在線監(jiān)測正受到越來越多研究人員的關注[33]。此外，多核解決器的發(fā)展，也為監(jiān)測提供了更多的途徑：由于業(yè)務邏輯與監(jiān)測邏輯相對分離，完全可以由不同的核分別進行業(yè)務解決與監(jiān)測解決。對軟件內部的監(jiān)測。對軟件內部的監(jiān)測方法與運營時驗證的方法比較接近，上面提到的各種插裝技術對于在線監(jiān)測都合用。不僅如此，對于在線系統(tǒng)，還可以運用在線升級（upgrading）的技術[36]，或者動態(tài)編織（weaving）技術[41]等將監(jiān)測代碼“在線”地部署到目的系統(tǒng)中，以加強監(jiān)測的覆蓋面；或者從系統(tǒng)中移除監(jiān)測代碼，以減少監(jiān)測開銷。除此之外，尚有許多對實例的監(jiān)測，例如：負責客戶連接對象的實例數目、負責數據庫連接的實例數目等等。對外部交互的監(jiān)測。重要監(jiān)測對象涉及：來自客戶程序的請求消息順序是否對的？參數值是否在允許的范圍內？請求者的權限是否夠（與安全相關）？應答消息的參數值是否在允許的范圍內？從收到請求消息到發(fā)出應答消息的響應時間是否符合規(guī)定？管理人員的操作是否合法？等等。對運營環(huán)境的監(jiān)測。對運營環(huán)境的監(jiān)測重要體現(xiàn)為對底層資源的監(jiān)測，通常是獨立于具體應用的監(jiān)測內容，例如：CPU的使用情況、內存使用情況、網絡帶寬等等。對于越來越多的嵌入式系統(tǒng)，由于各種資源都有較大的限制，監(jiān)測就顯得更加重要。分析技術的評價面對種類眾多的軟件分析技術，人們通常不僅希望能了解它們，還希望對它們進行評價、比較，以在其中選擇選擇合適自己當前任務的分析技術。事實上，由于這些技術錯綜復雜，對它們的評價自身也是一個十分值得研究的題目。目前人們比較關注的評價準則有：誤報率（Falsepositiverate）、漏報率（Falsenegativerate），精度（Precision）、速度（Speed）、等等。誤報率與漏報率。誤報是指當軟件不存在某個缺陷時，分析工具報告軟件也許存在某個缺陷。大量的誤報將導致大量的人工分析工作：人們必須手工判斷系統(tǒng)是否真的存在某個缺陷。漏報是指軟件中存在某個缺陷，但分析工具沒有報告這個缺陷。將報告結果與缺陷的實際情況進行對比，就可以得到具體的量化指標：誤報率與漏報率。誤報率與漏報率是目前評價分析工具的兩個最重要的指標：一個工具的誤報率與漏報率越小，說明這個分析工具越好。但實際情況往往是：有的方法在減少誤報率方面很有效，但往往同時增長了漏報率；而有的方法在減少漏報率方面很有效，但卻抬高了誤報率[1]。誤報率與漏報率的反面說法分別是查準率（Precision）與查全率（Recall）。一般來說，靜態(tài)分析可以比較全面地考慮執(zhí)行途徑，因此可以比動態(tài)分析發(fā)現(xiàn)更多的缺陷，漏報率比動態(tài)分析低；但動態(tài)分析由于獲取了具體的運營信息，因此報出的缺陷一般更為準確，誤報率比靜態(tài)分析低。精度與速度。為了提高分析的精度，即減少誤報率與漏報率，實際的靜態(tài)分析工具往往綜合運用多種分析技術，并需要做一些較進一步的分析，這自然意味著更長的分析時間。因此，分析的精度與分析的速度往往也是一對不可兼得的矛盾體，必須在兩者之間進行折中。此外，動態(tài)分析由于往往一次只關注少部分的軟件性質，因此精度可以更高一些，并且受程序規(guī)模的限制較??；而靜態(tài)分析在程序運營之前就可以實行，因此可以更早地發(fā)現(xiàn)問題。軟件分析與質量保障軟件分析的一個重要應用是保障軟件質量：通過度析某個軟件，查找出其中包含的軟件缺陷，就可以讓開發(fā)人員修改軟件，將缺陷修復，從而提高軟件質量。ISO9126提出了一個兩層、六類的質量模型，涉及：1）功能性（含：適合性、準確性、互操作性、保密安全性）；2）可靠性（含：成熟性、容錯性、易恢復性）；3）易用性分析（含：易理解性、易學性、易操作性、吸引性）；4）效率（含：時間特性、資源運用性）；5）易維護性（含：易分析性、易改變性、穩(wěn)定性、易測試性）；6）可移植性（含適應性、易安裝性、共存性、易替換性）。本文以ISO9126的分類為基礎，從軟件分析的角度出發(fā)，結合上面的質量屬性，歸納出5種相對并列的軟件質量屬性：對的性（Correctness）、健壯性（Robustness）、安全性（Security）、效率（Efficiency）、易維護性（Maintenance）。當然，這5種屬性之間不是完全正交的，它們之間存在著一些不同形式的關聯(lián)。本節(jié)重要介紹如何運用上一節(jié)中提到的一些分析技術對這些屬性進行分析。特別是，如何運用這些技術發(fā)現(xiàn)相應的質量問題。3.1軟件對的性“對的性”重要指程序的運營結果是否與預期值相同。假如不相同，則視為結果不對的，該程序包含一個“對的性”錯誤。對的性的考慮比較單純，重要是從輸入到輸出這個函數映射的角度看待計算過程，特別關心輸出結果的對的與否，而不考慮輸入數據的具體來源與錯誤輸出結果的后果如何。與對的性相對的是健壯性與安全性：對的性考慮的是軟件是否按照預先的設定執(zhí)行，健壯性與安全性則考慮軟件是否在一定條件下執(zhí)行設定之外的事情。動態(tài)測試/驗證動態(tài)測試/驗證是發(fā)現(xiàn)對的性缺陷最有效的手段。對于任何一個稍具規(guī)模的軟件而言，窮舉所有也許輸入的測試/驗證都是不現(xiàn)實的。因此，對于發(fā)現(xiàn)與對的性有關的缺陷而言，測試/驗證的關鍵在于生成有較強揭示錯誤能力的輸入數據，并通過程序的執(zhí)行最終檢測與對的性相關的缺陷?；诔绦蚍治龅臄祿斎肷杉夹g大體可以分為面向途徑的測試用例生成[56]和面向目的的測試用例生成[57]。面向途徑的測試數據生成是指給定程序的一條執(zhí)行途徑，生成一個恰好執(zhí)行該條路經的測試用例。面向途徑的測試用例生成可以轉化為約束求解問題。面向目的的測試用例生成是指，給定測試的某個目的（比如語句覆蓋），生成一組可以達成該目的的測試用例。面向目的的測試用例生成通常以面向途徑的測試用例生成為基礎，其基本思緒是將面向目的的測試用例生成轉化成面向途徑的測試用例生成甚至直接轉化成約束求解問題。多數情況下，一種測試用例生成技術并不僅針對與對的性有關的缺陷，同時也會兼顧與健壯性有關的缺陷。靜態(tài)分析靜態(tài)分析也是發(fā)現(xiàn)與對的性有關缺陷的重要途徑。靜態(tài)分析的基本思緒是建立一些與對的性有關的形式化規(guī)約，然后檢查軟件是否滿足這些規(guī)約。靜態(tài)分析可以不針對軟件的特定輸入發(fā)現(xiàn)一類缺陷，因此在很大限度上可以與測試互為補充。3.2軟件健壯性“健壯性”重要是指系統(tǒng)是否能控制軟件內外客觀不良事件的發(fā)生，以保持系統(tǒng)的基本服務質量。例如，是否會發(fā)生因死鎖而導致系統(tǒng)不工作、是否由于內存泄漏而導致系統(tǒng)崩潰、是否因產生數據競爭而導致系統(tǒng)出現(xiàn)錯誤狀態(tài)等等。健壯性與對的性之間存在一定的關聯(lián)：一方面，不對的的輸出有也許影響包含軟件的系統(tǒng)整體上的健壯性；另一方面，因系統(tǒng)崩潰等因素導致“得不到結果”有時也被認為是“不對的”的一種特殊表現(xiàn)。與“健壯性”比較接近的一個術語是“可靠性”（Reliability）。后者目前被認為重要是指在規(guī)定運營環(huán)境下、規(guī)定期間內，軟件無失效運營的概率，并且是評價軟件對的性的一種重要途徑[55]。由于這個概念與對的性在內涵上重合較大，因此本文采用“健壯性”這個與對的性在內涵上重合較小的概念作為從分析角度上劃分的質量屬性之一。動態(tài)測試/驗證動態(tài)測試/驗證是發(fā)現(xiàn)健壯性的一個重要手段。與針對軟件對的性的測試類似，這方面軟件分析的重點也在于輸入數據（測試用例）生成。不同的是，針對軟件健壯性的生成的目的是生成不對的的輸入，并檢查這些輸入是否會導致非盼望的結果。模型檢查將模型檢查應用于健壯性分析的最典型例子是死鎖（deadlock）檢查。死鎖[58]是指多個進程（線程）因互相等待而不能完畢計算任務。死鎖通常是進程（線程）在競爭資源時產生的：每個進程（線程）擁有一些資源同時等待其他進程（線程）擁有的某些資源，每個進程（線程）都因不能擁有所需的所有資源而無法繼續(xù)進展。模型檢查可以對軟件也許的狀態(tài)進行窮舉、分析，從而判斷軟件是否也許進入死鎖狀態(tài)。指向分析軟件的許多健壯性問題與指針相關。因此，指向類分析對于健壯性保障十分重要。例如內存泄漏（memoryleak）問題。內存泄漏是指因內存使用后沒有釋放而引起的可用內存的異常消耗[59]。嚴重的內存泄漏會導致軟件系統(tǒng)因可用內存消耗殆盡而崩潰。靜態(tài)的內存泄露檢測重要檢查軟件中每個內存申請語句是否有相應的內存釋放語句，以及軟件是否存在內存申請語句和內存釋放語句不匹配的途徑。動態(tài)的內存泄露檢測重要分析內存的使用情況，檢查內存的使用上是否存在一些與內存泄露以有關的現(xiàn)象。例如，面向對象程序中的內存泄漏往往會導致某些類的對象的數目會隨軟件的執(zhí)行而不斷增長，跟蹤每個類的對象的數目可以輔助內存泄漏的檢測。3.3軟件安全性“安全性”重要指軟件是否存在安全漏洞，是否會由于人為襲擊，導致信息泄露（保密性）、數據損失（完整性）或者系統(tǒng)不能正常工作（可用性）等不良后果。安全性與健壯性之間的重要區(qū)別在于：導致系統(tǒng)不安全的因素是人為因素，而導致系統(tǒng)不健壯的因素是軟件自身。此外，兩者之間也存在關聯(lián)：許多系統(tǒng)由于健壯性存在缺陷（例如：字符串溢出）而導致安全性缺陷（惡意注入）。靜態(tài)代碼漏洞查找輸入驗證。這里的輸入不僅僅是用戶的輸入，還涉及：配置文獻、從數據庫檢索出的數據、命令行參數、環(huán)境變量、網絡消息等等。在一個軟件系統(tǒng)中，接受這些輸入的接口集通常被稱為應用程序的襲擊面。SQL注入、腳本注入、跨站點襲擊等都是這類襲擊。通過相應用程序進行分析，可以自動發(fā)現(xiàn)應用系統(tǒng)的可信邊界，還可以發(fā)現(xiàn)邊界上的點是否由于缺少有效的驗證而存在安全漏洞。溢出襲擊。由于緩沖區(qū)溢出很容易被襲擊者用來重寫內存中的數據，并非法獲取一些權限，因此許多惡意者運用緩沖區(qū)溢出進行襲擊。緩沖區(qū)溢出通常是由一些特殊的函數導致的。例如C語言中的gets(),scaf(),strcpy(),sprintf()等。靜態(tài)分析可以發(fā)揮的地方涉及：分析是否使用了不必要的高風險函數、是否存在多次內存釋放操作等。其中，內存釋放等問題往往涉及別名分析。隱私信息。多數程序中存在需要隱藏的內容。不嚴謹的編程人員很容易在程序總不經意地泄露相關的信息，導致系統(tǒng)被襲擊。例如：將私密數據放到日記中，程序中硬編碼了密碼信息，向瀏覽器返回過于具體的犯錯信息，隨機數的產生規(guī)則過于簡樸，選擇的加密算法不夠安全等等。靜態(tài)分析可以幫助編程人員發(fā)現(xiàn)這些漏洞。安全性測試安全性測試通過運營軟件、模擬惡意用戶的輸入來分析系統(tǒng)的安全性。一些重要考慮的問題有兩類：權限相關的安全性與網絡相關的安全性。權限相關的安全性涉及：是否明確地區(qū)分系統(tǒng)中不同用戶權限？系統(tǒng)中會不會出現(xiàn)用戶沖突？系統(tǒng)會不會因用戶的權限的改變導致混亂？是否可以通過絕對途徑登陸系統(tǒng)？等等。與網絡相關的安全性涉及：系統(tǒng)的補丁是否打上？模擬非授權襲擊，看防護系統(tǒng)是否堅固？系統(tǒng)中是否存在某些安全漏洞？等等。入侵檢測入侵檢測系統(tǒng)（IDS：IntrusionDetectionSystem）是一種對網絡傳輸進行即時監(jiān)視，在發(fā)現(xiàn)可疑傳輸時發(fā)出警報或者采用積極反映措施的防御手段。通過度析襲擊模式（例如某個特定的操作序列）可以判斷是否是一個潛在的襲擊。此外，傳統(tǒng)的身份認證與授權事實上也是以實時監(jiān)測調用者的角色來保證某些特殊的操作只能由通過授權的用戶來調用。類似的技術尚有監(jiān)測調用者的系列、與入侵操作模式進行對比等等，以發(fā)現(xiàn)潛在的入侵行為。3.4軟件效率“效率”涉及時間效率與空間效率。在時間效率方面，用戶的響應時間要小、吞吐量要大；所謂空間效率方面，運營過程中占用資源要少，特別是內存資源。由于初期CPU的計算能力有限，內存容量也有限，因此程序的效率問題在初期很受重視：算法復雜性的研究長期以來是計算機科學的重要內容，而衡量一個算法好壞的重要標準是時間開銷與空間開銷。算法復雜性分析多數是手工進行的。近十數年來，人們對效率問題的重視限度有所下降：為了提高開發(fā)效率，人們往往以犧牲軟件效率為代價。例如大量系統(tǒng)軟件、框架的引入方便了應用軟件的開發(fā)，但同時導致調用層次過多，系統(tǒng)執(zhí)行效率下降。只是由于硬件速度提高較快，蓋過了軟件效率的下降，使最終用戶感覺系統(tǒng)的總體速度還是增長了。不僅如此，為了提高用戶的響應時間，許多分布式的服務器軟件以大量的反復冗余計算為代價，為同一個用戶請求創(chuàng)建在多個機器上的計算，并將最先得到的結果返回給用戶，而將后續(xù)得到的結果直接拋棄。事實上，忽視對運營效率的追求是IT系統(tǒng)能耗連續(xù)增長的因素之一。隨著能源問題的日趨突出，這方面的研究迫切需要加強。效率測試測試是發(fā)現(xiàn)效率缺陷的最有效方法。效率測試通過運營軟件來分析軟件的時間效率與空間效率。通常這個過程需要自動化的測試工具來輔助完畢：測試工具重要用來模擬多種正常、峰值以及異常負載條件，從而對系統(tǒng)的各項性能指標進行測試。效率測試可以使在用戶模擬的環(huán)境中進行的。但是，由于軟件的運營效率與運營環(huán)境有很大的關系，因此效率測試更需要在系統(tǒng)部署到實際環(huán)境、但還沒有事實上線時進行。效率監(jiān)測在系統(tǒng)實際運營過程中，對效率進行監(jiān)測的重要對象涉及：系統(tǒng)的響應時間、CPU負載情況、內存使用、客戶連接實例數目、內部類型的實例數目、數據庫連接實例數目，等等。通過這些信息的獲取，管理者可以對照用戶需求看是否發(fā)生違反需求的情況，假如有，則可以考慮通過運營時刻調整負載、增長硬件資源等方式對系統(tǒng)進行調整。靜態(tài)效率分析編譯過程中的代碼優(yōu)化就是建立在靜態(tài)效率分析技術的基礎上。通過靜態(tài)分析，可以發(fā)現(xiàn)程序中的歷來就不會執(zhí)行的代碼、不會被引用的變量或者賦值操作、不需要的檢查、串復制、數字轉換，等等，從而可以對代碼進行優(yōu)化：在不改變程序語義的前提下，剔除冗余的代碼，從而減少內存開銷，提高執(zhí)行效率。3.5軟件易維護性“易維護性”重要是指系統(tǒng)是否易于理解、是否易于根據需求的變化對系統(tǒng)進行調整。此外，開發(fā)人員在維護軟件的過程中，為了便于及時了解與維護任務相關的一些性質，有時也需要進行軟件分析。面向易維護性分析的首要目的是對軟件的易維護性進行度量。為了讓維護人員更好地運用分析結果，如何將分析結果展示給維護人員也是相關分析技術的一個重要關注點。易維護性度量從軟件度量的角度看，軟件的易維護性是一種外部屬性，不能直接進行度量。需要把易維護性表達為一組可直接度量的內部屬性的函數，而這些內部屬性可以通過程序分析獲得。易維護性度量[60]通?？紤]以下兩個方面的內部屬性：1）程序的結構，重要涉及傳統(tǒng)程序度量中關注的內聚、耦合等屬性；2）程序的風格，重要涉及編程的格式、命名的方式等屬性。從已有文獻看，易維護性度量一般采用靜態(tài)分析技術。系統(tǒng)分解系統(tǒng)分解是指將大型的軟件系統(tǒng)劃分為若干子系統(tǒng)。對于大型軟件系統(tǒng)的維護，維護任務通常只涉及其中很少的子系統(tǒng)，系統(tǒng)分解有助于對系統(tǒng)不熟悉的維護人員理解與維護任務相關的子系統(tǒng)。從已有文獻看，系統(tǒng)分解一般也采用靜態(tài)分析技術，其基本思緒是通過對軟件結構的分析，將軟件劃分為若干高內聚、低耦合的子部分，每個子部分相應一個子系統(tǒng)。特性定位由于維護任務往往針對特性展開，特性定位（featurelocation）[61]可以分析哪些代碼與哪些特性相關，維護人員可以直接運用特性定位的結果支持程序理解。靜態(tài)的特性定位抽取程序的結構信息，然后通過自動或半自動地遍歷程序的結構信息找到與每個特性相關的代碼。動態(tài)的特性定位針對每個特性生成輸入數據，然后通過執(zhí)行這些輸入數據和分析執(zhí)行結果獲取特性與代碼的關系。逆向工程由于軟件文檔經常被人們所忽視，因此軟件維護過程中經常會面臨軟件文檔不完整的情形。這給維護過程中所必須進行的理解軟件、改善軟件等活動帶來了很大的困難。此時，通常可以對程序代碼進行靜態(tài)分析，通過數據收集、知識組織、信息瀏覽等一系列活動，逆向恢復出關于程序的構成成分、成分之間的關系等信息，以指導具體的維護活動。未來研究展望作為軟件技術研究領域的核心內容之一，軟件分析技術隨著軟件技術的發(fā)展而處在不斷發(fā)展之中，并受到如下幾方面的推動：軟件分析新理論和新方法的引入與集成、軟件形態(tài)的新發(fā)展、軟件運營平臺的新發(fā)展、等等。軟件分析新理論和新方法的引入與集成。隨著近年來高可信軟件研究的興起，近年來軟件分析出現(xiàn)了一些新發(fā)展趨勢，涉及：（1）新理論的引入與應用。將新邏輯系統(tǒng)應用到軟件分析上，例如面向動態(tài)結構的解決，分離邏輯的提出并應用于系統(tǒng)代碼的分析；在軟件分析中運用新的數學工具，例如將代數符號計算應用于程序終止性證明；（2）靜態(tài)分析與動態(tài)分析的集成與融合。靜態(tài)分析與動態(tài)分析在分析精度、分析開銷、合用的軟件屬性等方面各有所長。一個十分自然地想法就是將兩者結合起來考慮。例如，先進行靜態(tài)分析，為動態(tài)分析的監(jiān)測部署提供依據，以減少監(jiān)測代碼的部署范圍，縮短離線動態(tài)驗證的時間、減少在線監(jiān)測的開銷；或者先運用離線動態(tài)驗證生成大量的執(zhí)行軌跡，然后進行靜態(tài)分析，以提高分析精度。軟件形態(tài)的新發(fā)展。隨著軟件應用領域及其需求的發(fā)展，軟件的形態(tài)正在發(fā)生深刻的變化：軟件的規(guī)模不斷增大，人們對軟件行為特性結識的愿望也日益強烈。例如網構軟件作為網絡時代軟件的新形態(tài)，其開放、自主等形態(tài)特性將產生以往軟件分析未涉及的性質[20]。同時，軟件性質的描述需要直觀，以方便具有不同知識背景的人員描述性質。軟件性質的描述還需要盡量形式化，以提高分析的自動限度。近年來，由于軟件應用范圍的連續(xù)擴張，編程輔助工具代碼生成能力的提高、計算機網絡技術的推動、開放源代碼理念的被認可，軟件代碼量的增長十分迅速。據分析，到2025年人們開發(fā)的代碼將達成1萬億行[1]。軟件分析也因此需要一些新的視角，例如數量巨大的代碼激發(fā)了一個特殊的研究方式：基于記錄、挖掘的軟件分析。2023年發(fā)起的“挖掘軟件池工作會議”（InternationalWorkingConferenceonMiningSoftwareRepository）著重研究如何從大量現(xiàn)有的代碼中挖掘有價值的內容，例如，挖掘不同形態(tài)制品的追蹤關系、挖掘以往軟件項目開發(fā)過程中具有的特性等，以支持軟件的開發(fā)與維護過程。軟件運營平臺的發(fā)展。軟件運營平臺對軟件分析技術發(fā)展的影響體現(xiàn)在多個方面。例如多核技術對軟件分析技術發(fā)展的影響、各種數據中心/服務中心對軟件分析技術發(fā)展的影響等等。以多核技術的影響為例：一方面，多核體系結構使得并行軟件成為一種軟件常態(tài)，而并行程序的分析受制于語義復雜、狀態(tài)空間爆炸等問題，與需求差距明顯。另一方面，并行性也為軟件分析提供了提高分析規(guī)模和能力的空間，例如模型檢查的并行化以及多核平臺上的運營時驗證等。軟件分析是軟件技術中一個得到長期關注的研究內容，并與其它的軟件技術有較多的結合。隨著軟件規(guī)模越來越大、越來越復雜、積累的軟件越來越多，軟件分析必將在軟件開發(fā)、軟件維護等過程中發(fā)揮越來越大的作用。參考文獻DavidBinkley,SourceCodeAnalysis:ARoadMap,InProceedingofFutureofSoftwareEngineering,2023.MatthewB.Dwyer,JohnHatcliff,Robby,CorinaS.P?s?reanu,andWillemVisser,FormalSoftwareAnalysisEmergingTrendsinSoftwareModelChecking,InProceedingofFutureofSoftwareEngineering,2023.Appel,AndrewW.(1998).ModernCompilerImplementationinML.Cambridge,UK:CambridgeMoolySagiv;ThomasReps,ReinhardWilhelm(May2023)."Parametricshapeanalysisvia3-valuedlogic".ACMTransactionsonProgrammingLanguagesandSystems(TOPLAS)(ACM)24(3):217–298.ChanchalKumarRoyandJamesR.Cordy，ASurveyonSoftwareCloneDetectionResearch,Technicalreport,SchoolofComputing,Queen'sUniversityatKingston,Ontario,Candada,2023.B.S.Baker.Onfindingduplicationandnear-duplicationinlargesoftwaresystems.InWCRE,pages86–95,1995.B.S.Baker.Parameterizedduplicationinstrings:Algorithmsandanapplicationtosoftwaremaintenance.SICOMP,26(5):1343–1362,1997.T.Kamiya,S.Kusumoto,andK.Inoue.CCFinder:amultilinguistictoken-basedcodeclonedetectionsystemforlargescalesourcecode.TSE,28(7):654–670,2023.LingxiaoJiang,GhassanMisherghi,ZhendongSu,StephaneGlondu,DECKARD:ScalableandAccurateTree-basedDetectionofCodeClones,InternationalConferenceonSoftwareEngineering(ICSE),2023MarkGabel,LingxiaoJiang,ZhendongSu,ScalableDetectionofSemanticClones,InternationalConferenceonSoftwareEngineering(ICSE),2023ElmarJuergens,FlorianDeissenboeck,BenjaminHummel,StefanWagner,DoCodeClonesMatter?InternationalConferenceonSoftwareEngineering(ICSE)–2023LingxiaoJiang,ZhendongSu,EdwinChiu,Context-BasedDetectionofClone-RelatedBugs,EuropeanSoftwareEngineeringConferenceandSymposiumontheFoundationsofSoftwareEngineering(ESEC/FSE)2023SandroSchulze,MartinKuhlemann,MarkoRosenmuller,TowardsaRefactoringGuidelineUsingCodeCloneClassification,WorkshoponRefactoringTools(WRT)2023EkwaDuala-Ekoko,MartinRobillardCloneTracker:ToolSupportforCodeCloneManagement，InternationalConferenceonSoftwareEngineering(ICSE)2023EytanAdar,MiryungKim,SoftGUESS:VisualizationandExplorationofCodeClonesinContext,InternationalConferenceonSoftwareEngineering(ICSE)2023JanHarder,NilsGode,ModelingCloneEvolution,InternationalWorkshoponSoftwareClones(IWSC)2023SimoneLivieri?YoshikiHigo?MakotoMatsushita?KatsuroInoue,AnalysisoftheLinuxKernelEvolutionUsingCodeCloneCoverage,FourthInternationalWorkshoponMiningSoftwareRepositories(MSR'07)M.Shaw,“TruthVs.Knowledge:TheDifferencebetweenWhataComponentDoesandWhatWeKnowItDoes,”Proc.8thInt'lWorkshopSoftwareSpecificationandDesign,IEEECSPress,1996,pp.181-185.NedChapin,JoanneE.Hale,KhaledMd.Khan,JuanF.Ramil,Wui-GeeTan,Typesofsoftwareevolutionandsoftwaremaintenance,JournalofSoftwareMaintenanceandEvolution:ResearchandPractice,Volume13Issue1,

Pages

3

–

30,2023.楊芙清，呂建，梅宏，網構軟件技術體系：一種以體系結構為中心的途徑，中國科學F輯，2023,(38)6.W.R.Bush,J.D.Pincus,andD.J.Sielaff.AStaticAnalyzerforFindingDynamicProgrammingErrors.Software-PracticeandExperience(SPE),30:775–802,2023.BrunoDufour,BarbaraG.Ryder,GarySevitsky,

AScalableTechniqueforCharacterizingtheUsageofTemporariesinFramework-intensiveJavaApplications,Proceedingsofthe16thACMSIGSOFTInternationalSymposiumonFoundationsofsoftwareengineering(FSE),2023.T.BallandS.K.Rajamani.Automaticallyvalidatingtemporalsafetypropertiesofinterfaces.InM.B.Dwyer,editor,Proc.8thSPINWorkshop,volume2057ofLNCS,pages103–122.Springer,May2023.H.ChenandD.A.Wagner.MOPS:anInfrastructureforExaminingSecurityPropertiesofSoftware.InProc.9thACMconferenceonComputerandcommunicationssecurity,November,2023.J.Corbettetal.Bandera:Extractingfinite-statemodelsfromJavasourcecode.InProc.22ndICSE,June2023.W.Visser,K.Havelund,G.Brat,andS.Park.Modelcheckingprograms.InInternationalConferenceonAutomatedSoftwareEngineering,Sept.2023.D.L.Detlefs,G.Nelson,andJ.B.Saxe.Atheoremproverforprogramchecking.TechnicalReport,HPLaboratoriesPaloAlto,2023.S.Owre,S.Rajan,J.M.Rushby,N.Shankar,andM.K.Srivas.PVS:Combiningspecification,proofchecking,andmodelchecking.InR.AlurandT.A.Henzinger,editors,Proc.8thCAV,volume1102ofLNCS,pages411–414.Springer,1996.Goubaut-LarrecqJ,ParrennesF.CryptographicprotocolanalysisonrealCcode.In:CousotR,ed.Proc.ofthe6thInt’lConf.onVerification,ModelCheckingandAbstractInterpretatio.LNCS3385,Paris:Springer-Verlag,2023.363?379.BlanchetB,CousotP,CousotR,FeretJ,MauborgneL,MinéA,MonniauxDandRivalX.Astaticanalyzerforlargesafety-criticalsoftware.In:Proc.oftheACMSIGPLAN2023Conf.PLDI.SanDiego:ACMPress,2023.196?207.張健，精確的程序靜態(tài)分析，《計算機學報》(1549—1553)，2023年9期。E.M.Clarke,Jr.O.Grumberg,andD.A.Peled.ModelChecking.MITPress,2023.F.Raimondi,J.Skene,W.Emmerich,Efficientonlinemonitoringofweb-serviceSLAs.InProceedingsofACMSIGSOFT/FSE2023,Atlanta,USA,2023。BethA.Schroeder,On-LineMonitoring:

ATutorial,Volume28,

IEEEComputer,Issue6

(June1995)QianxiangWang,YonggangLiu,MinLi,HongMei,AnOnlineMonitoringApproachforWebServices.Proceedingsofthe31stIEEEInternationalComputerSoftwareandApplicationsConference(COMPSAC2023),Beijing,QianxiangWang,JunrongShen,XiaopengWang,HongMei,AComponent-basedApproachtoOnlineSoftwareEvolution.JournalofSoftwareMaintenanceandEvolution:ResearchandPractice,Vol.18,No.3,2023.FengChen,GrigoreRosu,TowardsMonitoring-OrientedProgramming:AParadigmCombiningSpecificationandImplementation,thirdworkshoponRuntimeVerification,2023.JianjunZhao:ApplyingSlicingTechniquetoSoftwareArchitectures.ICECCS1998:87-99.李必信,鄭國梁,王云峰,李宣東,一種分析和理解程序的方法──程序切片,計算機研究與發(fā)展

2023年

03期.QianxiangWang,AdityaMathur,InterceptorBasedConstraintViolationDetection.ProceedingsoftheIEEEInternationalConferenceandWorkshopontheEngineeringofComputerBasedSystems,WashingtonAndreiPopovici,ThomasGross,GustavoAlonso,DynamicWeavingforAspect-OrientedProgramming,Proceedingsofthe1stinternationalconferenceonAspect-orientedsoftwaredevelopment(AOSD),2023.MarkWeiser,"Programslicing,"IEEETransactionsonSoftwareEngineering,vol.SE-10,no.4,pp.352-357,July1984.LFroihofer,GGlos,JOsrael,KMGoeschka,OverviewandevaluationofconstraintvalidationapproachesinJava,Proceedingsofthe29thinternationalconferenceonSoftwareEngineering(ICSE),2023.NellyDelgado,AnnQ.Gates,andSteveRoach,ATaxonomyandCatalogofRuntimeSoftware-FaultMonitoringTools,IEEETransactionsonSoftwareEngineering,Vol30,

Issue12

(December2023),pp.859–872.

MichaelHind,Michael