OO UNIT4 总结

[21231110-司亦菲]

类图在正向建模过程中的作用

一阶类图：

确定核心类与职责：LibraryManager 管理 isbnMap 和 userMap，BookIsbn 管理 copies 列表，BookCopy 持有 location 和轨迹。一阶类图在编码前就固定了这些组合关系，后续代码中的构造函数、集合类型都是这些关系的直接映射。

明确方法签名：handleBorrow(LibraryReqCmd)、arrange(boolean) 等方法的参数和返回值类型在一阶类图中确定，避免了开发过程中频繁变动接口签名导致的连锁修改。

二阶类图：

校验实现细节：类图中的类型（如 Map<String, User>）与代码中的泛型必须一致，关联关系的多重性直接对应代码中的集合使用，二阶检查本质上是对代码静态结构的二次确认。

记录重构轨迹：当修正类名或拆分职责时，二阶类图需同步修改，保证了设计文档对代码的持续有效性。

整体架构设计

整个图书馆管理系统采用了控制层-实体层-状态层的三层架构：

控制中枢（LibraryManager）：作为门面类，负责接收所有请求指令（handleBorrow、handleReturn、arrange）。它不持有图书的具体状态，仅维护书目映射（isbnMap）和用户映射（userMap），并协调各实体完成业务逻辑。

领域实体（BookIsbn、BookCopy、User）：

• BookIsbn 负责管理同一书目的所有副本清单。

• BookCopy 负责记录单本书籍的物理位置（location）和借阅期限（dueDate）。

• User 负责记录借阅列表、预约状态以及信用积分（creditScore）。

状态与规则层（Location 枚举与 arrange 机制）：将图书的物理位置抽象为枚举（书架、借还处、预约处、阅览室、用户），并集中通过整理流程（arrange）处理所有跨地点的移动、逾期扣分和预约配送。

大模型辅助体验

与大模型交流要明确提出要求，否则ai会由于没有接收到要求而沉浸在上一个问题中。

要求大模型生成测试数据时一定要给出示例，否则ai只会生成很短的数据。

如果仅凭自己难以定位bug，又觉得在IDEA内debug有些繁琐，可以让大模型帮忙在代码内增加调试输出，通过分析调试输出来精准定位bug。

尽量不要同时交给大模型多个任务，将任务拆分或者分出先后顺序依次解决更好。

架构设计思维的演进

第一单元（表达式求导）：

初期完全是面向过程思维，试图用一个类完成解析、求导和化简。在迭代过程中，我初步建立了层次化设计的思想：将表达式拆解为树形结构，每个节点负责自身的求导与输出。

思维转变：认识到复杂系统必须通过分层来降低认知负荷，每一层只与相邻层交互，这初步实践了“高内聚、低耦合”的原则。

第二单元（电梯调度）：

第二单元将我从舒适的“单线程”拉入“多线程”的深渊。电梯、乘客、调度器之间的协作关系无法靠简单的类组合来保证。我被迫将视角从“类有什么属性”提升到“对象之间如何安全地通信”。

思维转变：架构设计的重点从数据组织转向行为协同。第一次意识到，即便类图结构清晰，如果忽视了线程交互时的时序与共享资源竞争，架构依然是脆弱的。这让我学会了在设计阶段就要考虑“谁锁谁、谁等谁”。

第三单元（JML规格）：

这一单元架构是给定的，我的任务是在既定框架内选择最优实现。JML规格约束了方法的前置、后置和不变量，这让我将精力从“思考如何划分职责”转向“思考如何高效达成规格”。

思维转变：架构（接口）与实现（算法）是分离的。好的架构能在不改变接口的前提下，允许底层替换数据结构。

第四单元（UML建模）：

本单元反转了开发流程：强制先画UML类图、状态图，再写代码。一阶类图在编码前对核心类（LibraryManager、User、BookCopy）进行了静态检查，二阶类图在迭代中（信用分、续借功能）强制保持设计文档与代码的一致性。

思维转变：设计缺陷在画图阶段暴露的成本，远低于代码写完后再重构的成本。

四次作业测试思维变化

第一单元的测试主要是手动构造测试用例和让ai随机生成测试数据。表达式的结果可以通过数学计算验证，因此测试的重点在于尽可能覆盖各种因子及其组合。

第二单元多线程程序的不确定性使得同样的输入在不同运行中可能产生不同的输出，bug难以稳定复现。

第三单元为特定方法编写JUnit单元测试，有针对性地验证规格中的每一条约束。

第四单元测试需要额外关注类图、状态图、顺序图的准确性及其与代码的对应关系。