OO第二次博客作业（2018春）

时间：2018-05-02 20:53:31 阅读：209 评论：0 收藏：0 [点我收藏+]

写在前面

多线程

搞死人

第五次作业

类图：

技术分享图片

　　这次作业的调度器（als_3_controller）继承了上一次的调度器(smart_controller)，并且分解了之前的schduel方法，内容分布在run()和新建的类ELE_thread的isCarry()和run()里。在程序运行启动了类ELE_thread 的三个线程，分别代表三部电梯的控制系统，分别操作三部电梯。

度量分析：

技术分享图片

　　问题都出在ELE_thread 的run（）里，包括圈复杂度和嵌套深度。主要是因为把上一次的大部分代码都集中放到了run方法里，代码冗杂，重复的部分多，聚合和耦合情况也不理想。

时序图：

技术分享图片

BUG分析：

　　又犯拖延症的我，花在这次作业上的时间并不多，大部分代码都是在上一次的基础上改动，对多线程的理解也不好，所以这次作业Bug满满：

　　1.没输出到文件。第一次用java对文件读写，有点生疏。

　　2.两次调度同一请求。多线程同步控制没写好，一个请求进到了两部电梯的队列里。

　　3.FR没捎带。捎带判断条件出了问题。

　　4.电梯选择错误。累积量的累积滞后，导致本不应被选择的电梯被选择。

　　还有茫茫多bug，上面是摘选的典型的几个。互测公测加起来大概有十多个，但测的同学特别nice，友好交流后帮我删了几个。

第六次作业

类图：

技术分享图片

　　这一次作业主要的两个类是monitor类和SafeFile类。其中SafeFile类把File类封装成一个线程安全的文件类，我的主要做法就是在方法前加关键字synchronize。而monitor类则负责分析每个请求，判断是否触发并通知几个任务类执行任务。在设计思路上，对于每个请求，我都启动了一个线程去分析它。这样的做法，让monitor的写法更加清晰，但很浪费资源。

度量分析

技术分享图片

　　圈复杂度和嵌套快深度超标在monitor的run方法里。在设计的时候，几乎把monitor要实现的所有功能都放到了run方法里，嵌套层数很多。而且我在处理监控文件和监控目录时，把它们分别放到了一个if-else语句里，两部分内容大致相同，导致代码重复。也由于上面的问题，代码的内聚程度不好。

时序图：

技术分享图片

BUG分析：

　　这次作业花了很长时间，但还是出现很多Bug，原因还是对多线程的协调理解得不透彻（绝望脸orz）：

　　1.rename部分情况未触发。当当前目录下有更深层目录时，renanme不触发，原因是递归遍历深层目录时，当不是文件时返回值出错。

　　2.path-changed部分情况未触发。当当前目录下有更深层目录时，path-changed不触发，原因是递归遍历深层目录时，当不是文件时返回值出错。

　　3.rename recover后无法再rename。rename追踪文件出错。

　　由于黑盒测试的问题，这次作业中的一个bug（递归遍历深层目录）被挂了分支树上包括互测公测的七个bug。再加上其他几个零碎bug，这次同样被扣了一大波分。

第七次作业

类图：

技术分享图片

　　第七次作业是出租车的第一次作业，几个主要的实现功能的类是taxi，schduel，Map和GUI。taxi类定义了单个出租车，负责出租车的各种行为，包括停止、等待、闲逛、接客等，在其中的run方法里规定了一个出租车在几种状态下转换过程。schedule类接收到乘客请求后，负责分析请求，为每个乘客开辟等待窗口，选择合适的出租车并通知它接送乘客。Map类主要负责用几种不同的数据结构初始化并储存地图。GUI负责将可视化。在设计思路上，为每个出租车和每个乘客请求都新开启一个线程，比较浪费资源，有待改进。