OO第四单元及课程总结

高宇轩-24371096 2026-06-19 20:49:36

面向对象第四单元及课程总结

一、第四单元：正向建模与开发的实践

第四单元的核心任务是以一个图书馆管理系统为背景，实践正向建模与开发。这与前三个单元直接根据文字需求或 JML 写代码不同，本单元要求先绘制 UML 图（类图、状态图、顺序图），再根据模型进行代码的编写。

1. 两阶类图在正向建模中的作用

一阶类图（前期架构设计阶段）： 在编写任何代码之前，我首先通过一阶类图（uml_pre.mdj）进行顶层领域模型的设计。它的核心作用是强迫我在编码前理清实体间的组合关系与职责划分。面对指导书中繁杂的借阅、预约和整理规则，我在类图中规划出了地点责任层：将 AppointmentOffice（预约处）、BorrowAndReturnOffice（借还处）、Bookshelf（普通书架）和 ReadingRoom（阅览室）抽象为平级的实体，让它们各自维护内部的数据集合。同时，我规划好了 BookCopy（负责图书状态）和 User（负责权限与信用）的数据结构。此时的类图偏向于宏观蓝图，帮助我在脑海中建立起各个模块的交互边界，避免了后续开发中的架构返工。
二阶类图（开发迭代与同步阶段）： 在代码落地过程中，随着极限边界条件的暴露（如强测中的时间步进问题），初始架构必然需要修正。二阶类图（uml_ultimate.mdj）的作用在于记录架构的演进，并保持模型与代码的严格一致性。例如，为了解决“逾期扣分被重复触发”的隐藏 Bug，我在 User 类中新增了 Set<LibraryBookId> penalizedOverdueBooks 属性来精准追踪已惩罚的图书；为了满足顺序图的一致性检查，我将代码中的辅助方法调整了对应的可见性。这些基于现实业务逻辑的微调，都被严格同步回了二阶类图中。两阶类图的对比，是从“理想设计”走向“工程落地”的真实轨迹。

2. 架构设计：代码实现与 UML 模型的追踪关系

本单元图书馆系统的架构设计严格遵循了高内聚、低耦合的面向对象原则。我的代码架构可以清晰地划分为三个层次

系统架构分层逻辑：
核心控制层： LibraryManager 是整个系统的中枢大脑。它不仅持有了五个核心地点类（如 bookshelf, appointmentOffice）的实例，还集中管理了全局的 users 和 allCopies 映射表。它负责接收外界解析后的 LibraryReqCmd 读写指令，并将核心业务（如借阅 handleBorrow、取书 handlePick）精准分发给对应的子模块，同时统筹每天开闭馆时的全局整理方法 arrangeBooks()。
实体与状态管理层： BookCopy 独立维护了图书的状态转移机（LibraryBookState）。外部只能通过唯一入口 moveBook() 来改变其位置，并在内部自动追加 LibraryTrace 轨迹，实现了状态变更的安全封闭。
User 类被设计为一个“充血模型”。它不仅存储了个人的 borrowedBooks 和 activeOrders，还高度封装了业务规则。例如，取书时的数量限制通过 checkBorrowLimit() 自我校验，逾期扣分通过 triggerOverduePenalties() 每日自主结算，绝不将这些核心逻辑泄漏给外部的控制层。
地点责任层： 不同的地点被封装为独立的类，根据自身业务特性采用了不同的底层数据结构。例如，Bookshelf 使用 Map<LibraryBookIsbn, List<BookCopy>> 来实现同类书的批量存储与分发；而 AppointmentOffice 则使用 Map<BookCopy, ReserveInfo>，将具体的实体书与用户的取书期限（clearDate）严格绑定，各自管理该区域内的图书流转。

代码与 UML 模型的追踪关系分析：
在编码落地的过程中，我的代码设计与 UML 模型保持了严密的追踪闭环：

