第五次作业：多线程电梯
作业内容：相比于前两次电梯作业，本次电梯作业新的变化是多电梯运行。要想实现功能，便需要学会使用多线程机制，使三部电梯保持相互独立的对分配的请求进行处理。电梯能够处理捎带，且调度时采用运动量均衡策略去响应楼层请求。
类图：
度量图：
bug分析：存在两个bug。在多线程电梯的调度过程中，经过一系列的调度操作后，会出现电梯运动量叠加的错误，原因在于在运动量进行更新时的条件分支判断上存在漏洞，在部分情况下会对于同时响应完成的请求进行重复计数，导致整体运动量计算错误。另外一点同样是由于代码逻辑层次的复杂性而导致的，在对于电梯判断捎带请求的分支中存在着FR后对ER的捎带判断漏洞。
分析评价：从度量图中，可以明显的看出电梯对于入队请求的处理的方法中，分支判断条件太多，使得代码复杂性上升，不利于维护。这也是由于设计上的缺陷导致，不能很有效的将分配机制完善以及其他一些机制进行合并，导致代码复杂性上升并且代码数量也较多。
第六次作业：IFTTT
作业内容：本次作业是实现一个监控程序，针对于给定范围内的文件属性的变化，通过预先设定的触发器的反应从而执行相应操作。监控的范围限定为一颗目录树。
然而，在本次作业中，由于时间安排上的不合理以及对于代码的理解还不够深入，导致未在规定时间内完成。在面对这种文件的监控时，并不能很好的实现对文件属性的扫描、监控。另外，由于个人原因导致的思考设计上的时间消耗过大，并存在部分不合理的设计，从而使得无法正常实现题目所要求的具体功能。
第七次作业：多线程出租车
作业内容：本次作业模拟出租车的乘客呼叫与应答系统，开发相应的程序，继续训练线程安全设计方法，同时应用课堂所讲授的面向对象分析方法和设计原则来开展分析和设计。
类图：
度量属性：
bug分析：bug一个。在乘客发出请求后的3s内，应该对所有进入乘客请求服务区间的空闲车辆进行标记，即抢单，但在此期间，若已进行抢单的出租车响应了另一请求并执行，应当对其状态进行更新，以防止出现同时占用同一辆车的情况。然而，在代码中，并未对该种情况进行处理，导致有时会出现程序输出错误的情况。
分析设计：在这次作业中，主要考察的是课上所讲的SOLID设计原则以及各种设计的注意事项，即对代码的设计、代码风格的考察。
在本次设计中，层次化抽象原则体现在将本次出租车问题抽象成为调度器类、地图类、出租车类、请求类、请求队列类。而各个类之间的方法均衡、分配上还是略有欠缺，部分方法的长度略微大。并且，部分分支的判断条件的部分使得代码逻辑更难被读懂。
心得体会
这一单元的三次作业，难度都十分的大，都是对于多线程的设计与调试。由于课程中后期的代码对于各个类以及类中方法的严密、均衡要求升高，因此，在真正开始作业前，还是应当多花时间去对问题进行细致的分析，并考虑各种可能出现的情况以及哪些情况的判断或功能的实现能够进行整合，以此避免bug的出现并使得代码更为简洁。否则，将会出现由于设计上的漏洞而不得不耗费大量时间重新设计的情况，致使时间被浪费。除此之外，和同学的交流还是十分重要的，因为对于一个人来说，作业设计上的一些要求容易出现理解上的偏差，如果能多与同学进行交流，不仅能很好的发现、修改理解上存在的问题，也能了解到其他人的设计方案，并将其与自己的设计方案进行相互对照，找出自己设计上的不足，从而在之后的作业中加以改进。
原文：https://www.cnblogs.com/98-0901/p/8978136.html