OO第三次作业 Care for a ride？

OO第三次作业 Care for a ride？

Care for a ride？是《海上钢琴师》中我最喜欢的一句台词，在一个风雨交加的夜晚，1900和他的小号手朋友一起，松开钢琴的轮锁，让钢琴在甲板上随意滑行，所以这四次出租车作业，我一直将“Care for a ride？”作为我的README题目。

规格设计发展史

为什么要写规格？

程序，是给机器看的，规格，是给人看的。为什么要在给机器看的东西上写给人看的东西呢，是因为工程的需要。工程是复杂的，长期的，多人合作的。因此，不仅仅你的代码需要实现功能，你也需要维护代码的可读性，你也需要辅助自己和他人，了解每个类每个方法的功能，这样他人才能维护你的代码，你的代码才不是“日抛型”代码，而可以持续的应用于生产活动当中。

并且，规格化设计也将辅助你从“意识流”设计，想什么写什么，变到标准化的设计。“To err is human.”不为自己定些游戏规则，人肯定会犯错的（虽然定了法律也有人犯罪）。

最初的程序设计是直接面向机器、阅读困难，后来出现了面向过程的设计思想。对于面向过程设计思想的变革，goto语句成为讨论的热点。Dijkstra于1968年发表著名的《GOTO有害论》，引起了广泛的关注，结构化的设计思想也在此时应运而生。结构化设计思想，是指的是通过“自顶向下、逐步细化、模块化”的方法进行程序设计。这种设计思想旨在控制各个模块的程序复杂度，从而保证整体工程的正确性。面向过程的设计存在着扩展性不好的弊病，由此，产生了面向对象的设计模式。程序设计的模块化体现的更为明显，各个部分更加独立，相应地，各个模块之间的交互也更加重要。

无论是面向过程还是面向对象，只要存在模块之间的交互，就必然存在着规格规范的问题。就个人感觉来说，规格是说明了模块的接口，说明了模块的IO要求。所以，规格化是模块化的发展的必然需求。

规格bug及其分析

主要有两个bug，一个是JSF规格书写，一个是repOK方法书写：

JSF 规格书写bug

Guideline1:

前置条件必须是布尔表达式。

在后置条件描述中，每个@EFFECTS后跟着的都应该是一个可判定的布尔表达式，且应该只使用集合论和一阶逻辑谓词来表示的布尔表达式，从而有效描述方法的设计约束。虽然也可以采用自然语言描述规格，但会不可避免的引入二义性。

备注：被 JSFTool 测试除了了问题。

  
  C:\oo\testee\src\oo11\InputHandler.java:47: 警告 - oo11.InputHandler.run() : "System.in"
  Warning 95 : @requires (pre-condition) must be a boolean expression!
    (Maybe this is a natrual language boolean expression...)

这个地方使用了成员变量描述 requires ，不是逻辑表达式、也不是自然语言，java 也没有 c++ 一样的对对象的非 null 判断，因而错误。

  C:\oo\testee\src\oo11\TrafficLight.java:36: 警告 - 
  oo11.TrafficLight() : "total_num = 0"
  Warning 4 : @effects (post-condition) must be a boolean expression!
    (Maybe this is a natrual language boolean expression...)
  ​
 C:\oo\testee\src\oo11\TrafficLight.java:36: 警告 - 
 oo11.TrafficLight() : "
        pos = new Position[MAXN]"
 Warning 5 : @effects (post-condition) must be a boolean expression!
  (Maybe this is a natrual language boolean expression...)

以及很多构造函数、setter 的 effects，直接使用了赋值，没有使用逻辑表达式、也不是自然语言，仅仅只描述了算法。

repOK 方法书写bug

针对构造方法，初始状态repOK为真。

备注

  package oo11;
  ​
  public class TestMain {
  public static void main(String[] args) {
   Car car = new Car(40);
   try {
    System.out.println(car.repOK());
   } catch(Throwable e) {
    e.printStackTrace();
   }
   TraceableCar carB = new TraceableCar(5);
   try {
    System.out.println(carB.repOK());
   } catch(Throwable e) {
    e.printStackTrace();
   }
   Request req = new Request();
   try {
    System.out.println(req.repOK());
   } catch(Throwable e) {
    e.printStackTrace();
   }
  }
 }

这是测试两个 Car 的 repOK 和 Request 无参数构造的 repOK 的主程序，repOK 没有返回 true，原因是 from 数组构造后新建了数组，但是里面的值基本都是 null，但是 repOK 中调用了 fromi.isValid()，导致 nullpointer。

再有是 Position 的带参构造，没有检查坐标的范围。

测试用代码：

  package oo11;
  ​
  public class TestMain {
  public static void main(String[] args) {
   Position pA = new Position(80, 80);
   System.out.println(pA.repOK());
   Position pB = new Position(-1, -1);
   System.out.println(pB.repOK());
   Request reqA = new Request("CR", pA, pB);
   System.out.println(reqA.repOK());
  }
 }

还有很多像是，Information 和 Main 的 repOK 没写（return true;）之类的问题。

