OO第四单元作业总结

[康建平-ZC061006]

 

一、第四单元图书馆作业：完整走完正向建模流程

第四单元强制正向建模，要求先提交一阶类图再写代码，后期迭代后再提交二阶类图，一整套流程下来，深刻帮助我们理解了两阶类图的意义。

1. 一阶类图：编码前的架构草稿，提前规避大规模返工

刚拿到图书馆需求时，规则极其繁杂：图书分 A/B/C 三类、借阅 / 预约 / 阅读三重权限、信用分增减扣分、开闭馆整理、预约过期、续订、逾期惩罚、阅览室当日回收…… 如果直接上手写代码，大概率会把所有数据、逻辑全塞在一个 Library 类里，后期新增续订、评分功能时根本无从下手。

一阶类图就是我梳理需求的草稿纸：

1. 拆分实体和场地：先把图书馆拆成总控Library、各类场地（普通书架、精品书架、借还处、预约处、阅览室）、核心实体（用户 User、单本图书副本 BookCopy、预约单 Reservation），提前划分每个类的职责，杜绝 “万能大类”；
2. 梳理类之间的关联：Library 聚合所有场地、所有用户、全量图书副本；User 持有借阅图书、当日阅读图书、未完成预约；BookCopy 绑定 ISBN、记录状态流转；
3. 提前定义核心接口方法：借书 borrow、预约 orderNewBook、整理 arrange、信用增减 deductCredit/addCredit 等，提前规划每个类该做什么，不会出现方法乱放、逻辑耦合；

画完一阶图再写代码，最大的好处是提前规避架构硬伤。比如建模阶段我就意识到借阅限制、信用校验逻辑应该封装在 User 类，而不是在 Library 的借书分支里写一堆 if，后续新增阅读、预约权限时，只需要扩充 User 的校验方法，不用大面积修改业务代码。

但一阶类图存在天然短板：只覆盖基础业务框架，三次作业迭代新增的细节（逾期惩罚标记、预约过期时间计算、续订延期逻辑、ISBN 评分存储）无法提前预判，代码实现后会多出很多属性与方法，模型和代码出现偏差，这就是二阶类图存在的必要性。

2. 二阶类图：代码的完整镜像，实现模型与代码双向追踪

完成全部编码、三次功能迭代后，我对照完整代码绘制二阶类图，修正一阶图缺失的属性、方法，补充所有关联关系，满足评测 R1-R5 一致性校验标准，它的作用主要有三点：

1. 完成模型与代码的双向可追溯 二阶类图里每一个类、私有属性、方法的名称、返回值、变量类型，都和代码严格对应。比如 UML 中标注User私有成员creditScore、方法canReadToday()，在 Java 代码中可以精准找到对应实现；Library 聚合所有场地类的聚合关系，代码中也通过成员变量一一体现。不管是自己复盘代码，还是助教检查程序，都能通过类图快速定位对应代码位置。
2. 留存迭代变更记录，看清功能迭代轨迹 对比一阶、二阶两张图，能清晰看到三次作业新增的全部模块：第一次基础借阅功能、第二次新增预约 Reservation 类和信用分系统、第三次新增续订 renew、评分 grade、开闭馆逾期惩罚。架构改动一目了然，如果后期需要重构，提交重构说明文档就能解释两阶图的差异。
3. 为行为建模提供静态基础 图书状态图、预约取书顺序图都依赖完整的静态类结构。代码中所有带@Trigger注解的状态转移方法，都能在二阶类图中找到；顺序图中所有生命线（Library、User、AppointmentOffice 等），全部来自类图定义的类，不会出现无中生有的对象与方法。

3. 两阶类图配合的正向建模闭环总结

以前总觉得画图是负担，做完图书馆作业才理清两者分工：

• 一阶类图：设计蓝图，开发前定边界、分职责，从源头减少后期重构；
• 二阶类图：工程文档，开发完成后对齐代码，沉淀完整系统静态结构，支撑状态图、顺序图绘制。

二、图书馆系统架构设计复盘：UML 模型与代码的追踪对应关系

1. 我的三层架构设计

结合需求复杂度，我把系统划分为三层，所有分层、类间关系都完整复刻在 UML 二阶类图中：

1. 总控调度层 Library 系统唯一入口调度类，聚合所有场地、用户、图书、评分数据，统一处理 OPEN/CLOSE 开闭馆指令，分发借书、预约、阅读、续订等业务，执行每日图书整理与信用惩罚，是整个系统的中枢。
2. 场地容器层（独立场地类） BookShelf、TreasuredBookshelf、BorrowReturnOffice、AppointmentOffice、ReadingRoom，每个场地只负责图书的存储、取出、移除，单一职责，互不耦合。整理流程中图书转运的逻辑统一由 Library 调度，场地只提供基础数据操作方法。
3. 业务实体层（核心数据载体） User 存储用户信用、持有图书、预约记录、当日阅读状态；BookCopy 代表单本图书副本，维护状态轨迹、应还日期、逾期标记；Reservation 封装预约信息与过期判断逻辑。

