BUAA-OO-2022 Unit-4 博客总结
第四单元架构分析
第一次作业
数据预处理
第一次作业是实现一个仅包含类图元素的UML解析器，代码框架已经给出，我们需要实现接口定义的八个方法。由于数据传入顺序随机，可能会出现子元素出现在父元素之前的情况，因此我们不能在一轮遍历中对所有数据进行整理，这样可能会RE，而要多轮遍历，每次遍历处理不同层次的元素。
元素存储
其实在预处理的部分还有一个问题，就是我们应当如何对元素进行预处理呢？笔者是为每一个UMLElement种类都设计了一个类，用来存储它们对应的信息，并将每一种UMLElement通过HashMap组织起来。
方法实现
这需要实现的八个方法中，其实较为困难的只有两个，涉及方法和属性的耦合度计算；其他方法只是对预处理后的元素进行简单的遍历和属性查询。
耦合度计算
该方法需要注意如果ReferenceType引用的类或接口是当前查询的对象，那么耦合度不增加，否则耦合度加1，另外可以考虑在每次通过HashMap获取元素后，可以考虑先判断获得的元素是否为null，再调用其方法，这样可以在一定程度上增加程序鲁棒性，减少后续因为自测数据违法造成的错误。
第二次作业
第二次作业增加了顺序图和状态图的内容。由于方法增加，我原先在MyImplementation类实现全部方法的思想肯定是不可行了，因为这样会超出Check Style的限制，因此我们在考虑可拓展性的基础上，对代码重新组织。笔者的思路如下：为每种图实现一个类，其中存储着对应方法的实现，并设置为static，在MyImplementation类中，我们只需要调用的对应的static方法。同时，我们通过多轮遍历的方法仍然可行，但是随着每一轮要处理的元素增多，可能会导致一轮处理的代码行数继续超过Check Style的限制，并且增加不同图处理的耦合图，因此我选择牺牲部分性能，逐一对各图元素进行预处理，而对于每类图而言，我们需要进行多轮遍历。
该次作业最困难的地方在于关键节点判断，由于性能要求很低，笔者使用DFS算法，这样需要仔细对关键节点的概念进行判断：如果最开始对于起点而言，所有终点任意一个都到达不了，那么所有状态均不是关键状态；如果不满足前种条件，且我们删除某个状态后，对于起点而言，所有终点任意一个都到达不了，那么该状态是关键状态。
第三次作业
第三次作业是有效性检查，性能要求同样很低，我们更需要关注实现的正确性。在本次作业中，笔者认为最困难的地方对于R002的理解，其他的需要注意如果通过DFS来判断循环继承、重复继承，中间过程存在细微差异，循环继承DFS的终止条件是判断我们遍历到的元素是否起始元素相同；重复继承DFS的终止条件是判断我们是否重复遍历了同一个元素。特别地，对于R001，我们还需要注意UMLAttribute的Parent ID并非只对应UMLClass。
关于架构设计与面向对象
通过荣老师在课上一遍又一遍的嘱咐，笔者从第一单元起就格外重视架构的设计。笔者认为在四次单元中，对架构设计与层次化设计思想要求最高的是第一单元，这也导致笔者在第一次作业中花费了大量时间去思考。在设计的过程中，我认为核心思想是自底向上，不同层次之间通过接口联系，而一个模块不需要考虑另一个模块的内部实现，只需要关注其能够提供给自己的信息。在后面的单元中，虽然第四单元的UML解析本身就代表着一种层次化设计，但由于几乎只有输入层、方法实现层、底层元素，这几个层次，要求并不高。而其他单元涉及到的类较少，笔者也没有在其中体会到层次化设计思想，但是每单元作业都需要充分地对架构进行设计，特别是前两个单元，这样可以减少重构次数，笔者在一学期的OO中，几乎没有重构体验，略感遗憾。
那什么是面向对象呢，笔者通过一个学期对这个概念建立起了一定的认识，面向对象的三个特征是：封装、继承、多态。封装在上文介绍过，我认为其体现了层次化思想，不同层级之间只需要考虑接口；继承是指子类自动拥有父类的全部方法与属性，在必要的时候还可以Override；多态是指一个父类或者接口，可以代表其底下的全部元素。
就笔者而言，笔者在第一单元第一次作业中，尤其想通过面向过程的思想尽快完成作业，这是由于笔者最熟悉这种思路，并且笔者认为也不困难，但笔者没有这样做，而且通过第一周，笔者深刻认识到面向对象相较于面向过程更不容易出现程序bug，这是因为在层次化思想的指导下，每个模块的实现都变得较为简单，也更加容易通过单元测试对程序进行debug，还有就是功能拓展也更简单，只需要新增类去实现，然后在原有部分调用即可。
关于测试
测试只能证明程序可能存在bug，不能说明程序没有bug。在第一单元中，笔者了解到的是黑盒测试，通过提供输入，获取唯一可能的输出，bug必然可以复现；在第二单元中，由于多线程的缘故，bug复现难度提高，评测机原理也变得比第一单元更为复杂，这单元更多的是需要进行白盒测试，特别是这单元代码量一般，我们可以花更多时间来分析自己的代码。后两个单元主要是熟悉单元测试，通过对底层模块的测试，保证其正确性，我们降低在顶层的调试难度。
课程收获
通过OO课程，笔者最大的收获是与朋友们分享架构、讨论、对拍测试时获得的满足感，即使只有这一点，笔者也认为这一学期OO的学习是值得的。对于其他的，可能就是面向对象的入门，笔者深知在未来碰到相应应用时，肯定大部分知识也需要重新去理解，但是OO课程已经让我在一定程度上体会到了面向对象的优势所在。
改进建议
最后笔者提出三个建议：
-
对于第三单元，笔者认为其过于注重了对于算法的考察，而由于
Java已经对很多数据结构进行了封装，比如Stack，这大大减小了我们在编写图算法时的难度，因此锻炼效果一般，同学更多出问题的地方往往是忘记优化，或者没有优化，导致最终在互测出锅。 -
对于第四单元，不知道是否课程组是在让同学感受奇怪的
用户需求，笔者认为其过于注重对阅读理解能力的考察，而我认为其原本的目的应该是让同学了解UML，就像第三单元让同学了解JML一样，后续可以考虑对这部分指导书的完成。 -
笔者认为对于
JML、UML的要求可以降低，比如放在一个单元，同时加强对于多线程编程的要求，我认为这在未来是一个很重要的能力，而目前通过完成作业，我们只能够学习最基本的加锁操作，对于理论课上学习到的轻量锁并没有相应的实践来进行锻炼。
