一、本单元两次作业的架构设计
本单元为UML图的学习，通过完成对图的解析来强化对UML图各部分内容的理解。
第一次作业：
初步完成对类图的解析。首先通过对各种UML元素的关系分析，结合常见的类，我对各解析出的UML元素进行了相关的组合，构造了几个类如MyClass、MyInterface等来将类的继承、类的方法及其参数都整合到一起，便于实现查找和统计的功能。接口的多继承使用DFS将其所有继承的接口全部找到并储存到相关位置。其他类的各种元素采用father循环方式找到继承的成员变量和实现接口。至于类和接口则存储在HashMap中，便于查找。在解析出所有元素之后建立一次新图，实现各种元素的关联，后续的查询基本上都是现成的。
类图如下：
第二次作业：
实现对顺序图和状态图的解析，并完成几个合法性检查。大体思路与第一次作业类似，也是将顺序图和状态图的元素进行整合，并将整体放入HashMap中。状态图的后继状态算法使用了DFS。合法性检查中由于所有与类有关的元素都存储到了MyClass中，因此R001的重名检查就很简单，直接遍历类的属性和其AssociationEnd的名字；R002循环继承，采用了讨论区大佬分享的tarjan算法，求有向图的强连通分支，其中分支中有多个元素的分支就为循环继承；但在做R003重复继承时，发现了在第一次作业中的DFS算法中稍做些改动就可以实现，R002也是如此，不需要新的算法，不会引入新的一次递归遍历，但是后来也没有再改，毕竟也学会了一种新的算法。
类图如下（好大）：
总的来说这两次作业的思路还是很清晰的，通过对数据的整合来建立新图，并在初始时统计全部关联数据，后续的查询就简单许多。
二、四个单元中架构设计及OO方法理解的演进
第一单元：
处理表达式并进行求导。在做这单元的作业时我还没有建立起面向对象的思想，几乎没有通过类来分解，啥功能都在主类里完成实现，前两次作业还好，比较简单容易对付，到了第三次作业简直是痛苦。第三次作业中，两个藕断丝连的类不断调用对方进行拆分直到不能再拆，逻辑混乱，也不知道是什么支撑我写完的。这单元，我体会到面向过程在有些问题上的难以实现。
第二单元：
多线程电梯。到了第二单元，有了第一单元的教训，我在每次作业之前都会先进行构思，将各种不同功能建立不同的类来实现，通过对象之间的合作来完运人的功能。但是这一单元存在着重构的问题，我在写单次作业时只考虑了本次作业的实现，而没有考虑到下次作业的扩展，这就导致程序的扩展性很差，基本上一次作业一重构。重构一时爽，一直重构一直爽。而且我对多线程的理解和具体实现还存在着一些问题，这也给本单元作业增添了不少难度。总之，这一单元应该是我尝试面向对象编程的实际上的第一单元，尽管存在着重构问题，但相比于第一单元已经有了进步。
第三单元：
JML系列。这一单元可以说是写的很舒服了，三次作业层层递进，没有重构（当然这也跟作业本身的引导性有关，并不意味着自己的构思有多好）。这单元指导书中引导的分类让我感到层次十分清晰，每个类各司其职，而又相互联系共同完成相应功能。分好层次和类后，实现每个类就变得很清晰很简单，尽管最后一次作业还是有些难，但是相比之前的两个单元，这一单元还是比较简单和轻松的。
第四单元：
UML系列。本单元主要考虑了设计构架的问题，这一单元相比于第三单元有了更好的自我思考和实现的空间，第三单元时我还是紧跟指导书的，傻傻的完成每个类而不去考虑其他功能在类中的实现，而在这单元作业中，自己进行构架设计，自己完成了对各种数据的管理，全方面的考量作业的需求，算是为课程画上了一个圆满的句号吧。
三、四个单元中测试理解与实践的演进
第一单元：
第一单元是初始单元，但却是最容易出错的单元，输入数据的不确定性让人很是头疼，要处理格式错误的输入是我之前从没遇到过的，实现起来也很容易出错。第一单元的测试过程，就是构造一些特殊数据来验证程序的正确性，在互测时尝试看看其他同学的代码，但是也看不了多少，主要还是构造数据，肉眼找错。
第二单元：
第二单元多线程，找错就比较麻烦，输入对应输出的不确定性让错误很难出现或者复现，而且电梯数量一多，就会很乱，肉眼找错已经几乎是不可能的了，但是自动评测机又不会写，只能通过看其他同学一堆一堆的代码和使用一些数据来尝试，手动测试真的很难，于是这一单元的测试主要还是针对自己程序的bug展开。
第三单元：
第三单元是JML单元，正好和测试代码的正确性相关，这一单元中了解和学习了许多进行自动化测试的工具，如Junit、TestNG等等，有的工具确实可以自动生成测试数据并进行测试，不过需要相应规格，这对于大点的工程来说是很有用的，不过对于我们这小作业来说就显得有些麻烦了。我在这单元的测试主要是使用自动化生成数据并对拍的程序和脚本（毕竟指令字符串很好生成），和同学对拍来找自己程序的问题，并在互测中找bug，只要拍的久，效果还是不错的。
第四单元：
第四单元UML图，无法再生成随机数据来找错了，只能自己手动构图进行测试。构建几个复杂的图涵盖所有可能的情况也不是容易的事，因此我在每次写完程序后，都要反复琢磨怎么构图，并和同学分享构造数据并对拍，最后还是同学的数据帮我找出了bug。不过本单元的测试还是有侧重点的，就是针对查询方法进行构图测试，类似于单元测试，对某一功能进行专门的构图测试，这样保证每个功能实现的正确性。
四、课程收获
本学期的OO课程可谓硬核，不同于计组的周周必过的紧张感，OO课程给人压力没那么大，但又时时刻刻都在督促你做一些OO的事情。正如同吴际老师所说的，我们这学期的每一周都几乎是在OO课程中度过的，从构思到实现，再到最后的debug阶段及互测阶段，一周时间没有哪一天是没有OO的，可以说是OO陪我们走过了大二下学期的学习生活。
通过这学期这门硬核课程的学习，自己也很有收获：Java语言自不必说，通过课程学习了一门新的语言（尽管还只是皮毛），不得不说大多数东西都封装好了真的好用；最重要的是面向对象的思想，以对象化的思维去分析解决问题，将复杂问题模块化，确实可以更加清晰更加具有层次性，实现起来也更加容易，就正如这几个单元自己的经历一样，从面向过程到分类完成，从无从下手到最后清晰实现，可以说自己也在从面向过程向面向对象转变；程序测试也是我从课程中感受比较深的，不同于以往的交上去就看结果的测试模式，我们每次写完一个Project，即便过了中测，也很有可能存在着明显的错误，OO课程让我明白了测试的重要性和一些进行测试的方法，写完代码不是终结，不断测试才是王道；自己的码力也得到了提高，一开始觉得写个200、300行代码就已经够多的了，到了后期的Project，几乎都会有上千行的码量，这在之前是想都不敢想的，写完好长的代码回头看看，总会有一种自豪感，付出总是值得的。
五、课程建议
1、实验课难度应该降低。毕竟实验课所要实验的内容是上午刚刚讲的新内容，难度不宜过高，应多以基础为主，或者多提供一些引导信息。最好别出编程题，不到两个小时实在是办不了。像最后两次实验课的内容形式就比较合适。
2、课堂上讲一些思想理念架构的时候，最好多加一些具体的示例。有些想法道理讲明白了，但是具体怎么实现、具体怎么用却没有说明白，显得有些大有些空。这里跟软件学院相比，感觉软院学的东西比我们更细致更具体，而我们总是学一些大的思想，这方面和软院结合一下，既有大的思想，又有具体的细节，虽然内容很多，但可能会更好吧。
3、感觉学生展示的研讨课没有让人真正学到什么东西，听大佬在上面讲，有的听不懂，有的听了也就听了，没什么实际价值，我觉得可以换成小组讨论交流制，几个人在一起分享自己的想法，不限于研讨课这一固定的时间，其他时间也可以交流讨论，或者让组里大佬讲讲作业的设计架构，接地气一点，而且每个人都能参与其中。