2. UML 模型与代码的完整追踪关系

（1）静态结构一一对应

1. 类映射：UML 图中所有类都存在同名 Java 类，无冗余、无缺失；
2. 属性映射：属性的访问权限、变量名、数据类型完全同步。例如 BookCopy 中private boolean overduePenalized标记逾期是否扣分，在二阶类图中完整标注；
3. 方法映射：方法名、返回值、参数列表严格对齐，包括图中仅为满足类图规范预留的空方法。

（2）关联 / 聚合关系双向匹配

UML 中 Library 聚合所有场地、User 聚合多个 BookCopy、AppointmentOffice 关联 BookCopy 与 Reservation，这些关联全部通过代码中的成员集合实现。比如private final Map<BookCopy, Reservation> reservedBooks，对应预约处与预约单的关联关系。

（3）行为模型与代码注解联动

状态图中所有状态转移 Trigger，对应代码中@Trigger注解标记的方法；顺序图中预约、取书的对象交互消息，对应 Library、User、AppointmentOffice 之间互相调用的方法，实现静态模型、动态行为、业务代码三者打通。

三、大模型辅助正向建模：踩坑后总结的高效使用技巧

这次写图书馆架构、画类图前期，我全程借助大模型辅助梳理需求、搭建初始架构，踩了不少坑，也总结出一套适合复杂业务系统的建模引导方法：

1. 前期踩过的坑

1. 只丢需求文档，让 AI 直接出完整类图：AI 会遗漏题目约束（比如说A 类不可借阅、信用分 80 分阈值、预约过期扣分规则），生成的类缺少关键校验方法；
2. 一次性要求完整代码 + 完整 UML：AI 会过度简化分层，把所有逻辑堆在主类，不符合单一职责；
3. 不限制建模规范：生成的类名、状态名和评测要求不匹配，后期需要大量修改。

2. 复杂场景引导 AI 建模的正确思路

1. 分步拆解需求，分阶段输入 先把需求拆分为实体、场地、业务操作、约束规则四部分依次发给 AI，先让 AI 输出实体清单，再划分分层架构，最后生成一阶类图框架，不要一次性抛出全部需求；
2. 明确约束与评测规范 提前告知评测规则：需要两阶类图、@Trigger 注解、单一职责、不能出现万能大类、信用分阈值、图书分类限制等硬性规则，约束 AI 输出的设计符合作业要求；
3. 先建模，再生成伪代码，最后落地 Java 要求 AI 先输出 UML 类图文字描述，再根据模型输出伪代码，最后自己对照伪代码手写 Java 代码，避免 AI 直接生成耦合度极高的成品代码；
4. 迭代修正模型 新增续订、评分等迭代需求后，把新增规则发给 AI，基于原有一阶模型迭代更新，而非重新生成，保证两阶类图相似度达标。

简单来说，大模型只能做辅助梳理工具，不能替代自己对业务规则的理解，必须自己把控架构边界、业务约束，再借助 AI 简化重复建模工作。

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

回顾四个单元，我的架构思维变化如下：

第一单元：初次接触复杂的题目，架构混乱

拿到需求直接写主类，纠结很久不知道应该设计什么类负责什么东西。后来架构写的太过于混乱参考大模型重构，修改一个功能就需要大规模改代码。

第二单元：学习生产者-消费者架构思维

引入多线程后，学会了生产者-消费者模型和流水线模式。架构思维从普通的静态架构演进到了“动态的线程安全交互”，学会了利用调度器来解耦请求和执行。

第三单元：学会运用JML

了解到JML 定义每个方法、每个类必须遵守的行为契约，可约束一套可证明、无歧义的可靠架构。这一单元让我认识到接口与规格的威力。架构不再只是类的堆砌，而是基于前置条件、后置条件和不变式的严格契约。

第四单元：模型驱动正向开发，掌握标准化架构设计

严格遵循需求拆解→一阶类图预设计→编码实现→迭代更新二阶类图→行为建模完整流程。熟练运用分层、单一职责、高内聚低耦合思想，通过建模提前规避架构缺陷，代码可拓展性极强，新增续订、评分、逾期惩罚等功能时，仅需要扩充对应类的方法，无需重构整体结构。

五、四个单元测试思维的成长变化

第一单元：靠样例暴力调试

由于第一单元完全是静态的。写完代码运行样例，输出和样例一致就认为程序正确。测试思维停留在黑盒层面，主要依靠构造极端的、复杂的嵌套表达式。

第二单元：多线程的测试

主动手动构造各类临界输入单独运行验证，覆盖大量容易出错的边界场景：

