OO第三次博客作业
一、规格化设计的历史
最早的程序设计是用机器语言编写的,直接用二进制码来表示,但是这样太过困难,之后就出现了汇编语言,借助符号来表示操作。如此尽管提高了可读性,但本质还是面向机器的,抽象化程度还不够高。
随后出现了面向过程的“高级语言”,但是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在方法上的聚集关系
无
六、归纳自己在设计规格和撰写规格的基本思路和体会
规格不能以让对方看懂为原则,要以符合指导书且严谨为原则。