Pair project 2: 电梯调度

       伴随着 Pair project 1的结束，我和另外一个搭档开始了pair project 2 ，与上次3d桌面游戏开发不同，这次是在电梯调度的

framework中完善接口。

主要测试的技能：

a) Requirement Analysis

b) High level design (interface, information hiding, loose coupling)

c) Design by contract,

d) Implementation skills in C#

e) Algorithm design

提供的调度接口：

a, 乘客(passenger)：

     来到后立即按电梯，没有进入电梯则继续发送请求，直到进入电梯。但是我们不知道任何关于电梯乘客的信息和反馈，不知其重量几何，亦不知有多少乘客。

b, 请求(request)：

    当乘客请求时，我们在请求到来的时刻接到通知，并知道其请求方向（上楼还是下楼）。

     当乘客进入电梯时，我们在进入的时刻接到通知，知道乘客要到哪一层楼。

c, 电梯(elevator)：

   我们知道每一部电梯的状态（通过调用以上框架中电梯接口(IElevator)提供的方法）。

我们需要实现的：

   实现自己的scheduler接口。所有的乘客请求都由scheduler维护

Framework 测试框架：

整个框架是以时间为轴工作，下面是详细的uml框架图

 

 

我们的scheduler 流程图：

 

回顾：

      两周的pair work很快结束，也许是没有第一次结对的新鲜感及这次project难得的降低， 明显感觉到大家对这次的结对编程明显没有上次那么积极，

还好我和pair晓彬坚持讨论，结对编程，也许最终的scheduler算法没什么太大的优势，晓彬提出的基于学习的调度算法也最终没有实现，但是经历还是蛮重要的，我一直将其视为一个学习怎样和不同人的人合作的过程，而非一个简单的project 结果。

     在pair过程中，我们在数据结构的定义上花费了不少时间，随着讨论的深入也换了几种数据结构格式，耽误了不少的时间，我觉得这是在动手编程之前，没有进行深入思考全盘的结果，这一点在以后的编程练习中需要克服，我一直主张先分析清问题，然后定义数据结构开始动手编程实现，这也许和pair的习惯有点不同，导致我们的分析不够深入，缺乏全局设计的理念。整个project 2，首先需要感谢师兄sen，在工作繁忙的时候抽出时间来为我们设计和编写整个testframework，由于时间紧迫，sen 提供的framework 框也难免存在着一些bug，搞得有时候都分不清到底是我们scheduler的bug还是framework得问题，这个bug寻找的经历也还是蛮有意思的…

最后留下真相：