---恢复内容开始---
四月份的三次作业都是对多线程的学习，从最开始什么也不懂，到后来慢慢理解，慢慢掌握，过程中出了很多问题，但终于是有所收获。
第五次作业：
1、作业介绍
第五次作业与之前的作业一脉相承，增加了多部电梯协同工作的要求，并按照一定的要求把任务分配给电梯线程。
2、设计构思
作业已经明确要求使用多线程，经过初步的学习，在构建电梯类后，构造三个电梯对象，对应三个线程，模拟三部电梯的运动。请求类作为一个获取输入的请求作用，此外，命令类实现每一个请求的格式化，并实现对命令的处理方法；调度器类负责判断是否为同质，捎带，以及按要求分配给哪部电梯运载。
但由于对多线程的理解不够，出现了莫名其妙的bug，电梯的运载紊乱，最终无效，此次不再分析。
第六次作业：
1、作业介绍
本次作业为IFTTT工作，要求监控某个文件或者某个目录下的所有文件，只要监控对象发生了重命名，修改路径，最后修改时间改变或者修改文件路径等情况，就要触发触发器相应任务——累计触发次数，或者记录修改情况。
2、设计构思
此次作业，每当输入产生一个监控任务，就产生一个监控线程。由于只要触发文件的相应修改，监控器就会做出反应，当文件资源发生竞争时，就会产生线程间的冲突，所以使用线程安全的文件操作类来解决这个问题。
3、程序类图
4、度量分析
5、bug分析
本次作业的问题在于如果出现了对于目录下重命名的文件是没有进行判断的，这是设计的时候的疏忽，而对方仅能判断输入的正确与否。
第七次作业
1、作业介绍
本次作业是模拟出租车叫车系统。在所给定的点阵地图中安排100辆出租车，并对输入的叫车请求进行正确的回应。
2、设计构思
首先建立相应的出租车，乘客请求类（地图在所给的包中已经体现，简化了作业），出租车类中需要对应出租车的位置，信用，状态，以及相应状态的详细信息；乘客请求类中需要请求发出的时间，地点，以及目的地等请求，并且，由于是对请求进行处理，出租车是不会改变的，所以需要把每次处理请求的过程信息存在请求命令中，比如抢单车辆的信息以及被派单车辆的信息。
3、类图
4、度量分析
5、bug分析
本次作业的问题在于时间不是准确的两百ms，有待解决，对方的正则表达式有误，并且也没有实现200ms的要求，等待也并非20s一次。
---恢复内容结束---