oo第三阶段总结

Posted 2020-11-09 xyt1606

一、规格化设计发展历史

　　在上世纪60年代，由于程序猿们难以忍受超级难懂的机器语言和稍微好懂一点点的汇编语言，便发明了结构化的程序语言，使得程序猿们能愉快地编写复杂程度适中的程序。但是需求是在不断增长的，渐渐地程序复杂度上涨得超过了人们的想象，使用结构化的程序语言也会无法控制。这时，面向对象的程序设计方法便应运而生。但是人和人写代码的习惯是不一样的，就拿一个小习惯——括号换行来说，有人习惯左花括号换行，有人习惯直接跟在语句后面，会导致两种不同习惯的人互相看代码时都有种想跳楼的冲动。这时，有人就想了：哎，干脆用一套规格化的框架来写出代码大致功能，让不同的人都能看的舒服，看得懂不就完了吗！这时，规格化涉及便诞生了，并且作为工程化设计中相当重要的一环保留至今。并且，规格化设计作为能让其他人读懂代码的重要手段得到了许多人的重视。

 二、规格BUG分析

　　这三次作业没有被找到规格bug。

三、五种优化写法

　　虽然没有被同学报告规格bug，但是每次我都能自己发现一些问题（甚至我第九次作业中有个类五个方法全部没写JSF-_-||（感谢上苍分配给我一个只测功能的同学）），下面列举一些改进：

1、

 

/**
 * @REQUIRES: rq!=NULL;
 * @MODIFIES: req;
 * @EFFECTS: req.add(rq);
 * @THREAD_REQUIRES: \locked(this);
 * @THREAD_EFFECTS: \locked();
 */

 

这里add用的不是很明确，可能引起误解。

 

/**
 * @REQUIRES: rq!=NULL;
 * @MODIFIES: req;
 * @EFFECTS: 
 *     req.size==\old(req.size)+1 && req.contains(rq)==true
 * @THREAD_REQUIRES: \locked(this);
 * @THREAD_EFFECTS: \locked();
 */

 

改成这种写法，无论谁看都知道是添加了一个东西。

2、用自然语言写JSF不是好的写法。

 

 /**
  *  @REQUIRES: None;
     *  @MODIFIES: None;
     *  @EFFECTS: 返回x,y中较小的值
     */

 

改成下面这种写法就很清晰了。

 

 /**
  *  @REQUIRES: None;
     *  @MODIFIES: None;
     *  @EFFECTS: (x>=y) ==> \result = y;
     *      (x<y) ==> \result = x;
     */

 

3、还是自然语言的问题。

 

/**
 *@REQUIRES: None;
 *@MODIFIES: None;
 *@EFFECTS:  隔一段时间反转红绿灯；
 *@THREAD_REQUIRES: \locked(this);
 *@THREAD_EFFECTS: \locked();
 */

 

改成下面这样就比较清晰。

 

/**
 *@REQUIRES: None;
 *@MODIFIES: None;
 *@EFFECTS:  (!Exception exists) ==> 
 *   (\all int i,int j;(0<=i<=80,0<=j<=80)&&(light[i][j]==1)==>light[i][j]=2);
 *   (\all int i,int j;(0<=i<=80,0<=j<=80)&&(light[i][j]==2)==>light[i][j]=1);
 *@THREAD_REQUIRES: \locked(this);
 *@THREAD_EFFECTS: \locked();
 */

 

4、

 

/**
 * @REQUIRES: (req.get(x) exists);
 * @MODIFIES: req;
 * @EFFECTS:  req.remove(rq)；
 * @THREAD_REQUIRES: \locked(this);
 * @THREAD_EFFECTS: \locked();
 */

 

有可能引起歧义。

 

/**
 * @REQUIRES: (req.get(x) exists);
 * @MODIFIES: req;
 * @EFFECTS:  
 *     req.size==\old(req.size)-1 && req.contains(\old(req.get(x)))==false
 * @THREAD_REQUIRES: \locked(this);
 * @THREAD_EFFECTS: \locked();
 */

 

改成上面这种写法，就明确了去掉x位置的元素的效果。

5、Effects中必须是布尔表达式（这个是我所有的方法一开始的JSF都存在的问题）

 

/**
    * @Requires: None;
    * @Modifies: None;
    * @Effects: \result = new Date().getTime();
    */
这里Effects是不对的

 

 

/**
    * @Requires: None;
    * @Modifies: None;
    * @Effects: \result == new Date().getTime();
    */
改成==才可判定真假，才正确。

 

四、功能BUG和规格BUG的聚集关系

作业	功能性BUG数目	规格BUG数目	功能性BUG分析	规格性BUG分析	功能和规格BUG间关系
9	4	0	因为我load新地图时采取的策略是重新loadmap一下，导致我只要load新地图就会有两个地图线程运行，有很多同步问题（直接导致我出租车的移动都不是间隔500了），导致bug较多。	无	无
10	2	0	这次作业有一个开道路的问题，我可以打开原本没有的边但未在Readme中说明； 另一个问题是我投机取巧用了gui的流量（其实完全是错误的）被发现了o(╥﹏╥)o，被扣了一个bug。	无	无
11	0	0	无	无	无

 

 因为没有规格bug所以无法分析。

五、心得体会

 　　总的来说，这三次作业要修改的东西还是比较少的，做起来也相对上个阶段轻松了一些，做完第十一次作业后总有种革命胜利的感觉-_-||。这三次作业的重点其实不在功能添加（从功能实现的难易度就能看出来，红绿灯和可追踪出租车的实现相比于电梯捎带要简单不少，起码我是这么觉得），而在于JSF。这三次作业写下来，我并没有感觉这个东西对作业最后的实现有特别大的帮助，我的实现过程还是先在脑子里想，然后敲代码，最后补JSF。我觉得JSF这个东西应该被安排成一次独立的作业，它应该是确立我们思路的好帮手，而不是先大致完成了整体框架后再去补JSF。比如我惨烈的第九次作业，如果loadfile等功能全部在第七次作业告知我们并让我们写JSF，我可能会有一个更好的思路去实现加载新地图的功能（当然我能力不足是主要原因）。但不可否认的是，我还是学到了很多东西，从一个连正则表达式都用不明白的小白变成了一个能写大概1000多行代码的“大白”，就如同上学期的计组，我在学完这门课后能问心无愧地说出一句：我学到东西了，我觉得就行啦！