软件工程-pair work

如果用两个字来形容这次的任务,那一定是”卧槽”

结对编程人员

177 吴渊渊

193 薛亚杰

照至少一张照片, 展现两人在一起合作编程的情况。

还有好多方法根本不会编写测试代码啊….

结果最后只有一个方法能够测试啊…类的覆盖率挫也就是必然的了….

不要在意这些细节!（好吧我正在学习。。）

画出UML 图显示各个实体之间的关系 (画一个图即可)

vs2012中,右键scheduler项目,查看类图,直接生成类图…呵呵呵呵,虽然很挫……

当然staruml还是王道

说明你的算法的关键 （不必列出源代码）, 以及独到之处。

扫描每一部电梯,对当前电梯选择最适合的请求

如果电梯处于静止状态(Direction.No):

1.电梯的目标列表不为空,那么选择距离当前楼层最近的楼层前往

2.电梯的目标列表为空,那么从请求队列中选择最合适的前往（何为最合适的：通过实践检验，按照下下，下上，上上，上下的顺序选择）

如果电梯处于上行状态(Direction.Up):

扫描当前楼层与目标楼层之间是否有请求,如果有,那么将其加入电梯的目标列表中,并将电梯的下一个停靠楼层设为所有可以搭顺风车的请求中最接近当前楼层的

如果电梯处于下行状态(Direction.Down):

扫描当前楼层与目标楼层之间是否有请求,如果有,那么将其加入电梯的目标列表中,并将电梯的下一个停靠楼层设为所有可以搭顺风车的请求中最接近当前楼层的

算法关键:

卧槽..debug了两天半,最后发现问题出现对于QueueReq()这个方法的重写,原来的bus算法因为根本不考虑乘客的请求而在每一层都停,所以它一股脑的把乘客的全部外部请求都压入队列了;而我们的算法需要考虑乘客是否在电梯内,所以这里需要判断乘客的请求类型(RequestType),如果是外部请求(RequestType.DirectionReq),那么将其加入请求列表中;如果是内部请求(RequestType.DestinationReq),说明该乘客已经在电梯内部,那么只需将该请求加入相应电梯对应的目标列表中就好….卧槽卧槽…就这个点debug了两天半啊…我说电梯怎么一直不让人进……

独到之处:

目前的算法还算可以,对于电梯处于静止状态时他会选择离当前楼层最近的目标楼层前往,如果目标楼层为空那么会选择请求列表中最合适的前往,而如果请求列表为空那么根据样例分析,他会优先前往0层和1层,而如果不为空,那么根据多次测试,他会按照下下,下上,上上,上下的顺序选择目标.

这次的算法只是1.0版本,如果有必要,会进行2.0,3.0版本更高效算法的设计(毕竟要跑得比bus算法还慢基本是不可能了…)

PS:BUS算法和我们的算法跑分表:(工程原始输入文件,不是博客上面的数据要求..)

如果换成博客上面要求的电梯容量,那么必然速度会加快好多…运行后发现passenger2.xml可以跑到250左右,passenger3.xml可以跑到180左右

 另外，关于电梯上下班高峰的判断，我的想法是在每一个tick执行queuereq的时候,扫描一下当前准备进入的req,根据req占count的比重来判断是否是上下班高峰;如果req.direction=0|1的比重大于0.8,那么即可判断是上班高峰;如果req.destination=0|1的比重大于0.8(当然这一部分必须是已经进入电梯的req),即可判断是下班高峰.

不过实际执行过程中运行效果反而不如不采用理想…

相关资源：国内领先的在线试衣间软件3D试衣间_github3D试衣间源码-互联 …