告别了三次奇妙无比的求导作业之后，我们就开始搭建一部自己的电梯了。相信我们不同同学的电梯运行方式肯定各具特色吧，但值得肯定的是，在艰苦的走完了三次电梯逐步改进的作业之后，我们的电梯在正常情况下应该是可以运作了～所以当我们一起坐电梯，相信我们的电梯应该是不会接不到人、把人最后关在里面、莫名其妙的就把人给丢了以及把人送到+或者是-的啦。下面是我对这三次作业的总结与分析～

　　在三次作业中我都是用的三个线程。一个是main线程，主要负责构造并start另外两个线程，构建调度器对象；另外两个是Request与Elerun线程，顾名思义，一个用来得到请求并将请求put到调度器，另一个用来模拟电梯运行。调度器类命名为Control。

FAFS电梯调度

　　对于刚刚接触多线程的我来说，要实现一部相对智能的电梯几乎是不可能的，更不要说是多部电梯了。应该也是出于对同学们情况的考虑吧，第一次作业只是要求我们实现VIP（傻瓜）级别的电梯调度。即在任一时刻每当有一个用户给电梯发送了一个请求，那么调度器就将该请求传递给电梯，电梯在运行路径上不用去接其他的人，只把接到这个请求当作目标，来一次执行完各个请求。

设计思路：

　　因为这次作业不要求具体的各个请求之间的调度，所以我甚至没有在调度器里面构建一个链表。在Request得到一个输入之后便立马put给调度器，如果此时调度器之前要put的请求还没有被电梯get到，那么就先让put方法等待，直到电梯get完前一个请求之后再将这一个put进去。同样，在电梯get的时候，如果此时没有请求则调度器便让当前电梯的线程wait，直到put进一个请求被notify了之后才继续运行。最后在Request得到程序输入结束的指示后，会给调度器传入一个自定义好了的请求，而当电梯读到那个请求之后，便会直接结束运行。

　　下面是第一次作业的结构度量：

类图：

复杂度分析：

时序图：

ALS电梯调度

　　在FAFS电梯的基础上，这次调度要求电梯在运行过程中可以捎带着人以减少电梯的总运行时间，同时增加了底下层，具体原因不清楚为什么，好像是为了避免出现固定化楼层分析的情况？不过在这次编程中值得注意的一点是从底下-1层到1层电梯只是运行了1层，而不是单纯的减法就能够满足的了。

设计思路：

　　在Request线程方面，与第一次差别不大。唯一的区别就是在put的时候会直接put到调度器里面一个已经构建好的请求链表（比较习惯用ArrayList）里，这样Request每读到一个输入则会避免了等待而直接压入同时notifyAll一次主要来唤醒电梯的Elerun线程。

　　在电梯进行get初步读入请求时，如果此时ArrayList链表为空，则一直wait，直到Request线程重新唤醒该线程后再继续运行。在电梯运行时，我设计思路是电梯get时只get到第一个人的位置作为主请求，同时电梯向第一个人的方向运行，在每一层判断一次请求链表中是否有与电梯运行方向相同的人或者事要下电梯的人，如果有则在该层停靠完成相应的in或者out的过程，在in的时候每进入一个人则删除请求链表里的该请求。直到电梯将初步get到的请求运行完之后再重新从链表里得到一个新的主请求。

不足之处：

　　虽然这样写可以比较稳定的实现电梯在运行过程中执行捎带人的动作，而且也能知道电梯此时的运行情况及运行状态。但是有一个比较重要的点没有考虑到，就是假如有三个人同时分别在13、14、15层按了向下的按钮，那么此时电梯就会从一层上来逐个的送回三个人，那么在这种情况下就和FAFS电梯一样了，这是一个在设计层面上没有想到的情况，拉低了自己的性能分。而我在后来改进的时候只需要判断是否有比当前请求更适合作为主请求的请求，就可以初步的改进这个问题。

　　下面是我的第二次作业的度量分析：

类图：

复杂度：

时序图：

SS电梯调度

 　　第三次作业在第二次的基础上，增加成了三部电梯，并且规定了电梯所能到达的楼层各不相同，运行速度不同，容量不同等限制因素。要求尽可能的实现优化调度以在比较少的时间内执行完所有的请求。我在第二次作业的基础上，对Elerun与调度器进行了修改。

　　不同于第二次作业，我是在调度器里买面改成了三个链表存储对应的请求。每个电梯在每次改变状态时便实时通知调度器，在Request读取到一个请求之后便调用调度器的put函数，调度器根据此时各个电梯的运行状态来将此请求压入制定的链表。下面是部分内容的更详细的介绍。

　　首先介绍我实现的调度器是怎样将读到的请求尽量合理的压入不同链表的。如图所示，我在调度器里面用0代表A电梯，用1代表B电梯，2代表C电梯，这个二维数组表示不同

的电梯所能到达的楼层，能到达则为1，不能则为0。这样在判断电梯能否到达楼层时只需判断对应的值是否为1就可以了。那么在调度器得到一个请求之后，按照下面的步骤筛选应该压入的链表。

由于时间限制和个人能力不足的原因吧，我没有完成只把请求压到一个指定的链表中去的假想，在最后一步筛选时间最短时的筛选条件比较苛刻，如果没有满足的电梯，则就把该请求压入到满足前一个请求的电梯的链表里。

　　还有一点要提的是换乘时的判断。当没有电梯可以直达时，我先筛选出能在此层停靠的电梯，然后针对每一个电梯，筛选该电梯可以到达的最近的楼层floor，且有电梯可以在该floor直达目的地，那么我以此楼层作为中转，修改之前的请求。对应每一个电梯，当拆分请求完成后，压入对应的请求链表，完成拆分。

　　下面是我的第三次作业的度量分析：

类图：

复杂度：

总结与感想

　　这三次作业在强测和互测中都没有被?到，我猜测一方面是因为在每一次编写代码之前我都会把我能想到的情况罗列一遍，然后针对不同情况在设计时采取一定的手段来尽量避免一些bug，就像第三次作业时我花了将近两天一直在设计构想代码，而真正编写代码也是只花了一晚上就完成了。在设计阶段花费时间最长的就是对电梯的调度策略的优化的设计了。而另一方面呢，也是因为自己无法去想到或者实现自己没有能力做到的一些策划方案，因此自己的电梯在一些情况下还是会像傻瓜电梯那样运行。这一点是在以后的学习中要逐渐培养的，逐渐提高自己的能力，以便能够比较容易的实现一些合理的策划方案。

　　前面也已经提到，在这三次作业中我的代码的架构几乎是完全一样的。第二次作业改良了第一次作业的电梯运行方案，而第三次作业也只是在第二次作业的基础上加了两部电梯，而电梯的运行方案与第二次几乎相同。因此我也更加认识到在编写代码时尽量保证代码的可拓展性的重要性，在这种情况下可以使自己保持一个比较清晰的思路，对自己的调度策略有一个比较清晰的认识，这样在需要对其进一步拓展时，能够尽快的想出一个比较合理的改良方案，同时还不容易出bug。

　　在每一次互测时，我还是会注重测试在编写代码时不容易实现的地方。比如在第三次作业中，我把测试的重点聚焦于在电梯的换乘情况，同时加以容量问题、边界问题，虽然最后在同一个room内没有hack到同学，但是我认为这方面的相关测试还是蛮必要的～～

　　我们共同又度过了一个单元，在这个写博客的休整期，我们还是要好好调整自己的心情与状态，（该玩的玩，该摸的摸），以便在下一个单元无论是上课还是下课逐步学习到更多的知识，将自己的想法与学到的知识应用到新的编程、新的应用实例中。