ohhhhh，最后一个单元啦！
第一部分——第四单元作业分析
第一次作业
思路分析
第一次作业的要求是分析UML图中的类图。而类图分为两大部分，UMLClass和UMLInterface。其中针对class的查询多，对interface查询几乎没有。所以很自然，会要想到为UMLClass新建一个自己的MyClass类来管理其中众多的属性方法等元素。不过，经过了前面三个单元的打（暴）磨（虐），我知道事情肯定没有这么简单，之后的作业还有两次，指不定会有什么要求出现，可要想好扩展性。所以，为了提高可扩展性，我将UMLInterface也建立了一个自己的MyInterface类来管理interface及其属性方法等元素。当然，通过学习我发现UMLParameter元素的parent_id为UMLOperation类型，所以为了方便和统一管理，我给UMLOperation元素也建立了一个新的MyOperation类管理其中所含的参数。
同时，为了使整个代码结构更清晰简洁，我提取出了一个Search静态类，里面的全部属性和方法都用于查询操作，即将该类作为一个查询的桥梁，其他类只需扔给它id或是name，它就可以给提出请求的类返回一个查询的结果。
为了性能，我还建立了一个Buf类，该类存储着比较费时的查询操作一次查询后的结果，一次之后的查询就可以直接获取结果，节省时间。（空间换时间）
UML
由上图可以看到，最顶层的查询接口只保有一个Buf类的实例，作为缓存，其余的只与Search类进行交互，这样极大地降低了查询接口与实际存储的class、interface等元素的耦合。
本次作业我用了大量时间来对整体架构进行构思，因为我觉得这个UML图本来在StarUML中就是以层次化进行管理的，那我读取输入后也应该按照一定的规律建立起层次化。前三个单元自己搞了半天层次化也没太真正满意地弄出来过一个好的架构，心想着最后一个单元了，还在输入时已经给出了层次化，那一定要好好构造一下。看了上面的类图，发现这次架构还不错，比较满意，至少比较清晰，耦合性较低。
Bug分析
第一次功能较少，而且在架构上好好进行了设计，所以在强测中也没有出现bug。不得不说架构确实很重要！（其实一直都知道，只不过做不好啊
第二次作业
思路分析
第二次作业在第一次作业的基础上增加了一些查询功能，增加了对UML顺序图和状态图的查询。
看到这次作业，我不禁想到，这完全就是复刻第一次作业的思路嘛！（没想到我这个架构还挺好的，还能多次使用hhh）
所以，我用上一次完全相同的思路，对于需要进行很多查询和管理很多数据的UMl元素，都建立一个新的Mybalabala类，用于管理这些数据和进行对其管理的数据的查询。
在查询方面，思路依旧，只不过需要在Search类中添加一些新的属性来存储顺序图和状态图中的元素和信息。而Buf类同理，加一些顺序图和状态图相关查询的结果。
UML
这次功能新增的查询不太多，但是要管理的数据多了很多，所以类也多了不少。不过别看这一大张图，其实整体结构还是比较清晰。通过名字大概就可以知道其功能。整体最顶层一个总的查询接口，下属三个次查询接口，这三个次查询类分别对应类图、顺序图和状态图的查询。前面说到这次的架构与上一次的几乎完全相同，所以每个次查询接口的结构和关联与第一次作业的顶层接口一样，全部保有一个Buf类的实例，同时只与Search类交互进行查询和获取数据。而且每个次查询接口都只关注自己所要查询的图的元素。
所以整体看起来仍然是一层层推进，较为清晰，耦合性也较低。
不怕被笑话，实话说，我在第四单元才第一次对我自己所写的代码进行分包。而且我觉得这个分包的结构就很好地体现了我的整体层次，在此放出一张图：
上面的UML图总结来看应该就是如上的包结构。
Bug分析
这次作业新增功能也不多，但是在强测中错了一个点。这个原因，emmm，就是对JAVA容器理解的还不够彻底。这个错误是在构造HashSet时，如果给定的初始集合为null，则会抛出NullPointerException。我之前以为HashSet在构造时，如果传入的初始集合为null，就和没有赋初值一样，现在知道了原来不可以为null！！
第三次作业
思路分析
第三次作业考察点与之前两次不同，之前两次都在做查询操作，而这次却要增加规则判断。
这我心想，之前的套路不好用了，得想新办法。刚开始，还是想要新建一个专门对所有8条规则进行统一判断的类，而且使其只与Search类交互，这样将耦合度降到最低。
但是想来想去，发现这样耦合度确实低，整体也确实看起来像模像样。但是实现起来，这个新建的检查类会极其繁重，因为这些规则检查很多涉及class和interface内部属性方法等内容的检查，所以通过Search获得class或interface，在一步步获取属性检查，实在有点麻烦。所以最好的办法我觉得是将各个有关class或interface内部属性的检查全部放到MyClass类和MyInterface类中，这样可以在类内部直接对属性进行检查，十分简便。在检查类中，只需获取Class和Interface，进而调用其内部写好的检查方法即可。
而且还有一个较大变动时，我新建了GenerAndRealizaion静态类，来存储所有的继承和接口实现关系。因为规则检查涉及循环继承和重复继承等问题，如果采用之前的每个类和接口自己管理自己的爸爸和实现接口，则遇到循环继承时，将会陷入死循环。所以为了更简便地检测循环继承和重复实现or继承等问题，我就新建了一个类来管理这些继承关系。
UML
这次的UML图更复杂了，不过其实也只多了关于规则检查的部分。整体看起来仍是层层递进，主要功能都集中在最底层，这样上层查询接口与功能的耦合性就很低了。
Bug分析
这次作业强测CTLE了一个点，实际就是对于菱形图会产生死循环，就是在进行R003规则判断的时候没有设计好算法。
第二部分——四个单元的架构设计和演进
-
第一单元
依稀记得第一单元第一次作业一个main类解决问题的我。当时，觉得用上HashMap，用上正则表达式就很OO了。
第二次作业，不只一个main类啦。有四个类了，不过似乎当时也是迫于有了sin、cos、x三种项，所以只能建立了一个poly类来管理这三个项，同时多了系数cof类和指数index类。这些类的出现似乎并不是为了架构，为了扩展性，而是迫不得已加上的。
第三次作业，依旧是，只不过迫不得已加上的不只是管理数据的类，还有封装函数功能的建树类，求导类balabala之类的东西，反正要用啥大量代码解决的问题，建个类装起来用，就是这样。
-
第二单元
第二单元，进入了多线程的世界。
依旧还是没有架构设计（有想过），用到啥建啥。
不过我真的想好好设计一下架构，搞一个低耦合，超简洁，看起来就爽的一个架构。在动手前，想来想去（此时还没有被暴虐够，还想不到之后的迭代会有多可怕，所以对扩展性还没有一个概念QAQ)，还是没有一个比较完美的思路。索性直接动手写了吧，由于刚开始的作业也还不太复杂，这个架构还hold住。第一次作业也还比较顺利。
到了第二次作业，电梯多了，还能新增电梯。整个架构就有点捉襟见肘了，不过为了迭代开发，没有更改架构。
第三次作业，电梯多了，还不一样了，还停在不同层了。整个功能很复杂，建了很多类，为每个电梯建一个请求队列类，还有不同电梯不同类。反正一堆类，也没搞个父类，有点难受。第三次作业结果也不好，可见架构在程序质量方面的巨大作用。
第二单元，有开始考虑架构，也开始想要做，但是还是没有很好地实现出来。有点遗憾。
-
第三单元
第三单元，JML。
这个单元，以为助教给写出了JML，只要按着JML写代码就可以了。但是最后经过总结，发现原来在JML下也可以做出自己很好的架构设计，这是我刚开始没有想到的。
这个单元，我就按照这JML写代码，在有需要的时候建立一个类来帮助自己实现功能。现在回想起来，确实是丧失了一次很好的锻炼设计的机会。
啊，不仅感慨，这个架构设计真的是有点难啊。写了三个单元的代码也还没有真正写出一个自己的好的架构。
-
第四单元
啊，光明照亮了大地~
最后一个单元，我下定决心一定要写出一个好的架构，为这门课圆满收官。经过了好长时间的思考和准备，发现这个StarUML已经给出了很好的层次化设计思路。所以我仔细研究了StarUML的数据管理模式，并将其转化应用到我的架构设计中，效果很好。终于写出了我自己的较好的架构设计，有了一个圆满的结局，还不错~
最后一个单元，让我真正的体会了层次化，体会了架构设计的重要性（其实之前也知道，没做到QAQ）。看之前学长的博客，有的说第四单元作业有点鸡肋，有点难。其实我觉得这个单元对我架构设计的训练和提升最为巨大，是让我真正从UML中学习到了架构的设计方法并进行了实践。在架构方面收获颇丰。
第三部分——四个单元测试的理解与演进
-
第一单元
第一单元指导书给出形式化表述，那就按照指导书给的表达式构造样例嘛。手动构造，大脑处理，肉眼比对。（人·工智能）JUnit？听都没听过~
不过手动构造样例确实效率较低，而且很有可能边界条件考虑不周，所以在强测中有可能被一些特殊情况和极端情况wa掉。人工测试只能说在功能较为简单，数据较少的情况适用。范围较广，数据量较大时，人工测试就有些捉襟见肘了。
-
第二单元
第二单元是多线程的世界。多线程非常容易出bug，而且出了bug你还很难找到它，毕竟你再跑一次程序可能上一个bug就消失的无影无踪了。这对写代码和测试提出了更高的要求。
第二单元中，我在写代码时就十分小心，写完一部分就检测一部分的功能（低配版TDD？hhh），对于各种锁的使用也是仔细思考其产生的各种影响，尽力在写代码的阶段就把bug控制到最少。最后实践表明，这个方法还不错，写一点测一点，尽力在写代码的时候控制住bug的效果还不错。
对于测试数据部分，经历了第一单元的挫折，我决定要开始自动化构造数据了，于是使用了python构造输入。可是这第二单元的输出也是十分繁杂，仅凭人眼很难模拟出电梯的轨迹以及电梯行为的正确性。所以，找上我的小伙伴，一起写一个评测机吧！其实写出来最后也不是很多，毕竟输出格式都固定，只需正则拆分，同一个乘客归类，判断楼层开关门啥的也就容易了很多。有了这个手搓的评测机，最后效果也还不错，强测成绩还ok。
P.S.在此给出评测机代码链接https://github.com/wentForward/OO_elevator，若是有幸有学弟学妹看到这篇博客，可以自行取用并根据需求更改。
-
第三单元
第三单元，我知道JUnit是什么啦~
第三单元，在课程的指导下，我开始使用JUnit进行单元测试。不过，使用了一个单元加实验，说实话，这个单元测试只能帮助你检查你想的和你写的有没有差别，但是对于你想的和需求的不一样的错误，或是你想的过程是错误的等一系列问题，JUnit都是无能为力的。不过，有了自动化的单元测试总比没有要强，不得不说JUnit还是帮助我检查出了一些手抖等因素导致的错误的。
在这个单元，由于有了JML的帮助，还有一些更高级的工具链可以帮助我来进行测试和检测。不过由于有些工具链年久失修，使用体验确实不尽如人意。首先说OpenJML，这个工具链它只帮助我进行了静态检查，一动态就冒出各种奇奇怪怪的报错，心态很崩的。再说JMLUnitNG，这个听着功能确实是一个好东西，可以根据你的JML规格自动生成测试用例并进行运行，最后给你反馈测试结果。不过，似乎天下没有那么好的事情，这个自动化测试经过我的多次尝试观察，生成的用例全部都是极端边界情况，比如int给你输入个-2147483648，传入对象就给你来个null。所以这个测试方法确实帮助你把边界情况的测试覆盖了，可是基本功能和正常数据还是需要自己想其他办法来解决。
总的来说，第三单元我接触学习了大量自动化的测试方法和既有的工具链。通过这些工具链确实可以帮助我们减少测试的工作量。不过为了更好的测试效果，仅仅靠这些自动化的测试还是不够，还要自己仔细考量做出有针对性的测试。
-
第四单元
第四单元，测试方面我倒觉得没什么特别多学习的地方，但是我真的学到了很多架构方面的设计。其实测试不就是在补漏洞，可是如果从建设的时候开始就没有留下漏洞（当然这是不可能的，只是说很少或是比较明显的），那么测试方面自然会减少很多工作。
而架构这一层面，决定了整体的漏洞多少。所以在第四单元的作业中，我可能将之前作业中用在测试部分的时间转变为设计架构的时间，最后测试虽然用的时间不多，但是最后的强测结果却比之前用很长时间测试的作业还要好。这真真的是体现出了架构在整体质量的提高上的不可替代的作用！
第四部分——课程收获总结
回顾这一个学期的OO课程之旅，辛苦之余，还是收获满满。重要的是，这些收获不仅仅是面向对象程序设计方面的专业知识，更有一些比专业知识更有价值的体会和感悟。
总结为3点：
- 首先，专业知识上肯定是有巨大的收获和能力的提升。作为一个在寒假还是进程线程傻傻分不清、OO两个字母缩写傻傻不知道的小白，经过一个学期和老师助教们的学习，我了解了很多JAVA容器的使用，JAVA多线程这么高大上（以前这么觉得，现在依旧觉得还有很多东西需要继续探索）的东西也都初步掌握了，还有JML的知识，UML的知识。感觉这一个学期学到的知识真的很多很多，密度很大。这也许就是OO课高强度训练的结果吧
- 其次，我觉得这一个学期学到的这些知识，不仅仅可以用在OO课上，我在OO课上学到的知识对我的很多其他课程的学习也有很大帮助。这也许就是OO课的高度，从一个思维方法入手，而这个思维方法可以运用到很多领域。举个例子，多线程部分的程序设计，讲了锁的运用，同步的控制等等。等到了操作系统，诶，这不正是OO课学到的吗？等到了课外的一个项目，诶，这OO课学的让我能看懂代码了。再举个例子，层次化设计的思想。这个思想在之前没怎么仔细想过，但是现在学过之后发现这个思想岂不是一直在被频繁使用只不过之前不知道。计组的一层层的模块，和OO的层次化设计异曲同工；操作系统的一层层调用封装，和OO的层次化设计同宗同源；就连经济管理概论的学习中，都不时发现层次化设计的身影（项目管理中的WBS、生产系统中的CIMS都是层次化设计鲜明的体现啊~）。可见在这门OO课中学习到的知识不仅仅运用于OO课本身，更是对生活中一些其他事情的指导。
- 最后，说一点专业知识之外的收获。这一趟OO之旅真的是训练了我不少的能力。面对困难复杂问题的分析解决能力、中测wa掉后分析问题找到问题解决问题的能力。当然这些也许还和专业能力有所关系，那么最重要的也许就是得失心的一个锻炼吧。有的作业，辛辛苦苦认认真真写了好几天，测试也做了不少，但有时就是一点小小小小的疏忽导致了强测爆炸，也就代表着这几天的辛苦倒也不能说白费，只能说在分数上无法等值兑换了。那么面对这种情况，又能怎么办呢？要说工作量，也真是做了不少，但是这个小小小小的问题不也是自己写出来的，测试也没有发现的么？那经历了这些，就要有经验有教训，更要有一个良好的心态来面对生活中的一切问题和困难。OO课只是生活中的一小小小小部分，相比与其他更重要的事情来说，可能也是微不足道的。但是，能通过这样一门课来收获这些经历和教训，不也说是一种幸运？
第五部分——改进建议
- 首先，就我自己而言，感觉OO课的这个难度递进有点不太对劲。给我的感觉，从第一单元到第四单元难度逐渐降低，这让刚开始入手的我有点难受。也许有人会说是经过不断的锻炼和学习我才会觉得越来越简单，但是我最近重新翻出第一二单元的作业看了一看，发现依旧觉得不简单，做起来不会有之后这样顺畅。所以本人建议可以适当调整一下整体课程的难度递进顺序。（每个单元内部的难度递进本人感觉很合理）
- 第二点，希望可以在中测阶段给出更好的辅助手段来检测自己的CPU时间、运行时间等等本地和评测机有可能会有显著差异的指标，比如开一个界面来检测提交程序的CPU时间等。但是，我知道网站的承载能力有限，评测能力有限，所以可以给每人分配一定的次数来控制提交次数。感觉这样可以更好的避免CTLE等问题（尤其是在多线程部分，感觉本地和评测机时间还是有肉眼可见的差别的）。
- 第三点，就理论课给出一点建议。感觉理论课老师讲的很好，听的同学也都能听懂，但是似乎感觉学到的总是无法应用在作业或是实验等实践中。理论课所讲确实是很顶层，有为整个软件工程的思想做介绍和讲解，但是希望能结合一些更实际更细致的例子或是工程进行讲解（这学期的理论课中也有很多例子，但是这些例子中有些过于抽象或简单，无法体现到复杂软件时该怎么用怎么办），让我们这种初学者可以更快更直观的理解和应用这些知识。
第六部分——线上课程体会
疫情原因，这学期的课程都改成了线上课程，OO课也是。原本我以为这种线上课失去了与老师面对面的机会，会导致学习效果下降，问题得不到及时解决。但是等到开课以后，发现事实并不是我想象的那样。老师们精心准备了录播课程，让我在听课的过程中，几乎不会产生什么疑惑。更棒的是，老师们会在录播课中留一些思考题，课后我们可以在微信群中和老师探讨学习。我有好几次回答的问题经过老师的教导和改正，感觉收获很大，对当堂课程的理解也更加深入，感觉这个思考题的设置非常棒！
当然，线上课程还有一些通用的好处，比如可以重复观看，可以回看等等。说实话，感觉即使返校上课也可以继续沿用线上课程的一部分形式，比如思考题等，这样可以更好地提升同学对课程的理解与吸收。
总结
一学期的OO课程结束了，确实是名不虚传。不过虽然辛苦，但是学到的也确实很多。感谢这一个学期来辛苦付出的老师和助教们。虽然疫情原因无法返校，但是老师们仍然精心准备录课，助教们也耐心地为我们解答问题，在此表示由衷的感谢~