本单元的主要目标是实现具有处理UML预处理后语句的一个解析器类的程序，并具有相关查询与报错的功能，本质上讲仍然可以看成是根据一串pcode生成模型并进行解析处理的程序，整体难度不算太大，比较考验图论功底。

本单元架构设计

这图看着乱七八糟的，所以简要说明一下个人架构，整体模型构建主要由三个大类完成，一个是继承UserApi的MyImplementation类，一个是负责缓存模型的ModelingCaching类，还有一个是负责错误处理的RuleChecker类，对输入的处理大体思路如下：
把输入内容UmlElement[]放到ModelingCaching类的构造函数中进行处理，根据不同图的特征来决定要通过几次循环遍历来进行建模，如对于时序图而言有如下的层次关系(Collaboration->interaction->lifeline\endpoint->message)所以需要四次循环，而我实际上使用了5次循环来进行建模(stateMachine有五层)。同时为所有可能的ElementType分别构造以id为键自己为值的Hashmap存入ModelingCachine的属性中，方便后续的调用。
为了清楚的变现出所有UMLElement之间的层次关系，我为所有具有子层次的Element都分别构造了单独的类并将其所有子层次分别存入类中，例如下面的类：

public class MyUmlTransition {
    private final UmlTransition umlTransition;
    private final HashMap<String, UmlEvent> eventMap = new HashMap<>();
}

另外为了统一地处理时序图中的参与对象和状态图中的所有状态，我还分别构造了MyParticipant类和MyGeneralState类并让所有相关的类继承这两个类，方便某些指令的处理。
RuleChecker中的所有方法都是静态方法，在进行checkRule相关指令的时候，其流程如下：MyImpletation调用ModelingCachine，再由ModelingCaching静态调用RuleChecker，针对类里缓存的一大堆HashMap直接进行统一处理，事实上MyImplementation类的所有方法都是主要由调用ModelingCaching的相关方法来实现的。
最后迷迷糊糊写下来总代码量也是小过了2000行。

第一次作业

第一次作业主要是对类图的相关处理，对于判断两个方法的参数所组成的多重集是否相等，我使用了 HashMap 进行比较，键和值分别为对应参数类型和出现次数，除了这点以外，没有太多需要注意的地方。
bug方面由于写的时候没注意不小心把return参数也放进参数列表了，就WA了一个点。

第二次作业

第二次作业新增了时序图和状态图的处理，基本只涉及了简单图论问题，没有什么要注意的点。

第三次作业

第三次作业新增了对错误的判断，个人感觉只有R003 R004是需要重点关注的。对于R003判断成环可以直接topo，如果觉得topo麻烦的话也可以看一下从自己出发能否访问到自己，然后便利所有点（没限制复杂度就是爽。对于R004判断重复继承，仍然可以topo，采用topo+dp，dp去存当前点到入度非0的点的所有路径数量，topo的时候根据dpi去找答案就行，当然也可以直接拉一个HashMap去存所有点的入度，如果从当前点出发建立的map有入度大于1的点，那就把这个点也放答案里，不过要注意的是可能出现有两个source和target一样的继承关系出现，这种需要特判一下，剩下就再没啥了。

OO课程总结

总结自己在四个单元中架构设计思维及OO方法理解的演进

第一单元我学会了要将独立的元素尽量分离开，并把能细分的部分尽量进行细分，减少出错的可能，同时层次化的设计也更有利于后续拓展，同时我意识到一定要确定好架构在进行构筑，如果后续要出现架构上的重构，其时间开销会很大。
第二单元我学会了多线程设计的相关模式，更深一步理解了多线程并发的安全性问题和锁机制、连接池机制等，使我对设计安全性有了更深的体会，同时对临界区的设计也有了一定的心得。
但是出于性能考虑这两个单元还不是很能很好的体现OO思想，有些情况下为了必要的性能，牺牲架构和设计也确实是在所难免。
第三单元主要是讲JML规格相关问题，从这一单元我充分认识到了如何才能描述清楚一个方法可能带来的结果，同时也对OO设计的规范化有了一定的理解。
第四单元在前三个单元的基础上我从一开始就实现了高度层次化的设计，故在第四单元后面两次作业中，我都完成的非常快速，同时也对OO的设计模式和设计方法能带来的便利性有了更深一步的体会。

总结自己在四个单元中测试理解与实践的演进

由于自己没什么时间，测试这部分主要还是由自己手动捏造极端数据实现的，总体上没出太多问题，但是如果有时间的话还是应该尽量写评测机和同学对拍，这样的效率也更高一些。
至于如何捏数据，基本就是对着数据规范去，往上下限分别去构造足够极端的数据。

总结自己的课程收获

经历了一学期的OOP思想的灌溉，我对AOP设计的理解也有了些许的深入，同时由于没怎么进行过OOP方面的工作，对于JML和并发也是有了一个全新的理解，一学期下来我对JAVA相关源码的认识和对程序设计的理解都有了很大的提升。

立足于自己的体会给课程提三个具体的改进建议

1.首先我认为OO这门课程的所有参与学生都应该彻读《代码整洁之道》，甚至可以把这个要求放在pre里一同作为要求项目，不能只依靠直觉来认为自己的代码是优雅的，这样无论是互测还是实验，都对看代码的人员是个不小的包袱。
2.当前研讨课的分值占比设置我觉得有待商榷，我对于当前研讨课的收获感觉是甚微的，是否大家聚在一起每个人都发言讨论其效果就一定是正向的？这个问题我觉得不能理想化看待，当研讨课也成为了OO这门重课之中的一个压力点时，我感觉其效果未必就会有早年不讨论的好，所以从我个人角度来看的话，还是更希望研讨课能把占比放低一些。
3.我认为到OO课后期就已经可以适当向同学们介绍AOP方面的知识作铺垫了，在后续的开发类课程中AOP才是站主体地位的，而纵观计算机学院的所有课程甚至没有一门对AOP进行过系统性介绍，所以我认为到了后期比较轻松的时候，就已经可以适当渗透AOP的相关知识了。

标签：OO,HashMap,所有,topo,OO2022,AOP,第四,单元
来源： https://www.cnblogs.com/Horatio201/p/16400000.html