OO 第四单元及全课程总结：从代码堆砌到正向建模的蜕变

[刘钰汝-ZC061012]

随着第四单元图书馆管理系统最后一次强测的落幕，这学期的OO课程也画上了圆满的句号。回首这四个单元的历程，从最初面对多项式求导的无从下手，到如今能够熟练利用 UML 图进行正向的系统级架构设计，我感慨又欣喜。这不仅是代码行数的积累，更是思维维度的全面提升。

一、 正向建模与开发：两阶类图的“契约”与“护航”作用

在第四单元的实践中，“正向建模”是绝对的核心。过去我们习惯于“边写边构思”，而本单元强制要求我们先画图（建模），再写代码，这是一种典型的自顶向下的工程思维。

在这一过程中，两阶类图（一阶设计图与二阶最终图）扮演了不可替代的角色：

1. 一阶类图（uml_pre.mdj）—— 架构设计的蓝图与契约
   在动手写 LibraryManager 的任何一行逻辑之前，一阶类图强迫我去思考系统的边界和实体的划分。比如，我决定采用“中心调度 + 充血模型”的星型架构，由 LibraryManager 统筹全局，下设 Bookshelf、AppointmentOffice、BorrowAndReturnOffice 等独立的地点类。通过在类图中绘制有向关联线（Directed Association），我提前确立了数据的流向和各类的职责。一阶类图就像是与自己签订的开发契约，避免了在后续复杂的业务（如借书、预约、逾期结算）中迷失方向。
2. 二阶类图（uml_ultimate.mdj）—— 代码防腐的护航者
   随着开发的深入，代码往往会因处理边缘细节而偏离初衷。二阶类图及评测机严苛的 R1-R5 检验，强迫我保持代码与模型的高度一致。例如在 R2 检验中，由于我在一阶图里为借还处设计了 restore 方法，在代码实现时为了图省事想用 returnBook 替代，结果评测机精准报错。这让我深刻认识到：模型不是代码的草图，而是严格的领域规约。 二阶类图的严格审查，有效防止了架构的腐化。

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

本单元我的最终架构设计是一个典型的中心调度模式。代码设计与 UML 模型之间保持了 严格的映射追踪关系：

• 核心控制层： 代码中的 LibraryManager 类完美映射了 UML 中的调度中心，包含了处理各种命令（borrow, order, read, arrange 等）的方法。
• 数据与实体层： 图书馆的各个区域被抽象为彼此独立的实体类（如 Bookshelf, ReadingRoom, TreasuredBookshelf）。在 UML 图中，LibraryManager 通过带有 Role Name（如 -readingRoom）的实线箭头指向它们；在代码中，这严格映射为 LibraryManager 中的 private final ReadingRoom readingRoom; 成员属性。
• 状态图与顺序图的代码追踪：
• 状态图： 为了严格追踪一本书（Book）的生命周期流转，我在代码中不仅使用了 @Trigger 注解，还为了满足 Guard 条件互斥检验，特意引入了 targetState 这一辅助变量。这样不仅符合了状态图的逻辑闭环，也让代码的可测试性大大增强。
• 顺序图： 对于用户与图书馆的交互，我在代码中将 orderNewBook 等核心交互方法的可见性严格设为 public，并添加 @SendMessage 注解。代码中方法的调用链与顺序图中的 Lifeline 消息传递（:User -> :LibraryManager）严丝合缝。

三、 大模型辅助正向建模的体验与引导策略

在本单元复杂的架构搭建和令人抓狂的图评测排错中，我深刻体验到了使用大模型（LLM）辅助开发的威力。要想让大模型在复杂场景中真正发挥作用，需要掌握科学的引导策略：

1. 精准的上下文约束：
   不能简单地把指导书扔给大模型。在要求大模型生成或修改代码前，必须明确告知架构基调（如：“请基于我目前的 LibraryManager 调度架构”、“类名必须包含官方关键词覆盖率”），以及代码规范（如 CheckStyle 的单行 100 字符限制）。
