[OO] Unit4 Summary UML系列 暨 OO Summary

https://blog.csdn.net/ourfutr2330/article/details/106744912

@

UML单元总结

架构设计

• 由于UML系列的类图、状态图、顺序图之间彼此相对独立，故从第一次作业到第三次作业均使用XXXManager进行分包管理，源代码结构如下
  
• 由于官方包的UmlElement并不能维护UML间的成员组成关系，故采用适配器模式将UmlElemen转化为NodeElement，建立方便维护的数据结构
• 从UML类图上来看，MyUmlInteraction进行统一管理，将任务分派到三个Manager上进行数据管理，其中每个Manager都对规则检查模块PreCheckRuleManager有依赖关系，所有的Manager在对适配器Node进行构建时，都会使用PreCheckRuleManager进行检查，并将结果保存到其中，调用时才抛出异常
  

OO课程总结

架构设计与面向对象方法的演进

表达式系列

• 从面向过程到面向对象的思想转变主要是在这个单元内进行的
• 表达式系列三次作业的层层递进，每次扩展性功能的时候都需要修改大量代码，在这个地方我意识到保留一些扩展功能接口的重要性
• 此外，我的作业都是采用 Expression, Term, Factor 的结构设计的，但经过第一次博客总结后，我意识到 对于架构的设计不必局限与对应现实世界的实体，可以考虑尽可能抽象
• 利用组合模式进行设计，将组合项与项进行抽象，整体的架构设计能够拥有更好的扩展性，也就是抽象程度和扩展性更高

电梯系列

• 这个单元我的主要收获在于优化与架构设计的兼容性以及架构与性能的平衡
• 一个好的设计，一定是优化能够方便地建立在架构上，并且这样的优化策略能够很好地扩展
• 此外，这个单元中我开始对设计原则的满足进行追求，满足大部分设计原则的代码经过我的实践后发现，出错的概率大大地下降，而根据一些前辈们总结出来的设计模式，能够获得更好的鲁棒性

JML系列

• 这个单元主要尝试规格设计与具体实现分离的开发方法
• 架构上，采用了使用专用类进行包装的方法，例如ShortestPathManager等，开始意识到数据管理的重要性，这也是面向对象的一种设计方法

UML系列

• 这个单元数据管理显得尤为重要，三种UML图放在三个Manager中，各司其职互不干扰，再将公共的RuleCheck模块放在外面，最大程度地封装，十分便于数据管理
• 与JML系列类似，我也意识到了采用专门的算法类来完成一些相对独立的任务

测试理解与实践的演进

表达式系列

• 这一单元我的测试包括手动构造和随机黑盒测试的结合，主要是在完善代码的过程中想到的一些测试样例
• 经过这个单元，我发现软件开发的过程实际上并不是只有架构和代码，更多的是测试的花费
• 测试包括了正确数据、边缘数据和异常数据三类，而代价花费最大的是边缘数据和异常数据

电梯系列

• 这个单元的多线程测不准原理给测试带来了极大的挑战
• 严格随时间的输入发生装置对自动测试机有要求，由于这个单元的状态多样，经过实践发现大量随机测试的效果比较好，不能复现的多线程bug经过大量测试基本都能测试出来
• 另外我在这个单元的测试尝试用了多进程的自动评测机，多进程自动评测机

JML系列

• 这个单元给我的最大感受就是，即使写代码的时候再怎么仔细和自信，总在一个小地方会有意想不到的问题，因此我意识到测试无论如何都不能缺少
• 此外，这个单元比较适合基于JUnit的测试，而同时，一种测试方法不是万能的，往往需要多种测试的方法结合起来使用，效果更加
• 以及JML规格给测试提供了一种新的思路，能够在一定程度上减少随机性带来的不足

UML系列

• 这个单元我对测试有进一步的认识，主要是在正交实现方法的测试方面
• 由于这个单元所实现的功能比较基本，使用测试机无非就是把功能再次实现了一次
• 因此，这个单元的测试应该主要是对拍的方法，对于某个方法采用正交的两种方式进行实现，测试的时候进行对比

课程收获

• 总而言之，OO课程并没有传说中的难受，甚至还有些好玩，相比于OS实验和编译原理等，OO实在是太优秀太爽了
• CO、OS、编译等经常需要在一个毫无意义的bug上吊死一天，虽然OO有的bug也能吊死一天 ，但这样的bug往往是设计上的缺陷，并且经过修复后在各方面都有很大的收获
• 另一方面，课程中对于代码量的要求为今后管理大项目等有飞跃的提升，在架构设计上和代码实现上都有巨大帮助，之前做一个Project类似于实现一个服务器集群的同步控制算法，却因为面向对象功底的拙劣和大量工程代码实现的不习惯而最终没有做出很好的效果，经过这一学期的提升，自认为现在再来实现一次这个算法轻轻松松不在话下
• 而作为计算机科学专业的学生，各种程序的编写不可避免，而这门课在debug上也做到了充足的训练，帮助我们有一双发现bug构造特殊情形的眼睛和严谨细致的能力

课程建议

• JML在平常使用中感觉并没有太大用处，只不过是将规格与实现分开了，并不能在规格层面保证没有逻辑的问题，而且JML在同学们的心中风评也不是太好，个人感觉JML的语法十分繁琐，表达个意思虽然严谨但却非常麻烦。而且JML单元的作业感觉复杂度梯度也不是很高，建议将JML单元设置成两次作业，最终实现的内容不变，这样课程的整体就能少一次作业，为烤漆其他课程留出复习时间
• 由于在作业已经布置后又更改了指导书，每次都需要查看哪里不一样了，虽然并没有改变大的需求，但总感觉心里不踏实，建议尽量减少需求的更改，并在通知中具体说明更改的地方，而不是只说“指导书有更改”
• 后期理论课的存在感不太强，并且UML单元作业的内容与理论课讲的关系不是很大，建议提高研讨课的时间，毕竟大部分同学听研讨课还是很积极，干货很多

线上学期体会

• 很爽的一点在于，看理论课的时间非常灵活，并且可以倍数看，有重点地在需要的地方反复看几遍，听课效率大大提高！
• 但稍微不好的一点在于有时候因为家里的事情，耽误了测试等环节，大部分原因是懒了一手 ，造成一些巨大损失
• 总而言之，这学期特殊的体验非常酸爽，愿OO越来越稳！！，不要放过学弟学妹们