OO第三次博客做業

調研規格化設計

　　規格化設計的歷史和發展進程網絡上實在沒有相關的資料.........

　　下面分析一下問什麼獲得人們的重視：

•      規格化將運行細節（即模塊如何實現）抽象爲用戶所需求的行爲（即模塊作什麼），是從具體實現中抽象出模塊，須要的僅僅是模塊的實現可以匹配咱們所依賴的表述形式。每當將一個過程與一個註釋（這個註釋提供了充分的信息，是其餘人不用看過程主體就能使用該過程）關係起來；
•      從別的領域咱們已經獲得啓示，規格化的設計有助於提升生產效率，這個道理在咱們計算機領域也是如此，在開發一個大型程序時，每每須要分給多我的合做，爲了防止每一個人的理解是不一樣的而形成沒法知足具體需求，人們會提供一個規格來解決這個問題；
•      同時這個規格也能夠提示程序員來減小bug的產生

規格bug分析

規格bug	對應方法的行數
Effecets內容爲實現算法	331

　　bug產生的緣由：在EFFECTS中對於該方法的後置條件討論不夠充分，在不一樣狀況下對於MODIFIES中的屬性的改變狀況說明過於模糊。這個方法中實現的是出租車帶等待接單時車行走的方式，由於實現複雜沒法經過形式化語言實現，因此後置條件討論的不充分；對應的modifies屬性的改變也是模糊的。

很差寫法和改進寫法

　　個人jsf寫的確實不太好，由於有的方法實現的東西有不少，因此用的天然語言沒有形式化語言；　　

　　1.個人出租車判斷方向時：

 返回值爲-1不該該放入exception中

/** * @ REQUIRES: None; * @ MODIFIES: None; * @ EFFECTS: * normal_behavior: * (x==n_x&&n_y>y)==>\result == 4; * (x==n_x&&n_y<y)==>\result == 3; * (y==n_y&&n_x>x)==>\result == 2; * (y==n_y&&n_x<x)==>\result == 1; * exception_behavior(Exception e): * \result == -1; */

        if(x==n_x&&n_y>y) return 4; else if(x==n_x&&n_y<y) return 3; else if(y==n_y&&n_x>x) return 2; else if(y==n_y&&n_x<x) return 1; return -1;

 改進後

/** 　　　*　@ REQUIRES: None; * @ MODIFIES: None; * @ EFFECTS: * normal_behavior: *                 (x==n_x&&n_y>y)==>\result == 4; *                 (x==n_x&&n_y<y)==>\result == 3; *                 (y==n_y&&n_x>x)==>\result == 2; *                 (y==n_y&&n_x<x)==>\result == 1; * 　　　(!(x==n_x&&n_y>y)&&!(x==n_x&&n_y<y)&&!(y==n_y&&n_x>x)&&!(y==n_y&&n_x<x)) ==> \result == -1;
*/

 　　2.查詢出租車信息時：

用天然語言寫的很簡略

/** * @ REQUIRES: None; * @ MODIFIES: None; * @ EFFECTS: * normal_behavior: * 輸出i號出租車的具體信息; * exception_behavior(Exception e): * do nothing; */

改進後

/** * @ REQUIRES: None; * @ MODIFIES: None; * @ EFFECTS: * normal_behavior: * \result == "Time:\t"+System.currentTimeMillis()+"Station:\t("+t[i].x+","+t[i].y+")"+"Statics\t"+t[i].statics; * exception_behavior(Exception e): * do nothing; */

　　3.求處於某一狀態的出租車的編號

用天然語言寫的很簡略

/** * @ REQUIRES: None; * @ MODIFIES: None; * @ EFFECTS: * normal_behavior: * 輸出處於statics狀態的出租車編號; * exception_behavior(Exception e): * do nothing; */

改進後

/** * @ REQUIRES: None; * @ MODIFIES: None; * @ EFFECTS: * normal_behavior: * (\all int i; 0<=i<100; (t[i].statics == statics) ==> /result == i; * exception_behavior(Exception e): * do nothing; */

　　4.判斷是否還有路徑的下一個結點

寫法上仍是不太好

/** * @ Effects: \result == (cnt+1>=0 && cnt+1<=len-1) ==> true; (cnt+1 <0 || cnt+1>len-1) ==> false; */    

改進後　　　

/** * @ REQUIRES: None; * @ MODIFIES: None; * @ Effects:　　　　(cnt+1>=0 && cnt+1<=len-1) ==> \result == true; * (cnt+1 <0 || cnt+1>len-1) ==> \result == false; */    

　　5.返回路徑的上一個節點時

寫法上仍是有天然語言

/** * @ Requires: None; * @ Modifies: None; * @ Effects: \result == (cnt-1 >= A.arraylist.size() || cnt < 1) ? null : String of previous position */

改進後

/** * @ Requires: None; * @ Modifies: None; * @ Effects: (cnt-1 >= A.arraylist.size() || cnt < 1) ==> \result == null;
　　　*　　　　　　　!(cnt-1 >= A.arraylist.size() || cnt < 1) ==> \result == A.arraylist.get(cnt);

　　　*/

功能bug和規格bug在方法上的彙集關係

	方法名	功能bug數	規格bug數
第9次做業	request	1	0
第10次做業	無	1	0
第11次做業	dispath	2	1

　　在個人程序中，功能bug和規格bug沒有體現出具體的彙集關係，但實際上他們是密切相關的，若是規格寫很差的話很容易產生功能上的bug，相反規格寫的易於理解，更加正規化的是能夠大大下降產生功能bug的可能的；

本身在設計規格和撰寫規格的基本思路和體會

　　這個jsf寫起來確實很是的討厭，消耗了大量的時間，可能會比寫代碼的時間用的還要多，但這個時間確定是有所回報的，jsf是一個很是重要的東西。如今可能看不出來這個東西的重要性，可是當不少人在一塊兒合做時，這個東西的重要性就體現出來了，爲了和其餘人進行交互你必需要別人看懂你的代碼，而jsf就是一個很是好的讓人看懂你代碼的東西。同時jsf還能有助於你理清思路，讓你減小功能性bug的出現。

　　總的來講，jsf是很枯燥，很無聊，但它是很是有用的，因此得好好寫啊，很差好寫就被扣分了(.jpg)！