2026 OO 课程第四单元总结博客

李清伶-ZC061003 2026-06-19 19:45:40

一、正向建模实践：两阶类图的作用

第四单元围绕图书馆管理系统展开，历经三次作业逐步迭代——hw13 建立基础借还预约流程，hw14 新增精品书架、阅览室和评分机制，hw15 引入信用分系统、借阅期限与续订功能。三次作业都要求提交设计时的一阶类图和实现后的二阶类图，两者共同构成了正向建模的完整闭环。

一阶类图的作用在于强迫自己在写代码前就想清楚架构。以 hw14 为例，我在一阶类图阶段就确定了 ILocation 接口统一管理五个地点类（BookShelf、TreasuredBookShelf、BorrowReturnOffice、AppointmentOffice、ReadingRoom），LibraryManager 作为总调度器持有所有地点类引用，Arrangement 专门负责整理逻辑。这个设计决策在动笔写代码前就固定下来，避免了边写边改架构的混乱。

二阶类图的作用则是让类图与代码保持追踪一致性。实际编码中不可避免会有调整——比如 hw15 新增 CreditManager 来集中管理信用分，Book 类需要新增 dueDate、overduePenalized 等字段处理借阅期限和逾期防重复扣分。二阶类图如实反映了这些变化，使得提交时类图和代码能通过 R2-R5 的一致性检验。两阶类图之间的相似度检查也督促我在一阶阶段认真设计而不是敷衍了事。

二、架构设计与 UML 模型的追踪关系

三次作业的架构主线一以贯之：单一调度器 + 地点接口 + 职责分离。

LibraryManager（调度入口）
├── ILocation 实现类（五个地点，各自封装增删查）
├── Arrangement（整理策略，开/闭馆逻辑）
├── UserManager → User（用户状态管理）
├── BookInventory → BookIsbn → Book（图书层级）
├── TraceManager（移动历史）
├── ScoreManager（评分）
├── CreditManager（hw15 新增，信用分）
└── BorrowLimitChecker（借阅数量限制）

代码与 UML 的追踪关系体现在三个层面：

属性追踪：LibraryManager 中每一个成员字段都对应类图里一条关联关系。比如 creditManager: CreditManager 对应 LibraryManager → CreditManager 的 UMLAssociation。
方法追踪：handleBorrow、handleReturn、handleRead 等方法名在类图的 UMLOperation 中一一对应，状态图的 @Trigger 注解（borrow()、handleRead()、handleRestore() 等）也与状态机的迁移 Trigger 字段绑定。
关系追踪：BookShelf implements ILocation 对应 UMLInterfaceRealization；Arrangement 持有多个地点类引用对应多条 UMLAssociation。

三、引导大模型完成复杂架构设计的体验

本单元借助大模型辅助完成了部分建模工作，积累了一些有效的引导方式。

明确约束优先于描述需求。 直接说”帮我设计图书馆系统”效果很差；而说清楚字段、属性等要求，大模型才能生成符合格式的输出。复杂场景下，约束条件往往比功能描述更重要。（最后一次实验上机的内容也为我们提供了很好的利用大模型建模的思路以及提示词撰写方法！）

分层分步胜过一次性输出。 先让大模型确定类的划分和接口设计，验证通过后再补充属性和方法，最后生成关系。一步到位往往产生大量细节错误，分步迭代反而更高效。

四、四个单元架构设计思维的演进

单元	核心任务	架构思维
第一单元	表达式求导	以递归下降解析器为核心，类层次对应语法层次，初识面向对象
第二单元	多线程电梯	生产者-消费者模式，线程安全意识觉醒，开始关注共享状态的边界
第三单元	JML 规格验证	契约式设计，接口先于实现，用规格约束行为而非依赖实现细节
第四单元	图书馆 UML 建模	正向建模，模型驱动实现，类图-状态图-顺序图构成完整设计文档

架构思维最主要的变化就是：从“先写代码再想设计”转变为“先定模型再写代码”。第一单元时架构几乎是边写边改，第四单元时类划分和接口在动笔前已经稳定。另一个变化是对职责边界的敏感度——比如Arrangement 不直接操作用户信用分（交给 CreditManager），LibraryManager 不直接存储图书位置（交给各地点类），这种清晰的职责边界在前几个单元几乎没有意识到。

五、四个单元测试思维的演进

第一单元：手工构造边界样例（零系数、嵌套括号、幂次为0），测试以正确性为主，策略比较朴素。

第二单元：多线程的不确定性让手工测试几乎失效，开始关注覆盖场景而非具体输出——电梯超载、同时到达同一楼层、维护中断等场景需要刻意构造。

第三单元：有 JML 规格作为 oracle，第一次系统性地做等价类划分——空图、单节点、环路、重边分别覆盖。互测阶段也学会了针对规格边界（如 isValid 边界条件）构造 hack 数据。

第四单元：交互式评测机制让测试思维转向状态覆盖——哪些状态转移组合会触发信用分扣分？逾期跨越多个开馆周期时是否只扣一次？预约失效和阅读未归还同一天发生时顺序是否正确？等等问题。

六、课程收获

上完 OO 课程，最大的收获是面向对象的思想。第一单元写表达式求导时，对"类"的理解还停留在"把数据和函数装在一起"的层面，真正的转变发生在第二单元——多线程电梯要求把"楼层""请求""调度策略"都看作独立的、有状态、能通信的对象，而不是一堆全局变量加几个处理函数。到第三单元用 JML 规格描述容器类（如 MyGraph、Path）时，"对象"进一步抽象为契约的集合：一个类是什么，由它对外承诺的行为决定，而非内部如何实现。第四单元的图书馆系统把这种思想推到了建模层面——ILocation 接口让五个风格迥异的地点类（书架、阅览室、借还处……）可以被 LibraryManager 一视同仁地调度，这正是面向对象"用统一接口屏蔽差异"的精髓。回头看，四个单元其实是同一种思维方式在不同场景下的反复确认：先想清楚"有哪些对象、它们各自负责什么、彼此如何协作"，再去想"怎么实现"。

另一个收获是真正理解了设计和实现是两件事，而且设计应该先于实现。这在第一单元完全是理论，到第四单元才算有了切实体会——一阶类图通过评测意味着架构是合理的，之后写代码只是在填充细节，而不是在解决架构问题。

最后是对迭代式开发的认识。每个单元内部都是三次作业递进式加需求——第四单元尤其典型，hw13 的核心架构（LibraryManager + 地点接口 + Arrangement）在 hw14 加入精品书架、评分、阅览室时几乎没有伤筋动骨，hw15 引入信用分系统时也只是新增了 CreditManager 并在已有方法里插入信用分检查逻辑，没有动摇整体骨架。能有这样的效果是因为前一次设计时就为后续扩展留了余地——ILocation 接口不绑定具体地点数量，Arrangement 不耦合具体整理策略的细节。把这个经验往回看，第一单元三次作业里表达式的处理能力从多项式扩展到三角函数嵌套，第二单元电梯从单部扩展到多部协同调度，本质上都是同一套迭代逻辑：好的第一版不是功能最全的版本，而是最经得起增量扩展的版本。这大概是这门课留给我最持久、也最能带到工程实践中去的认识。