1. 引言
摘要：本篇博客详细讲述电梯调度算法的流程，测试程序的框架，以及测试文件（XML）的生成。
继上一个结对编程项目（3D中国跳棋 —— 记与子禾童鞋的结对编程（附网站地址及完整源码））之后，我们迅速进入了第二个pair的怀抱中。
结对人员 许晓彬&胡文凭
时间 2010/12/4 – 2010/12/10
源代码 --
快速使用说明 已经编译好，解压后运行Runme.bat即可看到测试结果
事实上这是一个非常不错的学习的例子！对于有兴趣的读者，请参阅pair project II (电梯调度程序)获得关于整个
project的详细信息，并可以在我们刚发布的C#中XML文档生成实例：Elevator Scheduler测试文件的生成详解 中
获得关于电梯调度程序测试文件生成的方法和代码，然后您可以自己进行探索
。如果你有更好的算法或者建议，
请联系 Xiaobin(xxb263@hotmail.com) 告知我
，谢谢！
下面是详细的说明：
2. 电梯调度测试程序框架：
提供给我们的调度算法的接口（即从调度算法的角度能使用的东西）：
1. 乘客(passenger)：我们不知道任何关于电梯乘客的信息和反馈，不知其重量几何，亦不知有多少乘客。
2. 请求(request)：当乘客请求时，我们在请求到来的时刻接到通知，并知道其请求方向（上楼还是下楼）。
当乘客进入电梯时，我们在进入的时刻接到通知，知道乘客要到哪一层楼。
3. 电梯(elevator)：我们知道每一部电梯的状态（通过调用以上框架中电梯接口(IElevator)提供的方法）。
我们需要实现的：
1. 调度程序算法：即 IScheduler 中 Run() 函数的内容，在每一时刻（tick），Building框架会调用该 Run() 函数来进行电梯调度。
（实际上框架做了优化，如果一段时间没有请求，将直接跳过该时间段，不会运行 Run() ）
2. Initialize(in Elevators)：初始化函数，用于初始化调度程序所需数据结构。
3. Queue(in req)：乘客请求到达时的通知函数，每一个乘客请求到来的时刻，Building框架程序会调用 Queue(in req) 来将乘客
请求信息传递给电梯调度程序。我们需要实现在 Queue(in req) 很好地管理这些请求。
下面是框架的详细UML类图（by Sen Xiang)：
3. 电梯调度算法
下面是我们程序的基本流程（visio流程图，更清晰的您可以下载：https://files.cnblogs.com/codingcrazy/ElevatorSchedulerFlowChart.rar）：
4. 调度性能测试
测试文件的生成和原理请见：C#中XML文档生成实例：Elevator Scheduler测试文件的生成详解
5. 感想及pair存照
关于电梯调度算法，我和文凭进行了很多讨论，同意写一个通用的算法，在将它做得非常健壮以后，再来考虑针对要求的测试例子做优化。
回想起来，是11月30号我和文凭讨论了整个测试程序的框架，提交以后发现我们想的真是难以想象的粗糙。后来在Sen的框架基础上进行算法设计和编程，我们是走得比较快的pair之一。我们有过激烈的PK，也有过一同为一个bug的苦思冥想，还有在公交车的回家的路上的讨论，所以这次pair算是相当成功吧。文凭是个挺随和的人，但是当盯上某个问题之后，就会进行思考并试图说服我，这是很好的。而我一开始想先把程序写出来其实也应该促进了我们的进度，如果按文凭的意思是要先把问题想清楚，这样的话可能我们会少走些弯路（少碰到一些bug），有利有弊吧。
小小有点遗憾的是我们的算法最后并没有对测试例子的特点进行优化，仍然是一个“通用”算法。我向Sen提的做一个“自我学习”的调度算法的想法最终停留于想的阶段。如果有下了程序研究的读者可以看看这个：ElevatorScheduler调试记录。
PS：刚和辉哥去电梯里实测，发现走5层楼需要20秒，即每层4秒，但电梯起始需要加速，停止时需要减速，所以如果是只下降一层需要7、8秒，但由于根据约定，乘客在相邻层之间游动的概率很小，因此可以假设每层楼需要5秒，而电梯到达请求层后，开门让乘客进来然后关门需要近10秒（考虑到人多时可能时间更多），因此电梯开关门时间宜设为10个tick，因为测试框架中是以每个tick为一秒来模拟的。但现在测试框架只设有关门时间5个tick，且在乘客进来一个tick后会检查是否还有乘客需要进来，以利用出去的乘客产生的电梯容量的增量。
by Xiaobin(xxb263@hotmail.com)
