oo作业总结报告2

第五次作业 多线程电梯

多线程同步和控制的设计策略

1. 明确类和对象，以及是否区分对象实例。具体类可以从类图中看出；
2. 明确线程的类型和数量。输入作为一个线程，调度作为一个线程，三个电梯独立工作，互不影响，分别是一个线程；
3. 明确线程之间共享的数据，控制同步，以及保证线程安全。输入线程将输入存放在请求队列中，调度类访问请求队列中的请求，所以对请求队列的操作需要做到互斥，即要加锁；电梯线程接受到请求后处于运动状态，其各个属性参数在不断变化，而调度器调度时需要访问电梯的属性状态，所以为了保证得到的是准确数据，改变和访问电梯状态的操作需要上锁，做到互斥；

类图

　　

设计方案

　　这次电梯可以看做是生产者消费者模型，其实发现，如果能够找到一种模型来适应工程，其实核心的设计模式就已经出来了。其中，当请求队列不空时，调度器就从请求队列中取请求进行调度，为空时，调度器就需要等待，知道请求队列中有请求是，再将调度器唤醒。而每个电梯都有自己的执行请求队列，当这个请求队列不空时，唤醒该电梯线程，为空时，等待，用到了两次生产者消费者模型。其他关于调度的算法和前两次电梯基本差不多，就是多了电梯之间的选择。

度量

OO度量

　　可以看出，调度器的圈复杂度标红了，复查代码发现这个方法的代码重复率比较高，三种情况，基本是一样的代码，应该是当时懒了，设计原则的意识还很弱，导致圈复杂度较高；对于重复的代码，便可以抽象出一个方法，用起来也十分简明，复杂度也会有较大的改善。

Bug分析

此次多线程电梯调试花了很久时间，由于时间很紧，就只实现了基本的功能，对于指导书要求的严格的时间输出，没能实现，挂了几个点。互测的时候拿到一个只能识别格式的代码，基本功能都不能实现，所以测试也较为容易，没去深究更小概率的bug。

第六次作业IFTTT

多线程同步控制的设计策略

1. 明确类和对象，判别是否区分对象实例。从类图中可以看出该工程的各个类；
2. 明确线程的类型和数量。一个文件一个线程，一个目录一个线程，三个动作三个线程。这次的线程类型是确定的，但是文件线程的数量却是动态的，不确定的，需要根据输入的监控文件对象个数来确定，但是好在程序是在已经确定了输入后才真正开始运行，这么说其实线程的数量也是确定的。
3. 明确线程之间共享的数据，控制同步，以及保证线程安全。这次实现的是对文件的监控，以及触发动作，由此引入了快照这一概念。文件属性是作为此次工程的核心，也是共享数据，所有的操作都是围着它转的，首先是有一个文件安全类，专门提供对文件的一系列操作方法接口，必须保证是互斥的，文件监控线程需要访问文件的属性，必须保证此刻获取到的文件属性是正确的以及最新的，比较过程为和快照对比。

类图

　　

设计方案

整体的设计思路是根据输入的IFTTT构造监控线程，初始化快照，当监控到变化需要触发操作时，触发相应线程的更新快照，快照是作为监控线程对象的一个属性存在的，监控线程保持一定周期的频率扫描文件。

度量

　　

　　

度量分析　

　　对目录监控的函数出现圈复杂度过高的现象，其中主要是用了两重循环和if条件嵌套，对于目录的监控，需要检测目录下的每一个文件，而目录下还可能有目录，所以在和快照比较的时候嵌套就复杂了些，尝试中发现要是将这个对比过程在抽象出一个函数，圈复杂度就会好很多，还是需要注意单一性原则，实现功能模块化。

第七次作业

多线程同步和控制的设计策略

1. 明确类和对象，以及是否区分对象实例。类图中可见；
2. 明确线程的类型和数量。输入一个线程， 调度器一个线程，100辆出租车100个线程，计算路径的线程。
3. 明确线程之间共享的数据，控制同步，以及保证线程安全。输入和调度器共享用户请求队列，所以请求队列为共享数据，需要保证互斥原则，调度器获取出租车状态信息，出租车自动改变状态信息，所以出租车的状态信息为共享数据，需要保证访问互斥。

类图

　　

设计方案

这次的设计和之前的多线程电梯有相似之处，实现实时调度，面对一个请求，选择最优的车辆去执行请求，但是整体的复杂度感觉比多线程电梯高一些。输入线程将输入放入请求队列中，当请求队列不为空时，调度器遍历请求队列，为每一个请求寻找发送讯息的出租车队列，其中每一个请求控制在3秒的窗口期，当抢单窗口关闭时，就确定了该请求的最后出租车队列，然后再根据挑选出租车的原则选出最终执行请求的出租车，在这期间，计算线程一直在计算每一个请求的最短路径，并将最短路径保存在相应请求的Point容器属性中，出租车在启程是必须确保该请求的最短路径已经得出，其中对于最短路径的计算需要保证互斥，因为函数中有一个距离数组是共享的。这样执行效率是很低的，因为计算最短路径比较费时，调度也不够灵活，不能够将每一个请求分离开。想过为每一个请求建立一个线程，但又担心自己维护不好，出了奇奇怪怪的错误，就没这样实现，后面会去尝试这样做。

度量

　　

　　

　　

度量分析

　　随机化出租车运行路线函数，寻找最短路径函数，以及调度器中的寻找合适出租车函数，这三个函数复杂度确实挺高的，感觉稍微写个两层循环，以及一些判断条件语句圈复杂度就会爆掉，但是要是将一个功能函数再进行拆分，有会感觉这样太过零散，调用的深度又会增加。在代码的质量上还需要进行不断的深究。

Bug分析

这次作业我没有交，因为没有实现功能，自己在设计和实现的连接方面还十分欠缺，总写出bug连连的代码，准确的说是写出的代码和自己心里想的完全是两个东西，也许是coding的太少，由于直接无效，所以并未进入互测阶段，也没有测同学的程序，继续努力吧。

心得体会

　　三次多线程，可以说是做的一次比一次差了，是心态变了，还是真的作业难度增加了，也许都有吧。但并不是没有收获，最起码自己还是去设计了，学习了多线程的相关知识，去按照设计原则编写了自己的代码，虽然实现的效果很差。反应比较慢，逻辑能力欠缺，思维也不够缜密，在实现逻辑功能的时候容易出现bug（感觉设计的时候还是不够细致），并且完成代码后的调试过程比较慢，但是时间又是有限的，所以结果并不如人意。我觉得自己在实现这些工程的时候确实是有困难的，不想只是为了不无效而交上一份质量非常差的代码，这也是我第七次不交作业的原因，反应慢就需要比别人花费更多的时间去学习，补给站也定是有它的意义所在，但能够正常避免不去补给站，就尽量不去，无论在哪，目标只是想老老实实完成这门课的要求——2000行高质量的OO程序，希望自己可以做到。