首页 > 代码库 > 结对项目:电梯调度算法的实现和测试
结对项目:电梯调度算法的实现和测试
结对编程人员:
12061167林旭鹏
12061174李靖
TFS上Pairproject11
结对编程优点:
(1)结对编程相对来说比较高效,一些基本功能可以分开来写unit在进行整合,核心算法可以进行讨论,选择效率比较好的哪一种算法。
(2)两个人同时进行编程,不容易分神,集中程度相对一个人时更高,双方也可以互相监督。并且若有一个人实时对另一个人的代码进行实时监督,可以避免手滑打出来的小问题,这些小问题在调试时时很难找出来的,可以节约调试的时间。而且debug时,也可以让头脑比较清醒的人上。
(3)可以让我们提前熟悉团队合作
缺点:
(1)两个人写程序时,也许有时候还需要给对方讲一讲他看不懂的你的程序的具体实现细节,这在一个人写程序时是不必要的。
我(林旭鹏)的优点:之前做过win8app开发,熟悉vs的使用,熟悉c#,代码能力较强。
缺点:打代码时非常容易犯一些手滑打错的小错误,debug时往往从思路方面切入,经常搞了很久最后才发现是笔误导致的bug
李靖的优点:代码风格比较细腻。
缺点:不太熟悉c#语言。
(以下三点来自网络)
Information Hiding:首先,在类中,定义的变量和方法可以再前面加上一个下划线"_"来标识,这是一个好的命名规范,可以避免无意中对私有成员进行赋值。类与类之间交换信息时,要交流私有变量时,要用事先设计好的方法来访问,这样如果我们在其它类里面调用另外一个类的私有变量,那么我们必须定义一个获得该类私有变量的方法;要在另一个类里面改变另外一个类里面的变量时,我们也要定义一个改变该类私有变量的方法。在C#里特别方便的一点就是有set和get,我们可以很方便的定义访问一个类私有变量的方法。
interface design:一个好的接口能够提供给后面的程序设计一个良好的框架,在这次电梯调度项目里,接口IElevator、IPassenger、IScheduler、IRequest,我们通过接口能很快的知道电梯、乘客、调度方案、请求都有哪些属性,要实现哪些方法,而不用关心具体的实现细节;这样我们的软件测试也变得更简单了。
loose coupling:在我们的代码设计时,不用担心会破坏其它地方的代码。这种类与类之间依赖性低的设计方法,使一个类与另外一个类仿佛隔开了,它们之间只是通过消息来联系的,所以设计一类时,可以不用担心破坏另外一个类。当代码有改动时,可以不用大规模的改动我们的代码,我们只用定位于一个出问题的模块,然后对其进行更改就好了,而且能做到不改变其它模块的服务。
信息隐藏、接口设计、松耦合都是面向对象设计的重要方法,都是使程序设计时更接近日常认识,在大模块之间关系中不用过于担心细节,只需在模块设计时下功夫。
契约编程:
给编程者提供了非常明确的要求,非常明确地提出了契约者希望实现的功能。
测试单元及代码覆盖率:
UML图:
算法关键:
调度算法主要根据电梯的“History dirction”变量,以及有无乘客等信息,进行调度算法。
电梯的初始History dirction默认为up。
每个tick:
电梯若在底层,令其History dirction为up,若在顶层,则设置为down;
电梯内没有人时:
先检查有没有方向一致且当前History dirction方向上可达的楼层请求,若有,Reqstopat最近的;
若当前History dirction方向上,没有方向一致的楼层请求,则检查有没有方向不一致且当前History dirction方向上可达的楼层请求,若有,Reqstopat最远的,并令电梯的revs变量为true;(revs变量为真时乘客类会进入方向不一致的电梯,接到最远的乘客后此变量为false)
若当前History dirction方向上,没有任何楼层请求,将电梯方向转向,下个tick再判断。
电梯内有人时:
遍历所有的电梯内部请求,以及当前History dirction方向上可达,并且方向一致的楼层请求,Reqstopat这些请求中最近的。
算法的独到之处:
这种算法确保了电梯每一趟都至少会把当前方向上的所有请求都考虑完毕后,才考虑转向的问题。
由于题目中提供了一种情形,当一层和零层有大量的请求时,电梯每次都只能带一部分人上楼,最好电梯是应该送完人上去后马上就下来再载人上去,同时响应顺路的请求。而我们一开始想的调度算法,就可能出现电梯在楼上不断上下响应高楼层的请求,而忽略较远的零层和一层的请求,这样由于0层和1层的等待人数太多,就会使平均调度时间大大增加。
使用新的算法,保证了电梯不会无视这些较远的请求。
结对项目:电梯调度算法的实现和测试