2018 OO第一次總結（做業1-3）

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　第一次做業
1.程序分析

（1）OO度量


（2）類圖：

（3）分析與評價：

 此次做業因爲做業總體設計難度不大，所以按照去年暑假上的OO先導課老師講的設計方法很容易實現一個還不錯的面向對象式程序，類與類之間的耦合度不是很高。可是即第一次簡單的做業仍是在設計上出現了漏洞被找到了bug，說明設計作的仍是不夠充分。
類圖分析：本次設計分爲Poly類，InputDeal類，Main類，Item類，其中Item類實現了Comparator接口，Main類主要進行主函數運行。Item是一個項數和係數的偶對，而且經過Comparator接口進行按照指數遞增的順序排序。InputDeal的主要做用是對輸入序列進行處理，包括合法性檢查。
2.

　　本次做業公測全部測試樣例點所有經過，互測的時候被發現一個bug，緣由是若出現(0,0) (0,0)兩個指數和係數都爲0的程序不會判斷(0,0)是指數重複。出現這個問題的緣由是程序採用了鏈表存儲相應多項式信息，首先會將係數爲0的項刪掉，使其不能加入到鏈表之中去，而後再進行判斷是否出現重複指數的操做。此次錯誤出如今InputDeal類的read_poly方法之中。
　　從設計結構角度來看，這個bug出現的緣由主要仍是在於自我設計的時候沒有將設計的先後順序等弄明白，程序的流程控制出現了問題。
從分類樹角度來看，雖然在測試的時候注意到了指數重複這個錯誤樹分支，可是測試使用的相同指數狀況沒有構造出係數爲0的狀況，係數爲0的狀況主要被用於測試當多項式最後爲空的時候的輸出是否正確。

3.測試策略：自我測試的時候按照分支樹生成了測試數據，先對對方進行粗測，再結合代碼進行進一步測試。
　　此次做業抽到的同窗公測出現了一個bug，表現形式是會多輸出一個逗號。通過閱讀代碼以及調試，發現緣由來自於輸出控制不當，當最後計算結果冪常數項爲0的話會多輸出一個逗號，由於這個逗號是放在全部係數和指數都不爲0的項輸出以前的。因爲這次任務比較簡單，針對本身有疑問的幾個帶代碼片斷也進行了針對測試，並未發現問題。

 

　　　　　　　　　　　　　　　　　　　　　　　　　　第二次做業
1.程序分析
（1）OO度量

（2）類圖：

 

（3）分析與評價：

　　此次做業經歷了從模擬時間到記錄請求完成時間來判斷同質兩種設計方式的轉變，單就本次做業來講，後者的編程複雜度遠遠比前者低。存在的最主要問題就是在遇到一個稍微複雜的問題時候如何快速並且合理地劃分出不一樣的類，如何合理分配每一個類的行爲與方法。

類圖分析：本次設計主要分Main Request Queue Floor Lift Scheduler類這幾個類，Main類是運行主函數，當從main類輸入一條指令會送到Floor或者Lift類進行合法性判斷，並由電梯和樓層類發出請求（向Queue對象中插入一個Request類對象）。而後輸入完畢後調度器依次遍歷Queue請求隊列中的全部請求，輸出多了人類主要有schedule方法（負責判斷同質以及調度），pop方法將輸出當前執行過的請求並打印出相應的信息。



2. 本次做業公測和互測部分順利經過
　　此次做業讓我認識到了bug和設計結構密切相關，原本是採用了模擬時間的寫法，可是在幾個開關門瞬間的理解條件老是處理不當，致使老是出現了各類意想不到的bug。後來採用了記錄按鈕熄滅的時間來判斷是不是同質請求，代碼邏輯變得簡單起來，後期調試和測試也簡化了很多。

3.此次程序最後並無在互測階段發現對方的bug，可是在嘗試找bug的過程當中收穫了很多的知識。
　　採用的測試策略：先使用本身編程的時候構造的分支樹測試樣例對對方程序進行粗查，隨後結合代碼對可能出現的隱患位置進行重點攻破。
在瀏覽一遍對方的代碼以後，發現了一個頗有可能出現問題的狀況：對方讀取時間的正則匹配是無限個數字，可是在將字符串轉爲數字的時候並無try-catch去捕捉parseDouble產生的異常，這個地方最初在我看來是有很大隱患的：double的數據範圍也是有限的，假設輸入時間位數超過double的範圍，且最高一位是1，其他位是0的話，若是發生溢出，高位丟失，而後就會出現將一個很大的數讀成0或者是直接程序crash。可是通過嘗試發現每次都沒有出現問題，到此處單步調試後發現原來的數字被讀成了infinity，並且這個infinity默認大於全部的數。上網查閱資料發現infinity不等於MAX_DOUBLE,而是大於MAX_DOUBLE,因而構造MAX_DOUBLE 和infinity之間的數字，可是結果發如今eclipse之中只要超過MAX_DOUBLE 就會識別爲infinity,與資料不符。這個過程當中雖然最後證實了該同窗的程序不存在問題，可是我仍然認爲在使用這種有可能出現異常的函數時應該養成使用try-catch的習慣。



