一、总结本单元两次作业的框架设计
1.1. 需求分析
通过分析mdj文件可知，两次作业如果对于时间复杂度没有要求，可以不涉及任何数据结构，直接根据读入的UML_ELEMENT逐个分析得到各个函数的结果。
由此观之，两次设计的目标其实都是缩短数据查询与访问速度（不在需要通过id去全文遍历），以类间关联关系增加数据的关联程度。
1.2.1 第一次作业
本次作业围绕类图展开，因此设计了MyClassAndInterface类，类中持有了除其自身信息外：属性、方法、关联、实现、继承这五种关系相关信息。
1.2.2 第二次作业
本次作业在前一次作业的基础上新增了类图规则检查、顺序图和状态图的解析。
UmlRuleChek中对于循环继承和重复实现的实现中，应用了离散数学中类似查环的方法。
顺序图、状态图的解析和第一次作业中极为相似，仍然可以用bfs或者递归解决。
二、总结自己在四个单元中架构设计及OO方法理解的演进
2.1 第一单元 ： 表达式求导
第一次大作业中由于处理输入内容过多，让我最初误以为这门课的难点在于处理输入数据。但是经过第三次作业后，我发现输入数据与要求已经复杂到仅凭观察算式难以判断了。这也就诞生了两种输入有效性检查方式：1.处理前统一检查，2.处理中逐层检查。两种方式各有利弊：统一检查在代码物理范围上相对集中，但是不如逐层检查逻辑清晰，而且难以与需求产生一一对应关系。反思出现这种情况的根本原因在于输入的处理与整合其实就是抽象的过程，如果采取处理前统一检查，那么处理算法面对的是未经过任何抽象过的数据结构：一段朴实无华的字符串。而如果在抽象过程中逐层检查，就相对方便得多。
2.2 第二单元 ： 多线程电梯
这次作业主要依靠着concurrent中线程安全的LinkBlockedQueue勉强度日。似乎使用了他人已有的线程安全库屏蔽了许多这个单元的乐趣，因此本单元除了学习了生产者-消费者模型这种抽象设计模式意外并没有太多的收获了。
2.3 第三单元 ：JML
第三、四单元开始，我们学习着配合着开源库进行开发。自然也就没有了什么架构设计，主要重点在于图算法的相关实现。
2.4 第四单元 ： UML
对于第四单元的用意，我认为对于UML具体理解要大于代码本身。当然不用从原始mdj处理数据确实大大的幸运。本单元仍然是简单的方法实现，会涉及到少量图知识。
三、四个单元中测试理解与实践的演进
2.1 第一单元 ： 表达式求导
本单元测试方法相对多样，我采取了黑盒测试：自动随机生成字符串 + matlab模拟评测机对拍。本以为会挑出很多bug，但是最后发现还是手动编写了一些边界测试来的简单。因此产生了对白盒测试的需求
2.2 第二单元 ： 多线程电梯
本单元主要利用评测姬进行测试。
2.3 第三单元 ： JML
这个单元是测试最为欢乐的一个单元。我们可以采用JUNIT以方法为单位进行测试。同时我们可以用JMLUnitNg+JML自动生成测试用例，但是进行过程和想象相去甚远，遇到了许多如今都没有解决的问题。
2.4 第四单元 ： UML
又回归朴实的手动构造测试数据，毕竟StarUml还蛮好玩的 :)
四、总结自己的课程收获
本次课程确实改变了我对于“代码长度”的认识。
同时体会到了编写代码并不仅仅局限于敲代码，其背后竟然还蕴含着深邃的思想。
更有趣的是刷新了我对于程序“”正确性“的理解，一个正确的程序不仅仅可以通过简单的几个测试用例，还应该可以通过压力测试等等。
五、立足于自己的体会给课程提三个具体改进建议
首先，实验课的设置不好。无论从与理论课的相对时间、到实验内容所需时间似乎都缺乏考量。
其次，毕竟是课程新改革第一年，尤其觉得三、四单元内容较为匮乏。可以看出命题时不得已用问题的算法难度和知识广度来弥补。
最后，希望邀请行内大佬的讲座多一些。
