面向对象第四单元（UML）总结体会&课程总结

1、第四单元两次作业的框架设计

两次作业的框架设计是一脉相承的，第14次作业完全继承了第13次作业类中的方法。

通过对UmlElement类的分析，直接将前一次作业中涉及到的9个类在构造方法中便分开并单独存放，即分为了9个HashMap

​ 因为一开始对查询需求没有做过多考虑，后续发现这种分离方式在一定程度上使查询结果复杂化了，而一些结构也可以使用ArrayList代替，而不会增加时间复杂度。

​ 在另一方面，为了存储查询过程中涉及到的中间结果，建立了ClassDate类来存储，其内部主要数据结构如下：

    private int operationFlag;
    private int operationNum;
    private int paramOperationNum;
    private int noParamOperationNum;
    private int returnOperationNum;
    private int noReturnOperationNum;

    private int attributeFlag;
    private int attributeNum;
    private int attributeMapFlag;
    private HashMap<String, AttributeClassInformation> attributeMap;

    private int associationFlag;
    private int associationNum;
    private HashMap<String, String> associationMap;
    private ArrayList<String> associationList;

    private int interfaceFlag;
    private HashMap<String, String> interfaceMap;

​ 其中xxxxFlag代表此大项的数据结果是否被算出，而内部的数据结构则记录具体的数目，自身名单以及包含父类的名单。在调用每个类/接口的查询方法时，初次查询，创建相应的ClassDate类，而查询相应数据时，将其中的数据结构中的内容逐一完善。

而第14次作业在第13次作业的基础上，仅仅是构造方法中的HashMap结构变多了，将所有有用的类单独存放，而在查询中没有用到的类则直接舍弃，不会存入结构体中。

2、四个单元中框架设计及OO方法理解的演进

​ 在前期的过程中，由于受到面向过程编程的长期影响，在代码框架设计上并没有很多的理解，将Class看作是实现所有函数的集合，而将所有需要实现的函数，均加到同一个Class中，没有关注到代码的耦合性过大。

准备阶段

昨夜西风凋碧树，独上高楼，望尽天涯路

​ 在之后的框架设计中，我更加注重了框架设计，在之后的作业中，有因为框架合理而后续作业几乎不需要改动的情况，但也出现了其他的问题。例如：在第一单元最后一次作业中，由于前期没有建立好良好的数据结构，对于层次分析的方法也不甚了解，最后靠两天的完全空想完成了“有限状态机”+“表达式树”的方法，并且其中包含了大量的接口继承。我同时和一些同学讲述了这种方法，但自己其实没有实现出具体的细节，仅仅是一个前期的框架。吴际老师在总结课上说的，所有没有具体实现的框架都是没用的，最简单的验证方法就是"show me your code."。我对这句话的感触很深，在自己没有思考清楚的情况下，给别人去讲述自己的方法，简直是害人害己。

酝酿阶段

衣带渐宽终不悔，为伊消得人憔悴。

​ 第二单元的多线程调度，是对框架设计的一次很好的练习。由于对请求序列 / 总控制器 / 电梯调度器 / 电梯各自功能非常清晰。电梯仅仅充当一个根据主需求上下行的机器，而请求序列将所有请求加入总控制器，总控制器根据电梯的繁忙情况及现行状态，将其分配到各个电梯的分调度器上。其中的耦合关系较小，仅仅在传递阶段，各类分工明确。这三次作业是我充分认识到：一个好的设计框架在实际开发中将使你的修改事半功倍。

顿悟阶段

众里寻他千百度，蓦然回首，那人却在灯火阑珊处

​ 将之后的框架设计看作是顿悟阶段，其实是夸大事实的。只能说，由于在前两单元的摸爬滚打，在最后的两个单元作业中，我在写代码之前会更加注重 SLIOD原则。并且在实现过程中不直接和大家分享我框架的先进性，更多的还是细节方面实现的交流。

3、四个单元中测试理解与实践的演进

肯定

​ 四个单元的测试环节是非常重要的。测试过程是真正开发中不可或缺的一环，在前期没有JUnit单元测试的前提下，采取了肉眼测试的方法。通过阅读别人的方法与注释，感觉受益匪浅，从另一个角度看待了这个问题。

否定

​ 之后通过和其他同学的沟通交流，逐渐掌握了更自动化的方法，包括使用matlab进行对拍，使用正则表达式构造样例并使用shell进行测试，对比整个房间的结果。虽然一开始可以找到大量bug，但却逐渐怀疑这种方法的科学性：我们仅仅机械地构造了样例，却没有阅读别人的代码，更没有从中获取知识。

否定之否定

​ 厌倦了这种机械式找bug行为后，一次分享课使我受益匪浅。那位同学在通过自动化生产样例发现bug之后，会尝试在别人的代码中发现bug存在的原因，并尝试在5行之类将其进行修复。在修正完毕后，继续通过自动化样例测试修正后的程序，如此一来找出的bug便几乎不会出现同质现象。原来一开始的没有收获仅仅是因为自己的惰性驱使，自动化测试没有错，而使用自动化测试后没有勤加思考才是最大的问题所在。

4、课程收获与总结

​ 在经过一学期的操作系统课程后，逐渐了解了真正的产品研发的步骤。通过第一单元的表达式求导，了解到用户输入的正确性判断与录入；而第二单元的电梯调度与操作系统的课程内容完美对接，可以从原理角度与高级语言实际实现角度双管齐下，对线程概念有着更深的理解。第三单元的JML和第四单元的UML，一个用协议规范方法的实现，通过阅读规格定义便可了解代码的输入，输出，前提条件等必要内容；一个用图的方式实现了框架的可视化，使我们清晰地了解执行顺序和状态转变。

​ 但对自己还是有一些不满意的地方：原本计划读完读透的《Java编程思想》因为课业压力越来越大只能中断，而最后的几次代码也没有那么认真完成，摸鱼情况时有发生，到强测完毕才发现为时已晚。而对于Java底层运行时间和CPU时间等并没有充分思考他们与时间复杂度之间的关系，如何在保证程序正确性的前提下，将程序的CPU占用时间降低，需要以后更多的学习和思考。

5、课程建议

​ 我认为今年的面向对象课程进行巨大的变革后，确实使同学们的满意度大幅度提高，但还是有部分地方有所欠缺。

• ​ 本学期面向对象的课上测试部分，基本上没有什么体验感，除后期几次难度适中外，前期要么涉及到刚刚学到的知识点，要么工作量过大导致无法完成，还有少数几次不知所措（多线程调度观察）。希望可以充分考虑课上测试强度和其意义，将课上测试的机制做得更加完善。

• 在指导书发布阶段，尽量少一些模棱两可的解释和例子，尽量细致，避免看完指导书还是不明真相的现象发生。

• 在涉及到多线程，UML等重要知识时，由于涉及的知识量过大，建议课上之前便发布一些简明扼要的知识点概括，或者明确告知下次测试将涉及到哪方面的知识。对于一些软件的使用，由于网上的方法多而杂，建议推出符合教程需求的教程。

  老师和助教对本课程的努力改善有目共睹，期待下届的同学能在这门课中收获更多，乐趣更多！