第十二次oo做業

做業十二

規格化設計簡介

規格化設計的發展歷史

1950年代，第一次分離，主程序與子程序的分離結構是樹狀模型，子程序可先於主程序編寫。經過使用庫函數來簡化編程，實現最初的代碼重用。產生基本的軟件開發過程：分析—設計—編碼—測試，使大型軟件系統的開發成爲可能。

1975—1980年代，第二次分離，規格說明（Spec）和體（body）的分離說明是類型定義和操做描述，體是操做的具體實現。（具體的例子就是C++,Java等面嚮對象語言的類說明與類實現的分離。）解決方案設計只關注說明，實現時引用或者設計體。體的更改、置換不影響規格說明，保證了可移植性。支持多機系統，但要一樣環境。此時產生了劃時代的面向對象技術。

1995—2000年代，第三次分離，對象使用和對象實現的分離基於構件開發：標準化的軟件構件如同硬件IC，可插拔，使用者只用外特性，不計內部實現。Web Services：軟件就是服務。分佈式，跨平臺，鬆耦合。

規格化設計爲什麼獲得你們的重視

一方面，規格化設計能夠幫助開發者理清思路，構建一個寫程序的框架，這樣一來開發者能夠按照既定的套路來完成本身的任務，從而可以摒棄雜念，提升效率。

另外一方面，一個程序中不少代碼會以一塊一塊的形式被反覆使用，這些重複的代碼塊有可能被封裝爲函數反覆使用，也有可能被放入庫中供他人使用。若是能按照必定的規格去完成他們，那麼調用者沒必要大費周折的去理解代碼，能夠經過已有的對於格式的學習以及清晰明瞭的格式來快速完成對代碼的理解，從而提升學習工做的效率。

bug分析

第九次

BUG內容	BUG類型	BUG代碼行數	BUG緣由	方法名
程序沒法運行	error	10	在main方法中未將全部線程start	public static void main()

無JSF錯誤

第十次

BUG內容	BUG類型	BUG代碼行數	BUG緣由	方法名
規格檢查->沒有寫Overview	imcomplete	1	將Overview寫在了每一個方法前，而沒有寫在類前
是否選擇流量最短的路徑	error	1	忘記將上一次有車通過的邊的流量加一	public void drive(int des)

彙集關係：無

第十一次

BUG內容	BUG類型	BUG代碼行數	BUG緣由	方法名
方法規格檢查->JSF不符合規範	imcomplete	1	有的JSF中將==寫爲了=
缺程序設計文檔	imcomplete	1	誤解了指導書的要求，沒有寫程序設計文檔
行駛一條邊的時間不爲500ms	error	10	由於程序採用系統時間，並且不能進行化整，故每過幾秒程序會有幾毫秒的偏差

彙集關係：無

很差的寫法

未按照要求格式書寫

//錯誤
/**
 * @REQUIRES:None
 * @MODIFIES:None
 * @EFFECTS :return flow;
 */

//改進
/**
 * @REQUIRES:None
 * @MODIFIES:None
 * @EFFECTS :\result == flow;
 */

誤將==寫爲=

//錯誤
/**
 * @REQUIRES:None
 * @MODIFIES:None
 * @EFFECTS :\result = errorInfo;
 */

//改進
/**
 * @REQUIRES:None
 * @MODIFIES:None
 * @EFFECTS :\result == errorInfo;
 */

使用天然語言

// 錯誤
/*
 * @REQUIRES:None
 * @MODIFIES:None
 * @EFFECTS: 初始化出租車；
 */
// 改進
/*
 * @REQUIRES:None
 * @MODIFIES:None
 * @EFFECTS: \this.id == id;
 */

語句結束未加;

//錯誤
/**
 * @REQUIRES:this.repOK == true && edge.repOK == true
 * @MODIFIES:this.edgeNearBy
 * @EFFECTS :(edge.isLegal) ==> edgeNearBy.add(edge)
 */
//改進
/**
 * @REQUIRES:this.repOK == true && edge.repOK == true
 * @MODIFIES:this.edgeNearBy
 * @EFFECTS :(edge.isLegal) ==> edgeNearBy.add(edge);
 */

部分語句不夠簡潔

//錯誤
/**
 * @REQUIRES:this.repOK == true && taxiNumber >= 0 && taxiNumber <= 99
 * @MODIFIES:taxiCanTake
 * @EFFECTS :taxiCanTake.add(taxiNumber)；
 */
//改進
/**
 * @REQUIRES:this.repOK == true && 0 <= taxiNumber <= 99
 * @MODIFIES:taxiCanTake
 * @EFFECTS :taxiCanTake.add(taxiNumber)；
 */

思路和體會

這幾回做業，咱們的主要着重點在於程序的JSF規範，類規範上，這些雖然對於代碼質量沒有直接的提升，可是在咱們之後開發大型程序，須要一個團隊協做時，一個好的JSF規範，類規範，可以極大地提升團隊協做的效率，可以從另一方面提升代碼，乃至整個團隊的質量。 在咱們之後的學習中，咱們也能夠保持書寫規範的習慣，這可以極方便的與他人進行交流學習，下降學習與合做的成本。同時咱們最好也在寫代碼前先進行規劃，好比寫JSF優先於代碼實現，這樣可以經過抽象出某一段代碼的功能，提早考慮好程序各部分之間的關係，提升後續編寫代碼時的效率，提升代碼總體的可讀性。