oo第二单元总结

时间过得很快，转眼间又过去了三周，在第一个三周，我们围绕求导这个主题进行了训练。在这三周，我们难度有所升级，围绕着电梯调度这个主题进行了训练。众所周知，这个是每一个学习计算机的学生必写的程序。

第一次作业

（1）简单分析

第一次作业在各个方面的设计都比较简单。因为这是我们刚开始接触多线程编程，对于一些设计原则以及语法问题还有一点陌生，给我们一些简单的问题练练手也是很好的。这次我们只有一部电梯，电梯的运行的时间限制也比较宽松，只要一个人一个人的完成每个人的请求就不会有问题。因此我的总体的调度设计也非常简单，就是按照先来先服务的原则，一次一次的去接一个人，再把这个人送到指定的楼层。这次由于对多线程的陌生，也没有做任何的优化，而且对于暴力轮回的问题还不太懂，导致有的地方出现的暴力轮回的情况。从线程方面来说，我一共有两个线程，一个线程负责输入，一个线程负责电梯的运行与调度。两个线程以等待队列为共享对象，输入线程在接收到数据后存入等待队列，电梯线程从等待对列获得请求。逻辑十分的简单。

（2）程序结构

以下是UML类图

可以看出，我的主函数为maininput，在这个主函数中，我创建了一个等待队列，以及两个进程（电梯和输入进程），这两个进程以这个等待队列做数据交换。

以下是Metrics分析

在Elevator的run方法中，我调用了多次等待队列里的方法去判断一些条件，导致ev（g）偏高。

（3）bug分析

第一次作业并无bug，在此就不过多分析。

第二次作业

（1）简单分析

第二次作业和第一次相比，多了对电梯调度的要求，并不能一次只运送一个人，要进行捎带工作。而且电梯的运行楼层发生了变化，出现了负的楼层。我认为这次的难点就在于捎带算法的实现，以及如果要拿更多的性能分，如何找到更优的算法。我在这次作业中用的就是简单的扫描算法。首先选择离当前电梯所在位置最近的有人的楼层作为运行方向。如果到达的楼层有人，且目标楼层的方向与电梯运行方向一致就让其进入。如果电梯里还有乘客或者电梯运行方向还有人在等待，那么电梯不转变方向。反之转变方向。如果都没有人了，那么电梯就会停止工作知道再次有人来到。

我认为我设计的不同的地方在于，我等待队列的设计并不是一个可变数组了，我是按照等待的人所在的楼层来存储所有请求，这样可以使请求的分配更加方便。

（2）程序结构

以下是UML类图

可以看到，这个类图与第一次作业的类图不一样的地方在于，电梯中也要设计一个存储队列，因为调度不再简单是一个人一个人的满足。

以下是Metrics分析

在ev（G）偏高的方法中，都是与调度有关的算法，需要反复调用等待队列中的函数。

（4）bug分析

很遗憾的是，这次我没有找到别人的bug，好消息是自己也没有被发现bug。我觉得，就求导过程来说，按照一定层次来写，是不容易犯错误的，我写的时候没有想到可能会出bug的点，因此我也没有测出别人的bug。

（5）优化

这次我就是按照简单的ALS去写，没有太多的优化，因此就得到了90分

第三次作业

（1）简单分析

第三次作业与第二次相比，瞬间就变复杂了许多。首先电梯的数量变多了，从一台变成了三台。其次电梯增加了乘客人数的最大承载量。还有电梯上升一楼的时间也不同。最后电梯的可到达楼层也是不一样的。这就给设计带来的一些阻力。首先，对于每部电梯基本信息的不同，我认为还是很好处理的。只要在构造对象时给与每个电梯不同的信息即可。对于每部电梯的运行，我认为可以不做变化。这次作业需要加入的，就是一个调度器。我的调度器的功能就是把所有请求分配给每部电梯。而这个算法其实是很复杂的，我也没有写出特别好的算法。

（2）程序结构

以下是UML类图