OO第三阶段作业总结

调研:

       最早的程序设计是直接采用机器语言来编写的,或者使用二进制码来表示机器能够识别和执行的指令和数据。机器语言的优点在于速度快,缺点在于写起来实在是太困难了,编程效率低,可读性差,并且编写规模大的程序。之后逐渐产生了面向过程和面向对象的编程思想,来满足不同条件下的编程方式。1968年《GOTO有害论》这篇著名的论文发表后,引起了许多人的广泛关注,结构化思想逐渐进入人们的视野。之后在编程过程中,程序员越来越对已经产生的抽象水平不满,不足以满足他们对规模大的程序编写的需求,因此出现了一种语言机制,也就是规格化抽象,允许程序员在需要时构建自己的规格化设计方法。规格化抽象是将运行细节(即模块如何实现)抽象为用户所需求的行为(即模块做什么)。在规格化设计的基础上,各个模块表达得简明扼要,可读性强,规模大,耦合性好,因此越来越受到人们的重视。规格化是程序发展所必要的条件。

 

BUG分析:

        第九次作业:

 

BUG内容 BUG类型 BUG原因
map加载错误 crash 在loadfile的时候存取数组越界
出租车运行20s没有停1s error 在设置出租车行驶方式时疏忽
地图文件中有空格 crash 未处理异常情况
出租车运行一边的时间有可能超过500ms error  随机数设置错误

 

        BUG产生原因:这次的BUG最主要的问题在于对新增的要求Loadfile的设计过于粗略,没有考虑到各种不合理的情况,在功能上的实现不完全,同时也没有花时间去debug,认为其不重要,这就是自食其果,然后导致了两个crash类型的bug,其实测试者很善良,如果再仔细一点,估计还会多很多的crash类BUG。同时由于上次没有发现这两个error的BUG,导致这次被测了出来。总而言之就是设计不够细致,同时没有花时间去debug。

        第十次作业:

BUG内容 BUG类型 BUG原因
没有选择流量最小的路径 error 在读取流量文件时存储出错
调度时间少于7.5s error 由于整体时间上升,但忘记设置调度时间了

        

        BUG产生原因:这次的BUG蠢得让我无话可说,先说调度时间少于7.5s,由于之前改变了出租车行驶地图一条边的时间,从200ms增到了500ms,于是出租车调度时间从3s增加到了7.5s,但是我忘记改正这个地方了。不知道为什么上一次作业没给我测出来,然后一直错到了现在。很神秘。

        第十一次作业:

        经过两次作业的痛定思痛,把前两次的bug全部de完了,并且这次作业是最后一次编程作业,因此格外用心,所以没有被挑出bug来,可以说结尾得还行了。

 

JSF的不足和改进:

        前置:

        1. 大量使用None;(本人就喜欢这么干)

            例如:方法public boolean judge(String filename)

            改正前:@REQUIRES: None;

            改正后:@REQUIRES: filename != null;

        2. 缺乏类型描述

            改正前:@REQUIRES: map.exist && map.bound <= 80;

            改正后:  @REQUIRES: map.exist == true && map.bound <= 80;

        3. 忽略范围限制

            例如:方法public BFS(point E, point S)

            改正前:@REQUIRES: E != null && S != null;

            改正后:@REQUIRES: 0<= E.getx() <=79&&0<= E.gety() <=79 && 0<= S.getx() <=79&&0<= S.gety() <=79;

        4. 多余的前置条件

            改正前:@REQUIRES: num != null && num <= 80;

            改正后:@REQUIRES: num <= 80;

        后置:

        1. 使用自然语言(本人见过直接用中文的)

            改正前:@REQUIRES: 如果a包含了b,则返回true;

            改正后:  @REQUIRES: a.contains(b) ==> (/result == true);

        2. 考虑得不周到,只写了一部分

            改正前:@REQUIRES: a.contains(b);

            改正后:@REQUIRES: a.contains(b) && a.size() = a.size() - 1;

        3. 使用了错误的伪布尔式子

            改正前:@REQUIRES: flow.add;

            改正后:@REQUIRES: flow.add == true;

        目前遇到的,并且也只能想到以上几点前置条件和后置条件容易出错的地方。其实使用自然语言是可以的,但是不能大量使用,还是应当使用布尔表达式来表示。其实感觉JSF的撰写还是十分的有必要的,在debug的时候,JSF能够起到很好的预览作用,可以大致判断出bug出现的位置。第一次写可能会出错或者不适应,到后来就发现了JSF的实用之处。

 

感想和体会

        本人在完成作业时,是把整个程序的功能都完成后,再回头去写JSF的规格设计,然后发现对于代码量庞大的方法,需要花大量时间去回忆这个部分的功能和作用才能完成JSF的撰写。而且再debug阶段也很花费时间和精力。因此规格应当是在方法撰写之前就开始设计,同时在代码中就应当按照规格来完成方法。这样不仅在设计时不需要花费大量时间去处理,在debug时也能更快的找到问题出现的位置。OO的编程作业终于完结了,撒花撒花。

posted @ 2018-05-30 10:48  aicoy  阅读(139)  评论(0编辑  收藏  举报