2026OO Unit4总结

王正易-24373224 2026-06-25 18:47:23

2026OO Unit4总结

本次 Unit4 主要围绕图书馆管理系统的迭代以及如何使用 UML 构建代码框架到最终实现。

一、正向建模

本单元的核心不是从代码反推 UML，而是由需求构建 UML 模型，最终到代码实现的的正向建模。因此在设计过程中画的一阶类图很可能与二阶类图有所差异。

两阶类图的作用

一阶类图 uml_pre.mdj 是设计，第一次从零开始构建，而之后的迭代就可以在此基础上增添新的必要类与方法。一阶类图回答“谁有什么”的问题，涵盖代码的基本骨架。

二阶类图 uml_ultimate.mdj 需要有完整类图，需要包括代码实现的具体逻辑，比如一阶类图中的一个 pick 方法，可能在实现中需要拆分成检查是否可行的 canPick 以及操作书籍状态的 move。

在第二、三次迭代中又新增了状态图和顺序图，增加了对方法操作的描述，明确代码的正确运行逻辑。完整的类图回答“最终需要什么”的，状态图回答“属性怎么变化”，顺序图回答“谁调用了谁”的问题。

正向建模中的体会

使用 UML 正向建模。先结构、后行为、再细节规则。类职责不清时，状态图和顺序图也会画乱。

同时，正向建模不意味着画出看似可行的一阶类图就能写出正确实现的代码，也需要在编写过程中时刻注意设计上是否有偏差（比如取书时没有信用分限制）。对于需要调整的地方应及时修改，并在二阶类图中有所体现。

二、架构设计

使用 LibraryManager 类接收处理请求，之后调用 User 类中的判断方法以及 BookCopy 类的状态得出是否接受，然后修改对应的状态，并且在对应的场所修改容器即可。比如在取书的 pick 中，需要调用 User 的 canPick，之后调用 AppointMentOffice 中的 pickOrderedBook，调用多个方法判断书籍状态（是否在预约处，是否已经预约，是否过期等），最后调用不同的 move 方法。

代码设计与 UML 一一对应。在测试修改过程中需要持续追踪，比如在描述顺序图的时候，修改了类之间调用的关系，导致新增了 User 和 AppointMentOffice 的关联关系，需要新增类图的关联关系。（完整类图方法太多了，这里都删掉了）

三、大模型辅助正向建模

先仔细描述背景与需求，让大模型分阶段给出实现思路，禁止跳步（否则会天马行空地生成）
比如：先读题目要求，代码和当前类图，列出类图要加什么，需要新增什么方法。

再给具体约束，一步步规范实现。
比如：借书期限的方法使用包含 limit 的命名

然后全面测试。
让大模型生成测试程序，要求测试样例的格式以及复杂程度。

最后亲自 review。
确认调用方法正确，命名正确，实现逻辑和题目相符，手动构造一些样例（比如预约时信用分足够，而取书之前信用分降低不会导致取书失败），对大模型的误判，导致生成的评测也无法正确测出的 bug，做出及时的修改。

四、架构设计思维演进

第一单元中设计递归下降，主要是为了实现功能而写出的冗杂且效率低下的代码，没有什么设计与思考，只是缺什么加什么；第二单元是多线程设计，需要深入思考电梯状态机的设计以及锁的控制，以及线程间的通信，在这部分，只是简单设计了状态机与接客逻辑；第三单元是 JML 设计，重点是如何用高效准确的代码实现逻辑，设计思考不多；第四单元重点学习了使用 UML 正向建模，真正的在开始写代码之前认真思考并设计了代码的架构。

五、测试思维演进

第一单元只是通过对题目的理解自行构造测试数据，效率低下并且覆盖率也低，bug 频出；第二单元通过自行设计测试脚本批量测试，但是对于数据的构造依旧只能从几个条件中自行思考；第三单元对于 JML 明确规定的设计规格，采用了单元测试的方法，配合大模型构造测试数据（大模型理解稍好），并使用大模型生成了固定框架的随机数据，高效测试；第四单元对于复杂且动态的输入输出没有什么好的思路，但好在逻辑不算复杂，只针对本地的输出逻辑构造了静态的数据进行测试，相较于第二单元多线程极度复杂且难以复现的测试要简单许多。

六、课程收获

本学期的 OO 和上学期的 OOpre 共同构建了我对面向对象的编程逻辑，认真思考了实现一个业务在行为上的逻辑。由一开始 OOpre 交给我的简单的继承封装多态的逻辑，到这四个单元多维度的业务设计与描述方式，深刻理解设计一个正确稳定且容易迭代的代码有多么困难。通过这两个学期的学习，不断精进我的架构设计能力与测试能力，同时了解了不少的测试思路以及算法实现。