OO 第四单元总结
OO 第四单元博客
提纲
- 总结本单元作业的架构设计
- 总结自己在四个单元中架构设计思维及 OO 方法理解的演进
- 总结自己在四个单元中测试理解与实践的演进
- 总结自己的课程收获
- 立足于自己的体会给课程提三个具体的改进建议
本单元作业架构设计
本单元的主题为 UML 解析器，要求对 UML 类图，顺序图和状态图进行基本的查询和合法性检验。后两次作业的架构设计分别如下图所示：
第二次作业：
第三次作业：
由于本单元的作业为迭代开发，故直接总结第三次作业的架构中核心类的功能：
ElementCollection类：该类是所有 UML 元素的集合，以及相应的 getter ，但现在回过头来细想，这个类的设计太过臃肿ElementSearcher类：该类是对 UML 元素之间关系的处理，以及查找元素的方法，如通过 id 查找元素、在特定的元素中通过 name 查找元素、找某元素的 parentId 对应的元素等Counter类：该类用于处理对目标元素类型次数的统计MyImplementation类：该类用于实现前两次作业中关于类图、状态图和顺序图的查询指令RuleChecker类：该类用于第三次作业中实现正确性检查的指令
架构设计思维及 OO 方法理解的演进
第一单元
第一单元的主题是解析表达式，并将其展开和化简。在第一单元尚未建立起良好的面向对象编程思想时，我的代码耦合复杂度非常高。虽然第一单元层次化的特征十分明显。但我也仅仅做到了数据层面的抽象，将不同的 Term, Expression，单独建立。但未做到行为层次的抽象，既没有把控制逻辑，查询逻辑，操作逻辑等等单独包装。而是将其一股脑的塞进了与之相关数据类中，并未实现最小职责等基础思想。这导致我想替换算法，或者改进逻辑时，往往需要重构整个流程。万幸的是，我也在第一单元学习到了工厂模式，这为后来其他单元的设计打下了良好的基础。
第二单元
这个单元的主要目标是通过模拟电梯来理解多线程。相比于第一单元，多线程编程中不仅要考虑之前的问题，同时也要考虑线程安全问题。在开始这个单元的工作之前，我花了比较多的时间去了解什么是多线程，java 中多线程的实现等。在第一次作业中，需要重点考虑的是策略，就是如何实现捎带。第二次作业由于每一座/层有多个电梯，因此需要加入调度器进行调度。第三次作业中加入了换乘和横向进出限制，需要再对电梯和调度器进行修改。
在这个单元的学习过程中，我一开始没有搞得很明白，在很多地方都加 synchronized 和 notifyAll，直到有一次我的电梯出现了不断阻塞又唤醒的行为，消耗了大量时间，于是我又去仔细学了一遍，弄懂了其中的原理。
第三单元
第三单元的主题为依据 JML 规格编写代码，初步接触契约式编程。这一单元的整体架构基本上由课程给出，自己只需合理地设计网络以实现更高效率的查询。例如，为了提高对连通分支数的查询效率，新建了并查集类，并基于并查集建立了相应的 Block 类，用以记录相关的属性。到了第三单元，对于面向对象编程思想的运用已经比较自然了，能够自然地考虑到实现工具方法的解耦等。本单元的主要收获为对 JML 规格的认识以及契约式编程的相关知识。
第四单元
第四单元其实是为了让我们能够对 mdj 语言有更好的理解。对于开发团队的层面来说：有利于队员间在各个开发环节间确立沟通的标准，便于系统文档的制定和项目的管理。因为 UML 的简单、直观和标准性，在一个团队中用 UML 来交流比用文字说明的文档要好得多。对于各个开发项目来说：可以通过 UML 共享开发经验和资源。uml 只是面象对象分析、设计思想的体现，和具体的实现平台无关，用 UML 建模和设计的系统可以用 JAVA 或 C#来实现。除此之外还可以做为系统分析设计过程使用的表示和体现工具。
测试理解与实践的演进
实话实说，由于本人能力欠缺，前两个单元都并未采用自动化测试来验证自己程序的正确性。而是主要采用手动构造测试数据 + 肉眼判断正确性为主，不但费事低效而且还有覆盖性不足、测试量不够等问题。
后两个单元由于难度下降可以通过对拍进行验证，因此我写了自动生成数据 + 批处理比较两文件输出进行测试，相对于前两个单元确实高效而且可靠。这样做的好处是测试量提上去了能够发现很多细小的 bug，但覆盖性仍然不佳。
不过在学习的过程中，我逐渐明白了软件中测试的重要性：软件测试整体是验证功能的实现、可用性，检查程序的错误，最终目的是为了确保软件的质量、确认软件以正确的方式做了所期望的事情。除此之外，在测试的过程中还要遵循测试的原则。
课程收获
- 学会 git 进行简单的代码管理。通过 OO 以及 OS 的课程，我对 git 工具从一无所知到熟练的使用，这大大的增加了我对代码的管理效率甚至是工作效率。
- 积累了写博客的经验。OO 课程的博客也算是我第一次写博客的经历，让我在总结一个单元的学习过程的同时也学习了博客的书写要求和技巧等。
- 对架构设计的重要性有了更深刻的认识。一个优秀的工程或者项目，需要经过多次的迭代开发。一个良好的架构是一切的基础，在拿到需求后，需要认真进行理解并合理地认识到各个板块的需求和作用，给出了合理的架构设计之后再动手写代码。编写代码的过程中再不断思考如何改善架构。架构的可移植性，可扩展性，性能复杂度等等都是需要考虑的。
- 学习 JML 了语法，实现契约式设计，同时也学习 UML 统一建模语言，能够画图并理解各元素之间的关系。对于 JML ，虽然个人认为之后并不会在用到它，但这一形式化描述的语言还是让我对契约式设计有了更深的了解，同样 UML 建模语言的学习使得我在对项目代码的设计能力有所提升，而不再局限于代码编写能力范围内的进步。
- 除此之外也学习了许多相关的知识。比如多线程运行机制，多种设计模式，复习图论、堆栈、prim 算法、dfs 、并查集等没有在数据结构中学好的各种知识等。
改进建议
- 后两单元的强测时间公布可以提前一些。个人认为，前两单元不当天公布强测结果是因为第二天有互测，所以没必要公布。但是后两单元没有互测，个人认为没有必要再隔一天公布强测结果，毕竟正值期末，bug 修复还是能够提前弄完较好。
- 学习第三单元内容的个人感受。实话实说，JML 虽然确实是一门很好并且很优秀的形式化语言，但在这一单元的学习中我感觉学到最多的并不是 JML，而是关于图和树的数据结构和算法，而且对 JML 的学习中也是耗费大量的时间去理解这一语言的少部分内容。这一点表现最为明显的就是网上可参考的资料极少，我不清楚在业界或者哪些地方在发展 JML 语言。在学习的过程中，我感觉在完成 OO 这门课之后，我以后都不会再遇到这门语言，这使得我对它的学习的意义有所减弱。
- 可以为有兴趣的同学给出测评机搭建教程，培养自主测试能力。做测试无疑是很重要的一个环节，但是不论是在课堂上或者是指导书中对测试尤其是评测机的构建的指导很有限，而在个人能力有限的情况下，例如我自己造的测评机数据往往不够理想，不够全面，最后把搭建的评测机丢掉去手动构造。