不好的条件写法及其改进

  修改前：
  public void addNearby(Long now_time, Request now_req) {
  /**
  * @REQUIRES: \exists cars[i].getStatus == Car.CarStatus.waiting
  * @MODIFIES: now_req
  * @EFFECTS: 将符合抢单条件的车辆加入到now_req的备选集合中
  */
 ​
 修改后：
 public void addNearby(Long now_time, Request now_req) {
  /**
  * @REQUIRES: \exists cars[i].getStatus == Car.CarStatus.waiting
  * @MODIFIES: now_req
  * @EFFECTS: \all Integer i, req.set.cotains(cars[i]) ==> (cars[i] can answer req)
  */

  
  修改前：
  public ArrayList<Integer> getCarAtStatus(Car.CarStatus status) {
  /**
  * @EFFECTS: 返回处于status状态的Car的下标集合
  */
  
 修改后：
 public ArrayList<Integer> getCarAtStatus(Car.CarStatus status) {
  /**
  * @EFFECTS: \result = ArrayList<Integer> set, \all Integer i, set.contains(cars[i]) ==> (cars[i].status == status)
  */

  修改前：
  public void loadRequest(String file_path) {
  /**
  * @REQUEIRES: file_path!=null
  * @MODIFIES: Q
  * @EFFECTS: 读取Loadfile中的Request，并加入请求队列中。
  */
  
 修改后：
 public void loadRequest(String file_path) {
  /**
  * @REQUEIRES: file_path!=null
  * @MODIFIES: Q
  * @EFFECTS: \all Request req, Q.contains(req) ==> (Loadfile.contains(req) )
  */

  
  修改前：
  public void openRoad(Position now_src, Position now_dst) {
  /**
  * @REQUEIRES: (now_src.getX() >= 0 && now_src.getX() <80) &&
  *      (now_dst.getX() >= 0 && now_dst.getY() <80);
  * @MODIFIES: dig;
  * @EFFECTS: 打开(now_src,now_dst)对应的路;
  */
 ​
 修改后：
 public void openRoad(Position now_src, Position now_dst) {
  /**
  * @REQUEIRES: (now_src.getX() >= 0 && now_src.getX() <80) &&
  *      (now_dst.getX() >= 0 && now_dst.getY() <80);
  * @MODIFIES: dig;
  * @EFFECTS: \all Integer i,j; (dig[i][j] == 1) ==> (dig[i][j] in (now_src, now_dst))
  */

  
  修改前：
  public synchronized void remove(Request now) {
  /**
  * @REQUEIRES: (queue != null);
  * @MODIFIES: None;
  * @EFFECTS: 从queue中删除当前请求。 
  * @THREAD_REQUIRES: \locked(this);
  * @THREAD_EFFECTS: \locked();
  */
 ​
 修改后：
 public synchronized void remove(Request now) {
  /**
  * @REQUEIRES: (queue != null);
  * @MODIFIES: None;
  * @EFFECTS: (\forall Request req; req != now; queue.contains(req) == \old(queue).contains(req)); 
  * @THREAD_REQUIRES: \locked(this);
  * @THREAD_EFFECTS: \locked();
  */

功能bug及其与规格的联系

第11次指导书中：

b) 可追踪出租车扩展普通出租车的路径选择方法，使得可追踪出租车能够行走关闭的道路（普通出租车则不可以）。注：关闭的道路的车流为0，且保持不变。

测试检查对于关闭的道路，可追踪出租车是否会将被关闭的道路的流量记为0。

结果输出算得的最小流量为 2，并下一步走到流量更大的边 (0,0) -> (1,0)。但根据指导书，被关闭的边 (0,0) -> (0,1) 流量更小、为0。bug 源于我使用了GUI中的流量，但是我忘记修改了本次新GUI的代码，导致对于被关闭的道路 getFlow 时，得到的流量不一定为 0：

  
  public static int GetFlow(int x1, int y1, int x2, int y2) {// 查询流量信息
  synchronized (guigv.memflowmap) {
   return guigv.memflowmap.get(Key(x1, y1, x2, y2)) == null ? 0 : guigv.memflowmap.get(Key(x1, y1, x2, y2));
  }
 }

其与规格之间的联系，在于我没有明确规格中的流量是怎么来的，而忘记了使用新GUI时造成的流量维护错误。

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

最初我真的觉得写规格一点用也没有，因为据我所知，大家都是在写完代码之后写规格·····

这样的规格意义就不大了，因为规格是用来设计的，而不是用来debug或者完成任务的，否则那还不如直接写两句注释。

直到在OO第六次上机当中，我们的任务是完成一个银行账户管理系统，而在这个系统中，有一个类的方法全部都是空的，只有规格，但是规格很完备（老师写的和同学写的是不一样）。

规格用布尔表达式式写成，我发现基本上根据规格写出代码是一件非常容易的事情，而且，写明前置和后置条件，应该可以避免很多由于疏忽造成的bug，想起了高中时写函数，老师逼着你写定义域一样，不在定义域内的计算都是不合理的，不明确前置后置条件的方法，都是耍流氓的方法。