程式中的規格化設計的發展歷史，與計算機的發展歷史、程式設計設計的發展歷史是緊密相連，密不可分的。從2023年的面向機器程式設計，到之後的面向過程程式設計，逐漸出現了我們現在使用的各個語言的原始版本。而隨著**量的不斷增加，程式功能的不斷複雜化，簡單的面向過程程式設計不再能夠滿足人們的需要，因此，出現了結構化程式設計。而從這一過程中，編寫**的人們也注意到了規格的重要性。「結構化程式設計」作為另外一種解決軟體危機的方案被提出來了。 edsger dijkstra 於 1968 發表了著名的《goto 有害論》的**,引起了長達數年的論戰,並由此產生了結構化程式設計方 法。同時,第乙個結構化的程式語言 pascal 也在此時誕生,並迅速流行起來。在此之後，隨著硬體的快速發展，程式的複雜度迎來了再一次的飛躍，而這時出現了物件導向程式設計。此後規格化得到了人們越來越多的重視，因為其可以幫助閱讀者迅速理解**，也能幫助設計者更好的設計、規劃自己的程式，避免由於粗心大意造成的種種錯誤。
規格bug
功能bug
是否有聯絡
第九次作業00
無第十次作業12
無第十一次作業02
無唯一乙個規格bug是某乙個類規格的抽象物件不明確。而4個功能bug中，3個都是由於後來作業中，每次更新新的gui時，總會漏掉某一些之前作業中對於gui的更改（比如對於時間的更改。。）。
第十次作業中規格bug產生的原因，是對於抽象物件的概念不明確。也可以說是對類規格總體概念的不明確。在之後特意翻閱了前幾次的所有ppt，雖然沒有對抽象物件的明確定義，但根據上下文，以及對於類規格的理解更進一步後，也算是更加理解了抽象物件的概念吧。
1、前置條件、後置條件不準確。
修改前：
/** @ 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:
@ */
2、使用了自然語言
/** @ requires:
@ modifies: chead
@ effects: 將rl佇列的頭指標更新到相應位置
@ thread_requires:
@ thread_effects:
@ */
修改後：
/** @ requires:
@ modifies: chead
@ effects: while(headhead++;
@ thread_requires:
@ thread_effects:
@ */
3、沒有關於異常的資訊
/** @ 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:
@ */
4、沒有及時更新
/** @ 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:
@ */
5、不完整
/** @ requires: 0<=lp,cp,np<80
@ modifies:
@ effects: light's red ==> \result==wait time;
@ light's green ==> \result==0;
@ thread_requires:
@ thread_effects: \lock(gui**.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(gui**.lightmap);
@ */
在這一單元的三次作業中，功能bug與規格bug沒有聚集關係。規格bug出現在inputhandler的類規格中，而4個功能bug中，2個源於同乙個原因，即在loadfile類中，原因是忘記將編號-1再作為下標。而另外2個都在不要求寫規格的gui中。由於gui中的預設設定和新修改後的規定不一致，沒有修改完全（忘記了某乙個東西要改）造成的。
功能bug
規格bug
inputhandler01
loadfile20
gui2
0可以體會到，在將來我們在實習中、工作中所要處理的大型工程中，完善、統
一、嚴格的規格是十分必要的。這樣的好處有：
1、減少出現低階bug的概率，極大的減少了後期debug時需要的時間，提高了工作效率。
2、方便在團隊合作時的契合，使自己的**可讀性更高，在其他同伴理解、使用自己的**時，基本上不會出現過多的偏差。
3、優化自己的**風格，增強自己的**編寫能力。
寫規格的思路：在寫規格時，應盡量使用布林表示式。而這一重要原則也等於是再檢查了一遍自己的**是否符合物件導向程式設計的原則：當有那種極為冗雜，功能複雜，不符合物件導向程式設計思維的方法時，往往是寫不出來由布林表達是組成的標準後置條件的。
在第十一次作業中，出現了大量以「管他是不是bug報了再說，反正不是bug對方會申訴，是bug我就加分」心態報了bug的現象。這顯然是因為提交bug幾乎不需要成本，而誤報bug也沒有懲罰的制度缺陷下，測試者濫用權力造成的。個人認為，oo在引入了互測這種人為因素極大的測試方式的情況下，各方面規定極為不完善，還有許多沒有量化標準的規定，導致了許多爭端與不合理的扣分，也導致了每次作業同學們都需要浪費極為大量的時間在與助教溝通各項規定的細則、特殊情況，以及與測試者的溝通上。也許鍛鍊我們理解需求的能力、鍛鍊我們溝通能力的初衷是好的，但是在本學期中，個人認為oo的確存在占用了大多數同學過多的時間的問題。一門課程導致大多數學生經常熬夜難道不正是課程設計上不合理的一種體現嗎？而根據開課時老師們的表現來看，似乎為這此而引以為豪？。。
第三次部落格作業（OO）
一 規格化設計的大致發展歷史 軟體形式化方法最早可追溯到20世紀50年代後期對於程式語言編譯技術的研究，即j.backus提出bnf描述algol60語言的語法，出現了各 種語法分析程式自動生成器以及語法制導的編譯方法，使得編譯系統的開發從 手工藝製作方式 發展成具有牢固理論基礎的系統方法。形式化方...
OO第三次部落格
隨著社會上各公司業務的發展，專案越來越多，越來越大，複雜性也越來越高。查詢乙個bug變得越發抓狂 新人熟悉一塊 也變得越發困難。有的時候順手寫下的一行充滿壞味道的 可能當時不會出現什麼影響，而且當事人也十分清楚自己寫的東西。但是，當日積月累之後，這種壞 越來越多，整個專案就變得混亂不堪，牽一髮而動全...
OO第三次總結部落格
因為很難尋找，所以參考了下別的同學的調研結果 規格化設計與結構化 模組化設計密不可分，伴隨著oop語言的發展，規格化設計思想逐漸形成體系，慢慢完善。20世紀60年代，程式的模組化設計思想被提出。伴隨著計算機行業的迅速發展，為了解決程式可靠性等問題，結構化 模組化的設計為程式設計師提供了使用介面。每個...