為了清楚地描述本論文系統設計的考量與目標，我們特別設計一個 Java 網頁應 用程式的範例 Figure 3.1 為 Java Servlet 程式。從此範例中首先描述本論文研究想 要達成的目標，接著帶出我們系統設計的考量。
從第一章的研究動機與目的可知本論文研究希望藉由產生完備的測試案例，
並配合動態的污染資料流分析，同時改善動態分析的弱點漏報以及靜態分析的弱 點誤報。為了產生趨近完備的測試案例，從 Figure 3.1 的程式範例會指出我們在 測試案例產生的階段需要面對哪些問題與考量。為了進一步減少弱點誤報的情形，
在此我們會說明為何需要在測試案例執行階段加入動態剖面導向程式語言，來幫 助作程式弱點的驗證。
首先從 Figure 3.1 可以看到程式有三個危險的程式接收點(Sink)，分別在第 9、
12、19 行。其中注意第 12 行的程式接收點，根據程式邏輯我們可以知道程式不 可能執行到這個接收點。原因在於第 11 行的條件式(Branch Condition)永遠不會 成立，因為與第 6 行的條件判斷式相互矛盾。當字串變數 name 長度大於等於 5
也就包含 name.equals(”Admin”)的情況。但對靜態分析來說，會將此也視為一個 弱點所在。在此我們想要強調的是，採用測試案例產生的方法，我們可以確認到 達此接收點的程式路徑是不可執行的。因此，改善對於靜態分析來說會產生誤報 的情況。
產生測試案例一定會面臨的挑戰就是測試案例產生的完備性，也就是程式路徑涵 蓋率(Coverage)的問題。要是產生的測試案例不夠完備就會造成弱點漏報的發生，
比起誤報，弱點的漏報是更具危險性的。因此，測試案例產生的目標是要產生完 備的測試案例來保證不會有弱點漏報的情況發生。下面會說明要達成路徑涵蓋率 的目標，需要哪些考量。
01 protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws IOException {
02 String name = req.getParameter("name"); // Source 1 03 String id = req.getParameter("id"); // Source 2 04 PrintWriter writer = resp.getWriter();
05 int sum;
06 if (name.length() >= 5) { 07 id = idCheck(id);
08 if (id.length() >= 5) {
09 writer.println(id); // Sink point 1 10 }
11 } else if (name.equals("Admin")) {
12 writer.println(name + id); // Sink point 2 13 } else {
14 sum = 2;
15 for (int i = 0; i < id.length(); i++) {
16 sum++;
17 }
18 if (sum > 15) {
19 writer.println(name + id); // Sink point 3 20 }
21 }
Figure 3.1 A Java Servlet example for describing the design of the system
首 先 從 程 式 範 例 中 第 7 ～ 9 行 可 以 看 到 一 個 跨 程 序 的 外 部 呼 叫 函 式 (Inter-procedural call out method) idCheck，Figure 3.2 為函式 idCheck 的程式碼。
可以看到函式 idCheck 回傳值會影響變數 id 的值，而變數 id 又會影響第 8 行條 件式的成立與否。條件式成立就會到達第 9 行的程式接收點，所以跨程序的路徑 分析(Inter-procedural path analysis)是測試案例產生一定要處理的問題。加上程式 幾乎都有呼叫外部函式的情況，所以這是首要考量的路徑涵蓋問題。接著我們看 程式範例第 14～19 行，可以看到變數 sum 會受迴圈影響而改變最後的變數值。
其中變數 sum 會影響第 18 行條件式的成立與否，也就會影響路徑是否會到達接 收點而形成一個弱點。所以另外一個要考量的路徑涵蓋率問題就是迴圈的路徑處 理問題。尤其在不知道迴圈會執行幾次的情況下，迴圈可能會對程式的路徑帶來 無限種的可能，對於迴圈處理的細節與討論在後面的章節會再進一步說明。
說明完測試案例產生的設計考量與目標之後，接著是測試案例執行的部分。
在產生完備的測試案例之後，我們知道每一組測試案例都代表著一條潛在弱點的 可執行路徑，但是這些路徑中可能還潛藏一些誤報的可能性。我們先看 Figure 3.1 的第 9 行的第一個程式接收點，到達此接收點跟變數 id 的長度有關，變數 id 會 受外部呼叫函式 idCheck 的影響。接著從 Figure 3.2 看到函式 idCheck 分成兩條 路徑，第一條路徑在符合第 2 行條件式下回傳變數 s 值；而第二條路徑在第 5 行 陣列 array 會分別在 array[0]和 array[1]存入變數 s 與常數值”00000”，第 6 行回傳
01 public String idCheck(String s) { 02 if (s.matches("[A-Z][^a-z]+")) { 03 return s;
04 } else {
05 String[] array = new String[]{s,"00000"};
06 return array[1];
07 } 08 }
Figure 3.2 Inter-procedural call out method idCheck of Java Servlet example
array[1]為常數值”00000”。回顧 Figure 3.1 中第 7 行 id 變數的值，上述兩條路徑 回傳值的結果都會使 id 變數長度符合第 8 行的條件式而到達程式接收點，但只 有第一條路徑會造成潛在弱點。因為第二條路徑經過的陣列初始化後，靜態分析 只知道汙染資料變數 s 會被加入陣列中，而將整個陣列視為被污染。無法辨認 array[1]為常數值”00000”，實際上不會造成弱點發生，是一種誤報的情況。
而在測試案例執行的目標就是希望進一步利用弱點判斷的準確性改善弱點 誤報。我們利用剖面導向程式語言 AspectJ 對目標程式作插碼來實現動態汙染資 料流分析，以達成改善誤報的目標。以上就是本論文系統設計想要達成的目標以 及考量，後面會開始作系統架構概觀的描述與系統元件的設計概念。