本单元的架构设计总结：
本单元的作业在架构上与上一单元其实有些类似，尽管不是根据JML语言复现函数功能，但为了满足接口中函数的种种要求，仍然需要尽可能灵活的一一复现。由于本单元的测试要求中没有再出现构造指令远小于查询指令的情况，也不用预存矩阵计算最短路径什么的，所以能在函数内完成的功能我就直接写到了函数内，这也间接造成了第二次MyUmlGeneralInteraction类过大。我来来回回改了很多代码共用方面的细节，但是还是没办法在500行以内解决问题，从而损失了代码风格分。后来想想这就是典型的设计问题，过于关注代码work与否，反而在写的时候丧失了统筹安排的意识。
除了本次要实现的主类，我还使用了myasso类来表示关联，将associationend信息一并存了进去；使用了myclass来表示类以及其属性等信息；使用了myinterface来表示接口以及其中的operation；使用了myoperation连带parameter进行存入；至于状态图以及顺序图，则各有对应的mystatemachine与mytransition进行存储。（以上命名会和类图中有些出入）
以下为第十四次作业的类图：
BUG：第一次出现了审题不清的问题，在检查类属性隐藏性的功能中，没能理解所加类名的含义，所以输出的时候全按照输入的classname输出的（实际上应该是继承自谁的属性，是public，就输出那个类的名字）；第二次的两个错误分别是未考虑无finalstate的状态图类型以及UML008检测在某种情况下会出现死循环。总体来讲和原来的老毛病一样，测试不充分。这也算是贯穿本学期课程作业始终的问题，虽说这两次错的点并不多，但是仍然尝到了苦头。
四个单元中架构设计及OO方法理解的演进：
在之前的学年中，由于自己实在是对Java掌握的不好，所以早早掉队，今年重修刚刚开始的时候，为了不出现同样的问题，我把Java恶补了一番。这也算是我对OO课程的最原始的印象——Java语言的理解与使用。这样的看法与课前准备确实让我收益颇丰，至少第一单元的作业做起来顺当多了，虽说因为“输入检测”、“多项式化简”等这样那样的问题导致第一单元得分不是很理想，但是也算是成功的度过了对我来讲最为煎熬的第一单元。
到了第二单元，我慢慢的体会到所谓的Java理解与使用太过片面，本课程的核心“设计”的味道逐渐明显。从架构上将，这一单元其实是有固定的正解的，每一次作业只需要采用最合适的多线程同步模式，根据这种模式设计出的电梯就不会有太大的问题。这看似限制了自由度，但其实对于我这种对多线程控制比较生疏的学生来说反而提供了指引。我只需要认真读明白推荐书目里的相关设计模式的思想，安排好需要几个类需要几个方法即可。这也从侧面说明了一点，好的架构好的设计能够给coding的过程减轻很多的压力，节约很多的人力或时间成本。
第三单元对于设计的强调则更加明显，根据JML语言设计好规格与接口，然后进行复现。我在头两次的作业中没有理解自行设计的含义，只是单纯的读接口，“翻译”成Java代码，扔到函数中去，测试work与否。这样做的结果就是头两次作业疯狂超时……直到第三次作业下发后，在做之前与应届的同学交流了一下，才做了比较良好的设计，拿到了本单元第一个满分。最后到了第四单元UML，设计已经成为了我写代码之前必不可少的部分，有时候感觉思考与设计的时间要比coding和test的时间加起来都长。
这四个单元下来，我对这门课程的看法从编程语言的使用变成了如何去实现更好的设计，这也改变了我对于软件开发的看法：用什么语言，用什么算法都不是最重要的，重要的还是在设计中体现出整洁与优美。好的设计下的代码自然是可控的，自然是差错少的。
四个单元中测试理解与实践的演进：
通过这个学期对OO的学习，我对软件开发的测试环节的重要性有了更深刻的认识，虽然到最后，我仍然在测试这一环节比较薄弱（脑子不好使，测试用例构造的总是太简单），但是仍然获得了一些进步，尝试了许多的方法。其中比较典型的有Xeger生成符合正则表达式的输入的方法（主要应对第一单元），junit单元测试（第三单元），openjml规格化测试（第三单元）。
在互测的过程中，我更多的是抱着学习的心态去阅读代码，也学习到了其他同学的设计思路。虽说阅读代码是最根本的发现细微BUG的方法，但是效率的确是比较低的。读别人的代码有的时候时间很消磨耐心，很痛苦的过程，更好的方法还是准备足够充分的测试用例直接跑。所以个人体会，还是要更多的构造测试用例，用Junit这样的方法进行测试。
课程收获：
一学期的面向对象课程结束了，作为重修生，这一学期我付出了很大的努力，也突破了过去的自我。最后拿到的成绩如何尚未可知，虽然其中仍然有些遗憾（某几次作业可以做的更好），但总体来说我的努力还是得到了相应的回报。收获主要有以下几点：
代码风格：从最开始的先写再改到后来写的时候就把格式写对，可以说，缩进，驼峰命名等细节已经完全渗透到了我的编程习惯中，这应该是最外在的一种收获。
编程能力：这点更是无需多言，无论是从对Java语言的使用还是对一些只是从前学过但从未自己实现过的算法的实现，本课程的assignment一次又一次的推动我去学，去练，去使用。对比半年前，我的编程能力可以用“更快更准”来形容。
架构设计：设计永远优先于编码，错误有一半是来源于设计不周。经过这一学期，我完全理解了这句话。软件开发并不是一个用算法解题的过程，用算法解题重在结果，结果对就是没问题的。软件开发像盖房子，解法不唯一，但没有设计一层也建不起来。如何“不造危楼”，如何“造的美观”，这些都需要良好的设计才能达到。
反思与总结能力：很少有课程会在迭代式作业进行的同时穿插博客作业进行反思，我从这一制度中收获良多，也养成了一些总结的习惯。只有经常回望的人才能更好的往前走，于软件开发是这样，于任何其他的学科也是这样。
改进建议：
首先非常感谢老师和助教们这一学期的耐心指导与辛勤付出，本学期的OO课程在授课内容以及作业布置上都非常的合理，在此基础上我只能提出一些简单的建议，希望能作为参考。
在作业对CPU时间或者运行时间有要求时，最好提供一个评测机的接口让学生能够提前模拟一下。本地的测试环境并不能与评测机完全相同，做的时候没法参考，只能默默地自己降低时间复杂度，然后安慰自己all is well……
上机课程时间需要重新编排。一般来讲，上午上的课程，下午就消化吸收并应用，这是件非常困难的事，不太符合教学的规律（或许只有文科的知识点可以这样的考察）。我们这学期将这样的制度贯穿始终，搞得每次上机的时候都非常的狼狈。回顾课件，读题干，百度不理解的知识点，完成任务。这一套工序几乎让人没法在有限时间内应付过来。所以我希望这门课程实验课单双周能够交换，研讨课先行，研讨课内容老师或助教也做些准备，这样对于学习来说更有帮助。
另外还有一点（可能说的不对），个人认为最后一单元的作业在编程上与UML的学习贴合的不太紧。我们通过自设计函数完成了对UML图的分析，这也是课程组对学生的期望。实际上第四单元编程作业我们并没有用什么新的设计模式，新的构架，而只是在用前三个但愿积累下来的知识做了两次应用（临近考期，工程量还很大）。为了学习与UML相关的知识，理解其中的各个元素，我认为向第七次实验那样，绘制UML图去模拟软件场景会比我们的这些编程作业要更贴近一些，也更有利于学习UML。