标签：请求 匹配 内容 文件的操作 次数 变量 detail 区域 技术
第五次作业：
设计策略：
本次作业设计的基本思路是按照指导书所给的推荐方法来完成的，即共用对象为队列盘，线程有电梯、调度器、以及扫描器，扫描器将控制台输入的有效指令加入到队列盘中，调度器依据指导书的原则分配任务给电梯，然后电梯将其一条条执行。在电梯的类中，加入了一个小队列，即电梯依次需要完成的任务。在同步控制中，对队列盘对象加锁，在某一线程使用时，其他线程无法更改，但是可以访问。这样存在一些时间上不同步的问题，导致了一些bug的出现。
度量：
类图：
本次的类图较为简单，由于实际使用的类并不是很多，List类为扫描器，scheduler类为调度器，Elevator类为电梯，由于是三个电梯同时运行，因此实例化了三个电梯来同时运行。这次作业实现的好处在于思路简单，并且各类间的关系明确，易于在后续的找bug工作中提供帮助。但是缺点在于，类中只有run（）方法，代码的可读性太差，没有将各个工作模块化，全部工作塞在一起显得臃肿，并且代码复杂度极高，导致一些不必要的问题出现。
Metrics度量图：
第一行的红色标记，表明了本次作业中，我对从控制台读取有效命令的方法部分模块复杂度过于复杂，并且嵌套深度也过深，这在第三行中也表明了出来。这依旧是因为，我在处理控制台的输入时，将正则判断也加入了这个模块，这导致了一个方法承担了许多任务和工作，因此让该模块的复杂度直线上升。并且对一条输入进行了多次正则匹配，也直接导致了模块代码的复杂度和嵌套程度加深。对代码的优化和提炼做得还不够。
分析自己程序的bug和不足：
本次作业出现了两个bug，一个是由于没有使用继承机制，直接使用了以前的调度器和调度方法。事实证明，偷懒是没有好处的，测试者真的很细心，这样都能发现我用了以前的调度器。另一个bug是如果最后一条命令是（#ER,1,1），我的程序就会crash，这依然是使用之前的调度方法的问题。还有一个bug测试者并未发现，在我的设计中，调度和扫描只能交替进行，这是由于对同步控制错误导致的。虽然没被发现，但是如果不及时改正，对接下来的其他作业必定会造成影响。这次作业还是存在许多的不足，某个方法依然显得臃肿复杂，模块化和可读性程度都极差。对线程的同步控制也是做得不够完美，在调度上也存在一些问题，导致了程序crash。
第六次作业：
设计策略：
这次作业是实现对文件的监控和管理，明白ifttt原理。虽然老师一直说这次作业很简单，但是我觉得一直写到深夜的应该不止我一个人。这次作业最大的难点就是，需要自己先自学java里对文件的操作怎么描述。这就花去了我许多时间。其实这次的作业难点在于架构，基本方面在于，扫描器扫描控制台的输入，读取文件的路径，监控内容等。在文件经过相应的操作后，能够作出对应的响应。并且需要写一个类，让测试者能够操作目标文件。我的策略就是每两秒扫描一次目标文件所在的文件夹，然后判断是否做出了监控器监控的动作，如果出现了，就执行需要执行的输出。按照指导书的要求，判断各个操作是否出现。
度量：
类图：
其中List类是扫描器，负责处理控制台的输入。monitor类是监控器，也就是程序的主体，负责判断各个监控器的内容是否出现。detail记录了文件或文件夹的先后名臣，先后路径，先后大小和先后最后修改时间，并且输出到指定位置。summary类记录了监控器监控内容发生的次数，并且输出到指定位置。filevisit类是提供给测试者操作文件的另外线程。这次的优点在于我将detail和summary另起一类，让各个变量间独立，使结构更加清晰明了，输出到文件就不易于犯错。缺点在于需要在monitor中调用这两个实例化对象，会造成代码量变大以及monitor类中的变量增多，易读性就大大降低了。
Metrics度量图：
根据这次的metrcs度量图，可以看到已经没有红色的字体出现了。但是模块复杂度最高的还是我的扫描器对控制台输入的部分，由于这次对输入格式并未作要求，因此在正则匹配上就没有那么多的工作量，因此没有造成模块的过于复杂。嵌套程度最深的是我的监控器类的监控方法，由于调用了很多其他方法来监控文件，所以嵌套程度最深。这次对各个模块代码的优化和简练还是做得比较满意，模块化的程度也较高，并没有预料中出现过于复杂化的模块的出现。
分析自己的bug和不足：
这次作业的bug存在很多，主要原因是对recover要求处理不到位，对这个要求的并没有去测试，只是完成了基本代码，但是在自己测试的时候并没有考虑这个情况，因此就直接交上去了。然后错了一堆bug，才发现对recover，也就是将文件还原的操作是错误的，有时候程序还会不响应。后来在检查过程中才发现执行recover操作时，没有记录更改前目标文件的路径和名称，只是将文件的位置改变了而已，由此造成了极大的失误。还有一个比较严重的bug是没有设计好多个监控内容的情况，如果监控多个目标文件，时间上会不同步，导致输出到detail的最后修改时间错误。这是由于同步控制做得不好导致的。
第七次作业：
设计策略：
这次作业要求完成一个基本出租车功能的程序。基本方法在于，由扫描器扫描控制台乘客的目的地和所在地，然后由调度器调度附近符合要求的出租车去接送乘客。本次作业的难点我认为在于去完成最短路径的寻找，虽然由GUI提供的方法能够稍微魔改一下去找到最短路径，但是会花费大概3~4秒的时间，初始化时间太长我觉得不太合理。就想到了数据结构使用的链表方法，使用了一个差不多的方法来查找最短路径，事实证明效果还不错。在程序实现时也直接引用了GUI的方法，让程序能够可视化。另一个难点在于圈出4*4区域，让进入的出租车能够响应。
度量：
类图：
这次需要完成的类有很多，因此看上去结构比较复杂。这是主要的缺点。并且可以看到各类之间的互相调用很多，导致了程序的嵌套程度很深。但是结构上的复杂必然就会有思想上的简单。Dis类用来计算两点间的距离。map类用来从文件中读取地图。scan类即从控制台读取乘客的需求。queue类即等待对列。taxi类即是出租车类。各自处理各自需要实现的功能，不会互相影响，并且可读性极高，后续的debug工作容易进行，这也是本次作业没有被找出bug的原因之一吧。
metics度量：
第一行所指出的最复杂的模块是指导书所给的GUI模块中的让地图显示出来的部分。由于地图一直需要刷新，这是理所应当的。然后第三行，嵌套程度最深的又是我的扫描器的读取输入的函数。这次作业我对程序的优化和简练应该是做得比较好的，可能是由于这个线程需要一直从控制台读取有效输入导致的，这个线程在设计上是需要一直运行的，因为需要不断的接受乘客的请求。这是理所应当的。
分析自己的bug和不足：
这次作业在互测阶段并没有被找出bug来，可能是测试者没有发现，但是我自己在设计中有个缺陷，这也是我交上去作业的一瞬间才想起来的。如果控制台同时输入两个或两个以上的乘客请求，我的程序只会响应其中的一个。另一个不足在于，对于指导书提到的4*4区域，如果出租车一开始在该区域，但之后驶出区域后，应当是加入抢单队列的，但是我没有 处理这个出租车。虽然侥幸没被测试出来，但是确实存在这些小问题。必须在下次作业之前改进。
心得体会：
这三次作业据老师说已经是所有作业中比较难的了，希望如此吧。能够活过第二阶段还没有无效作业已经是万幸，希望以后也不要有无效作业出现吧。然后就是努力完善自己的程序吧，既然不喜欢给别人找错，那就让自己的程序变得更无懈可击就好了。
标签：请求 匹配 内容 文件的操作 次数 变量 detail 区域 技术
原文地址：https://www.cnblogs.com/y1027/p/8979452.html
