OO第三次博客作业

一、规格化设计的大致发展历史

在1960年代末至1970年代初期，出现了一次软件危机：一方面需要大量的软件系统，如操作系统、数据库管理系统；另一方面，软件研制周期长，可靠性差，维护困难。人们希望编写出的程序结构清晰、易阅读、易修改、易验证，即得到良好结构的程序。60年代中期，大容量、高速度的计算机出现，随之出现的是代码量急剧提升，复杂度急剧增长、程序可靠性问题突出的问题。结果化程序设计随之提出，它要求程序设计时以模块为单位，每个模块专职自己的工作，而要在模块间交流，在开发者和用户，开发者和开发者之间交流，就只需要相应接口即可。到了80年代，“软件工程”的概念第一次被提出，计算机的速度和容量大大提高，程序的复杂度也急剧增长，人们开始在程序设计时以模块为单位，有了自己各自独立的工作，开始出现规格化抽象。比如说C++和JAVA的类说明和类实现出现了分离。之后，随着计算机软件规模日渐庞大，结构化程序设计方法开始无法满足用户的需求，面向对象程序设计（OOP）应运而生。面向对象程序设计是一场重大的革命，提高了开发人员的效率，有效的控制了软件开发的复杂度，提高了软件的可维护性和可拓展性。

规格化设计大大提高了程序的规范性和规模化，提高了程序可读性，降低了维护难度，所以得到了广泛的重视。

二、三次作业规格BUG

第九次和第十次作业均没有出现规格BUG。

不过可能是九十两次作业欧气太足善良的测试者都没有报我规格书写上的笔误（可能根本就懒得看），第十一次作业的测试者捡了个便宜，报了一堆笔误的BUG，如<=打成<类似的错误，我觉得这种错误就没什么必要列个表格了吧，除了这种也没别的BUG了。

三、分析BUG产生的原因

自暴自弃，觉得在OO测试体系中引入JSF的互测是一件很没脑子的事，懒得检查，笔误频频。

四、写法改进

前置条件

@REQUIRES: 
         *      status != null;
         *      credit >= 0;
         *      pos != null;
改为
@REQUIRES: 
         *      status != null;
         *      credit >= 0;
         *      pos != null && pos.repOK();

@REQUIRES: 
         *      !neighboors.isEmpty();
改为
@REQUIRES: 
         *      neighboors != null && !neighboors.isEmpty();

 @REQUIRES: 
         *      None;
改为
 @REQUIRES: 
         *      this.status == CarStatus.STOP;

@REQUIRES: 
         *      None;
改为
@REQUIRES: 
         *      cars != null;

@REQUIRES: 
         *      req != null;
改为
@REQUIRES: 
         *      req != null && req.repOK();

后置条件

@EFFECTS: 
         *      (当前车处于等待状态且位于请求request范围内) ==> \result == true;
         *      (当前车不处于等待状态或不在请求request范围内) ==> \result == false;
改为
@EFFECTS: 
         *      (this.status == CarStatus.WAITING && 车位于请求request范围内) ==> \result == true;
         *      (this.status != CarStatus.WAITING || 车不在请求request范围内) ==> \result == false;

@EFFECTS: 
         *      this.waitTime == 0;
         *      this.choosed == false;
         *      true ==> (汽车停止一秒);
改为
@EFFECTS: 
         *      this.waitTime == 0;
         *      this.choosed == false;

@EFFECTS:
         *      (请求不是同质) ==> this.queue.contain(req);
改为
@EFFECTS:
         *      (\all Request r;reqList.contains(r) && r.time == req.time;!r.equals(req)) ==> this.queue.contain(req);

五、BUG聚集关系

As I have mentioned before, 几个规格BUG都是笔误，自然不会对功能产生什么影响，不存在所谓的聚集关系。

六、感想

累，甚至懒得表达自己的想法了。

首先要把规格化设计和“北航计算机学院OO课程的规格化设计内容”分开讨论，我认为我没有涉及到什么正儿八经的规格化设计的学习，因此我就只说后面这一部分了。

其实也没什么好说的，大家都说的差不多了，课程组自己心里也有数。第二次出租车作业来补规格，大家都是根据代码来写规格了，没什么好说的，更恶心人而已，增加了测试者急中生智强行JSF扣分的可能性。

没什么好说的，long live oo！

OO第三次博客作业

原文：https://www.cnblogs.com/wynterr/p/9108757.html