单元任务
第一个阶段是实现一个UML类图解析器UmlInteraction，可以通过输入各种指令来进行类图有关信息的查询；第二个阶段是扩展类图解析器，使得可以支持对UML状态图和顺序图的解析，第三阶段是对uml的一些错误进行处理，并可以通过输入相应的指令来进行相关查询。同时在所解析的UML模型基础上，按照规定的规则检查模型中是否存在违背规则的情况，并输出相应信息。
1.2 第一次作业总结
第一次作业可以说是三次作业中最困难的一次。由于刚开始接触UML，导致我需要花费大量的时间去理清楚各个元素的含义，以及元素之间的关系，但这只是开始，由于UML本身就很繁琐，同时指导书上所做的规定也非常琐碎，导致我在真正开始编码时，还需要搞清楚各个指令的含义与它所要处理的各种特殊情况。只有在搞清楚这些之后，才能真正的上手编码。
在熟悉了题目之后，第一次作业本身倒是并不复杂。第一次作业要求我们实现一个UML解析器，使其支持对UML类图的分析，可以通过输入相应的指令来进行相关查询。我的思路便是模仿UML本身的结构，将每个UML中的元素包装成一个类，并将这些元素建立成一个类似的层次结构，同时在建立的过程中记录下我所需要的各类信息，从而实现后续的查询操作。
总的来说，第一次作业的难点有以下几个：
- 如何建立自己的
UML模型：我采用了讨论区所说的三重遍历方法，按照层次关系在每一次遍历中提取相关元素，然后进行建模。 - 如何保存信息方便查询：由于
UML中的元素是按照id区分的，但是在查询时传入的参数是name，因此我的做法是针对某个信息，使用两个HashMap来存储，第一个HashMap的键是元素id，值是这个元素本身，第二个HashMap的键是name，值是一个ArrayList，存储同名但不同id的元素。 - 如何判断重复操作：这里一定要搞清楚参数列表相同的概念，两个操作的参数列表顺序可能不同，但只要两组传入参数之间存在某一一映射使得类型相同，就可以被判定为重复操作。
- 查找类实现的全部接口：我采用了最朴素的
dfs查找的方式，但是当我们对某一个类查找完成后，可以将结果保存起来，这样当另一个类向上查到到了这个类时，就可以直接合并，得到结果。
1.3 第二次作业总结
第二次作业新增了对UML状态图和顺序图的分析与查询。有了第一次作业的基础，这次作业就简单了很多，我们的建模方法和第一次作业一样，还是采取多次遍历提取元素的方式，而在存储信息时，也是按照应存尽存的原则，每种信息都使用了两到三个HashMap来存储。第二次作业的难点有以下几个：
- 搞清楚状态图模型里的各种状态的定义，以及他们在
UML里的表示，这里我们需要将UmlState、UmlPseudostate、UmlFinalState分别进行考虑，进行特殊处理。 - 判断关键状态：关键状态的定义很重要，在判断关键状态时，我采用的方法是使用两遍
dfs：首先从起点开始dfs看是否可以到达任意一个终点；然后去掉查询点再dfs查看是否可以到达任意终点。
1.4 第三次作业总结
第三次作业要求我们扩展UML解析器，使其能根据UML规则进行一定的规范性验证。本次作业在架构上和第二次作业基本相同，只需要在第二次作业的基础上增加对UML的检查即可。本次作业的难点有以下几个：
- 判断循环继承：循环继承要求我们输出在继承环里的所有类或接口，本质上是在求强连通分量，因此我使用了
tarjan算法来求大于二的强连通分量，并对自环进行了特判，从而求得结果。 - 判断重复继承，依旧是采用
dfs的方式，对每一个类或接口向上递归查找，如果发现有重复的继承，就加入结果。这里一定要注意，如果开始存储接口的父接口时，采用的是HashMap，就会导致一个接口多次继承另一个接口只被算作一次，即使对这种情况做了特判，之后还需要考虑其子接口的多重继承问题
完结撒花
最后的最后，引用诸彤宇老师的一段话：“我们 OO 课就是这样一步一步让你从一个渣渣，只经过三个月，一跃成为大神的种子（然而很惭愧，由于个人的原因，本人并没有达到）。这个期间你的茫然不知所措，担忧作业无效，熬夜都是物有所值的。” 感谢老师和助教这一个学期的辛苦付出，让我们学到了太多太多。衷心祝愿 OO 这门计算机学院的王牌专业课程越办越好，为更多的学生带去实用的知识、先进的思想和过硬的专业技能！
回过头来看，这学期一共输出了1万行的java代码，还是感觉到不可思议。OO使编写具有规模的程序变得更加容易。每次写完，除过几个简单的bug外，代码几乎很少有bug。与之相反，过程化编程的bug非常得多，在上学期写编译器的过程中，我对过程化编程的大量bug的感受尤其深刻。
OO是一种看待世界的思维方式，没有了上帝视角，组成系统的每个基本元素管好自己的事情，整个系统将井然有序，能够实现非常复杂的功能。