　　　　　　　　　　　　　　　　　　　　　　　　　　　第三次做業

1.程序分析
（1）OO度量

 

（2）類圖：

 

 

（3）分析與評價：

 　　此次做業因爲第二次做業的設計方法對於此次做業來講不是很適合可是又必須繼承第二次做業的關鍵類，因此在修改的過程當中爲了追求代碼的正確性犧牲了許多老師提到的良好的設計習慣。最大的體現就是核心類的方法過多，每一個方法代碼長度比較長，並且分支結構太多，這些都是代碼的隱患，在之後的做業中要儘量的避免這類狀況的出現。量化分析結果也代表塊嵌套層數過多，這種問題之後在編程的時候必定要注意。
類圖分析：本次設計主要分Main Request Queue Floor Lift Scheduler NewScheduler類這幾個類，Main類是運行主函數，當從main類輸入一條指令會送到Floor或者Lift類進行合法性判斷，並由電梯和樓層類發出請求（向Queue對象中插入一個Request類對象）。而後輸入完畢後調度器依次遍歷Queue請求隊列中的全部請求，對是否同質以及是否能夠捎帶進行判斷。其中is_same是判斷是否同質的方法，而set_mr是設置主請求的方法，update是在進行捎帶以後更新到達指定樓層的方法。



2.自我程序分析
　　本次程序順利經過公測和互測環節，可是完成程序初稿的過程就遇到了很多的bug。這些bug主要集中於對上次的類Scheduler繼承後重寫的新的schedule方法之中。此次在編寫後程序明顯感覺到了第二次設計樣式的不足，第二次主要是模擬當前按鈕熄滅的時間並無關心當前電梯的運動狀態，這種寫法在第二次設計起到顯著的簡化設計的做用，可是卻爲第三次設計形成了許多困擾。

3.測試方法

　　本次測試仍然是採用自測的時候按照測試樹生成的測試樣例加上採用結合代碼進行鍼對測試。可是此次在使用自測的樣例的時候就測試出兩個問題，一個是同質請求判斷的問題，另外是捎帶狀況處理的邊界條件沒有處理好。閱讀代碼後發現同質請求判斷失敗的主要緣由是隻判斷了相對於主請求是不是同質請求，而沒有判斷相對於其餘捎帶請求是否同質。

    

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　總結
1.    關於設計問題
　　第二次做業本來的設計是想模擬現實真實的情況，在外部模擬一個系統真實時間，把請求映射到電梯按鈕的熄滅和按亮狀態，只有在時間到達了相應的請求發出時間請求才會開始被訪問，可是這樣寫出來的代碼跟同窗的直接記錄這個請求完成時間來判斷同質相比仍是顯得複雜了一些。因而便也採用了記錄請求完成時間來判斷同質的作法。可是第三次做業在第二次做業的基礎上修改起來就很繁瑣，也加上了許多判斷控制條件，使得代碼的結構以及邏輯變得極其複雜，還要對指導書上的捎帶條件進行等價轉換，整個過程十分複雜，頗有可能須要在下一次的電梯做業進行代碼的大量重構。通過第三次做業我深入體會到了設計對於後續的修改以及調試起的決定性做用，通常來講，越是能模擬現實狀況的設計在後期編寫代碼的時候就越容易實現以及調試測試。每次本身在測試找到bug以後更要及時反思緣由，若是是編程過程出現實現不當，那麼就要勤加練習，讓本身的動手能力跟得上本身的思惟。反之若是是設計過程當中出現的顯著漏洞，那麼在每次做業以後必定要按時反思設計漏洞，不斷規範設計流程和思路。
2.    善用eclipse的TODO標註功能
　　每次做業都不多是一個下午和晚上就可以徹底實現，並且每次編寫代碼的時候也不能保證某個地方的邏輯百分之百正確。在同窗的推薦下，我開始使用eclipse的TODO標記功能，能夠在有疑問的地方作下標記，後續做爲測試的重點。晚上睡覺前或者是吃飯前能夠對手頭上的還沒有徹底完成的步驟進行標註，以便回來後繼續完成。

3. 關於設計與編碼的關係感想

　　第一次在課堂上聽到老師強調設計的重要性是上學期計組課上高老師在P4以後反覆強調在工程實現過程當中設計的構思甚至花的時間應該超過敲代碼的時間。快速寫完代碼後花大量時間找bug不只讓你整個工程的時間不會減小，更會讓你的程序變成一個打滿補丁並且不規範的程序。第三次做業度量分析以後被標紅的部分（塊嵌套過深）就是源於不停地向程序打補丁致使方法愈來愈多，調用愈來愈深。在從此的做業項目中必定要進行更細緻的設計，甚至能夠先構造大量樣例對設計進行調試，確保設計的完備性以後再進行編碼過程。在本文的最後附上上學期計組老師在作P5時給予咱們的忠告，但願時刻能提醒本身。