OO第三次博客作业

规格化设计发展历史

在调研的过程中再一次验证了“百度搜索不适合学术”这个观点，没有找到合适的搜索结果后，转用Google，才找到了一些细节。

保证程序的正确性以及减少软件错误一直是程序员关注的问题，Hoare提出了基于“前置后置条件”的接口规格方法。

为了建立正确的类规格，近些年来，研究者们进行了抽象变量、接口规格、状态抽象、查询方法等不同方面的尝试，并取得了很大的进展。

为保证程序的正确性， Hoare[l] 提出了关于接口的规格方法，即若一种方法在执行前满足前置条件，运行后满足后置条件，那么这种方法就是正确的。 Hoare 提出的这个结论为规格化发展起到了奠基的作用，也为类中接口的规格化提供了理论基础。

针对各方法的精确规格定义， MeyeP] 提出契约式编程延续了对方法的精确定义，但其不足是依赖内部状态来体现方法之间的相互依赖。

课程中使用的JSF更偏向于“契约式设计”(Design by Contract)：为传统的抽象数据结构增加了先验条件、后验条件和不变式。

规格bug分析

bug类型	bug内容	出现位置
JSF检查->Requires不完整	忘写JSF	Windows类
方法规格检查->Effects不完整	JSF不完整	Taxi类
方法规格检查->JSF不符合规范	可追踪出租车没有写继承	Taxi2类

bug产生原因：

• 第九次作业是JSF被扣分最严重的一次。我是写完代码然后再去写JSF，在金工实习上补全JSF就上交了，最后发现因为有一个类的JSF写漏了，对面对每一个没写的方法规格报了15个JSF imcomplete...
• 不是太重视JSF，导致部分后置条件不够详细，最后两次作业总共被报了3个JSF。

前置条件后置条件写法改进

前置条件

(1)修改前

/** @REQUIRES : map!=null,taxiGUI!=null,GuiInfo!=null;
	 * @MODIFIES : this.id,this.credit,this.map,this.taxiGUI,this.GuiInfo,this.flowMonitor,this.VIP;
	 * @EFFECTS : None;
	 */

对新增变量flowMonitor判断
修改后

/** @REQUIRES : map!=null,taxiGUI!=null,GuiInfo!=null,flowMonitor!=null;
	 * @MODIFIES : this.id,this.credit,this.map,this.taxiGUI,this.GuiInfo,this.flowMonitor,this.VIP;
	 * @EFFECTS : None;
	 */

(2)修改前

/** @REQUIRES : id > 0;
	 * @MODIFIES : None;
	 * @EFFECTS : \result == id;
	 */

不需要对id进行判断
修改后

/** @REQUIRES : None;
	 * @MODIFIES : None;
	 * @EFFECTS : \result == id;
	 */

(3)修改前

/** @REQUIRES: None;
	 * @MODIFIES: None;
	 * @EFFECTS: \result == System.currentTimeMills();
	 */

对于Thread进行追加Require
修改后

/** @REQUIRES: None;
	 * @MODIFIES: None;
	 * @EFFECTS: \result == System.currentTimeMills();
	 * @THREAD_REQUIRES:\locked(\this);
	 * @THREAD_EFFECTS:\locked(\this);
	 */

(4)修改前

/** @REQUIRES: None;
	 * @MODIFIES: None;
	 * @EFFECTS: (distance==1) ==> \result = true
	(distance!=1) ==> \result = false
	 */

对于坐标范围的判断
修改后

/** @REQUIRES: src>0 && src <80 && dst >0 && dst < 80;
	 * @MODIFIES: None;
	 * @EFFECTS: (distance==1) ==> \result = true
	(distance!=1) ==> \result = false
	 */

(5)修改前

