OO第三次博客作业

写在最前面：

　　啊，这次博客作业我要偷懒了。毕竟除了这3学分的面向对象，我还有23学分的其他课程要修，这门课占用我的时间已经够多了，不能再继续下去了。我这周的ddl有点多，牺牲一下OO好了。（想起吴老师有一次下课时候说的话，大致意思是这门课之前是没有的，但是嫌我们太闲了，就开了这门课，其实我觉得吧......心里想闲的人给他多少门课他也能闲下来，想要好好利用时间的人即使没有课也会把时间利用的很合理）

一、规格化设计的大致发展历史及受到重视的原因

　　软件形式化方法最早可追溯到20世纪50年代后期对于程序设计语言编译技术的研究，即J.Backus提出BNF描述Algol60语言的语法，出现了各 种语法分析程序自动生成器以及语法制导的编译方法，使得编译系统的开发从“手工艺制作方式”发展成具有牢固理论基础的系统方法。

　　形式化方法的研究高潮始于20世纪60年代后期，针对当时所谓“软件危机”,人们提出种种解决方法,归纳起来有两类：一是采用工程方法来组织、管理软件的开发过程；二是深入探讨程 序和程序开发过程的规律，建立严密的理论，以其用来指导软件开发实践。前者导致“软件工程”的出现和发展，后者则推动了形式化方法的深入研究。经过30多 年的研究和应用，如今人们在形式化方法这一领域取得了大量、重要的成果，从早期最简单的形式化方法一阶谓词演算方法到现在的应用于不同领域、不同阶段的基于逻辑、状态机、网络、进程代数、代数等众多形式化方法。形式化方法的发展趋势逐渐融入软件开发过程的各个阶段,从需求分析、功能描述(规约)、(体系结构/算法)设计、编程、测试直至维护。(百度百科)

二、第九次作业的bug

1）bug：

这次我被发现了一个功能bug，我的loadfile没有按照要求写，我只提供了各种设置的方法以及接口，没有按照指导书的要求读入Loadfile的文件进行设置。

2）原因：

我当时写的时候觉得指导书的要求有些不合理，心想着一个bug也无伤大雅，所以就没有按照要求写。

三、第十次作业的bug

1）bug：

这次被报了两个功能bug，都是loadfile的问题，测试者没有成功调用我的loadfile。

2）原因：

我其实在写第九次作业的时候没有预料到在公测的时候会要求必须使用loadfile，然后我就没按要求写，但是后来我觉得这样会给测试者带来不必要的麻烦，所以这次作业我就加上了。但是由于我的问题，在Readme中没有说清楚，导致测试者没有正确调用，造成了bug。原因是这样：我采用了String.equals("#flow")这样的语句来进行判断，但是测试者在loadfile的文件中写成了“#flow+空格”，导致没有正确读入。

四、第十次作业的bug

1）bug：

这次被报了两个功能bug：第一个bug是loadfile的incomplete，第二个是出租车流量没有选择最小流量

2）原因：

第一个bug的原因是我在loadfile中没有实现加载地图和红绿灯文件，因为我觉得有点没必要，多此一举，在测试一开始直接修改原来的地图文件和红绿灯文件就好了呀，一个incomplete也无所谓了。

第二个bug的原因我不知道.....我也懒得申诉了，我感觉还是由于红绿灯的时间频率是随机的导致了每个出租车的频率不同，加上gui刷新时间是有间隔的，导致了一定的误差，而且指导书规定的流量的计算方法我个人认为有点悬乎。

五、JSF的不好写法

　　从我个人的角度来说，我觉得JSF之分两类，第一类是方法实在写的太长了，以至于根本写不出规格；第二种只要你认真一点写就可以写的很好了。

　　我下面列两个我第九次作业中写的不是很好的JSF：

1）

    public int getvolume(int l,int m) {
        /**@REQUIRES:int l,m;
                     0<=l,m<80;
           @MODIFIES:None;
           @EFFECTS:
esult=volume[l][m];
           @THREAD_REQUIRES:None;
           @THREAD_EFFECTS:None;
         */
        return volume[l][m];
    }

　　这个规格写的有问题的地方应该是EFFECTS，应该使用布尔表达式进行表达，不应该直接写成赋值的形式，应该改为：

    public int getvolume(int l,int m) {
        /**@REQUIRES:int l,m;
                     0<=l,m<80;
           @MODIFIES:None;
           @EFFECTS:
esult==this.volume[l][m];
           @THREAD_REQUIRES:None;
           @THREAD_EFFECTS:None;
         */
        return volume[l][m];
    }

2）

    synchronized public void addvolume(Point a,Point b) {
        /**@REQUIRES:Point a,b;
                      0<=a.x,a.y,b.x,b.y<=79;
           @MODIFIES:volume;
           @EFFECTS:volume[a.x*80+a.y][b.x*80+b.y]++;
                    volume[b.x*80+b.y][a.x*80+a.y]++;
           @THREAD_REQUIRES:None;
           @THREAD_EFFECTS:locked();
         */
        int aa=a.x*80+a.y;
        int bb=b.x*80+b.y;
        volume[aa][bb]++;
        volume[bb][aa]++;
    }

现在看来，以上规格的写法存在两个问题：

1）volume应该写成this.volume，这样可以更好的区分传入的参数和属性；

2）严格的来说，不应该出现++这种表示，应该用old来进行表示，下面是更好的写法：

    synchronized public void addvolume(Point a,Point b) {
        /**@REQUIRES:Point a,b;
                      0<=a.x,a.y,b.x,b.y<=79;
           @MODIFIES:this.volume;
           @EFFECTS:this.volume[a.x*80+a.y][b.x*80+b.y]==old(this.volume[a.x*80+a.y][b.x*80+b.y])+1;
                    this.volume[b.x*80+b.y][a.x*80+a.y]==old(this.volume[b.x*80+b.y][a.x*80+a.y])+1;
           @THREAD_REQUIRES:None;
           @THREAD_EFFECTS:locked();
         */
        int aa=a.x*80+a.y;
        int bb=b.x*80+b.y;
        volume[aa][bb]++;
        volume[bb][aa]++;
    }

六、功能bug与规格bug在方法上的聚集关系

　　emmmm......由于我没有被报在规格方法上的bug，所以就不写这部分了，应该是没啥关系。

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

　　我个人觉得吧，在设计和写规格的时候，最重要的一点就是要把这个方法当成一个黑盒，你不需要知道具体它是怎么运作的，你只需要关注你给它什么东西，它会得到什么，产生什么样的影响就好了。总的来说吧，我个人感觉如果仅仅使用JSF语言，有些情况下描述起来很不方便，甚至还不如自然语言说起来清晰（我觉得毕竟这个玩意是给人看的，如果可以用一两句话说清楚就能理解的事情，再写十几行的JSF反而会显得多此一举了）

　　还有一点我想说的是，其实我们在写的时候大多数都是先把程序写好了，然后再写JSF规格，这种情况下可能我们对这个规格的理解可能真的没有那么深。我觉得可以增加一些看规格写代码这样的作业，可能对我们的提升会更直接一些（例如课上实验这种形式，我觉得相对于课下作业，课上实验的练习对我个人对JSF理解的提升更大）

　　其实我觉得啊，这不是我们唯一一门接触程序规格的课程，在填写OS代码的时候不就是按照规格写程序吗.......而且那个难度好像更大......