OO第三次博客做業

一、規則化發展歷史調研

　　程序中的規格化設計的發展歷史，與計算機的發展歷史、編程設計的發展歷史是緊密相連，密不可分的。從1940年的面向機器編程，到以後的面向過程編程，逐漸出現了咱們如今使用的各個語言的原始版本。而隨着代碼量的不斷增長，程序功能的不斷複雜化，簡單的面向過程編程再也不可以知足人們的須要，所以，出現告終構化程序設計。而從這一過程當中，編寫代碼的人們也注意到了規格的重要性。「結構化程序設計」做爲另一種解決軟件危機的方案被提出來了。 Edsger Dijkstra 於 1968 發表了著名的《GOTO 有害論》的論文,引發了長達數年的論戰,並由此產生告終構化程序設計方 法。同時,第一個結構化的程序語言 Pascal 也在此時誕生,並迅速流行起來。在此以後，隨着硬件的快速發展，程序的複雜度迎來了再一次的飛躍，而這時出現了面向對象編程。此後規格化獲得了人們愈來愈多的重視，由於其能夠幫助閱讀者迅速理解代碼，也能幫助設計者更好的設計、規劃本身的程序，避免因爲粗枝大葉形成的種種錯誤。

二、規格BUG分析

	規格BUG	功能BUG	是否有聯繫
第九次做業	0	0	無
第十次做業	1	2	無
第十一次做業	0	2	無

惟一一個規格BUG是某一個類規格的抽象對象不明確。而4個功能BUG中，3個都是因爲後來做業中，每次更新新的GUI時，總會漏掉某一些以前做業中對於GUI的更改（好比對於時間的更改。。）。

三、規格BUG產生的緣由

　　第十次做業中規格BUG產生的緣由，是對於抽象對象的概念不明確。也能夠說是對類規格整體概念的不明確。在以後特地翻閱了前幾回的全部PPT，雖然沒有對抽象對象的明肯定義，但根據上下文，以及對於類規格的理解更進一步後，也算是更加理解了抽象對象的概念 吧。

四、5個前置條件和後置條件很差的寫法

一、前置條件、後置條件不許確。

修改前：

/** @ REQUIRES: r!=null
@ MODIFIES: this
@ EFFECTS: RL[len++]=r
@ THREAD_REQUIRES:
@ THREAD_EFFECTS:
@ */

修改後：

/** @ REQUIRES: r!=null
@ MODIFIES: this
@ EFFECTS: r.repOK()==true ==> (RL[len++]==r) && (RL.contain(r)==true);
@ THREAD_REQUIRES:
@ THREAD_EFFECTS:
@ */

二、使用了天然語言

/** @ REQUIRES:
@ MODIFIES: chead
@ EFFECTS: 將RL隊列的頭指針更新到相應位置
@ THREAD_REQUIRES:
@ THREAD_EFFECTS:
@ */

修改後：

/** @ REQUIRES:
@ MODIFIES: chead
@ EFFECTS: while(head<len && RL[head].issleep==false) ==> head++;
@ THREAD_REQUIRES:
@ THREAD_EFFECTS:
@ */

三、沒有關於異常的信息

/** @ REQUIRES:
@ MODIFIES:
@ EFFECTS: AL.hasNext() ==> \result == AL.Next();
@ THREAD_REQUIRES:
@ THREAD_EFFECTS:
@ */

修改後：

/** @ REQUIRES:
@ MODIFIES:
@ EFFECTS: AL.hasNext() ==> \result == AL.Next();
@ Otherwise ==> throw NoSuchElementException
@ THREAD_REQUIRES:
@ THREAD_EFFECTS:
@ */

四、沒有及時更新

/** @ REQUIRES:
@ MODIFIES:
@ EFFECTS: str == CheckTaxi ==> \result=1;
@str == CheckStatus ==> \result=2;
@else \result=0;
@ THREAD_REQUIRES:
@ THREAD_EFFECTS:
@ */

修改後：

/** @ REQUIRES:
@ MODIFIES:
@ EFFECTS: str == CheckTaxi ==> \result=1;
@str == CheckStatus ==> \result=2;
@str == SetRoadStatus==> \result=3;
else \result=0;
@ THREAD_REQUIRES:
@ THREAD_EFFECTS:
@ */

五、不完整

/** @ REQUIRES: 0<=LP,CP,NP<80
@ MODIFIES:
@ EFFECTS: light's red ==> \result==wait time;
@ light's green ==> \result==0;
@ THREAD_REQUIRES:
@ THREAD_EFFECTS: \lock(guigv.lightmap);
@ */

修改後：

/** @ REQUIRES: 0<=LP,CP,NP<80
@ MODIFIES:
@ EFFECTS: (light's red) || (direction == right) ==> \result==wait time;
@ light's green ==> \result==0;
@ THREAD_REQUIRES:
@ THREAD_EFFECTS: \lock(guigv.lightmap);
@ */

五、功能BUG與規格BUG在方法上的彙集關係

　　在這一單元的三次做業中，功能BUG與規格BUG沒有彙集關係。規格BUG出如今InputHandler的類規格中，而4個功能BUG中，2個源於同一個緣由，即在LoadFile類中，緣由是忘記將編號-1再做爲下標。而另外2個都在不要求寫規格的GUI中。因爲GUI中的默認設置和新修改後的規定不一致，沒有修改徹底（忘記了某一個東西要改）形成的。

	功能BUG	規格BUG
InputHandler	0	1
LoadFile	2	0
Gui	2	0

 

六、基本思路和體會

　　能夠體會到，在未來咱們在實習中、工做中所要處理的大型工程中，完善、統1、嚴格的規格是十分必要的。這樣的好處有：

一、減小出現低級BUG的機率，極大的減小了後期DEBUG時須要的時間，提升了工做效率。

二、方便在團隊合做時的契合，使本身的代碼可讀性更高，在其餘同伴理解、使用本身的代碼時，基本上不會出現過多的誤差。

三、優化本身的代碼風格，加強本身的代碼編寫能力。

　　寫規格的思路：在寫規格時，應儘可能使用布爾表達式。而這一重要原則也等因而再檢查了一遍本身的代碼是否符合面向對象編程的原則：當有那種極爲冗雜，功能複雜，不符合面向對象編程思惟的方法時，每每是寫不出來由布爾表達是組成的標準後置條件的。

題外話：

　　在第十一次做業中，出現了大量以「管他是否是BUG報了再說，反正不是BUG對方會申訴，是BUG我就加分」心態報了BUG的現象。這顯然是由於提交BUG幾乎不須要成本，而誤報BUG也沒有懲罰的制度缺陷下，測試者濫用權力形成的。我的認爲，OO在引入了互測這種人爲因素極大的測試方式的狀況下，各方面規定極爲不完善，還有許多沒有量化標準的規定，致使了許多爭端與不合理的扣分，也致使了每次做業同窗們都須要浪費極爲大量的時間在與助教溝通各項規定的細則、特殊狀況，以及與測試者的溝通上。也許鍛鍊咱們理解需求的能力、鍛鍊咱們溝通能力的初衷是好的，可是在本學期中，我的認爲OO的確存在佔用了大多數同窗過多的時間的問題。一門課程致使大多數學生常常熬夜難道不正是課程設計上不合理的一種體現嗎？而根據開課時老師們的表現來看，彷佛爲這此而引覺得豪？。。