Architecture design of this unit summary:
Operation of this unit on architecture and the unit is actually a somewhat similar, though not function according to JML language reproduction function, but in order to meet the interface requirements of a variety of functions, still need to reproduce one by one as flexible as possible. As the situation is far less than the query instruction of the test requirements of this unit does not reappear configuration instructions, do not have pre-existing matrix to calculate the shortest path or something, it can be done within the function function I have written directly within the function, which also indirectly led to second MyUmlGeneralInteraction class is too large. I changed back and forth many of the details of code sharing aspects, but still no way to solve the problem in less than 500 lines of code so that the loss of style points. Then I think this is a typical design problem, too much attention to the code work or not, but at the time of writing lost the sense of co-ordination arrangements.
In addition to this secondary main class implemented, I also used to represent the class myasso association to exist inside a associationend information; myclass used to represent the class and the attribute information; myinterface used to represent the interface and operation therein; myoperation be used jointly stored parameter; as a state diagram and a sequence diagram, and the each corresponding mystatemachine mytransition stored. (Named above and class diagrams will be slightly different)
The following is a class diagram of the fourteenth operation:
BUG: first there is a problem of moderation is unclear, hidden in the functional check class properties, did not understand the meaning of the added class name, so that when the output of the full classname output in accordance with the input of (should actually be inherited from whose property is public, it outputs the name of the class); second two errors are not considered no finalstate state diagram types and UML008 will detect an infinite loop in some cases. Generally speaking and doing it the same as the original, the test is not sufficient. This could be considered throughout this semester course work has always been a problem, although the wrong point of these two is not much, but still tasted the bitterness.
Architecture and design in OO way to understand the evolution of four units:
在之前的学年中，由于自己实在是对Java掌握的不好，所以早早掉队，今年重修刚刚开始的时候，为了不出现同样的问题，我把Java恶补了一番。这也算是我对OO课程的最原始的印象——Java语言的理解与使用。这样的看法与课前准备确实让我收益颇丰，至少第一单元的作业做起来顺当多了，虽说因为“输入检测”、“多项式化简”等这样那样的问题导致第一单元得分不是很理想，但是也算是成功的度过了对我来讲最为煎熬的第一单元。
到了第二单元，我慢慢的体会到所谓的Java理解与使用太过片面，本课程的核心“设计”的味道逐渐明显。从架构上将，这一单元其实是有固定的正解的，每一次作业只需要采用最合适的多线程同步模式，根据这种模式设计出的电梯就不会有太大的问题。这看似限制了自由度，但其实对于我这种对多线程控制比较生疏的学生来说反而提供了指引。我只需要认真读明白推荐书目里的相关设计模式的思想，安排好需要几个类需要几个方法即可。这也从侧面说明了一点，好的架构好的设计能够给coding的过程减轻很多的压力，节约很多的人力或时间成本。
第三单元对于设计的强调则更加明显，根据JML语言设计好规格与接口，然后进行复现。我在头两次的作业中没有理解自行设计的含义，只是单纯的读接口，“翻译”成Java代码，扔到函数中去，测试work与否。这样做的结果就是头两次作业疯狂超时……直到第三次作业下发后，在做之前与应届的同学交流了一下，才做了比较良好的设计，拿到了本单元第一个满分。最后到了第四单元UML，设计已经成为了我写代码之前必不可少的部分，有时候感觉思考与设计的时间要比coding和test的时间加起来都长。
这四个单元下来，我对这门课程的看法从编程语言的使用变成了如何去实现更好的设计，这也改变了我对于软件开发的看法：用什么语言，用什么算法都不是最重要的，重要的还是在设计中体现出整洁与优美。好的设计下的代码自然是可控的，自然是差错少的。
四个单元中测试理解与实践的演进：
通过这个学期对OO的学习，我对软件开发的测试环节的重要性有了更深刻的认识，虽然到最后，我仍然在测试这一环节比较薄弱（脑子不好使，测试用例构造的总是太简单），但是仍然获得了一些进步，尝试了许多的方法。其中比较典型的有Xeger生成符合正则表达式的输入的方法（主要应对第一单元），junit单元测试（第三单元），openjml规格化测试（第三单元）。
在互测的过程中，我更多的是抱着学习的心态去阅读代码，也学习到了其他同学的设计思路。虽说阅读代码是最根本的发现细微BUG的方法，但是效率的确是比较低的。读别人的代码有的时候时间很消磨耐心，很痛苦的过程，更好的方法还是准备足够充分的测试用例直接跑。所以个人体会，还是要更多的构造测试用例，用Junit这样的方法进行测试。
课程收获：
一学期的面向对象课程结束了，作为重修生，这一学期我付出了很大的努力，也突破了过去的自我。最后拿到的成绩如何尚未可知，虽然其中仍然有些遗憾（某几次作业可以做的更好），但总体来说我的努力还是得到了相应的回报。收获主要有以下几点：
代码风格：从最开始的先写再改到后来写的时候就把格式写对，可以说，缩进，驼峰命名等细节已经完全渗透到了我的编程习惯中，这应该是最外在的一种收获。
编程能力：这点更是无需多言，无论是从对Java语言的使用还是对一些只是从前学过但从未自己实现过的算法的实现，本课程的assignment一次又一次的推动我去学，去练，去使用。对比半年前，我的编程能力可以用“更快更准”来形容。
架构设计：设计永远优先于编码，错误有一半是来源于设计不周。经过这一学期，我完全理解了这句话。软件开发并不是一个用算法解题的过程，用算法解题重在结果，结果对就是没问题的。软件开发像盖房子，解法不唯一，但没有设计一层也建不起来。如何“不造危楼”，如何“造的美观”，这些都需要良好的设计才能达到。
反思与总结能力：很少有课程会在迭代式作业进行的同时穿插博客作业进行反思，我从这一制度中收获良多，也养成了一些总结的习惯。只有经常回望的人才能更好的往前走，于软件开发是这样，于任何其他的学科也是这样。
改进建议：
在作业对CPU时间或者运行时间有要求时，最好提供一个评测机的接口让学生能够提前模拟一下。本地的测试环境并不能与评测机完全相同，做的时候没法参考，只能默默地自己降低时间复杂度，然后安慰自己all is well……
上机课程时间需要重新编排。一般来讲，上午上的课程，下午就消化吸收并应用，这是件非常困难的事，并不符合教学的规律（或许只有文科的知识点可以这样的考察）。我们这学期将这样的制度贯穿始终，搞得每次上机的时候都非常的狼狈。回顾课件，读题干，百度不理解的知识点，完成任务。这一套工序几乎让人没法在有限时间内应付过来。所以我希望这门课程实验课单双周能够交换，研讨课先行，研讨课内容老师或助教也做些准备，这样对于学习来说更有帮助。
另外还有一点（可能说的不对），个人认为最后一单元的作业在编程上与UML的学习贴合的不太紧。我们通过自设计函数完成了对UML图的分析，这也是课程组对学生的期望。实际上第四单元编程作业我们并没有用什么新的设计模式，新的构架，而只是在用前三个但愿积累下来的知识做了两次应用（临近考期，工程量还很大）。为了学习与UML相关的知识，理解其中的各个元素，我认为向第七次实验那样，绘制UML图去模拟软件场景会比我们的这些编程作业要更贴近一些，也更有利于学习UML。