第四单元架构设计
第一次作业
作业需求：实现一个UML类图分析器，可以通过输入各种指令来进行类图有关信息的查询
整体来说，这次作业的难度并不高。难点主要集中于对类图信息指令的解析，即筛选有用信息进行模型构建。
由于本次作业处理对象主要是类和接口，而其之间的关系不外乎继承、实现、关联……（由官方包试验可知，组合和聚合在语句中的体现和关联一致，或者说组合、聚合就是特殊类型的关联，这里也就没有必要特殊处理）。因此，这显然就是一个经典图论问题的一个延申，只是其中结点类型、边类型不统一，即有类结点，也有接口结点；有关联边、也有继承边、实现边。至于方法和属性而言，就可作为类和方法结点的属性进行存储，只需对类、方法进行包装记录信息即可。
对于查询方法而言，由于数据范围的限制，单纯地以为无脑递归就可以解决所有问题。
（经过这个单元的学习，才终于仔细研究了idea导出的uml图，发现确实是那么回事,梳理结构绝了。）
在我天真地以为这次作业这么无脑的时候，强测还是挂了两个点：一个是无脑递归没有打标记，另外一个就是手残的判断失误。（orz
第二次作业
作业需求：在上次作业基础上，扩展解析器，使得能够支持对UML顺序图和UML状态图的解析。
经过第一次作业的学习后，第二次作业基本上都是一套流程走下来：starUML画草图，在用官方包导出数据，分析一下关键数据，然后建类，写查询方法。
由于是在第一次作业的基础上扩展，第一次作业可以直接搬过来。对于顺序图而言，并不存在什么难度，把Lifeline和EndPoint作为结点构建图模型，进行包装记录信息即可完成。至于状态图，就图的属性来看，更是图的经典模型，又或者说，状态图UML本身就是经典图，我们所需要做的就只是包装结点，记录信息。
对于查询方法而言，我在第一次作业的基础上新增了一个管理层次即类图查询类、顺序图查询类、状态图查询论，通过这三个层次对构建的类图，顺序图、状态图进行查找。（主要还是为了满足chekcstyle）
为了查询方法实现的便捷性，我也增加了大量的信息记录，但是类之间的关联性较高。
庆幸的是，强测没有丢分。
第三次作业
作业需求：在上次作业基础上，扩展解析器，使得能够支持对UML顺序图和UML状态图的解析，并对模型进行有效性检查。
就内容实现方面而言，第三次作业依旧没有什么难度，只是增加了对于类图、顺序图、状态图的有效性判断，本质上也就是对于图的信息整理、分析。实现难度不高，R001至R008难度上限也不过是图的遍历（基于第二次作业）。
为了保证阅读性（checkstyle），新建了checkForUml类管理三个查询类QueryInteraction、QueryModel、QueryStateMachine，实现有效性检查。
从UML图分析可见，三次作业累积下来的作业模型是具有层次性的，只是为了实现的便捷性，大大增加了类之间的关联性。
可惜，这次又因为手抖，愚蠢低挂了两个点。（更主要的原因还是没有怎么测试）
单元回顾
Unit 1
架构设计与方法理解
在刚接触OO的时候，架构设计对于我而言就是一个很高大上的词汇，又或者说，我从来都没有考虑过架构设计。每一次的作业完成，与其说是在写OO，不如说只是在编程，只不过语言从C过渡到了Java，但脑子还是以前那个脑子。当然，这样带来的后果就是每一次作业就是一次重构，每一周都是代码活力的一周。
而在老师的讲解以及与同学的交流下，我也开始慢慢地明白用面对对象的方法去分析、去理解作业要求，并且通过类、接口的封装实现项目的层次化管理，并且有意识地在作业开始前去设计我的作业架构，满足一些后续开发所需要求。
测试理解与实践
第一单元由于作业本身就是一个很实际且很常用的数据模型，所以很容易就能找到对应的python包，而我们所需要的只是构造样例，数据对比就可以完成测试。本人也搭建了一个丑陋的评测机，进行大规模的数据测试。
得益于第一单元测试的便捷性，本人还是比较满意第一单元的成绩。
Unit 2
架构设计与方法理解
（刚看见第二单元作业的时候，我直接两眼一黑，这和第一单元是一门课？
第二单元，显然就是最经典的模型——生产者、消费者模型。
控制台输入即是生产者，等待队列就是tray，电梯就是消费者。至于性能相关的调度算法，网上已经有很多电梯算法，诸如ALS、SCAN……为了实现的便捷性，本人采用的是LOOK算法。这么说着第二单元似乎就那么回事，但我觉得第二单元，更多的设计应该考虑多线程的安全性，即保证任意时刻下，我们所搭建的电梯模型都是安全无误的。
当然，在实验中也体验到了观察者模型。
测试理解与实践
在第一单元尝到甜头后，第二单元也就没那种好事了。苦于找不到适合的测试包，只能手写数据的准确性检查，但这样的检查性只是基于部分规则而产生的，并不能很好地测试出多线程下，程序出现的不稳定以及其带来的未知BUG。目前，我也未能找到适合自己的且准确的检测多线程BUG的方法orz。
Unit 3
架构设计与方法理解
第三单元，主要是对于JML的学习，重点在于对JML的理解，以及模型的搭建。自己对于架构设计方面的体会也不是很多，架构设计主要考虑的是方法实现效率以及后续拓展。对于方法的实现效率，更多的是采用缓存的方法进行数据处理。至于设计模型，就是图问题的延申。
测试理解与实践
第三单元，可以说是发现了一个传说中debug的利器——JUnit，通过单元测试检测程序的有效性，但是我觉得JUnit在本质上和手动构造样例没有太大的差别，所以进行部分JUnit测试后，选择了和同学对拍更为便捷的方法。
Unit 4
架构设计与方法理解
第四单元，主要是对于UML的学习。在架构设计方面，更能领会到面向对象设计的一些精髓，以及如何搭建合理的程序模型，怎么做好不同类型数据的分类、管理，以及后续的开发。当然，体会更多的是图论。
测试理解与实践
由于第四单元的特殊性，无奈只能徒手构造测试样例，通过starUML画出一系列草图，通过官方包导出数据，然后再进行程序的准确性检测。
课程收获
在写第一单元博客的时候，我就说了OO虽然累，但是绝不乏味。
通过整个OO课程的学习，自己的收获确实不少，但是自己并不满意。很多地方都不满意，无论是课下作业的完成态度，还是实验课的完成情况，以及这篇赶着DDL的博客……由于是线上开展课程的原因，自己在家学习的状态可谓是一言难尽（可以说毫无学习状态）。但收获总归是有的，不然代码全白写了。
总的来说，OO这门课带给我最大的收获就是让我发现了面向对象设计的思想，为什么是发现，也不是理解，那是因为当我真正意义上地面向对象入门时，才发现这种思想就是在我们生活中的每个角落，只是我们并未去注意、去发现，又或者说，我们不曾以这样一个角度去思考问题、分析问题。
至于我们所学习的模型（生产者消费者、观察者……），无非就是生活中情景的总结。在未来的编程路上，我们或许会发现更多更多我们自己所总结出来的模型。
课程建议
- 对于单元之间的衔接可以更为流畅。在学习过程中，尤其是单元之间的切换，我最深的感触就是难度跨度太过突兀，最明显的就是第二单元，它的难度就像是夹在第一单元、第三单元中间的珠穆朗玛峰，个人感觉确实不太合适。当然，这里也不排除课程组对于我们学习进度的考量（比如错开烤漆……）。
- 实验课的调整，本人对于实验课的体验极差。在经过一学期的学习中，OO最让我难受的就是实验课安排（当然，也有自己限时完成效率低下的原因）。而且自己对于实验课的收获很少，每次实验完之后并没有得到任何反馈以及总结，自己也没有得到很明显的提高、收获。
线上学习体会
由于疫情的原因，这一学期的课程只得在网络上进行。个人是比较反感这样的方式，因为自己在家的学习激情并不高且学习效率也很低。但是仍然能够感受到课程组老师们、助教们对于课程的付出，为了给我们更好的课程体验，也付出很多很多精力、心血，也感谢课程组的付出。