1. 容量边界：空电梯、电梯满载达到载重上限等场景，单独投放呼叫请求，观察电梯是否正确限制乘客进出；
2. 楼层边界：一楼呼叫、顶楼呼叫、呼叫目标楼层与电梯当前楼层一致，单独测试电梯停靠、开关门逻辑；
3. 请求边界：无任何呼叫、单条孤立呼叫、大量呼叫同时涌入、同一楼层同时存在内外呼、同楼层上下行双向呼叫。 通过单独拆分每一类边界场景独立运行，打印电梯楼层、载客数量、等待队列日志人工核对，能够快速定位数值越界、单次请求处理逻辑错误等基础问题，提前保证单请求、单边界下程序运行稳定。

采用 “先单线程、再多线程” 的分层测试流程，分步验证功能，降低并发问题的排查难度：

1. 先关闭多线程并发逻辑，以顺序模式逐条投放呼叫请求，优先验证基础调度规则：电梯上行 / 下行选择、停靠开门、乘客上下、目标队列更新等核心流程，保证无并发干扰时调度逻辑完全通顺；
2. 基础逻辑验证无误后，再开启多线程，逐步增加并发请求线程数量，循序渐进测试并发场景。 分阶段的测试方式能够把 “基础调度 bug” 和 “多线程竞态 bug” 分离开，定位问题时可以快速区分错误来源，大幅降低多线程程序的调试成本。

第三单元：引入 JML 契约规范 + JUnit 单元测试框架

本单元同时接触两套正确性保障工具：JML 行为规格与 JUnit 自动化单元测试，我开始建立 “先定规范、再写代码、最后自动化校验” 的基础思路，但二者结合运用的完整思维尚未成型。

编码阶段我会为核心实体、业务方法补充 JML 规格，借助@requires/@ensures明确方法输入输出约束；同时使用 JUnit 编写自动化用例，主动覆盖各类极端边界：数据数量上限、空集合输入、临界日期、参数极值等容易出错的单点场景，不再只依赖样例手动调试，大幅减少随手调试带来的漏测问题。

第四单元：系统化场景化测试，模拟交互式评测

图书馆作业是交互式评测，评测机会根据我的输出动态生成还书、续订、取书指令，倒逼我建立完整测试思维：

1. 按业务模块划分用例：借阅模块、预约模块、阅读模块、整理流程、信用扣分模块分开测试；
2. 重点覆盖临界边界：信用分 0/80/180 分、借阅到期当日、预约过期临界日期、阅览室当日未归还扣分、续订逾期拦截；
3. 模拟交互联动场景：预约成功后图书送达预约处、超期不取扣分、借阅逾期还书扣分、阅读当日主动归还加分等串联场景；
4. 对照 UML 状态图测试图书状态：覆盖图书所有状态流转路径（书架→用户→借还处→书架、书架→阅览室→借还处等），保证无非法状态转移。

测试思维演进：仅依赖样例 → 零散边界测试 → 分模块 + 全链路场景系统化测试。

六、整门 OO 课程的完整收获

1. 思想层面：彻底转变编程思维

从前写代码只追求 “功能跑通”，现在明白可维护、可拓展、规范的架构远比快速实现功能重要。面向对象不是单纯使用类和对象，而是用封装、继承、关联、聚合抽象现实业务，用模型提前规划系统，从根源降低代码复杂度。正向建模思维不仅适用于课程作业，后续小型项目开发都可以复用这套流程。

2. 工程能力层面：掌握标准化开发流程

完整掌握需求拆解→UML 正向建模（两阶类图、状态图、顺序图）→编码实现→迭代重构→一致性校验的软件工程流程，学会通过 UML 图沉淀系统文档，看懂静态结构与动态行为的区别，理解模型与代码双向追踪的意义。

3. 编码能力层面：规范面向对象开发

熟练运用单一职责、高内聚低耦合设计原则，懂得拆分调度层、容器层、实体层，避免巨型类；学会合理封装权限校验、数据操作逻辑，减少重复代码；理解状态管理思想，而非零散记录状态变量。

4. 测试与问题排查层面：建立系统化测试思路

不再依靠随机调试找 bug，能够按业务场景、边界条件设计完整测试用例，针对交互式评测场景模拟联动操作，快速定位逻辑错误。

5. 工具使用层面：学会合理利用 AI 辅助开发

清楚大模型的优势与局限，掌握分步引导 AI 完成需求梳理、架构草稿、伪代码编写的方法，同时保持自主设计主导权，不依赖 AI 生成完整代码，规避架构设计缺陷。

结尾感悟

四个单元一路走来，踩过无数坑：巨型耦合类、模型代码两张皮、边界逻辑 bug、画图应付评测…… 但第四单元图书馆正向建模的完整实践，让我真正读懂了面向对象设计的核心。这门课教会我的不只是 Java 语法、UML 画图，更是一套解决复杂业务系统的工程化思维。今后再遇到复杂业务开发，我会先静下心梳理需求、搭建模型，再动手写代码，这是 OO 课程留给我最有价值的收获。