規格化設計的發展歷史和電腦程式通用性增強有關。早期的程式功能單一，編制後基本不進行維護和修改，因此設計的規範未成為程式編寫的阻礙。但隨著計算機系統的飛速發展，軟體的功能大大提公升，由此帶來的就是對程式可擴充套件性，可維護性的需求不斷增加。而規格化設計是解決問題的有效方法，因此程式編寫的各種規範逐漸推出，軟體開發也就走上了規格化設計的道路。
如今各種應用程式的開發都是以團隊合作為基礎，在多個開發人員共同寫作的情況下，不得不遵循統一的規則，這不僅僅是為了提高合作開發的效率，也是為了後期維護成本考慮。
寫規格是為了規範程式設計師的設計與程式設計，使之養成良好的習慣，從而增強軟體產品的穩定性、健壯性和可靠性。
同一的規格可以提高軟體的可讀性，讓程式設計師能快速地理解**，使產品的可維護性提高。
這三次作業我都很「幸運」吧，遇到的同學比較友好（很佛系），前兩次都是掛了我一兩個功能bug，jsf就沒給我細扣，所以實際上我規格裡還有很多錯誤等著我自己去發現和改正。
功能性bug產生的原因主要還是我能力不夠。本身時間就緊，有些時候連寫完**都是奢望，更別說除錯了，所以有些方法就是一遍寫完後也沒仔細測試就接著寫其他的了。而我經常粗心大意，沒有bug才是奇怪。
規格bug很多，只是互測時同學沒給點出來。自己對於規格的重視不夠，每次作業我都想著盡快完成，因此寫新方法時我仍然是先寫**再寫規格，寫規格的練習對於我來說基本就沒用。
1.更改前
1更改後private
void
colorconcert()
2/**
3* @requires:none;
4* @modifies:this;
5* @effects:
6* (\all int i,j;0<=i,j<80;this.lightinfo[i][j] == (this.lightinfo[i][j]==1?2:this.lightinfo[i][j]==2?1:0));
7* this.lastchangetime == system.currenttimemillis();
8*/
12.更改前private
void
colorconcert() {
2/**
3* @requires:this.lightinfo!=null && this.mygui!=null;
4* @modifies:this;
5* @effects:
6* (\all int i,j;0<=i,j<80;this.lightinfo[i][j] == (this.lightinfo[i][j]==1?2:this.lightinfo[i][j]==2?1:0));
7* this.lastchangetime == system.currenttimemillis();
8*/
1更改後public
boolean
canmovenorth() {
2/**
3* @requires:none;
4* @modifies: none;
5* @effects:
6* \result == (this.veratt>0&&map[this.veratt-1][this.horatt]>=2);
7*/
11.更改前public
boolean
canmovenorth() {
2/**
3* @requires:0<=this.veratt<80 && this.map!=null && 0<=this.horatt<80;
4* @modifies: none;
5* @effects:
6* \result == (this.veratt>0&&map[this.veratt-1][this.horatt]>=2);
7*/
1更改後public
void
2/**
3* @requires:info!=null;
4* @modifies:this.tmpstr;
5* @effects: this.tmpstr == (this.tmpstr + info);
6*/
12.更改前public
void
2/**
3* @requires:info!=null;
4* @modifies:this.tmpstr;
5* @effects: this.tmpstr == (\old(this.tmpstr) + info);
6*/
1更改後public
synchronized
void init(int graph, int
map, taxigui mygui,trafficlight light) {
2/**
3* @requires:(graph!=null && map!=null && mygui!=null && light!=null);
4* @modifies:this;
5* @effects:
6* this.graph== graph;
7* this.map == map;
8* this.mygui== mygui;
9* this.light== light;
10*/
13.更改前public
synchronized
void init(int graph, int
map, taxigui mygui,trafficlight light) {
2/**
3* @requires:(graph!=null && map!=null && mygui!=null && light!=null);
4* @modifies:this;
5* @effects:
6* this.graph== graph && this.map == map && this.mygui == mygui && this.light==light;
7*/
1更改後public
void
2/**
3* @requires:none;
4* @modifies:this;
5* @effects:
6* this.credit == this.credit + 1;;
7*/
1為了盡快完成作業（平時課外活動太多，時間不夠），我所有方法的規格都是寫完**後才補充的，因此規格寫得相當差。public
void
2/**
3* @requires:none;
4* @modifies:this;
5* @effects:
6* this.credit == \old(this.credit) + 1;;
7*/
因此我的基本思路都是錯誤的，大概就是根據已寫**總結一下，能用表示式的用表示式，不能的就直接用自然語言。
我寫作業的目的就不正確，所有的作業都是以完成為目標的，我並沒有把作業當成能提高自己水平的練習，相反，我潛意識裡覺得這是乙個負擔。因此我主觀上不夠積極，每次寫**都有許多不情願。而這致使我完成作業基本是在浪費時間，並沒有得到應有的鍛鍊。
態度決定一切。端正自己的學習態度，把重心轉移到學習上來，是我必須要做的。有時候被瑣事纏身，就會忘了分清主次。在接下來的學習中，我會及時轉換思想，盡自己所能完成好每一次作業，讓自己付出的每一秒時間都有其價值。
具體來說，現在急需解決的問題就是寫**的思路，我一直沒有給認真完成每次作業提供機會。每次作業我一開始就是在想演算法，忽略了物件導向這門課課程訓練要點，對整個程式一開始也不會有什麼把握，基本是先粗略打個草稿，然後邊想邊寫，最後不停地debug。其實我知道正確的流程應該是怎樣，而且我周圍同學也能為我提供各種幫助，但我一直未去改變這種模式。我想時間緊是我給自己的乙個藉口，我經常因為害怕完成不了而把作業質量打折。有時候改變就需要乙個開端，當邁出第一步後，一切就都順其自然了。所以下一步就是逼迫自己走出這關鍵的第一步。
OO第三次總結部落格
因為很難尋找，所以參考了下別的同學的調研結果 規格化設計與結構化 模組化設計密不可分，伴隨著oop語言的發展，規格化設計思想逐漸形成體系，慢慢完善。20世紀60年代，程式的模組化設計思想被提出。伴隨著計算機行業的迅速發展，為了解決程式可靠性等問題，結構化 模組化的設計為程式設計師提供了使用介面。每個...
OO第三次部落格
隨著社會上各公司業務的發展，專案越來越多，越來越大，複雜性也越來越高。查詢乙個bug變得越發抓狂 新人熟悉一塊 也變得越發困難。有的時候順手寫下的一行充滿壞味道的 可能當時不會出現什麼影響，而且當事人也十分清楚自己寫的東西。但是，當日積月累之後，這種壞 越來越多，整個專案就變得混亂不堪，牽一髮而動全...
第三次課程
作業 gcc static這個static作用？1 隱藏 當同時編譯多個檔案時，所有未加static字首的全域性變數和函式都具有全域性可見性 2 保持變數內容的持久 儲存在靜態資料區的變數會在程式剛開始執行時就完成初始化，也是唯一的一次初始化，static修飾的區域性變數只有在整個程式結束的時候才會...