一、規格化設計的發展歷史

　　20世紀60年代，軟件出現嚴重危機，Dijkstra提出了goto語句的危害，由此引發了軟件界長達數年的論戰，並產生了結構化程序設計方法。Pascal語言在20世紀70年代占有統治地位。

　　隨著計算機技術的發展，結構化設計語言和結構化分析無法滿足用戶的需求，OOP由此應運而生，即面向對象的程序設計。OOP的誕生是程序設計方法學的一場革命，大大提高了開發效率，減少了軟件開發的復雜性，提高了軟件的可維護性，可拓展性。1990年以來，面向對象分析、測試、度量和管理研究都得到長足發展。

　　規格化設計伴隨OOP而生，為了提高程序的規範性，對類、方法等進行規範化設計，有利於程序的模塊化劃分。這樣設計程序的數據更加安全可控，測試也變得容易，軟件的維護性得到提高，因而受到程序設計人員的重視。

二、規格bug表格及原因分析

三、前置條件後置條件寫法改進

前置條件不好的寫法1

對前置條件不做要求，自己在程序其他部分進行限制來保證一些隱含的前置條件會被滿足。其實這樣不是很好，降低了方法的通用性，如果都是自己寫的代碼還好說，在遇到繼承，或者作為借口時，往往會出現意想不到的問題。最好將前置條件寫明，來增強代碼的可讀性與可復用性。

前置條件不好的寫法2

本身這個前置條件問題不大，但是credit既然作為int類型，最好設定好上界2^32-1。即使不是int類型，一些參數最好也設定合理的界限。

前置條件不好的寫法3

隱含了(x1,y1），（x2,y2）這兩個點必須相鄰的要求。這樣會導致不處理錯誤的數據，作為規格並不全面。需要補全相應的約束。不完全的前置條件，給設計者和方法使用者都會帶來困擾

前置條件不好的寫法4

只對一個參數進行了前置條件的要求，應該加上對usedgraph的約束，至少保證usedgraph!=null。

前置條件不好的寫法5

對於方法內的的變量進行約束是不行的，規格與實現無關。應該去掉distance!=0

後置條件不好的寫法1

單純的通過自然語言來描述後置條件，這樣並不如邏輯語言清晰。

改為EFFECTS：\result = max_credit() [min_distance()];

後置條件不好的寫法2

直接將算法寫到了EFFECTS。後置條件應該描述結果而不是實現過程，實現過程應該由程序員自己決定。

後置條件不好的寫法3

代碼中存在IO操作在後置條件中卻沒有寫明。IO操作本身也應該是屬於後置條件的範疇，應該在後置條件中加入

後置條件不好的寫法4

該方法使用了鎖機制來保證方法的線程安全性，後置條件應該說明要鎖住哪些對象。

@THREAD_EFFECTS :\locked (cnt);

後置條件不好的寫法5

途中MAXNUM是方法內定義的變量，不應該在後置條件中使用。方法內的變量屬於如何實現的範疇，與規格無關。

四、功能bug與規格bug關系分析

總體來說，我個人的功能bug和規格bug聚合度不高。功能bug有兩個是沒有註意在issue中的補充要求。還有是自己對流量計算方法的錯誤以及調用叠代器時出錯。

五、設計規格撰寫規格時的體會

在第九次作業中，由於之前已經完成了程序的大部分設計，因此工作時給已實現了的方法加上JSF。添加JSF時，我發現

（1）自己某些方法功能過多，導致JSF不好描述

（2）方法與方法之間的依賴度過高

後面的作業中，在實現新的功能需要添加新類、方法時，我會先完成Overview和規格的設計，再去進行實現。這樣的設計流程，雖然在功能上差別不大，但是程序的安全性（可控制）與可拓展性有了顯著的提升。撰寫規格時，我主要的考慮順序是：

（1）需要實現什麽功能（EFFECTS）

（2）方法的線程安全性

（3）實現功能需要提供哪些參數（REQUIRES）

（4）在實現過程中改變的什麽數據（MODIFIES）

面向對象課程第三次隨筆