BUAA-OO 电梯类问题总结

BUAA-OO 电梯类问题总结

一、多线程电梯系列作业设计策略

1、第一次作业--“FAFS傻瓜电梯”

在第一次作业中，作业的要求是实现傻瓜电梯，即先来先服务，没有太大的难度。利用简单的生产者--消费者模型即可基本实现。以等待者作为共享对象，创建一个waiterqueue对象--即生产者--消费者中的tray，inputhandandler线程和elevotor分别作为生产者和消费者，另外我将人分离为两个类--taker即乘坐电梯的人，waiter,即为等待电梯的人，二者提取相似行为，相似属性得到父类Person.至于waiter与taker的转换会在waiter进入电梯时利用waiter的方法将其转换为taker类，与现实生活对应。

电梯则执行判断，如果乘坐者队列不为空，则将电梯运行到乘坐者要到达的目的楼层，否则就判断等待者队列是否为空，如果不为空，则将电梯运行到等待者等待的楼层，并将等待者加入乘坐者队列，否则进行wait操作。

对于这次作业中，我认为较为复杂的便是程序的终止，我采取的判断算法为从等待者队列取出的请求是null则直接进行system.exit(0)，结束相应的程序。

2、第二次作业--“ALS可捎带电梯”

对于第二次作业，我只在第一次作业的基础增添一个函数seekPerson(int targerfloor,int flag)其中的targetfloor就是主请求要到达的楼层，flag在后面会讲述，用来搜索该楼层是否有目的方向与电梯运行方向相同的waiter或者有taker已经到达目的楼层。

对于waiter如果满足该条件即可将waiter接入电梯waiter.getFromFloor() == currentfloor&& ((waiter.getToFloor() - currentfloor)* (targetfloor - currentfloor) >= 0)

对于taker如果满足taker.getToFloor() == currentfloor即可让taker out

就我看来，这次作业比较麻烦的部分主要在于实现open,close在这个楼层只输出一次，且保证这时候所有人的进出都在这二者之间，于是我在这个函数中引入了flag参数.。

①如果flag为1则说明这时候到达主请求需要到达的楼层已经会保证输出open and close，

②否则则需要在函数中输出相应的open and close 操作。

 

3、第三次作业--“多电梯调度策略”

多线程比较复杂，为了避免电梯互相抢夺资源的问题，例如A,C电梯都获得了等待者信息，但是A先到达相应的楼层，使得C在输出open之后不能接到人，故我利用调度器把每一个请求送入到每个电梯维护的一个等待者队列，一旦进入等待者队列，其他电梯就不能抢夺该资源，而程序结束的条件就是总的等待者队列长度为0，每个电梯的waiter和taker的size为0。

二、基于度量的程序结构的分析

1、第一次作业：

(1) 复杂度分析

 

 

FAFS算法

(2) UML类图分析

 

 

 

 

 

优缺点分析：

优点：通过复杂度分析，此次电梯的复杂度比较优良，此次的电梯方法比较简单，易于编码，主要为两个线程，类复杂度低，对于第二次作业有很好地扩展性，

缺点：但电梯没有很好地拟合现实情况，对于该电梯没有相应的调度器，对于电梯的负载较大。

（3）时序分析

 

 

（4）SOLID法则分析、

下面是我查阅资料对solid法则的一些理解：

①单一职责法则（一个类只负责一项职责，当一个职责修改时，不会使其他职责发生故障

②里氏替换法则子类继承父类，尽量不要重写，重载父类的方法。

③依赖倒置原则：高层模块不应该依赖低层模块，A为高层模块，依赖接口，而低层模块B,C各自实现接口

④接口隔离原则：接口不应该臃肿，类不应该去实现其不需要的方法，应该将接口切分

⑤迪米特法则：降低类与类之间的耦合，一个类发生改变，另一个类影响小，降低一个对象对其他对象的了解

⑥开闭原则：对扩展开放，对修改封闭。

对于这次实验中，我将waiter,taker继承了person类，

对于里氏替换法则不太符合，较多的重写，重载。

除此之外，电梯实现调度器和现实中电梯的功能，不符单一职责法则。

由于没有接口的应用，没有涉及到相应的法则。

 

2、ALS算法

(1)复杂度分析

 

 

（2）UML类图分析

 

 

优点：通过复杂度分析，ALS电梯的结构也比较优良，电梯方法仍旧比较简单，易于编码，仍旧为两个线程，各种方法的复杂度低。

缺点：将各种请求直接交给电梯进行调度，电梯类中的做法比较不纯粹，这对第三次的电梯没有良好的扩展性，需要重新新建一个类，进行相应的分配。

（3）时序分析

 

 

（4）SOLID法则分析

此次作业与第一次作业类似，分析相同

 

 

 

 

 

3、多线程实现多电梯

(1)复杂度分析

 

 

 

 

 

（2）UML类图分析

 

 

 

（3）时序分析

 

（4）SOLID法则分析

此次作业将调度器和电梯分离，在单一法则方面有所改进，其余与前俩次作业类似。

 

三、bug分析

在前俩次作业中，我没有被hack到，感觉作业完成得也比较轻松，但到了第三次作业当中，由于笔误（可以说在写的时候，不太专注导致的错误）导致的死循环，从而使得程序出现cpu_run_time_error类型的错误，与线程关系不大，又是一次血与泪的教训。

四、如何分析别人bug

额，在这几次实验中，本来是想通过python定点输入数据，但是迫于电脑命令行一直不能运行python指令和javac指令，真的很绝望，鼓捣了大半天，后来觉得可能是想让我做一个温文儒雅的互测者，然后放弃了。

希望能有哪位大佬能够提示一下，为什么一直按照网上说的那样执行python和javac一直无法成功。感恩！！！

 

后来，只能从别人那获取一些测试样例来进行互测（哭唧唧）

但是这样样例基本上也都涵盖了第三次作业中的临界时间问题，超容量以及判断程序结束等问题，针对性比较强。

五、心得体会

在线程学习中，大致能体会对对象加锁和对方法加锁，但对于老师课上所言的check-then-write,check-then-modify这些模式用到的原子操作，没有实际实现过。课上所言的为了实现线程安全，实际上就是对于共享对象有着相应的控制。有以下方法：

①读写，写写的控制：对相应的对象加锁

②操作具有原子性：利用java的内置类型，atomic类型的关键字

③实现引用的包的互斥：自己写一个方法，加上互斥锁之后，将该方法放入其中即可实现。

④避免对发布的对象的修改：利用final关键字，或者严格控制共享对象的发布。

总的来说，在这6次作业中，我对于线程，继承的理解还是不够深入，

需要多多理解与反思，希望在今后的作业中能够不断加油。

 

转载于:https://www.cnblogs.com/ytzhang/p/10744173.html