1 第四单元架构设计

1.1 第一次作业

1.1.1 基本任务

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

1.1.2 设计思路

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

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

我重新封装了以下类

1. UmlClass

2. UmlInterface

3. UmlOperation

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

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

类图如下

1.2 第二次作业

1.2.1 基本任务

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

1.2.2 设计思路

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

1. R001 重名成员检测

   1. 这个规则内容就是检测一个类中的属性和AssociationEnd名是否出现重合，编写比较简单。但是需要注意一下，可能存在AssociationEnd的name为空指针

2. R002 检测是否有循环继承。

   1. 类 ： 递归追寻被查询类的父类，查看是否再次出现已经记录过的类。若出现，代表出现“环路”，此时需要退出，检测被查询类是否为环路中的一员。如果单纯检测被查询类是否再次出现，则会在被查询类为一个循环类继承环的子类时，出现死循环。

   2. 接口 ：方法和类的检测方法一致。不过，需要注意一下，接口为多继承

3. R003 是否重复继承接口检查

   1. 其本质问题就是用类之间的继承关系，接口之间的继承关系，类和接口的实现关系构建一个(有向)图，查看一个结点是否有多条路径到达其余节点。

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

2 单元架构设计

2.1 表达式求导

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

1. 通过这一单元，清楚认识到程序鲁棒性的重要性

2. 认识到如何正确抽象元素封装成类的重要性

3. 认识到程序设计架构的重要性，三次作业的层次性递归很明显

4. 本单元中，我没有使用面向对象的设计模式

2.2 多线程电梯设计

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

1. 学习并使用了课件上的单例模式

2. 抽象电梯问题为生产消费者模型

3. 注意多线程的结束方式

4. 一些针对多线程的调试方式 - printf大法封装

2.3 JML设计

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

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

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

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

2.4 UML设计

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

3 测试方法演进

1. 第一单元，使用C语言写了一个输入数据生成器，然后利用python写了一个对拍器，进行程序的校验。

2. 第二单元，因为测试是实时输入的，我一开始用java模拟了一下，感觉不是很好，自动程度很差，于是就借助讨论区大佬们提供的魔改包，编写数据生成器，实现随机数据模拟输入。

3. 第三单元，按照讨论区的建议，使用了Junit来进行测试，又从网上学习到了一些Junit姿势，自己编写了个数据生成器来完成了测试

4. 第四单元，由于输入数据的自动构造比较困难，于是我就手动把自己编写的java程序导入StarUml生成Uml图，加上部分修改来对自己的程序进行测试 

4 本课程收获

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

1. 学习了面对对象的基本设计思想

2. 学习了很多测试方法-随机对拍，Junit等等

3. 学习了如何设计一个比较好的架构

4. 学习了多线程设计，很有意思，正好和OS lab4联系，而且电梯的调度和Os磁盘调度很像好吧！

5. 大大提高了我的编程能力。(每次作业代码量还是不少的)

6. 学习并编写了很多算法，从理论到实践。

5 课程建议

1. 前几次上机难度有点大，刚刚接触的小菜鸡受不了。

2. 理论课和平常作业的联系不是很大，而且上机和理论授课时间太多于接近。

3. 互测屋内的人数可否减少一点，看7人份的代码真的很困难。最后，大多数人都只能丢上去一些测试数据对拍了。

4. 代码风格是不是需要作业内容发生一些改变，后面的编码量如果为了符合风格检查，就不得不分拆类，导致原先好比较清晰的代码设计，变得有点丑，这个好像违背了风格检查的初衷。(可能是因为我设计的不好，导致代码量过多)。