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