OO第四单元总结

本单元的任务是根据输入的UML图元素，支持对类图中相应关系的指令查询

架构设计

第一次作业

第一次作业要求我们根据输入的UML类图元素，支持类图指令的查询。经过详细阅读指导书以及PPT后，不难发现可以根据UML类图元素之间的层次化关系建立一张UML类图，便于指令的查询。

由此我们可以对UML类图关系图中需要与其他元素产生联系的中间节点构造一个包装类，在第一次作业中体现为MyClass,MyInterface,MyOperation这三个类，UmlAttribute、UmlParameter，可以作为MyClass和MyOperation的属性，UmlGeneration、UmlInterfaceRealization作为类和接口之间的关系，可以在MyClass类中设置父类属性，在初始化时添加对应的关系。

由于输入中的UML元素之间是无序的，因此可以在MyImplementation类的构造器中先将每个UML元素添加到HashMap中，其中key值为element的Id，value为对应的Uml元素或者包装类。在所有元素输入完之后，再根据UML类图的层次关系初始化构造UML类图。

第二次作业

第二次作业在第一次作业的基础上新增了对状态图和顺序图的指令查询。由于第一次作业已经打好了地基，可以继续沿用第一次作业的思路，根据顺序图、状态图之间的关系，采用包装类来构造顺序图和关系图。

但由于新增了两个图，如果继续按照第一次作业的方法，直接把类图初始化方法放在了MyImplementation类，就显得有些捉襟见肘了。根据面向对象的思维，我们可以把MyImplementation类和关系图耦合度降低，分出三个类（MyClassDiagram、MySequenceDiagram、MyStateDiagram）进行三种关系图的构造。

比如状态图，我们可以根据状态图的关系进行构造，其中MyStateMachine、MyRegion、MyState、MyTransition为包装类，UmlEvent作为MyTransition的属性、MyState有三种类型（一般状态、初始状态、终止状态），拥有对应的MyTransition属性，由此可以构建起状态之间的转移

和状态图比起来顺序图更为简单一点，只需要构造MyInteraction和MyLifeline两个包装类即可，其中MyLifeline中有Creator，即创建它的Lifeline，为第二条指令服务。而指令 3：给定 UML 顺序图和参与对象，收到了多少个 Found 消息，发出了多少个 Lost 消息只需要在顺序图初始化时遍历所有的消息，根据关系对对应的MyLifeline添加Found消息数量和Lost消息数量即可。

第三次作业

本次作业是在前两次作业的基础上新增对9种异常的检查，基本上不用改架构，只需要在前两次作业的基础上增加一些异常的检测。看起来似乎不难，但需要注意的是有些地方很坑。

首先R004检查的是重复继承的类或者接口。但是由于类是单继承的，并且循环继承的情况已经在R003中被排除了，所以R004中无需考虑类的重复继承，只需要判断接口的重复继承

最坑的地方是R003的循环继承的检查，虽然课程组把数据限制在了300个UML元素内，但是根据我造的数据，先随机生成几十个接口，再两个接口间再随机继承，哪怕是这样完全随机的数据，如果循环继承的算法写的不好（直接暴力dfs找出每个点成的所有环，没有剪枝），就会tle，本地测试甚至300个元素的数据跑了一个多小时都没有跑出来。我的做法是遍历每个点，对每个点dfs看能否从这个点出发回到这个点，同时使用visited集合维护dfs中已经遍历的点，如果dfs中再遇到这个点就直接返回false，如果dfs中重新走到了这个点，也直接返回true。这样优化以后最差的情况也是遍历整张图，性能比前一种找环的方法提高了很多很多，一个多小时都跑不出来的数据只需要零点几秒。

数据生成与自动评测思路

第四单元开始时已经接近期末，本来不想搭建评测机了

标签：OO,defaultdict,作业,list,生成,collections,UML,第四,单元
来源： https://www.cnblogs.com/sdjasj/p/16414481.html