2. 聚焦于逻辑谬误而非单纯报错：
   在遇到强测中经典的“日期跳跃导致的预约处逾期 Bug”时，直接喂报错信息往往得不到好结果。我选择引导大模型去分析“时间跨度未被正常 OPEN/CLOSE 触发”这一逻辑漏洞。大模型理解后，立刻给出了基于数学日期比对的完美 arrange 补缴清理逻辑，而不需要重构整个时间轴系统。
3. 跨越工具与代码的鸿沟：
   StarUML 的底层是复杂的 JSON（.mdj）。当我遇到明明删了类却依然报错的“幽灵类（Ghost Class）陷阱”时，大模型帮我剖析了视图删除与模型删除（Delete from Model）的区别。引导大模型不仅分析 Java 代码，还要分析开发工具的底层逻辑，是解决疑难杂症的利器。

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

回顾这四个单元，我的架构设计思维经历了一场蜕变：

• 第一单元（表达式解析）：从面向过程到基于对象。 最初我只想着用正则暴力解析，但在递归下降算法的毒打下，我学会了将因子、项、表达式抽象为独立对象，初步建立了树形结构的面向对象思维。
• 第二单元（电梯调度）：解耦与并发控制。 引入多线程后，我学会了经典的生产者-消费者模型和流水线模式。架构思维从“静态的数据流”演进到了“动态的线程安全交互”，学会了利用调度器（Scheduler）来解耦请求和执行。
• 第三单元（JML 社交网络）：契约式设计（DbC）。 这一单元让我认识到接口与规格的威力。架构不再只是类的堆砌，而是基于前置条件、后置条件和不变式的严格契约。我学会了在满足规格的前提下，在底层替换更高效的数据结构（如并查集、Dijkstra）。
• 第四单元（UML 图书馆）：正向建模与领域驱动。 架构思维达到了系统级。不再是拿到需求就写代码，而是先画类图、状态图，从顶层俯瞰整个系统的实体、属性关系和状态流转。真正的体会到了“谋定而后动”的工程化美学。

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

与架构演进相伴的，是测试思维的不断升级：

• 第一单元：边缘数据轰炸。 测试思维停留在黑盒层面，主要依靠构造极端的、复杂的嵌套表达式，甚至利用脚本进行正则对拍。
• 第二单元：并发与时序测试。 黑盒测试在多线程面前显得苍白无力。我开始关注死锁、轮询和时序问题，学会了利用打印时间戳和特定时机投放请求来捕捉幽灵般的并发 Bug。
• 第三单元：单元测试与规格对拍。 引入了 JUnit 测试框架，测试思维从“整体黑盒”转向了“局部白盒”。学会了针对具体的 JML 规格去构造覆盖各种分支（正常、异常边界）的单元测试。
• 第四单元：状态空间与业务流测试。 本单元的测试难点在于复杂的业务状态流转。我的测试思维演进为“场景模拟”。比如，不仅要测试“按时还书”，还要测试“阅读未还 + 跨天逾期 + 续订冲突”这种复杂的时序与状态叠加场景。学会了基于状态机（Statechart）来覆盖每一条状态转移路径。

六、 课程收获

历时一学期的 OO 课程是一场真正的淬炼。

首先，我的代码规范得到了前所未有的重塑。CheckStyle 的红线曾经让我痛苦不堪，但现在，良好的命名、合理的单行长度、以及低耦合的包管理已经成为了肌肉记忆。
其次，我真正理解了什么是“软件工程”。代码只是表达逻辑的载体，而架构设计、UML 建模、JML 契约、多线程安全，这些才是支撑起一个健壮软件的钢筋铁骨。
最后，是抗压能力与问题排查能力的提升。无数个在评测机前“提心吊胆”的夜晚，无数次被 R1-R5 规则和“时间跳跃 Bug”卡住后的抽丝剥茧，让我逐渐褪去了普通 Coder 的青涩，开始以一名软件工程师的严谨视角去审视每一行代码。

感谢 OO，让我完成了这学期最痛苦却也最宝贵的蜕变。