一、总结本单元两次作业的架构设计
1.第一次作业
①建立一个CheckElements类对不同的Elements进行分类管理，将它们直接储存（数据没有顺序性所以无法直接构成）：我认为是叶类型（就是没有会属于它的属性的Element）直接储存，我认为不是叶类型的Element建立新的类储存。
②从我认为是叶类型的Element开始对每个Element类型进行遍历，构成这个模型最原始的结构状态。
③考虑如何获取我们想要的信息，主要就是继承和实现所导致的一些父类信息整合到子类信息的实现。我选择了在结束实例化前直接遍历，对Interface和Class采取一样的方式，从没有父节点的节点开始往下遍历，把父节点所有信息交付给子节点。
2.第二次作业
思路和第一次作业差不多，无非就是分了三个部分来进行，把CheckElements下分成三个更细致的功能对三种图进行具体分析。还是遵循先存原始类型——构建原始关系——进行进一步的信息整合三个阶段。
与之前比较不同的是，在类图进行precheck时，构建原始关系时进行了R001的判断，进一步做信息整合时又分为两步，第一步检查R002，采用了tarjan算法找强连通分支，第二部检查R003，此时因为有重复继承问题，而Interface多继承问题会干扰查找，不方便从顶级接口往下遍历，只好乖乖一个一个单独遍历。Class依然是单继承不会有这个问题可以沿用之前的方法。
二、总结自己在四个单元中架构设计及OO方法理解的演进
第一单元，多项式求导相关。
重点在于封装继承等思想的理解，三次作业重写了三次，每次的程序几乎没有可拓展性。
第一次简单只有两个类，几乎就是用JAVA做着大一数据结构课做的事；第二次写的很乱，刚开始的时候没有考虑好，导致写的时候拆东墙补西墙，到最后不知道自己到底写了什么，甚至不想再读一遍自己的代码；第三次虽然结果上来说翻车了，但是写的却是比较顺利，初步有了面向对象的概念，通过接口整合了不同的项，还有了工厂的概念。
第二单元，多线程电梯。
重点在于多线程的理解和使用。
其实相比第一个单元，这个单元但从写的过程来说反而顺利一些。这单元的作业每一次作业基本上是在上次作业的基础上修改的，虽然并没有做到完全地通过继承等实现代码拓展，但思路没有推翻重来。但是在调度器和电梯功能的安排上作出了不是很妥当的安排，并且算法影响了性能。
第三单元，JML规格化设计。
虽然这次作业给人一种很数据结构的感觉，但其实在过程中还是学到了许多的，比如说设计和实现分离。怎么去设计架构是一回事，怎么去实现具体功能是另一回事。也是一个对之前的作业的比较好的反思，是要急于去实现功能还是先做一个整体规划布局？第一单元第二次作业就是急于去实现独立功能，导致最后写的很乱，只能拆东墙补西墙去辅助这个独立的功能。
第四单元，UML相关。
我觉得UML在设计架构的时候是一个很有帮助的东西，可以帮助我们事前做一个规划布局；同时，其实UML类图对我看其他同学代码的时候应该也很有帮助。说回作业，作业比较好的呼应了课上内容，让我们对课上内容有了一个比较深刻的理解，虽然有一次出了些bug，但总体来说体验很好，感觉就是内容不难，但是其中有很多值得思考的地方。
三、总结自己在四个单元中测试理解与实践的演进
测试大概是我做得特别弱的、实践也比较少的一个部分，在这方面自己始终没有做出比较突破的尝试，比较可惜。
数据从哪里来：
第一，我个人的测试主要还是依靠自己编造数据。我觉得自己编测试数据的优越性是比较有针对性，很多边界或者刁钻的数据毕竟还是想出来比自动化生成容易。但是这也导致了其实你能想到的数据，你在实现的时候肯定也是特别注意的，所以只能检查你的实现是否达到了目的，很难找出你自己遗漏的点。
第二，数据共享。其实是部分弥补了上一个不足。
第三，自动化生成。随机数据在某种程度上是非常好用的，但是带来了部分时间的额外开销，需要有点耐心，所以我基本没有尝试。
怎么测试：
第一，纯手动测试，肉眼观察。
第二，将代码打包成jar包，用命令行测试输出对比。这也是我用的比较多的方式，比开N个IDEA对比好一些，又不用写程序……
第三，自动化测试，这个讨论课的时候有同学分享过，但是由于得过且过的心态，其实并没有尝试过。
至于Junit单元化测试那些，在JML单元的确是尝试过了，但是说实话也仅仅尝试了一下……
四、总结自己的课程收获
1.知识上的收获
这一点大概是毋庸置疑的，开学的时候我还不会用JAVA，到第一单元掌握了JAVA的语法，可以写出一些面向过程的JAVA程序，到第二单元的时候，渐渐有了一些面向对象的概念，可以写出一些简单的多线程程序，到第三单元的时候初步了解了JML，第四单元的时候学会了看UML类图。
2.编程思想的转变
刚开始的想法就是看到题目，赶快上手，赶快写，也不管性能什么的。之后渐渐地明白了设计应该优先于实现，因为第一第二单元的性能分以及第三第四单元不允许超时的要求，也渐渐开始考虑一些性能（时空复杂度）的问题，虽然其实常常是考虑的太浅了……但也不得不承认的是，有一些问题始终还是理解不够，比如解耦的思想……
3.对测试的态度转变
在测试过程中，心态其实是有一个转变的。因为原来我一直觉得看代码+理解代码才是debug的首要任务，数据怎么样只是一个非常次要的东西，但后来发现，其实数据真的是有助于我们去找bug的，并且很多bug是会反映在数据上的，一看数据你就会知道数据你就知道哪里可能有问题。
五、立足于自己的体会给课程提三个具体改进建议
1、实验课不要放在刚学习新知识的下午。
之前几堂课，刚上课讲完的内容，中午吃个饭就要上机了实践了，怎么都觉得有点魔鬼。第一次我没来得及提交。虽然是很push学生好好听课，push学生理解运用课堂内容，但是还是觉得有点魔鬼，我觉得给学生一点缓冲时间复习理解，个人先课下实践一下会比一上来就课上实践效果好。
2、一个测试房间人数降低
很感谢今年把一对一测试改成了多人互测，这样防止了很多问题，但是我觉得一组7~8人人数有点小多。我对互测的理解是一来可以互相找bug，二来也可以看看别人的代码是怎么写的，但是6-7个人的代码测试，让我更愿意去不断找数据测试，而懒得去一个个看看代码。降低房间人数（比如4人一组）会让学生更有动力测试吧。
3、关于“答案”
这学期的实验课，让我觉得push了我去看ppt，理解知识以外，作用有点局限，因为我甚至不知道到底什么叫比较优越，什么叫垃圾。作业还好，好歹经常会开放一些优秀作业，第三次也给了标程序，但实验实在是……希望实验也可以和作业一样，并且希望不要时给时不给，一切随缘看心情。