北航oo作业第二单元小结

类的设计：

　　　　首先，我对我的思路进行整体的说明，由于我的三次作业，思路是继承的，所以做总体的说明

　　　　第一，   Main类，Main类自身并没有功能，他的功能只是构造需要的电梯线程和输入线程。

　　　　　　其中，第三次作业中，main类负责将电梯参数（运转时间，负载上限，运行楼层）传入Memory类和Elevator类

　　　　第二，   是Eleinput类，这个类，是一个单独的线程，功能是读入需求，每次读入需求，将其写入Memory类中，当读入null时进程结束。

　　　　　　输入器，与电梯类不相连，只负责传数据给Memory，设计安全。

　　　　第三，   是Memory类，Memory类内构造了一个线程安全的容器（阻塞对列，或concurrenthashmap），功能是：

　　　　　　存储需求，

　　　　　　反馈自身一部分状态（如是否有需求，以及传出需求），

　　　　　　删除已执行的需求，

　　　　　　在第三次作业里，还加入了对换乘的处理。

　　　　第四，   是Elevator类，每次从Memory与该电梯内部队列（即已经进入电梯的乘客）中选择一个主需求，执行该需求的过程中，逐层（如果能到达的话，判断上客，下客。

　　　　　　我的设计中，电梯无法直接访问需求队列，只能通过memory中的mainset方法和search方法，得到一个需求，这样设计安全，也能大大解耦。

　　　　第五，   是PersonRe类，这个类，是官方给的包的personrequest的拓展，在这个类中实现了，改写起始楼层的功能。在程序中，用该类，代替personrequest（第三次作业中使用。

　　　　时序图如下：

1. 第一次作业

　　　　由于，第一次作业是先来先服务的傻瓜电梯，我并没有使用算法来优化电梯的时间。

　　　　在整体的设计思路上，设计了两个独立的线程，电梯线程与输入请求模拟器线程。在两个电梯的通讯中，由于首次设计多线程程序，并且第一次作业没有限制CPU时间，我选择了通过while循环暴力轮询的形式。

　　　　在两个线程之外，通过阻塞队列，设计了一个调度器，调度器，从输入请求模拟器中读入请求，并将其存入到调度器内的队列中，电梯通过while循环轮询调度器内是否有请求，一旦有请求就从阻塞队列中移出一个请求，并存入电梯内，循环这个过程即可。

　　　　最后，结束进程，通过两个条件判断，第一，在输入请求模拟器线程结束时，将调度器内内置的bool值设为true，当该值，与调度器内队列isempty的bool值都为true时，结束进程。

　　　　代码分析：

　　　　由类图可见，我的两个线程只是简单的一写一读。层次简单。

　　　　下面是我的代码度量分析：

　　　　这一系列的作业，我已经开始掌握了oo思想，没有出现上一系列的作业那种复杂度几十甚至上百的情况，不过run方法中，还是使用了过多的if判断，这一部分，可以选择分成三个小类，这样的话会是更好的选择。

　　2. 第二次作业

　　　　第二次作业是同向请求可稍带的“ALS电梯”。设计思路，与第一次作业有变化。首先，本次电梯，是需要考虑捎带的，而不是每次只服务第一位来的人。所以调度器内存储数据的容器不能继续使用阻塞队列，应该使用hashmap。在hashmap中，将需求到来排序的sequence作为key，需求作为value，这样也方便选择最先来的乘客进行服务。

　　　　此外，为了限制CPU时间避免暴力轮询，我使用了wait--notify让线程在不需运行的时候wait，具体的实现方法，是选择waitElevator类，每当Eleinput类，读入新的需求，便notifyall一次，最后，为了线程安全结束，当Eleinput类结束时，也notifyall一次。

　　　　最后，为了使电梯实现捎带功能，在电梯设计中，加入乘客处理类，每到一层后，先判断该层是否有人下，再结合电梯运行方向判断是否有乘客进入电梯，sleep开关门时间后，再判断一次是否可以捎带电梯（这一点十分重要，如果没有这一次判断，会使得可以上电梯的人无法被捎带，如果只有这一次判断，那么会导致每一层都需要开关门时间，尽管可能该层不需要停靠开关门）。

　　　　类图分析：

　　　　可以发现，代码架构变化不大，只是在电梯内加入了部分方法。

　　　　代码度量分析：

Method	ev(G)	iv(G)	v(G)
EleInput.EleInput(Memory)	1	1	1
EleInput.run()	3	3	3
Elevator.Elevator(Memory)	1	1	1
Elevator.choosemain()	4	3	4
Elevator.everyfloor(int,PersonRequest,int)	1	5	5
Elevator.floordeal(int,int,int,int)	1	2	5
Elevator.minus(int,int)	2	1	2
Elevator.order(int,int,int)	4	1	4
Elevator.pepolein(int,int,boolean)	1	3	3
Elevator.pepoleout(int,int)	1	4	4
Elevator.run()	5	10	12
Elevator.searchele(PersonRequest)	3	2	3
Elevator.sleeptime(long)	1	2	2
Memory.Mainisset()	2	1	2
Memory.Mainset()	3	2	3
Memory.Memoryadd(PersonRequest)	1	1	1
Memory.Memoryisempty()	2	1	2
Memory.Search(Integer)	1	1	1
Memory.Stopout()	1	1	1
Memory.follow(int,boolean)	5	4	5
Memory.order(int,int)	2	1	2
Memory.setStop(boolean)	1	1	1
Work.main(String[])	1	1	1
Class	OCavg	WMC
EleInput	2	4
Elevator	3.91	43
Memory	2	18
Work	1	1
Package	v(G)avg	v(G)tot
	2.96	68
Module	v(G)avg	v(G)tot
ElevatorPro	2.96	68
Project	v(G)avg	v(G)tot
project	2.96	68

