BUAA-OO-U4总结

[童震天-23373414]

BUAA-OO-U4

前言

这是北航面向对象课程最后一个单元的总结，主要是对UML正向建模的理解，当然也有我个人不使用UML的原因。

正向建模实践

所谓正向建模，是先使用统一建模语言(UML)设计和创建模型，再将模型转化为可执行的源代码的。

相比JML“设计和实现的分离”，UML也可以认为是一种设计和实现的分离，不需要将方法具体实现，只是确定类、属性和方法，完成程序的骨架，展示类和类之间的关系。

由此观之，实际上我们的迭代任务并非完全意义上的正向建模，只有类图可能践行了这个原则，顺序图、状态图都是后来添加的任务。

类图

本人的确尝试先绘制类图再编写代码，但是很快受挫，主要原因有以下几点：

• UML没有一个很好的编写工具
• 任务太小，且完全由一人编写代码，不需要UML来理解框架，直接打出public void readBook(){}甚至是比在类图中添加方法更方便的操作。
• 作业评测机制

也就是说，在我们的作业中，尽管通过比较复杂的类图评测机制，强制要求实现类图，但在实际执行上是反正向建模的，正向则很有阻力，反过来则海阔天空。

状态图

事已至此，状态图是摸鱼完成的这件事已经藏不住了。

顺序图

不考虑评测机制，认真的说，这个图在电梯单元的报告中我也尝试绘制过，当时认为还是一个比较好的表现方式。个人的观点是，在多线程这种真的要考虑时间的任务上，顺序图的作用比较大，但是在U4的图书管理系统中，这个图并没有帮我们理解太多内容。

大模型

如何使用大模型辅助开发，也是吾辈不得不回答的问题。事实上在OO作业中我并没有大量使用大模型辅助，至少不会让代码主体由大模型编写。在实际开发中，我使用ai做了如下工作：

• debug，这方面AI可以测出一部分bug，但是并不完全，无法查出较为隐秘的bug。
• 调整算法，在jml单元让ai进行一个变量的动态维护，这个的体验较好

在其他课程的开发任务中，也有使用agent ai，在编写的过程中进行代码补全的。大多数补全错误的情况是由于我的上下文本身编写错误，可见一般来说AI还是比我的能力更强。

架构演进实践

必须要心存怀疑，究竟是自己的架构设计能力变强了，还是任务对架构设计的要求下降了。虽然最后的答案往往是两者兼有。

• U1的架构：回顾U1的类图，虽然实现的类不算多，但是类和类之间的关系最复杂
• U2：主要是线性的，在线程通信的设计中贯彻了“托盘”的思想。
• U3：由面到点，U3通过jml设计与实现的分离，我更关注方法的实现，类的实现而不是类和类之间的关系，弱化了架构设计的地位。
• U4：自主设计架构，但是架构不算复杂。

得出结论：任务的难度确有降低，但是能不依靠往年博客自己设计架构也算学有所成。

测试

测试思维的进步，实际上就是摸鱼思维的进步。一开始自己尝试编写评测机，半路崩溃被大佬的评测机搭救，到后来心安理得地求助大佬，一摸到底。说到底，评测机只是为了通过评测不丢分而搭建的，谁搭建的并不重要。

当然写评测机本身也是锻炼代码能力的一个方式。不过并不总是有时间写评测机的，完成其他任务又何尝不能锻炼代码能力呢？所以为了训练而写评测机也只能说是愿者上钩。

不过不测试是不行的，每一行代码都有可能导致bug，怎么平衡花在测试上的时间也是OO课程的一个方面吧。

课程收获

• 不要信任课程组提供的内容，保留自己作出怀疑的余地。OO助教也只是普通的学生，官方包并不比讨论区出现的东西高级。
• 学会放过自己，卷性能没有出头之路
• OO的苦并非非吃不可，并非需要一个人埋头苦干，多寻找帮助对自己和他人都好