一、规格化设计的历史
最早的程序设计是用机器语言编写的，直接用二进制码来表示，但是这样太过困难，之后就出现了汇编语言，借助符号来表示操作。如此尽管提高了可读性，但本质还是面向机器的，抽象化程度还不够高。
随后出现了面向过程的“高级语言”，但是goto语句导致的面条式代码限制了程序的规模，为解决这一问题，人们抛弃goto语句，采取“自顶向下、逐步细化、模块化”的指导思想。提高了抽象化程度，从整体上降低了软件开发的复杂度。
随着需求越来越多，编程应用领域越来越广泛，产生了面向对象的思想，进一步提高了程序抽象的级别。而规格化设计能将运行细节抽象为用户所需求的行为，以此减少程序复杂度，使得程序员可以专注在处理少数重要的部分。
二、分析自己的规格bug
第九次作业
无
第十次作业
| 规格bug类别 | 方法行数 |
|---|---|
| Requires不正确 | 12 |
第十一次作业
无
三、分析自己规格bug的产生原因
自己对jsf的理解不够深刻，没有理解到none和null和true的区别，仅仅用jsf语言让对方理解自己的代码是不够的，还需要严谨的遵守jsf指导书，只有真正的理解了老师所教的jsf的精髓，才能不被对面报bug。
四、分别列举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;
五、按照作业分析被报的功能bug与规格bug在方法上的聚集关系
无
六、归纳自己在设计规格和撰写规格的基本思路和体会
规格不能以让对方看懂为原则，要以符合指导书且严谨为原则。