第一章 緒論
1.1 前言
軟體的發展日新月異，所能達成的功能越來越多。資訊化幾乎是現在這個社 會大家都有的共識，因此社會上使用電腦跟軟體的領域也快速的成長。便利商店 收銀機器上應用著一個收銀軟體，銀行當中的提款機也使用著銀行業務軟體，醫 院的病歷管理也從原本的紙本作業變成電腦上的資訊的處理。若要和人溝通，透 過網路使用即時通訊的軟體可以和世界上各地的人即時通訊。使用網路電話的軟 體跟國外的朋友聯絡，可以節省撥打國際電話的費用。一般企業也使用著這些科 技，例如帳單或是公文的電子化，不但有效地增進處理的效率，也減少了對紙張 的浪費。這些情況都代表著應用軟體的領域越來越廣，現代人的生活對軟體的依 賴也越來越重。
軟體存在一種問題至今仍無可避免，就是軟體會發生錯誤。軟體會發生錯誤 的原因分作幾點：
1. 載入程式平台上的錯誤-以 Java 程式為例，Java Virtual Machine(JVM)負責 載入 Java 程式到作業系統執行。若 JVM 載入程式執行卻因為系統記憶體不足 而無法產生物件，此時 JVM 將會丟出 OutOfMemoryError。這種是屬於載入程 式的平台上的錯誤。這種錯誤不一定是程式設計上的錯誤，在此例當中，有 可能是 JVM、作業系統甚至是硬體上的原因造成軟體發生錯誤。
2. 程式本身設計不正確所造成之錯誤-這種錯誤發生的原因在於程式設計師撰 寫程式的時候設計不當，導致程式在執行時發生錯誤。這種情況若發生，使 用者無法對程式做任何處理，而在程式發生錯誤的原因這種情況卻相當常 見。因為軟體是一種具有很複雜行為的東西，所以程式設計師在撰寫程式時 往往很難考慮到一個軟體的所有使用情況，而導致程式內部有所謂的臭蟲
(bug)。
軟體在執行時若遇到上述這些情況就會發生錯誤而中斷執行，軟體的發展一 直在進步，而處理軟體發生錯誤的方法也應該要有所進步。本研究主要針對程式 本身設計錯誤的情況做探討，提出軟體錯誤診斷的概念。透過這個概念，讓未來 在各種不同領域使用軟體的人，若遇到程式本身設計不正確而導致軟體發生錯誤 中斷的情況，能對錯誤進行後續的處理。
1.2 研究動機
當軟體執行時發生錯誤，使用者往往對發生錯誤的軟體的處理方式相當有 限。例如選擇回報或是不回報錯誤訊息，然後再關閉程式。或是作業系統出現錯 誤訊息，使用者重新啟動作業系統。無論是哪一種，對於避免下次系統再發生類 似錯誤都沒有太大的幫助。
針對上述情況本研究提出軟體錯誤診斷(software crash diagnosis)的概念 及其設計架構，對於軟體發生錯誤而中斷的情況進行診斷。紀錄發生錯誤後軟體 所留下之部份資訊，並且利用這些資訊對軟體錯誤的原因進行分析以及評估，找 出可能造成錯誤之軟體元件。軟體發生錯誤的原因經過評估後的結果，以軟體的 元件做為基本單位，並以元件圖(component diagram)顯示系統架構，然後加入 評估的結果呈現給使用者參考。
軟體元件的概念在軟體業界推廣已久，也有不少軟體公司針對元件的標準進 行統一的訂定。根據這種趨勢未來有可能在軟體上會訂定各式各樣的元件，每一 個元件都提供已經規定好的介面，使用者可以任意置換組裝。在這樣的假設下，
使用者可以對軟體當中可能造成錯誤的元件進行置換，例如把舊版本元件更新成 新版本的元件。以上是我們對於使用者處理軟體發生錯誤的新想法。使用者不再 被動地等待程式設計師修改軟體當中的錯誤，而是主動的對軟體內部元件進行替
換，也許可以在使用者進行後續處理之後，避免相同錯誤再次發生。而軟體仍然 能夠正常的運作。
在軟體工程中元件的定義之一為元件提供穩定的介面跟外部元件互動，並且 是一個獨立的部份[16]。在此定義為前提下，當我們將軟體以元件為單位呈現架 構圖給使用者，理論上使用者可以針對部份元件進行替換，軟體替換過新的元件 後仍可穩定執行。若是以其他單位，則不一定能夠隨意替換，因為其他呈現方式 的單位不一定提供穩定的介面，若將其置換，可能導致軟體無法繼續運作。因此 我們決定使用元件作為我們呈現結果的單位，用以達到使用者置換軟體元件卻不 影響整個軟體的運作。
在 軟 體 錯 誤 診 斷 系 統 的 設 計 上 ， 本 研 究 使 用 了 program slicing[6][9][10][11][18][19]技術作為輔助。Program slicing是一種簡化程 式的技術，透過選擇程式中欲觀察的變數，將不會影響到此變數的值的敘述排除 在外，留下直接或是間接影響變數的敘述集合，這個集合便叫做slice[13]。我 們 把 欲 觀 察 的 變 數 叫 做 criterion ， 一 般 而 言 criterion 被 定 義 為 一 個 組 合 (tuple)：criterion=(i ,V)，i通常代表程式當中的敘述句位置(行號)，V則是 在程式當中變數的子集(subset)[11]。透過program slicing的分析可以有效的 排除不必要分析的資訊，也因此program slicing技術常使用於維護、測試、軟 體驗證、除錯或是理解程式等軟體工程領域[6][9][19]，本研究將其運用作為診 斷軟體發生錯誤原因的技術之一。
本研究設計了許多規則(rule)作為分析方法用來辨識出使軟體發生錯誤的 變數並且將這些變數設定為criterion進行program slicing，產生的slice則為 可能造成軟體發生錯誤的指令集合。而我們設計的部份規則也會分析這些slice 當中的指令，若當中部份指令的格式符合某些規則條件，則根據規則當中訂定的 行 為 來 動 作 ， 如 標 記 程 式 碼 。 我 們 設 計 規 則 將 軟 體 錯 誤 診 斷 架 構 成 一 種
rule-based的原因在於：軟體發生錯誤的原因相當複雜且多樣化。以Java程式舉 例NullPointerException以及ArithmeticException : divided by zero，這兩 種錯誤發生情況相差甚遠，程式發生NullPointerException的原因在於使用一個 null的物件的方法或是存取其field值；而ArithmeticException : divided by zero則是因為程式在做數值運算時，被除數為一個值為 0 的整數變數，對於這兩 種錯誤情況，就已經很難用單一的方法同時進行評估。也因此面對各種軟體發生 錯誤的情況，我們目前不考慮只用一種演算法來處理所有造成軟體錯誤的原因。
所以本研究設計並且使用規則對軟體內部指令進行分析，診斷各種軟體發生相異 錯誤的情況，也提昇了軟體錯誤診斷系統分析方法的擴充性。
1.3 研究目標
綜合上述的分析，可整理幾個對於軟體錯誤診斷系統開發的方向：
1. 軟體錯誤診斷系統提供給使用者一個對於軟體發生錯誤之後，能對軟體進行 後續處理的方法。例如從網路上抓取功能及介面相同的元件，替換可能造成 錯誤的軟體元件。避免軟體因為內部設計不當，一再發生相同錯誤。
2. 使用 program slicing 的技術，輔助系統排除軟體當中不必要的資訊，縮小 診斷軟體之範圍。
3. 設計許多規則(rule)用以分析軟體內部程式碼，推導出整個軟體當中可能造 成軟體發生錯誤原因之部份。
4. 使用UML2.0 當中的元件圖呈現評估系統後的結果，利用軟體元件的特性，達 到第一點所提到的使用者可以軟體內部進行替換，卻又能維持軟體運作。
1.4 論文架構
本研究分為五章：首先，第一章說明了研究動機與目標。第二章將會介紹軟 體錯誤診斷所使用的一些背景知識、技術以及名詞定義做介紹，例如 Java 的類
別載入器、Java exception 的分類、程式的依存性、program slicing 以及 ProGrammar。第三章則是討論軟體錯誤診斷的概念，本研究如何設計軟體錯誤診 斷系統的架構。第四章加以探討與分析許多 Java 程式發生錯誤的案例。第五章 則提出結論以及軟體錯誤診斷未來的方向。
