OO第四单元博客总结 - GRAND BATTLE

最新推荐文章于 2024-06-17 19:24:09 发布

weixin_33933118

最新推荐文章于 2024-06-17 19:24:09 发布

阅读量221

点赞数

原文链接：http://www.cnblogs.com/MGcyh/p/11072963.html

版权

本次作业最终需要实现一个UML类图解析器，可以通过输入各种指令来进行类图有关信息的查询。

根据UmlElement之间的逻辑关系如类的继承关系，类和接口的实现关系，接口间的继承关系，类和方法的包含关系构建自己的UML图。

为了能实现上面所提到的逻辑关系

我重新封装了以下类

为了完成类名 -> MyUmlClass ，类名 -> 出现次数的映射，我分别构建了俩个hashmap

其中需要注意的是，根据讨论区的回答，UmlElement的输入顺序不一定满足UmlElement的逻辑关系

类图如下

第二次作业中新增了状态图和顺序图的查询。

相关的查询都比较简单主要的难点为三条规则的编写

R001 重名成员检测
1. 这个规则内容就是检测一个类中的属性和AssociationEnd名是否出现重合，编写比较简单。但是需要注意一下，可能存在AssociationEnd的name为空指针
R002 检测是否有循环继承。
1. 类：递归追寻被查询类的父类，查看是否再次出现已经记录过的类。若出现，代表出现“环路”，此时需要退出，检测被查询类是否为环路中的一员。如果单纯检测被查询类是否再次出现，则会在被查询类为一个循环类继承环的子类时，出现死循环。
2. 接口：方法和类的检测方法一致。不过，需要注意一下，接口为多继承
R003 是否重复继承接口检查
1. 其本质问题就是用类之间的继承关系，接口之间的继承关系，类和接口的实现关系构建一个(有向)图，查看一个结点是否有多条路径到达其余节点。

类图如下（后面为了能过代码风格，增加了部分类，导致很丑........）

通过这一单元的训练，我们开始逐渐接触到 Java面对对象的设计思维，开始层次化构建Poly，term，factor类。

在本单元作业中，需要合理设计和解耦各个线程所在类。其中，为了保证可扩展性，我使用了泛型，避免了共享队列的一些重复编码。这样的话，在完成后面的要求时，提供了一个很好的基础。

按照本单元的JML设计，一步步地清楚地构建一个地图查询系统

不过，由于我本单元第一次作业设计架构不好，导致我第二次作业直接重构

把数据结构和查询方式分离。

为了更好地实现算法，和降低复杂度，学习了OS lab2的映射，完成从Hashmap图-> 邻接矩阵图的转变，避免了超时出现

这一单元的风格和第三单元十分相识，我也吸收了第三单元的设计经验，从一开始就分离数据解析和具体操作。可扩展性极佳，而且学习了一些如何封装的方法。

第一单元，使用C语言写了一个输入数据生成器，然后利用python写了一个对拍器，进行程序的校验。
第二单元，因为测试是实时输入的，我一开始用java模拟了一下，感觉不是很好，自动程度很差，于是就借助讨论区大佬们提供的魔改包，编写数据生成器，实现随机数据模拟输入。
第三单元，按照讨论区的建议，使用了Junit来进行测试，又从网上学习到了一些Junit姿势，自己编写了个数据生成器来完成了测试
第四单元，由于输入数据的自动构造比较困难，于是我就手动把自己编写的java程序导入StarUml生成Uml图，加上部分修改来对自己的程序进行测试

首先，本学期在oo，os俩兄弟的夹击下，学滴有点艰难。但是，还是收获满满的。

前几次上机难度有点大，刚刚接触的小菜鸡受不了。
理论课和平常作业的联系不是很大，而且上机和理论授课时间太多于接近。
互测屋内的人数可否减少一点，看7人份的代码真的很困难。最后，大多数人都只能丢上去一些测试数据对拍了。
代码风格是不是需要作业内容发生一些改变，后面的编码量如果为了符合风格检查，就不得不分拆类，导致原先好比较清晰的代码设计，变得有点丑，这个好像违背了风格检查的初衷。(可能是因为我设计的不好，导致代码量过多)。

转载于:https://www.cnblogs.com/MGcyh/p/11072963.html