　　　　由于我基本继承了第一次作业的写法，Elevator中的run方法逻辑复杂度还是过高，order、choosemain等方法，也是因为if等判断过多，带来了逻辑复杂度过高，这是我程序设计的弊端。此外，本次作业中，由于run方法内，每层判断能否捎带乘客，带来了过高的模块设计复杂度和圈复杂度。在debug过程也因此耗费了很多精力。

3. 第三次作业

　　　　第三次作业，基本是在第二次作业的基础上完成，只做了为数不多的改动。

　　　　第一，   将personrequest拓展成一个新类，实现改变出发地点的功能。

　　　　第二，   为电梯添加负载人数等接口。

　　　　第三，   将调度器中的hashmap加锁。

　　　　第四，   在调度器中加入换乘类，计算请求是否需要换乘。

　　　　　　　　如果需要换乘（即三部电梯都不能独立完成，则将该电梯的转乘位设为由换乘类算出的最佳换乘楼层）。当有电梯到达该需求出发楼层，且能到达换乘楼层的就进行捎带。

　　　　第五，   在电梯内加入换乘功能。

　　　　　　　　判断乘车出电梯，加入换乘的情况，那么乘客到达换乘楼层，就出电梯，出电梯时，还要调Memory中一个特殊的方法，将这个需求处理后添加到请求队列中，（起始楼层更改，转乘位置为0），并notifyall一次。

　　　　类图：

　　　　本次类图中可以看出，加入了新类（数据类）PersonRe，该类，由Memory类处理完成。

　　　　度量分析：

Method	ev(G)	iv(G)	v(G)
Method	1	1	1
Method	3	3	3
Elevator.Elevator(Memory,String,List,long,long,long,int)	1	1	1
Elevator.checkfloor(int)	3	2	3
Elevator.choosemain(String,Boolean)	9	6	9
Elevator.everyfloor(int,PersonRe,int)	1	5	5
Elevator.floordeal(int,int,int,int)	1	2	5
Elevator.order(int,int,int)	4	1	4
Elevator.pepolein(int,int,boolean)	3	4	5
Elevator.pepoleout(int,int)	1	10	11
Elevator.run()	7	11	13
Elevator.searchele(PersonRe)	3	2	3
Elevator.sleeptime(long)	1	2	2
Elevator.tofloor(PersonRe)	4	3	4
Elevator.waituntil()	3	3	4
Memory.EleTrans()	2	1	2
Memory.Mainset(String)	9	9	9
Memory.Memoryadd(PersonRequest)	1	1	2
Memory.Memoryaddextra(PersonRe)	1	1	1
Memory.Memoryisempty()	2	1	2
Memory.Search(Integer)	1	2	2
Memory.Stopout()	1	1	1
Memory.check(String,PersonRe)	1	3	3
Memory.checktrans(PersonRe)	2	2	4
Memory.follow(int,boolean,String)	6	4	6
Memory.listrtans(PersonRe,List)	3	2	5
Memory.order(int,int)	2	1	2
Memory.setStop(boolean)	1	1	1
PersonRe.getDirty()	1	1	1
PersonRe.getFromFloor()	1	1	1
PersonRe.getPersonId()	1	1	1
PersonRe.getToFloor()	1	1	1
PersonRe.getTrans()	1	1	1
PersonRe.resetDirty()	1	1	1
PersonRe.setDirty()	1	1	1
PersonRe.setFrom(int)	1	1	1
PersonRe.setMemory(PersonRequest)	1	1	1
PersonRe.setTo(int)	1	1	1
PersonRe.setTrans(int)	1	1	1
Work.main(String[])	1	1	1
Class	OCavg	WMC
EleInput	2	4
Elevator	5.15	67
Memory	2.92	38
PersonRe	1	11
Work	1	1
Package	v(G)avg	v(G)tot
	3.12	125
Module	v(G)avg	v(G)tot
ElevatorPlus	3.12	125
Project	v(G)avg	v(G)tot
project	3.12	125

　　　　其中，逻辑复杂度，是和前两次作业一样由if判断导致。而在pepoleout类和mainset类中的模块设计复杂度增加的原因，是我加入了换乘。我的换乘实现方式需要Memory和Elevator的协作处理，导致该复杂度增加。至于处理方法，可以添加一个新的类，在将调度器的存储需求队列的功能分离，可以解耦。

自己程序的bug：

　　　　我只在第三次作业出现了bug，该bug来自于在程序中使用固定值，进行for循环，由于第二次电梯最多30条指令，我将该固定值设计为32，在第三次电梯中沿用了第二次电梯的设计，导致，我的电梯，无法处理32号之后的指令。

　　　　该结构来自于结构的不合理，结构中应避免出现魔术数字。

发现别人的bug

　　　　本次系列课程中，我未能发现别人的bug，但我采取的策略是构造测试样例，并带入检验。

　　　　构造测试样例，重点考察，换乘情况，一上一下，以及大量人在同一楼层同时进入。

心得体会：

　　　　第一，在程序设计中，一定要避免magic number的引用！我第三次作业就是血泪的教训。

　　　　第二，方法一定要简洁，一个方法只做一件事，这样能降低逻辑复杂度，降低debug难度。

　　　　第三，要使用wait和notify机制，用好这个机制，可以减少cpu时间，写出巧妙的代码，（跑测试样例时，也不会像暴力轮询那样，风扇狂转）

　　　　第四，多花时间进行架构的设计，本次电梯作业中，如果第一次就做出了非常漂亮的架构，整个扩展过程都会舒服很多，程序的稳定性也会更佳。

　　　　第五，在synchronized的运用，要多加思考，用少了会影响正确性，用多了又影响性能，需要精雕细琢。