第二单元电梯作业总结

一、设计思想

　　第二单元的电梯也是一个逐步继承，功能逐步趋于完善的迭代作业，首先说一下三次作业的构思。

　　第一次电梯：首次电梯是ALS单电梯，采用的是生产者和消费者方式，能够实现简单捎带服务。

　　第二次电梯：第二次电梯能够支持多部电梯捎带，但电梯间不能换乘，采用的是和第一次电梯类似的模式，每个电梯有自己的调度程序，除了共同处理请求外，互不干扰。

　　第三次电梯：第三次电梯电梯有三个基础电梯，有不同的楼层和运行速度，还规定了最大人数。根据每个请求的起始和到达楼层分情况处理，先看能否由一个电梯单独处理，否则的话，由第一个电梯换乘至和第一个电梯有共同停靠楼层的第二个电梯。

二、程序分析

（一）分析程序结构

　　（1）第一次作业

　　类图如下：

 　　　　

　　复杂度如下：　

　　　　　

　　耦合度如下：

　　　　　

 

　　第一次作业由于并不复杂，做调度策略也相对单一，而且由于第一单元作业的练习，各个类的结构也很合理。

　　（2）第二次作业

　　类图如下：　

　　　　

　　复杂度如下：

　　　　　

　　　　　

　　耦合度如下：

　　　　

　　　第二次作业中，我的做法为每到一楼层，遍历请求队列，符合捎带的请求便加到处理队列中，由于电梯上行、下行两种情况，且要由前次运行的终点楼层先到这次运行的起点楼层，情况共有6种，且各情况的差别不大，因此要分三层嵌套函数，复杂度较不合理。

　（3）第三次作业

　　类图如下：

　　　　

　　复杂度如下：

　　　　

　　　　

　　耦合度如下：

　　　

 　　第三次作业中，我先写好了三个电梯各自的换乘策略，由起始楼层和终点楼层决定换乘方式，再结合捎带策略做到简单的捎带，由于情况需要考虑的太多，实际上实现复杂度较高，且由于各个电梯只有某几个参数不同，实现代码也有较大重复。

　（二）BUG分析

　　第一次作业：实现容易，思路简单，因此并没有BUG产生。

　　第二次作业：第二次作业简单的捎带不难，但是由于电梯处理完请求后需要重新回到起始层，时间会有浪费

　　第三次作业：第三次作业我只能实现单人的换乘，多人的捎带和换乘会出现线程不安全的情况，因此时间会超时很多，强测成绩很糟糕

　（三）互测策略

　　结合别人的问题和自己dbug的经验，我发现很多人的BUG会出现在特殊楼层的捎带和边界时间上，如虽然符合捎带，但是时间处于边界。尤其第三次作业中，边界楼层的换乘和捎带的结合会出现很多情况。

三、总结

　　第二单元的电梯中，给我最大的体会就是，特殊情况的检查，如0层这种符合现实，但是和代码正常逻辑相悖的情况，我有很多BUG都出现在对0层的考虑不周全上。而线程的不安全也是写程序的一大难题，而且自我测试也是BUG出现的主要问题，尽管对边界情况进行疯狂的检测，但是由于本地对于时间的精准把控的不可能，测试不能考虑各种情况。而且调度策略决定了电梯的最终性能，尤其是第三次电梯最多6个电梯一同调度，一个简单优化就会很大的性能提升。