2022面向对象第四单元总结

第四单元总结

架构设计

核心类图

架构细节

• IdElementMap 类
  • 初始化类图、顺序图和状态图
  • 存储了各种元素的 id 到元素自身的映射
  • 进行所有检查（R001~R009）
• MyDiagram 类
  • 实现 UserApi 接口
  • 实例化了一个 IdElementMap 对象，将检查下发
  • 存储了 Map<String, MyClass> 的对象，为名字到类的映射，将类图请求下发给相应的 MyClass
  • 存储了 Map<String, MyInteraction> 的对象，为名字到顺序图的映射，将顺序图请求下发给相应的 MyInteraction
  • 存储了 Map<String, MyStateMachine> 的对象，为名字到状态机的映射，将状态图请求下发给相应的 MyStateMachine
• 在查询时均利用了动态维护与缓存
• 检查合法性时，大量使用了 stream，简化代码
• R003 的检查采用了 tarjan 算法，巩固了图相关算法

数据构造和测试

• 数据生成
  • 主体采用随机生成的方式，通过增加各种全局开关与限制，来生成符合不同作业要求的数据
  • 手动或自动构造了一些特殊数据，测试边界情况等
• 测试完全采用黑盒测试，进行多人对拍

架构设计思维及OO方法理解的演进

• 第一单元
  • 学习了层次化设计、不可变对象、工厂模式等
  • 将关键模块之间解耦，降低了耦合度，使得可维护性大大提高
  • 懂得了好的架构对迭代的重要性，体验了重构
  • 认识到了好的架构需要在易实现性、复杂性、鲁棒性、可扩展性等之间找到平衡点
• 第二单元
  • 学习了多线程编程和如何设计线程安全的程序
  • 学习了生产者-消费者模式、单例模式等设计模式
• 第三单元
  • 学习了JML和规格化设计
  • 学习了契约式编程和防御式编程等概念
• 第四单元
  • 和第一单元很像，需要把输入解析成图结构，再次体会了层次化设计
  • 如果完全复原UML图，会具有很好的可扩展性，但是复杂性会大大提高，代码行数也容易膨胀。考虑到没有迭代的需求，只维护了必要的结构，控制了代码量，也提高了可维护性

测试理解与实践的演进

• 第一单元
  • 采用黑盒测试 + 对拍
  • 学会了命令行编译、运行、打包java程序
  • 通过大随机来增加数据覆盖率，同时利用常量池缩小数据范围，增大有效性
• 第二单元
  • 采用黑盒测试 + special judge
  • 第一次编写 special judge 程序
  • 学会了 subprocess 库的使用，引入多进程跑点和多程序联测，增大bug复现率
  • 利用 ctypes 库获得程序运行时间和 cpu 时间
  • 输出错误信息时对输入和输出按电梯进行分类，以便更好的定位错误
  • 在随机生成的基础上，构造了几十种不同特征的数据，提高了覆盖率
• 第三单元
  • 采用黑盒测试 + 对拍
  • 初步学习了 Junit 的使用，但并没有利用它进行测试
  • 在随机生成的基础上，构造了不同类别的数据，用于测试不同的指令
• 第四单元
  • 采用黑盒测试 + 对拍
  • 分别对类图、顺序图、状态图进行数据构造，三者分开测试
  • 随机生成 + 全局开关控制数据限制

课程收获

• 学习了面向对象程序设计，对封装、继承、多态等概念有了深入的体会
• 学习了层次化设计、多线程编程、JML规格、UML图等
• 编写 java、python 的能力大大提升
• 构造数据和搭建测评机的能力大大提升（造数据真的太难了）

改进建议

• 可以加强第一、二单元的互测强度，尤其是第二单元，因为复现率低和挡刀等问题，很多刀没有中
• 互测分房感觉还不是太合理，即使是强测满分的人在一个房，有的人可以没有bug，有的人却漏洞百出。建议在强测时增加几个强度更大、但不算分的数据点，用于更精确地分房，这样感觉互测也更有意思一点
• 研讨课小组讨论的形式可以改一改，个人觉得在短时间内，让每个人都发言并且让别人理解他的想法是有一定难度的。本来就难以完全表达清楚的想法，再经过总结提炼后，剩下的东西已经不多了而且意义不大。个人建议可以改成让小组完成某一项任务（例如有一次写JML规格），将小组合作改为动手而不是动嘴的形式