OO_Unit4_Summary
本单元作业的架构设计
UML类图
UML顺序图
UML状态图
由于gitlab上已经给出了各UMLElement的组成，我们只需对需要查找，或者查找中需要用到的元素自定义一个类管理这些Element，其他元素直接使用课程组给出的定义。
本单元作业的代码设计可以大致划分为两个阶段，先根据输入的UML图建立一个完整的关系网，在MyImplementation类中建立总表，存储读入的UML元素；第二个阶段是查询，根据查询内容的不同，可以将查询指令分为两类，一类可以直接通过查表得到结果，还有一类指令需要通过上层类到下层类的逐级查询返回结果。对于合法性的检验，设置9个变量对应9个不合法情况，当判断为不合法时抛出异常，9种情况包括可以直接查表得到的及需要进一步查询的，如循环继承和重复继承。
本次作业的结构如下图所示
本单元作业的类图如下：
四个单元中架构设计思维及OO方法理解的演进
第一单元
刚刚接触面向对象，尽管已经经过pre的训练，但是并不具备建立良好架构的能力，尽管选取了相对友好的预处理模式，但我仍然只是用面向过程的思路分析问题，认为只要根据表达式的结构建立相应的类就实现了面向对象的要求，这样的话没有好的架构，导致项目实现起来非常困难。在这单元的作业里，我根本没有仔细思考过架构问题，一直是写一行算一行的状态。
尽管如此，做完四个单元我还是觉得第一单元是oo最难的单元，第一次作业幸运地卡点提交，后面两次作业也是度过不少难熬的夜晚勉强完成而且性能分很低。
第二单元
电梯单元我认为没有传说的那么恐怖，这单元的架构设计很大一部分要归功于实验课的代码，初次接触多线程，免不了需要在解决死锁、轮询等问题上花功夫，好在实验代码提供给我足够多的思路，两周时间也足够去完成第一次作业了。另外，多线程对架构的要求相对更高，良好的架构可以将并发的线程逻辑梳理清楚，正确地绘制时序图也能帮助我们有更清晰的架构。
第三单元
第三单元JML，这一单元可以说纠正了我们在前两个单元中的坏习惯，帮助我们形成良好的架构和良好的代码编写习惯。这一单元中，每几个类之间协作工作，共同完成构建一个功能完备的社交网络。
第四单元
这个单元的理论课和指导书已经帮助我们了解了UML类图、顺序图、状态图的结构，本次单元作业的架构设计就是模拟一个完整的UML图结构，另有一个类用于管理这些对象以便查询实现交互，这一单元的架构也不成问题，同样地，每个类之间能较好地协调，不同对象相互协作，保证UML解析的结构清晰完整。
总体来看，四个单元对的架构设计的引导性实际上是持续增加的，但前两个单元的作业也对架构有较高的要求，可能这就是先苦后甜的道理把。
测试理解与实践的演进
第一单元前两次作业都是几乎压线完成的，强测和互测就是我的测试，找到了不少bug，很开心。第三次作业的功能在第二次作业就实现了，主要还是手动构造边界数据，遗憾没有使用单元测试，要是在第一单元进行单元测试，我想测试效率和强度都将大大提高。
第二单元的测试先是采用简易的评测机实现基本功能测试，但我的评测机的数据是完全随机的，没有考虑指令间的依赖关系，是不完备的。基本功能的实现没有问题之后，主要是进行特殊数据的构造防止死锁，构造如电梯运行时中断输入人为构造空窗期、横向电梯没有符合条件的楼层需要多次换成的数据。第二单元没有挂强测，测试效果不错。
第三第四单元的数据要么量太大要么不便构造，除了第三单元用了单元测试和针对部分高复杂度指令的特别测试外，都借用了同学的评测机进行测试，由于愚蠢的性能问题，第三单元TLE了几个测试点，说明测试的强度是不够的，只能考虑正确性而忽视了性能。
课程收获
oo课程作为大学生涯来第一个需要自己完成项目的软件代码课，大大提高了我的代码能力，至少能够实现真正用程序去解决一个实际问题，当然这也归功于指导书撰写得很详尽。此外，oo课程帮助我形成了良好的架构意识和较为美观的代码风格，在遇到问题时懂得去分析问题，理清思路，而不是闷着头上去做一通，能写出来一点正常人能够读懂的代码了。
三个具体的改进建议
改良课程安排
相信很多朋友会提出调整一二单元和三四单元的顺序之类的建议，然而细想一下，在期末周完成表达式解析和电梯这样的大型任务显然是不现实的。我觉得可以适当改变pre的内容，将第三单元的内容提前，提前学习一些JML的知识，课程组以JML的形式引导同学们完成pre任务，相对分摊一下开学初期的任务，适当延长作业时间。
适当更换训练代码
第二单元训练的代码与作业的关联太紧密了以至于很多同学出现了重复率过高的问题，第一单元训练对作业的帮助又有点太少了，需要同学们自己摸索的东西太多。可以适当调整一下内容。
修改互测模式