状态图的追踪： 状态图定义了图书副本在各个地点流转的合法路径。在代码中，这些状态转移完全通过 @Trigger 注解显式追踪。例如，全局整理方法 arrangeBooks() 头部的 @Trigger(from = "ao", to = {"bs", "tbs"}) 完美映射了过期预约书被收回书架的模型设计。代码中针对图书是否为精品的条件分支（isTreasured），以及闭馆时将书从 rr 移动到 bs/tbs 的逻辑，与状态图中定义的 Guard 保护条件严丝合缝，确保了运行时的状态转换绝对合法。
顺序图的追踪： 顺序图刻画了动态的跨对象消息传递。以用户取书为例，从触发起始消息 orderNewBook 开始，代码中体现为 LibraryManager.processCommand() 捕获指令并调用 handleOrder；随后依次触发 User.addOrder() 与 AppointmentOffice.addPendingOrder() 的内部逻辑；最后在取书成功时映射到 getOrderedBook 消息。为了满足顺序图的严格一致性评测，代码中涉及跨生命线（Lifeline）调用的方法均被显式地调整为 public 或包可见，彻底打通了从 UML 设计图纸到 Java 字节码的追踪链路。

二、大模型在复杂场景中辅助正向建模的引导策略

在第四单元中，开发的核心是先完成 UML 建模，再写代码落地。面对指导书中复杂的图书流转和信用分规则，我总结了以下几点引导大模型辅助架构设计的经验：

1. 拆分需求以抽取核心类

在画一阶类图时，不要直接把一整篇指导书发给大模型让它写全套代码。最好的做法是把需求分段，让它先帮忙提取核心实体。比如，我把预约和借还的规则发给大模型，它建议我把预约处、借还处和普通书架拆分成独立的地点类。这直接帮我确定了系统最初的结构，方便后续画图。

2. 聚焦生命周期以完善状态图

图书的状态流转是设计的难点。我专门针对图书的生命周期向大模型提问，让它列出图书从书架到预约处、再到用户手里的所有状态，以及每次变化的触发条件。大模型帮我找出了很多容易忽略的细节，比如预约过期后图书退回书架的流转过程。根据这些回答，我能够很顺利地画出符合要求的状态图。

3. 设定具体场景以梳理顺序图

在处理多对象交互时，方法调用顺序很容易乱。我会给大模型设定一个具体场景，比如“用户取书成功”，然后要求它按顺序列出用户、核心控制类和预约处之间的方法调用过程。这种提问方式直接对应了顺序图的绘制需求，帮我理清了对象之间的连线。

4. 提前输入规范约束大模型

大模型并不清楚课程里具体的 UML 评测要求。所以在让大模型辅助设计架构时，必须提前告诉它我们的限制条件。比如，明确告诉它跨类调用的方法不能是私有的，类的设计要满足单一职责。有了这些约束，大模型给出的架构建议才不会在提交评测时因为可见性等格式问题报错。

三、架构设计思维的演进

回顾整个课程，我的架构设计思维经历了以下阶段：

第一单元（表达式解析）： 思维重心在于功能的实现。起初倾向于直接处理字符串，随后引入递归下降和层次化设计（词法分析、语法分析、多项式计算层），初步体会到了解耦复杂逻辑的必要性。
第二单元（多线程电梯）： 重点转向状态管理与并发控制。懂得了将共享数据与线程逻辑分离，学会使用同步块和生产者-消费者模型来处理复杂的并发竞争，认识到架构设计不仅是代码的静态组织，更是对运行时序的动态管控。
第三单元（JML 社交网络）： 体会到契约式编程与性能的权衡。架构设计的关注点扩展到数据流的维护（如使用缓存降低查询复杂度）。学会在满足规格契约的前提下，设计出满足时间复杂度要求的底层结构。
第四单元（UML 图书馆）： 实践了模型驱动开发。在动手编码前，先建构系统的顶层蓝图，用图形化的方式理清实体关系和状态流转。代码的实现成为了架构设计的自然延伸。

四、测试思维的演进

在四个单元的迭代中，我对软件测试的理解也逐步深入：

针对边界条件的测试设计： 第一单元时，主要构造基础数据验证功能是否正常。到了第二单元和第四单元，我开始有针对性地针对极限边界构造数据（如电梯的高并发请求涌入、同一时间多用户对特定逾期图书的预约），测试用例的设计更加注重系统的极端负荷场景。
内部状态的深度验证： 第三单元的 JML 规格表明，测试不能仅依赖方法返回值。为了验证无副作用（pure 方法）或状态的正确修改，必须对对象状态进行深拷贝，并进行执行前后的严格比对。测试目标从功能正确性扩展到了对系统内部状态完整性的保护。
自动化与辅助测试工具的引入： 随着项目复杂度的提升，手动构造数据的成本逐渐不可控。我开始利用大模型辅助编写数据生成器，搭建自动化评测机进行批量测试，显著提升了覆盖率和排错效率。