BUAA面向对象设计与构造——第二单元总结

BUAA面向对象设计与构造——第二单元总结

第一阶段:单部傻瓜电梯的调度

第二阶段:单部可捎带电梯的调度

  (由于我第一次写的作业就是可捎带模式,第二次只是增加了负数楼层,修改了一部分参数,因此一起总结。)

  1.设计策略

  这次作业我设计了两个线程:Elevator和DealWithInput,前者模拟电梯,而后者用来处理输入。队列PersonQueue作为一个单例模式下的对象,被两个线程所共有,充当调度器的角色。

  DealWithInput基本套用下发的模板,只是增加了每次读到新请求就通知调度器pq.add(requst),并且pq.notifyall(),以用来唤醒电梯。在读到EOF后,设置标志输入结束的flag,并再次唤醒电梯,防止电梯一直等待。

  PersonQueue调度器里包含了一个Floor类型的数组,将每个楼层独立处理。每个Floor类中包含一个记录等待乘客的数组waitingPersion,乘客按到来的先后顺序进入数组。描述乘客的Person类记录了每个乘客的ID、起始楼层、目的楼层和运行方向。电梯向调度器询问主请求时,调度器扫描所有楼层,查看是否为空,只要有一个楼层不为空,电梯就仍需运行。当到达某一层后,电梯需要捎带,这时又要向调度器发出询问。调度器将这个询问转交给对应的Floor对象。Floor遍历本楼层全部乘客,如果有相同方向的乘客,则把这些乘客打包成一个数组返回给调度器,并且从该楼层的等待队列删去。之后调度器再返回给电梯。

  Elevator采用扫描算法,即当电梯静止时,先向调度器询问主请求,根据主请求决定运行方向,之后到达每一层如果还有同方向的乘客则捎带。下乘客则是由电梯自己判断,电梯包含了一个Person类型的eleList数组,记录电梯里的人。每到一层,先下后上,电梯遍历数组查看是否有人的目的楼层是当前层,如果有,则让他下电梯并且从电梯数组中删除。上下乘客结束后,电梯要向调度器询问是否需要改变方向。改变方向后进行二次上乘客。这个操作是针对这种情况:例如电梯向上运行到达5层,所以第一次查找乘客时只会查找5层要向上的乘客。但是如果这层没有人向上,电梯内已经没人了,5层以上的楼层也没有需求,因此电梯可以改变方向下,并且接5层向下的乘客。并且二次查找乘客也可以尽量多的捎带。

  时序图如下:

  

   第五次和第六次作业的一个比较大的区别在于:

  第五次作业电梯采用轮询方式,比较占用CPU。

  第六次作业改成wait()和notifyall()的模式,如果楼里没有请求,那么电梯会wait,而当输入进程读到了新的请求时会唤醒电梯进程。当读到EOF时,也需要唤醒电梯防止一直等待。

  2.结构度量

   类图如下:

  

  类图展现了类之间的实例化和创建关系。主进程MainClass创建了Elevator和DealWithInput两个进程,DealWithInput直接向PersonQueue增加请求,PersonQueue管理多个Floor类,每个Floor管理等待的Person.Elevator进程和调度器互相传递信息,同时也管理Person来记录电梯内部的人。

  

  以上是关于程序本身的一些数据统计。可以看到每个类的平均循环复杂度还是比较低的,说明方法的设计比较符合“高内聚、低耦合”的原则,而不是大多数功能集中在某一个方法中。

  3.程序bug

   第五次作业在公测中没有什么bug,但是用相同的架构在第六次的弱测就发现了bug。

  首先最致命的bug是程序CPU运行时间超时。因为我第五次作业采用轮询模式,电梯一直在while循环,每次循环都询问调度器是否需要运行。这种模式在第五次比较简单的测试中侥幸存活了下来,但是第六次就不行了。因此我改为了等待与唤醒的模式。电梯如果询问调度器得到的回答是暂时不需要运行,那么将调用pq.wait()进行等待。而输入进程一旦获取到新的需求,就调用pq.notifyall()来唤醒电梯。

  其次是电梯的方向问题。第五次作业我的电梯是送完乘客且运行方向的楼层没有乘客了,才进行方向的改变。但是这样有可能发生在某一层第一次开门下乘客,然后电梯意识到要改变方向,再次开门上乘客。因此为了节省时间以及更加符合实际,我在每次开关门之间增加了对运行方向的判断,修改为二次搭乘模式。

 

