OO第三次博客做业

调研规格化设计

　　规格化设计的历史和发展进程网络上实在没有相关的资料.........

　　下面分析一下问什么获得人们的重视：

•      规格化将运行细节（即模块如何实现）抽象为用户所需求的行为（即模块作什么），是从具体实现中抽象出模块，须要的仅仅是模块的实现可以匹配咱们所依赖的表述形式。每当将一个过程与一个注释（这个注释提供了充分的信息，是其余人不用看过程主体就能使用该过程）关系起来；
•      从别的领域咱们已经获得启示，规格化的设计有助于提升生产效率，这个道理在咱们计算机领域也是如此，在开发一个大型程序时，每每须要分给多我的合做，为了防止每一个人的理解是不一样的而形成没法知足具体需求，人们会提供一个规格来解决这个问题；
•      同时这个规格也能够提示程序员来减小bug的产生

规格bug分析

规格bug	对应方法的行数
Effecets内容为实现算法	331

　　bug产生的缘由：在EFFECTS中对于该方法的后置条件讨论不够充分，在不一样状况下对于MODIFIES中的属性的改变状况说明过于模糊。这个方法中实现的是出租车带等待接单时车行走的方式，由于实现复杂没法经过形式化语言实现，因此后置条件讨论的不充分；对应的modifies属性的改变也是模糊的。

很差写法和改进写法

　　个人jsf写的确实不太好，由于有的方法实现的东西有不少，因此用的天然语言没有形式化语言；　　

　　1.个人出租车判断方向时：

 返回值为-1不该该放入exception中

/** * @ REQUIRES: None; * @ MODIFIES: None; * @ EFFECTS: * normal_behavior: * (x==n_x&&n_y>y)==>\result == 4; * (x==n_x&&n_y<y)==>\result == 3; * (y==n_y&&n_x>x)==>\result == 2; * (y==n_y&&n_x<x)==>\result == 1; * exception_behavior(Exception e): * \result == -1; */

        if(x==n_x&&n_y>y) return 4; else if(x==n_x&&n_y<y) return 3; else if(y==n_y&&n_x>x) return 2; else if(y==n_y&&n_x<x) return 1; return -1;

 改进后

/** 　　　*　@ REQUIRES: None; * @ MODIFIES: None; * @ EFFECTS: * normal_behavior: *                 (x==n_x&&n_y>y)==>\result == 4; *                 (x==n_x&&n_y<y)==>\result == 3; *                 (y==n_y&&n_x>x)==>\result == 2; *                 (y==n_y&&n_x<x)==>\result == 1; * 　　　(!(x==n_x&&n_y>y)&&!(x==n_x&&n_y<y)&&!(y==n_y&&n_x>x)&&!(y==n_y&&n_x<x)) ==> \result == -1;
*/

 　　2.查询出租车信息时：

用天然语言写的很简略

/** * @ REQUIRES: None; * @ MODIFIES: None; * @ EFFECTS: * normal_behavior: * 输出i号出租车的具体信息; * exception_behavior(Exception e): * do nothing; */

改进后

/** * @ REQUIRES: None; * @ MODIFIES: None; * @ EFFECTS: * normal_behavior: * \result == "Time:\t"+System.currentTimeMillis()+"Station:\t("+t[i].x+","+t[i].y+")"+"Statics\t"+t[i].statics; * exception_behavior(Exception e): * do nothing; */

　　3.求处于某一状态的出租车的编号

用天然语言写的很简略

/** * @ REQUIRES: None; * @ MODIFIES: None; * @ EFFECTS: * normal_behavior: * 输出处于statics状态的出租车编号; * exception_behavior(Exception e): * do nothing; */

改进后

/** * @ REQUIRES: None; * @ MODIFIES: None; * @ EFFECTS: * normal_behavior: * (\all int i; 0<=i<100; (t[i].statics == statics) ==> /result == i; * exception_behavior(Exception e): * do nothing; */

　　4.判断是否还有路径的下一个结点

写法上仍是不太好

/** * @ Effects: \result == (cnt+1>=0 && cnt+1<=len-1) ==> true; (cnt+1 <0 || cnt+1>len-1) ==> false; */    

改进后　　　

/** * @ REQUIRES: None; * @ MODIFIES: None; * @ Effects:　　　　(cnt+1>=0 && cnt+1<=len-1) ==> \result == true; * (cnt+1 <0 || cnt+1>len-1) ==> \result == false; */    

　　5.返回路径的上一个节点时

写法上仍是有天然语言

/** * @ Requires: None; * @ Modifies: None; * @ Effects: \result == (cnt-1 >= A.arraylist.size() || cnt < 1) ? null : String of previous position */

改进后

/** * @ Requires: None; * @ Modifies: None; * @ Effects: (cnt-1 >= A.arraylist.size() || cnt < 1) ==> \result == null;
　　　*　　　　　　　!(cnt-1 >= A.arraylist.size() || cnt < 1) ==> \result == A.arraylist.get(cnt);

　　　*/

功能bug和规格bug在方法上的汇集关系

	方法名	功能bug数	规格bug数
第9次做业	request	1	0
第10次做业	无	1	0
第11次做业	dispath	2	1

　　在个人程序中，功能bug和规格bug没有体现出具体的汇集关系，但实际上他们是密切相关的，若是规格写很差的话很容易产生功能上的bug，相反规格写的易于理解，更加正规化的是能够大大下降产生功能bug的可能的；

本身在设计规格和撰写规格的基本思路和体会

　　这个jsf写起来确实很是的讨厌，消耗了大量的时间，可能会比写代码的时间用的还要多，但这个时间确定是有所回报的，jsf是一个很是重要的东西。如今可能看不出来这个东西的重要性，可是当不少人在一块儿合做时，这个东西的重要性就体现出来了，为了和其余人进行交互你必需要别人看懂你的代码，而jsf就是一个很是好的让人看懂你代码的东西。同时jsf还能有助于你理清思路，让你减小功能性bug的出现。

　　总的来讲，jsf是很枯燥，很无聊，但它是很是有用的，因此得好好写啊，很差好写就被扣分了(.jpg)！