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的编程做业终于完结了，撒花撒花。