OO第三次博客做業

面向對象第十二次做業暨第三次博客做業

1、探究規格化設計

　　1.面向機器編程

　　　　從最初的打孔式編程到彙編語言，本質上都是對人很不友好的面向機器編程，儘管彙編語言相對於二進制編碼有了更高的可讀性，可是由於不直觀、最簡單的邏輯過程也要編程者一步步緊盯着，很是容易出錯。

　　2.面向過程編程

　　　　面向過程是一次思想上的飛躍，將程序員從複雜的機器操做和運行的細節中解放出來，轉而關注具體須要解決的問題。

　　3.軟件危機

　　　　如今咱們能借鑑的編程經驗與約定俗成的習慣都是前人從經驗與失敗中總結出來的成功率更高的規律：

　　　　軟件危機最典型的例子莫過於 IBM 的 System/360 的操做系統開發。佛瑞德·布魯克斯(Frederick P. Brooks, Jr.)做爲項目主管,率領 2000 多個程序員夜以繼日的工做,共計花費了 5000 人一年的工做量,寫出將 近 100 萬行的源碼,總共投入 5 億美圓,是美國的「曼哈頓」原子彈計劃投入的 1/4。儘管投入如此巨大, 但項目進度卻一再延遲,軟件質量也得不到保障。布魯克斯後來基於這個項目經驗而總結的《人月神話》 一書,成了史上最暢銷的軟件工程書籍。

　　　　第二次軟件危機的根本緣由仍是在於軟件生產力遠遠跟不上硬件和業務的發展,相比第一次軟件危機主要 體如今「複雜性」,第二次軟件危機主要體如今「可擴展性」、「可維護性」上面。傳統的面向過程(包括 結構化程序設計)方法已經愈來愈不能適應快速多變的業務需求了,軟件領域迫切但願找到新的銀彈來解 決軟件危機,在這種背景下,面向對象的思想開始流行起來。

　　4.規格化設計的誕生

　　　　規格化設計不是一次就完整的提出來的，一套完備有效的規格化設計標準也有一個發展的歷程：1960年代晚期至1970年代晚期的期間中，編程語言的發展也有了重大的成果。大多數如今所使用的主要語言範式都是在這段期間中發明的。在1960年代以及1970年代中結構化程序設計的優勢也帶來許多的爭議，特別是在程序開發的過程當中徹底不使用GOTO。[跑題]在正式上大學學習編程以前就聽過一個關於GOTO的段子，在一部各類編程語言擬人化的漫畫中，C語言在田徑項目中因爲使用GOTO語句在前半圈領先衆人（衆語言），在最有一個彎道直接跳到了未定義區域衝出了跑道GG。

　　　　1980年代的編程語言與以前相較顯得更爲強大。C++合併了面向對象以及系統程序設計。在語言設計上有個重大的新趨勢，就是研究運用模塊或大型組織化的程序單元來進行大型系統的開發。這一階段程序的模塊化、標準化程度進一步提升。

2、做業中關於規格的BUG

做業	分支名稱	錯誤位置	問題緣由
第九次做業	JSF不符合規範	Taxi.java	@和REQUIRE沒有連在一塊兒
第十次做業	JSF不符合規範	/	由於想寫成標準的英文不使用天然語言，部分EFFECTS留空，申訴後測試者認同個人想法撤回了BUG
第十一次做業	/	/	通過三次重寫，規格部分看起來好多了

3、分析BUG緣由

 　　在課程學習過程當中個人問題主要出如今兩個地方：

　　1.開始時規格書寫不規範

　　　　第一次沒有仔細看JSF說明犯了不少錯誤…感謝此次的測試者沒有在JSF上大作文章，而是很實在地經過一個bug指出了個人問題並給出了一些建議。

　　2.使用了天然語言描述

　　　　第一次時使用了天然語言描述，在OO第五次課上實驗後，由於提供的代碼中有不少規範的JSF書寫，因此才學會了該怎麼寫，可是此時EFFECTS部分個人理解還不對，不少地方留了空，而且理解錯了OVERVIEW的功能，幸運的是測試者理解、接受了個人想法，沒有在JSF上扣太多而是把測試和討論重點放在了代碼自己上；後來在第十一次做業我也儘快改正了以上的問題。

4、條件寫法的改進　　

 　　1.　　使用天然語言描述

　　改進方法：　　　使用標準的符號語言描述邏輯關係

　　2.　　「@ REQUIRES」中間留有空格

　　改進方法：　　改成：　　* @REQUIRES

　　3.　　誤認爲返回值void類型的方法EFFECTS能夠留空

　　改進方法：　　像返回值爲boolean類型的方法應有\result相關描述，void類型的方法的EFFECTS中若是不爲null就將改變過涉及的類屬性都寫全；

　　4.　　線程安全的方法規格不完備

　　改進方法：　　

　　　　*@THREAD_REQUIRES: locked(this);
　　　　*@THREAD_EFFECTS: locked(m);

　　5.　　再簡單的方法也要寫完善的JSF，側面說明另外一個問題

　　改進方法：　　某次測試中個人被測有幾個功能很是簡單的方法，只有一行return，可是沒有寫JSF，側面說明另外一個問題就是各個方法之間功能性「不均衡」

5、分析彙集關係

做業	方法名	BUG	與JSF彙集關係
第九次做業	/	Request有一些問題	加了沒必要要的線程鎖，JSF冗餘
第十次做業	serve	接單後沒有暫停1s模擬上下車	主要是readme看漏了，JSF的EFFECTS部分也沒有寫全
第十次做業	setLight	在不合法路口設立紅綠燈時沒有給出輸出提示	/
第十一次做業	/	/	/

 

6、概括總結

 　　由於陌生，因此會犯錯；我比較幸運，遇到的測試者將測試重點放在功能上，只是在JSF部分指出我確實存在的問題沒有把JSF當作刷分的工具。可是看到身邊不少同窗被扣不少不少JSF，我內心仍是很難受的，教學團隊爲了讓咱們重視規格因此將之加入了互測，可是即便設置了扣分上限仍是可能會受到不公正的待遇，每週四晚上十點點開oj就跟開獎同樣，若是是兩三個BUG，能夠心平氣和地把不合理的申訴了跟測試者聊聊天；要是一點開一片紅，仔細一看還一大片JSF，能夠洗洗睡了。平心而論我也由於互測好幾回很生氣，可是說實話沒有想到更有效的讓咱們重視規格化的方法，老師一再強調這東西有時比代碼自己更重要，可是就算設置個OO期末考試也很差測試這個，就當是把期末考試那種瞬間的緊張和難受分攤到平時了吧。若是能夠提建議的話，我以爲OO第五次、第六次提供的代碼中的JSF都寫的很是不錯，若是在第一次書寫規格時就提供這些（標準的）代碼做爲參考的話，你們犯的錯誤可能會更少一些。

　　就我本身來講，經過這三次規格的撰寫，對於如何介紹本身的函數、如何確保個人類和方法有效有了必定的掌握，可是在讀了一些標準庫的代碼後以爲本身所寫、所考慮的還有不少欠缺。