面向對象課程第三次隨筆

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

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

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

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

2、規格bug表格及緣由分析

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

前置條件很差的寫法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是方法內定義的變量，不該該在後置條件中使用。方法內的變量屬於如何實現的範疇，與規格無關。

 4、功能bug與規格bug關係分析

整體來講，我我的的功能bug和規格bug聚合度不高。功能bug有兩個是沒有注意在issue中的補充要求。還有是本身對流量計算方法的錯誤以及調用迭代器時出錯。

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

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

（1）本身某些方法功能過多，致使JSF很差描述

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

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

（1）須要實現什麼功能（EFFECTS）

（2）方法的線程安全性

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

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