第四单元架构总结
第四单元围绕UML解析展开，第一次任务要求同学们实现类图的构造和查询，第二次加入了时序图和状态图，第三次任务添加了错误和异常的判断。解析器提供的UmlElement是独立的，但是根据UML语意可以确定出他们之间层次结构关系。我本次采用了封装的思想进行建模，先根据底层逻辑封装自己的元素类，并进行建模。等到指令查询时，只需要针对现有的模型进行分析。
-
第一次作业中：为了满足指令需求，我将官方包中的一些需要用到的类设计成了自己的类，比如MyUmlClass等。在自己的类中将各种继承关联关系等由id转换成具体的对象，提高了查询的速度。用HashMap存储可以将id和对象进行一一对应。
-
第二次作业中：将状态图和顺序的图的架构加入，相对较难的是寻找“关键节点”，主要方法也是使用两次DFS，从初始状态开始将要查询的结点作为参数传入每一次递归，如遇到该结点则跳过对该结点的递归，在递归中再判断是否到达了最终状态。
-
第三次作业中：我对于新增的9个查验规则单独设置了9个类，使用起来很方便，也避免了Myimplementation的重构。起初，在重复继承的语意理解中遇到不太明白，和同学讨论后清晰。实现的方法是不断向上递推，记录已经继承的类，若发现重复，则记录下来。
架构设计思维的演进
-
第一次理解“面向对象”的思维是在pre作业的过程中。当我风风火火快写完pre3，才突然意识到自己基本全部是按照“面向过程”的思路去写的。看了同伴的代码，才有一些明白。故进行了重构，也第一次认识用“面向对象”的思维贯穿架构设计的重要性。
-
由于pre得来的经验，我在第一单元表达式求解的过程中，非常注重架构设计。每次作业一发下来，都会花上几天进行理解与构思，和伙伴们讨论，只有差不多完全想清楚了才会下笔。设计的架构具有良好的扩展性，有时也会进行一些超前设计，锻炼了我的全局性思维。
-
第二单元电梯月中，虽说重点偏向了多线程，但作业的灵活性很高，架构设计仍是需要好好考量的问题。我将多线程的思想融入了架构设计的分析，比如将需要保护的几个共享变量单独作为一类等等。
-
三四单元中，侧重点在JML和UML的理解与实践，架构方面限制的比较死，所以这两章的作业中架构设计的观念反而有所退化，更加注重了具体算法的实现。
关于测试
-
在OO课程中，我第一次学会了完整地书写评测机，很开心。
-
在第一单元中，从讨论区各种评测机搭建的帖子中，我照猫画虎，书写着随机数据生成器，逐渐掌握了门道。答案校验方面，由于第一单元“表达式求解”场景的特殊性，可以使用“sympy”的方式进行化解比对。虽说仍有一些可以不使用同伴对拍的方式直接比对结果，但我在第一单元也尝试完成了对拍器，进行简单化简后的比对。
-
第二单元的数据生成难度并不高，但难就难在电梯运行的验证过程。起初我借过同伴的评测机，学习他的验证逻辑，后面慢慢地在第二三次作业中，就自己完成了整套评测与验证，也帮我de出了非常多的bug。
-
第三单元随机数据生成与对拍的难度都比较小。但我在和伙伴对拍交流的过程中，发现我随机生成数据的强度是非常不够的，多亏了伙伴们合力互助，才不至于强测出锅。我也发现，身边不少同学，已经具备了手搓极限数据、各种分类情况数据、白盒测试的能力。感觉自己在这些地方仍有欠缺，希望在将来的学习中能有所弥补。
-
第四单元是真的很仓促了，前两次作业都在火热地准备冯如杯，第三单元又是烤漆之际，没有出现更多的bug只能说全是仰仗ygg的评测机了。
课程收获
一学期的OO课程，投入很多也收获了很多。
-
四个单元的学习后，我对于面向对象思想和层次化设计的重要性有了比较深刻的理解，并且能够利用其完成一些大型项目。同时，第二单元的电梯作业让我充分练习了多线程的编程技巧，对临界资源、临界区、共享、同步等概念有了更深刻的理解。抽象层面上，课程培养了一种全局性的思维，提升了我工程化迭代开发的能力。
-
另一方面，在写评测做测试的过程中，我学会了使用python搭评测机。在和伙伴对拍互测的过程中，bug虽苦但朋友很甜，也提升了我在很长的错误数据中定位debug的能力。
改进建议
-
我的改进策略是：告诉同学们形式化方法是可以被证明的。阅读之前学长的博客，尝试过OPEN JML等工具，但是可能由于机械化证明方法的局限性，表现并不理想。思考能否提供一些相对简单一些的函数，如：二分搜索（并没有仔细推敲这个用例是否合适），让同学们在提交代码的同时提交对于此函数的证明，即自己的代码如何保证了此JML形式化约束成立。
-
研讨课在今年实施改革，我在实际体验中还发现了以下两个问题，并提出了针对性的解决意见：
-
研讨课中一个重要的讨论话题是“架构设计”，可是以我自身的感受来说，架构设计方面，大家的重合度非常高，导致讨论的时候，第一个人说出他的架构，之后的人同学很多会直接表示与之前同学相似而无话可说；讨论完代表们汇报的时候，每一组的汇报内容有的时候也是大同小异。不是说完全没有收获，只是有大量的时间都是已有的知识在相互之间传递。
对此我的改进意见是：将“分享架构设计”这个话题转变成，讨论与当次课演讲者分享架构之间的差异。这样既可以督促同学们更加认真地倾听演讲者的发言，理解他的架构思路，又可以减少许多不必要的同质化讨论；“分享架构设计”部分缩减后，我认为每次研讨课可以增加一些启发性的、真正需要同学们在一起研究讨论的问题，我姑且暂时想到了以下两种形式：
-
本次课课程内容的延伸——不如一些课上略微提到但是有些深入不要求大家一定掌握的知识，可以放到研讨课让同学们相互讨论/查资料，共同探讨（举个例子，关于线程安全的延伸思考）；
-
在本周完成OO作业的过程中，你有些什么独属于你的经验（碰到了一个离奇的bug并如何修复/因为某些巧合，对某些知识点有更深刻的理解等等），这甚至可以成为每次课的一个保留环节，毕竟大家真的都很有创造力。
-
-
现在的小组讨论，更像一种“轮流发言”，真正的“对话回合”其实不多。我认为主要原因是每次课的小组成员之间很可能并不熟悉或者才刚刚认识，讨论气氛比较尴尬。在这样的氛围下，我感觉很难真的产生激烈的讨论，大家更像是“相敬如宾”地听每个同学发言，如果有没有听清楚或者不太理解的地方，有时候也不会主动提出，可能就任凭问题过去了。
对此我的改进意见是：将这个讨论小组的功能扩展化，让它不仅仅是一次讨论课的学习小组，而是整次OO作业的学习小组。即从作业发布开始，大家就可以互相讨论架构，在编程中遇到的问题可以互相解决，可以一起写评测机造数据，一起debug。整个学习过程不再是每个同学的小圈子，而是通过OO课程随机分配的学习小组，打破固化的圈子，认识更多的同学，大家在一起互相学习。
-
