OO第三次博客做業

1、規格化設計的歷史

最先的程序設計是用機器語言編寫的，直接用二進制碼來表示，可是這樣太過困難，以後就出現了彙編語言，藉助符號來表示操做。如此儘管提升了可讀性，但本質仍是面向機器的，抽象化程度還不夠高。
  隨後出現了面向過程的「高級語言」，可是goto語句致使的麪條式代碼限制了程序的規模，爲解決這一問題，人們拋棄goto語句，採起「自頂向下、逐步細化、模塊化」的指導思想。提升了抽象化程度，從總體上下降了軟件開發的複雜度。
  隨着需求愈來愈多，編程應用領域愈來愈普遍，產生了面向對象的思想，進一步提升了程序抽象的級別。而規格化設計能將運行細節抽象爲用戶所需求的行爲，以此減小程序複雜度，使得程序員能夠專一在處理少數重要的部分。

2、分析本身的規格bug

第九次做業

無

第十次做業

規格bug類別	方法行數
Requires不正確	12

第十一次做業

無

3、分析本身規格bug的產生緣由

本身對jsf的理解不夠深入，沒有理解到none和null和true的區別，僅僅用jsf語言讓對方理解本身的代碼是不夠的，還須要嚴謹的遵照jsf指導書，只有真正的理解了老師所教的jsf的精髓，才能不被對面報bug。

4、分別列舉5個前置條件和5個後置條件的很差寫法，並給出改進寫法

前置條件很差的寫法有null，none或使用天然語言等。你僅僅讓對面看懂你的規格是不夠的，你還得讓它成爲布爾表達式，否則不嚴謹。所以要改爲true。

五個很差的後置條件

• 用天然語言====>改爲相應的條件
• 寫null====>分析內在關係
• this.init=====>分析代碼真正的構造的後置條件
• Change(lightMap)===>\all 0<=i<80,0<=j<80; (lightMap[i][j] == 2) ==>lightMap[i][j] = =1 ; (lightMap[i][j] != 2) ==>lightMap[i][j] ==1;

5、按照做業分析被報的功能bug與規格bug在方法上的彙集關係

無

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

規格不能以讓對方看懂爲原則，要以符合指導書且嚴謹爲原則。