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、概括本身在设计规格和撰写规格的基本思路和体会

规格不能以让对方看懂为原则，要以符合指导书且严谨为原则。