調研：
最早的程式設計是直接采用機器語言來編寫的，或者使用二進制碼來表示機器能夠識别和執行的指令和資料。機器語言的優點在于速度快，缺點在于寫起來實在是太困難了，程式設計效率低，可讀性差，并且編寫規模大的程式。之後逐漸産生了面向過程和面向對象的程式設計思想，來滿足不同條件下的程式設計方式。1968年《GOTO有害論》這篇著名的論文發表後，引起了許多人的廣泛關注，結構化思想逐漸進入人們的視野。之後在程式設計過程中，程式員越來越對已經産生的抽象水準不滿，不足以滿足他們對規模大的程式編寫的需求，是以出現了一種語言機制，也就是規格化抽象，允許程式員在需要時建構自己的規格化設計方法。規格化抽象是将運作細節（即子產品如何實作）抽象為使用者所需求的行為（即子產品做什麼）。在規格化設計的基礎上，各個子產品表達得簡明扼要，可讀性強，規模大，耦合性好，是以越來越受到人們的重視。規格化是程式發展所必要的條件。
BUG分析：
第九次作業：
| BUG内容 | BUG類型 | BUG原因 |
| map加載錯誤 | crash | 在loadfile的時候存取數組越界 |
| 計程車運作20s沒有停1s | error | 在設定計程車行駛方式時疏忽 |
| 地圖檔案中有空格 | 未處理異常情況 | |
| 計程車運作一邊的時間有可能超過500ms | 随機數設定錯誤 |
BUG産生原因：這次的BUG最主要的問題在于對新增的要求Loadfile的設計過于粗略，沒有考慮到各種不合理的情況，在功能上的實作不完全，同時也沒有花時間去debug，認為其不重要，這就是自食其果，然後導緻了兩個crash類型的bug，其實測試者很善良，如果再仔細一點，估計還會多很多的crash類BUG。同時由于上次沒有發現這兩個error的BUG，導緻這次被測了出來。總而言之就是設計不夠細緻，同時沒有花時間去debug。
第十次作業：
| 沒有選擇流量最小的路徑 | 在讀取流量檔案時存儲出錯 | |
| 排程時間少于7.5s | 由于整體時間上升，但忘記設定排程時間了 |
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的程式設計作業終于完結了，撒花撒花。