BUAA_OO_Unit2_Review
OO_Unit2_Review
一.作业结构的结构度量、策略分析及BUG分析
1.WORK1 - 单个ALS电梯
1.结构
第一次作业，我除了MainClass外，设置了QueueIn和QueueOut两个线程类，由于表示电梯内外的用户队列。QueueIn其实就是电梯本身，控制电梯的运动；QueueOut其实就是Input类，用于输入添加操作。并新建PersonRequestQueue类来给PersonRequest创建队列类并内聚add、remove等队列方法，以及一些信号量操作。
UML
A.类复杂度
B.方法复杂度
2.策略分析：
本次作业严格遵循题干给出的ALS策略，即可捎带策略。
3.BUG分析：
本次作业没有BUG。
4.线程协作：
本次作业一共有电梯内队列以及电梯外队列两个线程，电梯外负责处理输入并将乘客加入队列，电梯内队列则负责电梯的移动以及输出。两个线程synchronized的对象为用户队列。
2.WORK2 - 多部可捎带电梯
1.结构
本次作业比起上次作业，多了Controller类，即调度器类，用于给每个用户分配最佳的电梯。而将HW1的QueueIn改名为Elevator，以及将QueueOut改名为UsersStream，更符合多线程下的功能角色扮演。其中每个电梯都有自己的用户等待队列，而不是多个电梯共用一个用户等待队列。
UML
A.类复杂度
B.方法复杂度
2.策略分析：
本次单个电梯仍然采用ALS策略，多电梯的协调则采用以下策略：
遍历现有的用户总队列，对每个用户，再遍历所有电梯，以ALS策略模拟算出该用户加入后的总时长，同时在遍历前设置一个极大的整形数，为min，若该时长小于min，则将min替换为当前时长，同时记录下该电梯，以此类推，最后可以得出对于该用户的最佳电梯。最后将该用户add进最佳电梯的等待队列中。其后过程即为作业一的过程。
3.BUG分析：
BUG概括：本次作业有一处BUG，此次作业限定了电梯的最大载客数量。在对每个用户计算他的最佳电梯时，若该电梯是满员的则跳过，这就造成若只有一个电梯且该电梯是满员的时候，此时进入的用户将会丢失。
BUG修改：在调度器环节去掉对满员的判断即可。
4.线程协作：
此次作业一共有三类线程，分别为输入流、调度器以及电梯。输入器负责处理输入以及将用户添加至用户队列，调度器负责将总的用户队列里的用户分配到各个电梯的等待队列，而电梯只负责接送各自的用户。其中输入流和调度器的synchronized对象为用户队列。
3.WORK3 - 可添加的有差异的多部可捎带电梯
1.结构:
本次作业作业基本上沿袭第二次作业的结构，唯一微小的差异就是将Elevator的可达到楼层、运动时间以及最大容量设置为可变量，同时在调度器类里设置添加电梯的类方法。
UML
A.类复杂度
B.方法复杂度
2.策略分析：
此次作业在策略上的最大难点为换乘分析，解决策略如下：
每个电梯的运行范围可以视为多个闭区间的并集，因此在模拟计算运行时间时，不必算出到目的地的截止时间，只需要算出到包含目的地的区间的边界就行，而具体是上边界还是下边界，则只需要动态模拟ALS的运行轨迹即可得到。同时值得注意的是，为了避免换乘等待带来的时间浪费，我把所有无须换乘的电梯种类视为最佳电梯，无须再继续计算时长，直接返回。
3.BUG分析：
BUG概括：这次BUG很简单，我忘记将不同电梯的最大承载量差异化。
BUG修复：将Elevator的最大承载量设置为可变量即可。
4.线程协作：
线程结构与第二次作业相同。
二.可拓展性分析
对于第三次作业，我将所有的部分功能相区别开。调度器专门负责给每个电梯分配用户，电梯只负责接送用户并输出行为，而用户输入流负责处理输入并添加用户或者电梯，符合SOLID之SRP原则。因此，如果有任何的功能拓展，只需按类补充即可。比如从第二次作业到第三次作业，只需要修改电梯的运行规则以及输入流的输入行为即可。
三.发现BUG策略
此次互测，我没有发现别人BUG，但是被一位同学揪出BUG过，即在同一时刻挤入大量乘客，由于我忘记考虑不同电梯的不同载客量，因此出错。
四.心得体会
此次系列作业，难度还是较为平缓，在第一次作业适应了多线程的思想后，之后的几次作业都是在原有的基础上的拓展。且此次作业的逻辑性其实并不强，主要的难度都集中于多线程部分的调度，所幸这个单元我都没有遇到严重的线程安全问题，因此这部分给我造成的麻烦不大。因此，除了第一次作业投入的精力较多外，其余两次都可以在较短的时间内完成。比起第一单元的系列作业，实在友好了不止一个档次，希望接下来的作业都能如此。
