OO第三次博客总结作业
1.规格化设计的大致发展历史和为什么得到了人们的重视
发展历史...上网搜索了一圈...什么都没搜索到,只能谈谈自己对规格化设计重要性的一些看法。
规格化设计,顾名思义,是有规范有规格的去管理、编写自己的代码。这样的好处就在于,当自己编写一个大的项目的时候,虽然有成千上万行的代码,但是依然能够通过规格化设计准确的检索到自己想要找的部分。同时,在以后的码农生活中,用户通过你的规格化设计,也能很好的理解和使用你的代码。
2.按照作业,针对自己所被报告的规格bug以及雷同的规格bug(限于 bug树的限制,对手无法上报),列一个表格分析
第九次作业 | |
requestIn类没写JSF | 821行 |
Taxi类没写JSF | 1202行 |
不符合JSF规范 | 182行 |
第十次作业 | |
modifies格式错误 | 7行 |
JSF不符合规范 | 12行 |
第是一次作业 | |
JSF不符合规范 | 7行 |
3.分析自己规格bug的产生原因
对于JSF没有那么重视吧...而且每次遇到的人,对于JSF的要求还都挺高的。第一次有JSF要求的作业,正好周三那天有事,本来想的是把功能写完之后,周三写一些JSF,后来被耽搁了,就没写,还好那次测我的人,没有对这个要求很高,才没有很多bug。第二次有JSF,是根本没把这个太当回事儿,也没有想到有人会很认真的看过每一个JSF,挑很多错误。第三次有JSF,是 上次的一个bug,忘了修复了。
4.分别列举5个前置条件和5个后置条件的不好写法,并给出改进写法
前置条件
例1
更改之前
/**
* @REQUIRES:(\all int a;);
*/
更改之后
/**
* @REQUIRES:(\all int a; 0 <= a <=79);
*/
例2
更改之前
/**
* @REQUIRES:任意a;
*/
更改之后
/**
* @REQUIRES:(\all int a; 0 <= a <=79);
*/
例3
更改之前
/**
* @REQUIRES:(x!=null && x.state==state.order);
*/
更改之后
/**
* @REQUIRES:(x instanceof taxi && x!=null x.state==order);
*/
例4
更改之前
/**
* @REQUIRES:(x!=null && x.state=state.order);
*/
更改之后
/**
* @REQUIRES:(x!=null && x.state==state.order);
*/
例5
更改之前
/**
* @REQUIRES:无
*/
更改之后
/**
* @REQUIRES:None;
*/
后置条件
例1
更改之前
/**
* @EFFECTS:赋值语句;
*/
更改之后
/**
* @EFFECTS:this.number = number;this.credit = credit;
*/
例2
更改之前
/**
* @EFFECTS:(credit==credit+k);
*/
更改之后
/**
* @EFFECTS:(credit==(old)credit+k);
*/
例3
更改之前
/**
* @EFFECTS:(credit==(old)credit+k);
*/
更改之后
/**
* @EFFECTS:(credit==(old)credit+k);
* @THREAD_REQUIRES:
* \locked(\this);
* @THREAD_EFFECTS:
* \locked();
*/
例4
更改之前
/**
* @EFFECTS:(credit=(old)credit+k);
*/
更改之后
/**
* @EFFECTS:(credit==(old)credit+k);
*/
5.按照作业分析被报的功能bug与规格bug在方法上的聚集关系
方法名 | 功能bug数 | 规格bug数 |
detail.write | 1 | 0 |
Taxi.run | 2 | 1 |
RequestIn.run | 2 | 1 |
RequestAndControl | 1 | 0 |
Taxi.changelight | 0 | 1 |
Taxi.change | 0 | 1 |
Main.main | 0 | 1 |
6.归纳自己在设计规格和撰写规格的基本思路和体会
每次都是先写完代码,后补的JSF,所以JSF可能就和实际运行有一些不同。
REQUIRES:回忆回忆有什么前置条件,想起什么就写什么
MODIFIES:看那些变量是蓝色的...因为我用的黑色底板颜色,特别注意return。
EFFECTS:只看结果,不看过程
THREAD_RQUIRES\THREAD_EFFECTS:方法是否带锁。