/** @REQUIRES : s!=null;
	 * @MODIFIES : this.str;
	 * @EFFECTS : str == s;
	 */
	public Request(String s) {

基本数据类型不需要进行判断（编译器保证）
修改后

/** @REQUIRES : None;
	 * @MODIFIES : this.str;
	 * @EFFECTS : str == s;
	 */
	public Request(String s) {

后置条件

(1)修改前

	/** @REQUIRES: requestQueue!=null;taxiGUI!=null;
	 * @MODIFIES: this.requestQueue,this.taxiGUI;
	 * @EFFECTS: None;
	 */

修改后

	/** @REQUIRES: requestQueue!=null;taxiGUI!=null;
	 * @MODIFIES: this.requestQueue,this.taxiGUI;
	 * @EFFECTS: this.requestQueue == requestQueue, this.taxiGUI == taxiGUI;
	 */

(2)修改前

/** @REQUIRES : None;
	 * @MODIFIES : None;
	 * @EFFECTS : \result == invariant(this);
	 */

repOK 的具体判断
修改后

/** @REQUIRES : None;
	 * @MODIFIES : None;
	 * @EFFECTS : \result = (requestQueue != null);
	 */

(3)修改前

/**@REQUIRES : readFile!=null;taxiGUI!=null;flowMonitor!=null;GuiInfo!=null;
	 * @MODIFIES : requestQueue,readFile,taxiGUI,flowMonitor,GuiInfo;
	 * @EFFECTS : this.requestQueue == requestQueue;
	 * 		this.readFile == readFile;
	 * 		this.taxiGUI == taxiGUI;
	 * 		this.flowMonitor == flowMonitor;
	 */

对新增的GuiInfo没有修改Effects
修改后

/**@REQUIRES : readFile!=null;taxiGUI!=null;flowMonitor!=null;GuiInfo!=null;
	 * @MODIFIES : requestQueue,readFile,taxiGUI,flowMonitor,GuiInfo;
	 * @EFFECTS : this.requestQueue == requestQueue;
	 * 		this.readFile == readFile;
	 * 		this.taxiGUI == taxiGUI;
	 * 		this.flowMonitor == flowMonitor;
	 * 		this.GuiInfo == GuiInfo;
	 */

(4)修改前

/** @REQUIRES : str!=null；
	 * @MODIFIES : this.reqSame,this.timeSame；
	 * @EFFECTS : \request.equals(同质请求添加到同质判断队列)；
	 */

尽量转换自然语言为逻辑语句
修改后

/** @REQUIRES : str!=null；
	 * @MODIFIES : this.reqSame,this.timeSame；
	 * @EFFECTS : reqSame.add(str),timeSame.add(time)
	 */

(5)修改前

/** @REQUIRES : taxis!=null;
	 * @MODIFIES : None;
	 * @EFFECTS :None;
	 */

get方法一定要写\result !
修改后

/** @REQUIRES : taxis!=null;
	 * @MODIFIES : None;
	 * @EFFECTS : \result == taxis;
	 */

功能bug和规格bug的聚集关系

这次博客作业这样要求，按照可能的论证：由于不清楚代码的功能细节，所以导致出现了规格bug，这种规格bug伴随着方法的功能bug出现，所以会出现聚类关系。
由于JSF是在代码收工之后写的，所以基本没有聚类关系。
三次作业最严重的规格bug就是忘写部分JSF，其他出现规格bug的地方并没有出现功能问题。
如果说有什么没有被报的功能bug,那么对应的规格bug一定是有的，只是没有被抓出来而已。

设计与撰写规格的思路

• Require部分：一般都是对于输入的形参做非空判断
• Modify部分：对于方法写到的private变量挨个判断是否修改
• Effects部分：对于Modify的变量变化的情况进行分析

最后使用JSFTool.class进行复查

心得体会

最近几次OO作业感觉收获比较小，在做课程作业时对于Java的语法没有更深学习的动力，也没有Java与其他技术的结合应用，如果只是完成作业只需要JavaSE的部分语法基础而已。这两周花费大量时间在JSF的书写上，而且遇到对面的***钻扣分也容易受到打击，可能大家都觉得相对于程序的功能Bug，要扣规格的分不要容易太多吧。

参考文献
[1]王伟,丁二玉,骆斌.基于抽象状态的类的行为规格化方法[J].计算机科学,2016,43(S1):457-460.