第三阶段:多部可捎带电梯的调度

  1.设计策略

   这次我依然选择将调度器作为一个共享对象,而不是进程的模式。输入进程依旧存在,电梯进程变成了三个,电梯单独运行的框架和前两次类似,也都是先向调度器询问主请求(即启动方向),每到一层都询问可捎带乘客和该下电梯的乘客。

  第七次作业比较大的一个改进在于赋予了Person类更多的功能。就像老师上课讲的工厂和工人的例子一样,乘客可以自己判断上下电梯,并且在一开始就规划换乘的路线。每当实例化一个Person对象时,将调用内部方法,来判断该乘客是否需要换乘。如果不需换乘,那么就当作正常的乘客,记录其起始楼层和目的楼层。如果需要换乘,那么将调用方法来得到他的换乘楼层(middleFloor),并且将这位乘客的目的楼层存入换乘楼层。当该乘客在目的楼层(即换乘楼层)下电梯后,再修改自身的起始楼层为换乘楼层,目的楼层为真正的目的楼层,将更新后的这名乘客再次加入等待队列。这样相当于把要换乘的乘客分为两名乘客,先后加入等待队列。这样就把换乘这一难题交付给乘客来完成,调度器辅助更新,而电梯只需要正常运行,更加清晰有效地分配了功能。因此IN和OUT这两个方法都在Person类,而不是电梯进程来完成。

  按照题目中电梯楼层的分配,有一些乘客是可以乘坐多个电梯都能到达的。例如ABC三部电梯都可以从1层到15层。因此我先在Person类中加入了可乘坐的电梯这一属性,用三位二进制数表示是否能乘坐对应电梯,例如其值为111表示三部电梯都可乘坐。这一属性是在判断换乘时同时完成的,而对于要换乘的人,在他第一次OUT后更新楼层信息时,同时更新这个属性。

  为了实现三部电梯的配合,我又引入了按钮属性。每个Floor类增加了三个数组,每个数组有两个元素,这六个值描述了ABC三部电梯上下行共六个按钮。当乘客第一次加入某一楼层等待队列时,考虑以下三种情况:

  1.只能坐一部电梯,那么就按对应电梯对应方向的按钮;

  2.可以坐两部电梯AB,那么若A到达时间短/A排队人数没有满员/B的反方向按钮被按则按A电梯,否则按B电梯。关于B的反方向按钮被按这一点,主要是因为如果B电梯要先以反方向经过本楼层的话,那么同方向会等更久。因此如果A的理论到达时间更短就优先选A。

  3.可以坐三部电梯,那么类似于第2种情况,从三部中选一部按按钮。

  因此每个乘客在刚进入等待队列时,都只按了一个理论上最合适的电梯。当然这只是理论值,不能排除电梯因为停靠楼层开关门所导致的时间延误。因此当电梯A(BC同理)每运行一层时,还要通知调度器刷新按钮。对于楼层x,如果此时A刚从x层上行,那么我们可以推测对于A再次以下行方向返回x层需要比较久的时间,因此对于低于x层的楼层,如果等待A电梯的人势必要等很久。因此这时刷新所有<=x层的楼层,如果等待A电梯的乘客中,有可以乘坐BC电梯的人,那么也按BC的按钮,这样如果BC电梯先于A电梯到达,那么这些人就可以早一步上电梯。

  这样一来,每个人虽然最开始只按了一个按钮,但可能因为刷新操作按多个。因此当电梯停靠一层并进行了上下乘客操作后,要遍历该楼层的所有乘客再次进行按电梯操作。这里的按电梯原则与最开始是一样的,都只按一个。按多个的刷新是在电梯运行到其他楼层时才进行。

  通过按钮这个属性,使得电梯之间的调度更加充分,而不是只集中在一部电梯上。每部电梯在向调度器询问时,调度器遍历每一楼层的按钮即可安排电梯接下来的运行方向了。

 

 

  2.结构度量

  类图如下:

  

  类图展现了类之间的实例化和创建关系。主进程MainClass创建了Elevator和DealWithInput两个进程,DealWithInput直接向PersonQueue增加请求,PersonQueue管理多个Floor类,每个Floor管理等待的Person.Elevator进程和调度器互相传递信息,同时也管理Person来记录电梯内部的人。Person类拥有了更多的功能,诸如向调度器报告按按钮,在电梯进程中进行IN和OUT的操作等。

  

  这一次作业Floor类和Person类的复杂度增长幅度很大,主要是因为赋予了Person更多的功能,以及Floor添加了按钮属性所导致的。但总体来看复杂度还算比较平均,没有出现某一类包揽大多数功能的情况。

  3.程序bug

   公测中全部通过,但性能分不太高。我认为是因为我的电梯调度还是针对于一些细节部分的优化,例如尽量多按按钮来使得乘客尽早上电梯。但是这也可能导致电梯空跑。我觉得一个绝对的优化策略还是很难找(几乎不存在)的,因为电梯对即将到来的乘客是未知的。因此优化这一点只能尽力从架构上设计地更完备,考虑更多的情况。

  在弱测和本地测试中,我发现我还是遇到了CPU超时的情况。虽然单部不会忙等,但是由于多部电梯同时工作,才会导致这一错误。当AB电梯都没有需求后,他们发现输入也结束了,但是楼里还有人,因此会进入等待状态,此时C还在工作,当C结束工作后,他检测到输入也早早结束了,因此结束了进程。但是此时AB没有被唤醒,也就无法检测楼里没人这个真正的结束条件。另一种情况是最后一个乘客需要换乘,他从C电梯出来后,AB电梯还在等待,也就没有电梯来接他了。因此我对于电梯在每一层的运行结束后都加入了notifyall,这可以解决以上两个问题,并且对于不需要工作的电梯,即使被唤醒后也能马上再次进入等待。

 

