一、架构设计
1.第一次作业
第一次作业的官方接口中只涉及到了类图的查询操作，所以需要解决的主要问题就是如何合理解析UML类图并进行存储。我采用的方法是用新增自定义类来模拟UML中的类、接口和方法元素。存储类的自定义类中包括类的属性、方法、关联、父亲和实现的接口等信息，存储接口的自定义类中存储了接口的操作、属性和继承的父亲接口等信息，由于每个操作包含了不同类型的参数，所以我用自定义类来存储操作的信息，将封装好的操作存储在类和接口中。
在处理输入时，我采用的是分层处理的方法，先找到UML类图中的类和接口元素，再找属性和操作元素，再找继承、实现关系和参数。这样处理可以确保寻找到每个元素时都能找到它所归属的元素，方便处理。在实现官方接口的方法时，涉及到找父类的操作时我使用循环查找的方法，涉及到接口实现的图结构时我采用的是广度优先搜索的办法。此外，为了减少程序运行时间，我在第一次得到结果后就将结果保存，再次碰到相同操作时直接返回即可。
本次作业在强测中TLE了一个点，是由于广度优先搜索没有记录已经访问过的结点导致复杂度过高。在自己测试时我考虑了这个问题，然而把图画错了。
2.第二次作业
第二次作业相比第一次作业增加了状态图和顺序图的解析。我继续采用了第一次作业的架构，新增了两个自定义类来存储UML图中的状态图和顺序图，状态图的类中存储状态、转移等元素，顺序图中存储生命线、消息等元素。为了减轻实现接口的类的负担，我将所有查询操作分别转移到了相应的类中，但没有改变查询的逻辑。
在处理输入时，我仍然采用上次的分层处理的办法，将新增的状态图和顺序图像类图一样分了层次，分别解析和存储，总体思路和类图相似。在实现官方接口的方法时，顺序图几乎只涉及到存储，没有特别的地方。状态图中比较复杂的是查询后继状态，我采用的是广度优先搜索的办法。
本次作业强测中没有出现bug。
3.第三次作业
第三次作业在第二次作业的基础上增加了合法性检查。我并没有改变原有的实现细节，只是在外层框架上做了改动。由于增加合法性检查后的程序比较庞大，因此我使用了官方接口，将类图、状态图、顺序图和合法性检查的所有信息分别封装到了不同的类中，没有改变原有的实现逻辑。
在合法性检查的实现中，涉及到搜索的方法我均采用的是逐级找父亲和广度优先搜索的方法，其余的方法我均在处理输入数据时进行了存储。
本次作业强测中没有出现bug。
二、架构设计及OO方法理解的演进
这学期经过了四个单元的学习，从初识java和面向对象，到多线程设计，到规格化设计和UML模型的解析，一学期下来，巨大的代码量和紧迫的时间也使得我对于OO的理解更加深刻。
第一单元是多项式求导，由于是刚接触OO，我并没有设计出很好的架构，为了达到预期的功能，我三次作业换了三次架构，每次都是将表达式中的项和因子抽象成类，然后写了大量的逻辑来处理字符串。除了正则表达式之外，我写的其他逻辑都很面向过程，总体上只是将部分内容进行封装，不能称得上是很好的面向对象的设计。
第二单元是多线程与电梯，这一单元我采用了生产者消费者的设计模式，相较于第一单元，这一单元在架构上更容易设计和实现。我将输入线程、主调度器、子调度器和电梯的功能分别封装在不同的类中，在调度器中设有缓冲区，输入数据经过处理后放到缓冲区中，电梯不断在运行过程中取走缓冲区的请求。我认为本单元我的架构设计的比较合理，三次作业都使用了第一次作业的架构，并且增加需求时也比较轻松。此外，我认为多线程的程序设计与以往的程序设计思路有很大不同，多线程需要着重考虑线程安全问题以及合理安排架构和各部分的分工来提高效率。
第三单元是规格化设计，架构设计和JML规格的描述几乎相似，在处理数据时不断进行缓存以减少程序运行时间，大部分查询操作可直接返回已缓存的结果。
第四单元是UML模型的解析，我采用自定义类来模拟UML图中的类图、状态图和顺序图的方式，在处理输入时不断解析和存储属性、操作、关联、状态转移和消息的发送等信息，并将各个图及其相关信息进行封装，在查询时直接返回对应图的对应信息。
总的来说，我认为面向对象与面向过程最大的区别就是功能划分和封装，以及随之衍生出来的继承等特性。在设计程序时，将一组逻辑上有紧密联系的变量和方法封装在一起，看作程序的一个模块，模块内部集中实现相应功能，模块之间降低耦合度。面向过程的程序给我的感觉像是一根弦，从头到尾的实现过程中像是走在一条路上，这一条路上的一部分可能会对整条路产生影响。面向对象的程序给我的感觉更像是一张网，每一部分有更高的独立性，程序本身更加坚挺和健壮。在实际编程过程中，当程序规模达到一定程度时，面向对象的方法显得程序内部分工更加明确，更容易对程序进行有效的管理和扩展。
三、四个单元中测试理解与实践的演进
在四个单元的测试中，我针对每个单元的特点，用了不同的方法进行测试。
第一单元是多项式求导，在测试时我主要针对复杂嵌套和边缘的情况手动构造数据，然后用python的sympy库进行验证。由于我第一单元将表达式、项和因子分开处理，我在程序中写了多个main函数，从最底层开始，逐步测试每一层次的功能，最后到整个程序的黑箱测试。
第二单元的多线程中，我分别写了数据生成程序和结果验证程序。数据生成程序中随机生成符合条件的数据，结果验证程序中根据输入数据和输出数据，从乘客是否都到达、是否存在开关门错误、是否存在先上电梯再开门等不符合逻辑的情况等几个方面进行验证。虽然写了比较复杂的验证程序，但是我觉得程序的线程安全问题可能无法测出来。
第三单元中，我觉得JML工具链并不是特别好用，因此我用的是随机生成数据加自动对拍的方法，测试效率比较高，随机覆盖性也比较好，但是面积庞大和逻辑比较复杂的图则不好生成。
第四单元我采用在starUML上画图然后导出数据并对拍的方法，针对每个查询功能进行各种情况下的测试，覆盖性尚可，但有些缺乏效率。
在四个单元的自测和互测中，我发现很难有可以同时针对所有类型程序的测试方法，最好的测试方法就是根据不同的测试程序进行针对性的测试。自动生成数据并且对拍的方法效率非常高也节省人力，并且随机覆盖性也比较好，但需要不断改进数据生成程序来生成强度更高的数据。手动构造数据更适用于查漏补缺和定点爆破，在互测中针对其他程序的漏洞而手动构造特殊数据往往会有比较好的效果。
四、课程收获
总的来说，一学期的高强度训练下，收获还是非常大的。我学会了一些面向对象的基本原则和一些实用的设计模式，以及一周内完成500-1000行规模的JAVA中小型程序设计和测试。此外我还学会了利用bat批处理程序和python搭建自动评测机。我认为编程本身就是一个不断练习不断进步的过程，能力的提升也必然需要一定的代码量作为支撑。一学期的学习之后，我更加认识到了架构的重要性和好的架构在迭代开发中的优势，我也能够在接到需求之后认真分析，先设计出好的架构再开始编写代码。相信这门课从OO原则和思想、编写代码的实践这两个方面对于我今后的学习都会产生深远的影响。
五、课程改进建议
1.
希望实验课后能得到反馈以及bug修复，并且适当的降低难度。本学期一共八次实验课，给我最大的感觉是有些摸不着头脑，有的时候题目非常难，做的时候有些吃力，并且结束后没有反馈，并不知道自己做的怎么样，也不知道自己对于实验课所涉及到的知识点是否理解正确。所以希望实验课后能有反馈，这样能在实验课上有更多的收获。
2.
个人感觉研讨课上同学们讲的有些内容不太适用。比如很多同学讲了一些课程内没有提到的设计模式，虽然这些设计模式在以后工作中可能会接触到，但是在oo课程中，每周一次作业带来了很强的推背感，架构一旦设计好了也不会轻易改，并且出于正确性考虑，一般也很少会用自己不熟悉的写法，这就导致这些设计模式没有很好的实践的机会，只能当作理论的东西去听。希望研讨课上能对同学们讲解的内容的范围进一步约束，使得研讨课内容和OO作业关联度更高。
3.
希望能增加第三单元的中测强度。有的时候一个疏忽引起的bug可能会导致强测全挂，并且中测测不出来。在此也希望给分的时候将bug修复情况考虑在内，比如如果一次就可以修复所有原来全炸的强测数据，可以考虑减少最终分数上的损失。
六、线上学习OO的体会
线上学习的方式对于OO这门课并没有什么影响，从作业的发布到完成到测试和上机，体验都十分良好，遗憾的是一学期下来没有见过老师、助教和在研讨课上进行分享的同学们。
七、其他
感觉OO这门课总体来说比较成熟，从作业内容到测试到bug修复和实验这一套体系十分完整，学习体验也比较好， 就是真的好累啊 。同时，老师和助教们也都非常负责，可以看出老师和助教们为了完善课程体验而做出的努力，在此也谢谢老师和助教们的辛勤付出，希望OO课程越来越好！