OO Unit4 & 课程总结

[赵一丁-24371248]

随着第四单元图书馆管理系统的收官，长达一学期的OO课程终于画上了句号。在此，对本单元及整个学期的学习进行复盘。

一、 正向建模与开发

本单元的核心要求是正向建模与开发，这彻底颠覆了以往“边写边想、边想边改”的开发模式。新引入的两阶类图机制，在其中扮演了关键的约束与指引作用。

• 一阶类图：在这个阶段，我无需关注底层的 HashMap 或 ArrayList，而是聚焦于核心业务实体。例如，抽象出 User、BookCopy 以及连接二者的 BorrowedBook 和 ReservationRecord。一阶类图是业务逻辑的骨架，它回答了系统里有什么和它们之间是什么关系的问题。

• 二阶类图：在实际写代码时，由于具体调度需求，系统必须引入更多细节。例如引入专门处理评分的 getIsbnScore 方法。二阶类图是对一阶类图的具象化。两阶类图的对比，本质上就是理想业务模型与现实工程约束之间的妥协与适配。它让我明白，优秀的设计不是一蹴而就的，而是在宏观抽象与微观实现间不断迭代的结果。

二、 架构设计与模型追踪

在本单元的图书馆系统中，我的整体架构围绕着中心化调度与部门自治展开。

• 架构设计： 我设计了 LibraryManager 作为调度核心，并拆分出 BookshelfArea 、AppointmentOfficeDept、BorrowAndReturnOfficeDept 以及 ReadingRoomDept。每本书的移动本质上是在这些容器间的流转。

• 模型与代码的追踪关系： 最终的代码实现与UML模型保持了高度的同构性。状态图中的转移对应代码中的逻辑判断。例如，状态图中的 bs -> user 转移，在代码中直接映射为 handleBorrow 方法内对 user.getScore() > 80 以及借阅数量上限（A/B/C类书限制）的检查。顺序图中的 orderNewBook 到 getOrderedBook 的交互，追踪了 LibraryManager 将调用委派给 AppointmentOfficeDept.orderBook() 的时序控制。

三、 大模型辅助正向建模的体验与方法论

在本次系统的架构设计中，我尝试引入大模型辅助建模。大模型在处理结构化信息有着天然优势，但前提是必须予以正确的引导。

1. 不能简单地把几页指导书扔给大模型，而是需要提炼核心规则。例如，告诉它“系统分为日间请求和夜间整理两段逻辑，存在图书超期扣分机制”，并限定必须存在的实体（如A/B/C类图书、各类部门）。

2. 先让模型给出顶层组件关系（Manager与各部门的依赖），再深入某个具体难点。

四、 架构设计思维的演进

回望四个单元，我的架构思维经历了从“堆砌逻辑”到“体系化设计”的变化：

• 第一单元（表达式解析）： 初识OO，当时更多是将Java当C语言写。尽管引入了递归下降和多态，但类的职责常常纠缠不清，扩展性较差。

• 第二单元（多线程电梯）： 迎来了一次质的飞跃。为了解决并发安全，我深刻理解了同步块（Synchronization blocks）、线程安全的请求队列以及生产者-消费者模型。

• 第三单元（JML规格）： 架构思维从“如何实现”转向了“如何定义”。通过JML，我学会了站在接口调用者的角度思考前置条件与后置效果，用契约编程的思想规范了代码接口。

• 第四单元（UML建模）： 达到了“未写代码，先有全局”的层次。不再依赖边调试边补丁，而是先画图谱，将系统拆解为高内聚、低耦合的模块，最终实现了真正的正向开发。

五、 测试思维的演进

• 从 Printf 到自动化脚本： 第一单元时主要靠肉眼造数据和打印调试。到了多线程单元，并发Bug难以复现，我开始编写Python自动化评测脚本，结合数据分析来批量验证调度策略的正确性和性能。

• 白盒与形式化验证： 第三单元彻底改变了我的测试观。我引入了JUnit进行单元测试，针对JML规格的边界条件进行全面的覆盖测试。

• 互测： 在互测环节，阅读并hack同学代码是很好的学习途径。通过对比同学的代码实现、性能差异，我不仅学会了如何构造极端数据，更学会了在防御性编程中保护自己的模块。

六、 课程收获

OO课程带给我的，不止Java语言的运用或几种设计模式的记忆。它是一次全方位的工程素养训练。复杂的面向对象思想落地让我真正体会到了一个软件工程师开发的日常。感谢这门充满挑战的课程，让我彻底告别了对复杂工程的畏惧，拥有了驾驭大型软件系统架构的底气。