OO第三階段做業總結

調研：

       最先的程序設計是直接採用機器語言來編寫的，或者使用二進制碼來表示機器可以識別和執行的指令和數據。機器語言的優勢在於速度快，缺點在於寫起來實在是太困難了，編程效率低，可讀性差，而且編寫規模大的程序。以後逐漸產生了面向過程和麪向對象的編程思想，來知足不一樣條件下的編程方式。1968年《GOTO有害論》這篇著名的論文發表後，引發了許多人的普遍關注，結構化思想逐漸進入人們的視野。以後在編程過程當中，程序員愈來愈對已經產生的抽象水平不滿，不足以知足他們對規模大的程序編寫的需求，所以出現了一種語言機制，也就是規格化抽象，容許程序員在須要時構建本身的規格化設計方法。規格化抽象是將運行細節（即模塊如何實現）抽象爲用戶所需求的行爲（即模塊作什麼）。在規格化設計的基礎上，各個模塊表達得簡明扼要，可讀性強，規模大，耦合性好，所以愈來愈受到人們的重視。規格化是程序發展所必要的條件。

 

BUG分析：

        第九次做業：

 

BUG內容	BUG類型	BUG緣由
map加載錯誤	crash	在loadfile的時候存取數組越界
出租車運行20s沒有停1s	error	在設置出租車行駛方式時疏忽
地圖文件中有空格	crash	未處理異常狀況
出租車運行一邊的時間有可能超過500ms	error	隨機數設置錯誤

 

        BUG產生緣由：此次的BUG最主要的問題在於對新增的要求Loadfile的設計過於粗略，沒有考慮到各類不合理的狀況，在功能上的實現不徹底，同時也沒有花時間去debug，認爲其不重要，這就是自作自受，而後致使了兩個crash類型的bug，其實測試者很善良，若是再仔細一點，估計還會多不少的crash類BUG。同時因爲上次沒有發現這兩個error的BUG，致使此次被測了出來。總而言之就是設計不夠細緻，同時沒有花時間去debug。

        第十次做業：

BUG內容	BUG類型	BUG緣由
沒有選擇流量最小的路徑	error	在讀取流量文件時存儲出錯
調度時間少於7.5s	error	因爲總體時間上升，但忘記設置調度時間了

        

        BUG產生緣由：此次的BUG蠢得讓我無話可說，先說調度時間少於7.5s，因爲以前改變了出租車行駛地圖一條邊的時間，從200ms增到了500ms，因而出租車調度時間從3s增長到了7.5s，可是我忘記改正這個地方了。不知道爲何上一次做業沒給我測出來，而後一直錯到了如今。很神祕。

        第十一次做業：

        通過兩次做業的痛定思痛，把前兩次的bug所有de完了，而且此次做業是最後一次編程做業，所以格外用心，因此沒有被挑出bug來，能夠說結尾得還行了。

 

JSF的不足和改進：

        前置：

        1. 大量使用None；（本人就喜歡這麼幹）

            例如：方法public boolean judge(String filename)

            改正前：@REQUIRES: None;

            改正後：@REQUIRES: filename != null;

        2. 缺少類型描述

            改正前：@REQUIRES: map.exist && map.bound <= 80;

            改正後:  @REQUIRES: map.exist == true && map.bound <= 80;

        3. 忽略範圍限制

            例如：方法public BFS(point E, point S)

            改正前：@REQUIRES: E != null && S != null；

            改正後：@REQUIRES: 0<= E.getx() <=79&&0<= E.gety() <=79 && 0<= S.getx() <=79&&0<= S.gety() <=79;

        4. 多餘的前置條件

            改正前：@REQUIRES: num != null && num <= 80;

            改正後：@REQUIRES: num <= 80;

        後置：

        1. 使用天然語言（本人見過直接用中文的）

            改正前：@REQUIRES: 若是a包含了b，則返回true；

            改正後:  @REQUIRES: a.contains(b) ==> (/result == true)；

        2. 考慮得不周到，只寫了一部分

            改正前：@REQUIRES: a.contains(b);

            改正後：@REQUIRES: a.contains(b) && a.size() = a.size() - 1;

        3. 使用了錯誤的僞布爾式子

            改正前：@REQUIRES: flow.add;

            改正後：@REQUIRES: flow.add == true;

        目前遇到的，而且也只能想到以上幾點前置條件和後置條件容易出錯的地方。其實使用天然語言是能夠的，可是不能大量使用，仍是應當使用布爾表達式來表示。其實感受JSF的撰寫仍是十分的有必要的，在debug的時候，JSF可以起到很好的預覽做用，能夠大體判斷出bug出現的位置。第一次寫可能會出錯或者不適應，到後來就發現了JSF的實用之處。

 

感想和體會：

        本人在完成做業時，是把整個程序的功能都完成後，再回頭去寫JSF的規格設計，而後發現對於代碼量龐大的方法，須要花大量時間去回憶這個部分的功能和做用才能完成JSF的撰寫。並且再debug階段也很花費時間和精力。所以規格應當是在方法撰寫以前就開始設計，同時在代碼中就應當按照規格來完成方法。這樣不只在設計時不須要花費大量時間去處理，在debug時也能更快的找到問題出現的位置。OO的編程做業終於完結了，撒花撒花。