总结 

  根据SOLID原则分析:

  SRP(单一责任原则):我一共设计了MainClass, DealWithInput, Elevator, PersonQueue, Floor, Person六个类,前三个类分别是三个进程,第四个作为调度器,后两个分别针对楼层和乘客两个角度设计功能。实现了功能的划分,使得程序架构条理清晰。

  OCP(开放封闭原则):指架构应该是可扩展的。这个单元我做的比较好的一点就在于减少了代码的重构,第六次和第五次代码几乎一样,只是针对bug和指导书不同的要求进行一小部分的修改。第七次作业里,每部电梯的运行架构也和第六次一样,只是增加了电梯间配合调度的功能。

  由于本次作业没有使用继承、接口和抽象类,因此其他三个原则不做讨论。

  对于线程安全方面,我采用synchronized加锁的模式。所有针对调度器即等待队列的操作都需要加锁,包括添加乘客,捎带乘客(即取走乘客)和判断是否为空等。这样才能保证对象的安全,防止出现一个乘客同时上两部电梯,或者是从队列中删除但是却没有上电梯的错误。

  总之经过这一单元的练习,增强了我对多线程的认识,对于线程安全有了更深刻的体会。不再像第一单元那样每次重构代码,是本单元最大的进步。

 

转载于:https://www.cnblogs.com/cathywang03/p/10756577.html

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值