OO第十二次作业

规格设计的发展历史

　　随着计算机软硬件的发展,代码的复杂程度也在不短增加,随着计算机软件规模日渐庞大，结构化程序设计方法开始无法满足用户的需求，面向对象程序设计产生。面向对象程序设计是一场重大的革命，提高了开发人员的效率，有效的控制了软件开发的复杂度，提高了软件的可维护性和可拓展性。一个复杂,功能强大的程序,往往不只是由单个人员设计而成,需要多人的合作,各司其职,再把多人的工作整合起来,而要达到多人为一份作业服务,就需要要求代码的规格化,提高程序的规范性以及程序的模块化划分. 这样使得程序设计的数据更加安全, 软件的可维护性得到有效的提高.

bug分析:

　　功能性bug:

　　第九次作业:出租车不能初始化信用值

　　产生原因:把指导书里面的NO和status看到了一起,所以在设置初值的时候忘记还有个信用值了,自己的测试不够准确.

　　　　代码:

public void set(int mode,int honesty,int x,int y){
    /**@ REQUIRES:0<=x,y<=79,1<=mode<=4
     @ MODIFIES:customer dest mode
     @ EFFECTS:mode = input(mode) pos = input(pos)
     @ */
    pos = new Point(x,y);
    if(mode == 0)
        this.mode = 4;
    if(mode == 1)
        this.mode = 3;
    if(mode == 2)
        this.mode = 1;
    if(mode == 3)
        this.mode = 2;
    this.honest = honesty;
    if(mode == 3 || mode == 4){
        customer = new Point(1,1);
        dest = new Point(1,2);
    }
}

　　第十次作业:没有按照最短流量规则行走.

　　产生原因:因为功能改变导致流量计算规则更新,重写了流量相关的代码,结果最后增加流量的一个语句写掉了,主要还是自己的测试有点简单,不充分.

规格 bug:

　　第九次作业有需要写得不合规范,第十次作业和第十一次作业有关于jsf格式问题被扣很多,比如空格还有'\result的格式等等.

规格 bug 产生的原因

　　自己并没有充分理解格式,对于jsf的规范写法不够了解,仅仅当做注释一类的作用

　　有的测试者比较过分.按照自己的理解而又不给出依据.

分别列举 5 个前置条件和 5 个后置条件的不好写法, 并给出改进

前置条件

鉴于自己的做修改

• @ REQUIRES:中间@不要加空格,@REQUIRES
• 对于对象数组, 应判断数组中每个对象也不为空 @REQUIRES: (arr != null) && (\all i in arr; i != null)
• 要对传进的所有有对象进行描述,不要忽略 null的情况@REQUIRES: * != null
• 少用自然语言
• 约束对象范围,如坐标值需要大于0等

后置条件

• 要写完整,对于满足requires和不满足的都要填写
• 不能用纯代码的格式,要用规范格式书写,比如==需要用两个=,只能是判断
• 描述规范,/all /exsit要分清.
• 对常量单独定义, 否则失去意义 @EFFECTS: (0 <= x < max_limit) ==> (\result == true)
• 少用自然语言

　

功能 bug 与规格 bug 在方法上的聚类关系

功能 bug 与规格 bug 在我的程序中没有同时出现.无法描述

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

说实话这个规格有点让人难受,描写规格本来是很好的,很规范,让人对于代码的理解更轻松的一件事情.但是由于不够准确的规格指导,规范化完全不够的jsf写法,就我个人很言,写起来让我很烦恼,很难写,甚至比我写那些代码都更麻烦,而且,按照写法写完的jsf也并不利于阅读,对于这个规格同学们都有各自的理解,往往有很多人能找出很多无理的错误,对于作业来说,公测现在已经够弱了,基本上已经快变成想拿分就能拿分的情况,你要做到jsf能符合完全的"规范"(我现在也没有了解完全的规范),比你写出一个合适的程序更加困难.

希望以后能让jsf达成他应有的效果,是提供方便,提高效率,消除分歧,而不是现在这样的麻烦,降低了效率,引发了争端.