(因為很難尋找，所以參考了下別的同學的調研結果)
規格化設計與結構化、模組化設計密不可分，伴隨著oop語言的發展，規格化設計思想逐漸形成體系，慢慢完善。
20世紀60年代，程式的模組化設計思想被提出。伴隨著計算機行業的迅速發展，為了解決程式可靠性等問題，結構化、模組化的設計為程式設計師提供了使用介面。每個模組各司其職，這樣的程式便於擴充套件和維護，大大降低了當時開發者的困難。
20世紀80年代，物件導向語言興起，結構化、模組化的思想在物件導向語言裡作用被體現得更加徹底。與此同時，為了提高程式語言的規範性，對類和方法進行更好的維護，對其進行規範化設計，也使得資料變得更加安全可控，測試也更加簡單易行。
為了類和方法能夠變得規範可控，對類和方法進行規範化要求就變得有必要起來。在工程裡面， 乙個程式也許會有多人同時進行編寫，那麼由於沒人不同的**習慣，可能產生不同的設計理念，通過規格化設計也可以同步多人的設計方法，避免產生設計上的漏洞。規格化的程式不更易於除錯，也更容易被維護，有利於程式的長遠生存和發展。
僅homework9有規格bug，且無雷同問題(雷同的倆都被報了)
bug類別
bug內容
出現位置
**行數
前置條件不為布林表示式
用了逗號來連線而不是用&&
updatemap
22前置條件不為布林表示式
用了逗號來連線而不是用&&
updateflow
4究其原因是因為在寫不等式時用了逗號，比如:0<=x1,x2<=1 這種型別，導致前置條件不是布林表示式。但是很奇怪，在下一次作業裡，助教又告訴我前置條件可以不為布林表示式了，既然要這樣子，我也沒什麼辦法，起碼從此以後我每次都有注意前置條件要為布林表示式。
(1)不用布林表示式，而選擇用自然語言
改進條件：use bool expression
(2)在後置條件裡寫出**的演算法實現
改進條件：only display the changes of attributes instead of the algorithm
(3)很多人喜歡在前置條件裡寫none，但我覺得這不是布林表示式
改進條件:@requires: true
(4)過於簡略，沒有完整體現後置條件
改進條件:complete the effects
(5)用=代替==
改進條件: use ==
和規格bug無聚集關係，一共就倆，就不列什麼表了
第一次被報了3個都是因為整體演算法偏慢，執行久了每個計程車就不同步了，然後就有問題了，為了解決這個問題，我讓每個車sleep的時間變成了settime-演算法花費的時間。也就是給程式"造了個假",這樣每輛車就同步了。
第二次是因為對於load filename的指令忘記正則了，輸個a|file.txt，程式也能正常執行，雖然我readme寫了load filename 由測試者來保證正確，但我也懶得管了。
規格這個東西設定的初衷是好的，但拿來被惡意扣分就很可恥了。
有的人惡意扣了分後還站在制高點教育被測者，這就更不對了。
這種人我這麼多週就遇到過乙個，然後上次作業在吐槽版又看到了有同學惡意被扣，我也不知道是誰，但我只覺得，這很可悲。
在這種課程制度下，人性變得好可怕。
OO第三次部落格
隨著社會上各公司業務的發展，專案越來越多，越來越大，複雜性也越來越高。查詢乙個bug變得越發抓狂 新人熟悉一塊 也變得越發困難。有的時候順手寫下的一行充滿壞味道的 可能當時不會出現什麼影響，而且當事人也十分清楚自己寫的東西。但是，當日積月累之後，這種壞 越來越多，整個專案就變得混亂不堪，牽一髮而動全...
第三次部落格作業（OO）
一 規格化設計的大致發展歷史 軟體形式化方法最早可追溯到20世紀50年代後期對於程式語言編譯技術的研究，即j.backus提出bnf描述algol60語言的語法，出現了各 種語法分析程式自動生成器以及語法制導的編譯方法，使得編譯系統的開發從 手工藝製作方式 發展成具有牢固理論基礎的系統方法。形式化方...
OO第三次部落格作業
程式中的規格化設計的發展歷史，與計算機的發展歷史 程式設計設計的發展歷史是緊密相連，密不可分的。從1940年的面向機器程式設計，到之後的面向過程程式設計，逐漸出現了我們現在使用的各個語言的原始版本。而隨著 量的不斷增加，程式功能的不斷複雜化，簡單的面向過程程式設計不再能夠滿足人們的需要，因此，出現了...