2025_OO第四单元总结

王明天-23371300 2025-06-15 21:37:34

2025_OO第四单元总结

一. 单元总结

1. 正向建模与开发

其实我们一直以来写作业都是先建模再开发，只不过之前的作业没有强制要求UML。

说实话，刚开始看到“正向建模”这个词，心里是有点犯嘀咕的。以前写代码，都是需求看明白了，在脑子里或者草稿纸上随便画画，就有个大概的轮廓，然后直接开干。现在非要用UML这种标准化的语言先画出类图、状态图、顺序图，感觉像是被上了个“紧箍咒”，有点束手束脚。

但实际走一遍上图这个流程，才发现“真香”。

需求分析：这步没啥说的，就是硬着头皮啃长长的指导书。
草图建模：这就是我以前的舒适区，在脑子里把各种类、方法、关系先“混沌”地构思一遍。
UML建模：这是本单元最核心的一步。它逼着我把脑子里那些乱七八糟的想法，整理成一套清晰、无歧义的“通用语言”。
- 类图不必多说，帮我理清了有哪些类，类的属性和方法，以及类之间的关联。
- 状态图 可以说是辅助整个过程最有用的工具。比如一本书，到底是在书架、在用户手里，还是在预约处……各种状态之间的流转路径和条件都可以用这张图来呈现，编程的时候也一目了然。
- 顺序图 则更加具体，把一个给定的复杂场景里，好几个类是怎么一步步对话协作展示清楚。
代码实现与迭代修改：这绝对不是一条单行道！最真实的体验就是，我照着UML图信心满满地开始写代码，写着写着就发现：“诶，这个地方查询效率太低了。” 或者 “这里多传一个参数会方便很多”。这时候，就得掉头回去修改UML图，然后再回来改代码。这个来回“折腾”的过程，恰恰是设计的精髓，它让我的设计蓝图和工程落地能够动态地对齐，越来越健壮。
评测验证：最后就是拉到评测机上“是骡子是马拉出来遛遛”了。

这个流程的核心价值在于，它将大量的设计思考前置，通过UML这一通用语言，在编码前暴露潜在的结构性问题，从而有效降低了后期重构的风险和成本。

2. 架构设计

本次作业的架构设计，以LibrarySystem为核心，构建了一个职责清晰、高内聚、低耦合的系统。

统筹 - LibrarySystem：该类是整个系统的入口和调度中心。它对MainClass屏蔽了内部复杂的子系统交互，负责接收并解析指令。其内部通过一系列私有handle和process方法，将具体的业务逻辑委托给相应的领域对象处理。同时，它也作为数据中心，统一管理系统中所有的核心实体集合，如allBookCopies、allUsers等。
实现：这些是封装了自身状态和行为的富领域对象，是具体业务规则的执行者。
- BookCopy：代表了单本图书的完整生命周期。它不仅包含ID、ISBN等静态属性，还封装了其位置状态currentLocation、移动历史movementHistory以及状态判断（如isOverdue, isOnAnyShelf）等核心业务逻辑。这使得关于“书”的状态判断和行为完全内聚于BookCopy自身。
- User：作为用户的领域模型，它管理了用户的信用分、借阅记录borrowedBooks、当前阅读和预约状态activeReservation。所有与用户资格相关的判断（如canBorrow, canOrder）都由User类自身负责，实现了业务逻辑的闭环。
- Reservation：将“预约”这一复杂的业务流程抽象为独立的领域对象，是一个关键的设计决策。Reservation类通过ReservationStatus枚举管理其内部状态（待分配、待取书、已完成、已过期），清晰地定义了预约的整个生命周期。这种设计将复杂的预约逻辑从LibrarySystem和User中剥离，极大地提高了模块的可维护性。
- MovementLog, BorrowingRecord：作为值对象，用于封装和传递特定的数据集合，使代码意图更清晰，也便于数据的管理和追踪。

总而言之，整个代码通过LibrarySystem的统一协调和各个领域对象的专职负责，实现了控制逻辑与业务逻辑的分离，保证了系统的可扩展性和可维护性。

3. 大模型的使用

在本次正向建模过程中，我尝试将大语言模型（主要是Gemini）作为辅助工具，其体验和效果远超预期。为了高效地利用其能力，我总结了以下引导策略：

任务分解与循序渐进：避免直接抛出整个复杂需求。我会将任务分解，首先让模型辅助进行高层抽象，例如：“请根据以下需求，识别出核心的领域实体及其关键职责。”在模型给出BookCopy, User等核心类后，再针对某个具体类的复杂行为进行深入探讨，例如：“请为Reservation这个业务流程设计一个状态机，包含哪些状态，以及状态转换的触发事件是什么。”
上下文提供与迭代式优化：模型的输出质量与其获得的上下文信息密切相关。我会将关键的业务规则、约束作为Prompt的一部分提供给模型。当模型生成初步的设计方案后，我会基于自己的专业判断进行审查，并提出具体的、有针对性的修改意见，例如：“当前设计在LibrarySystem中处理了过多的预约逻辑，耦合较重。请重构设计，将预约抽象为一个独立的Reservation类，并定义其状态和行为。”通过这种迭代式的对话，可以逐步将模型的设计方案优化至满足要求的水平。
辅助生成与格式转换：大模型在处理结构化文本生成任务时表现出色。一个高效的应用场景是，在确定了设计思路后，用自然语言向其描述类图的结构或顺序图的交互流程，然后让其生成对应的PlantUML代码。这极大地减少了手动绘制和调整UML图的工作量，使我能更专注于设计本身。

我的体验是，大模型是强大的“设计放大器”和“知识伙伴”，它能加速设计过程、提供多样化的解决方案，但最终的架构决策权和质量守门职责，仍需由开发者自身承担。

三. 期末总结

1. 架构设计思维

四个单元的训练，让我的架构设计思维经历了一次完整的、从点到面的演进：

第一单元（表达式求导）：核心是层次化设计。通过递归下降，将复杂的表达式问题分解为“表达式-项-因子”的层次结构。思维重心在于如何通过对象封装和多态来处理不同类型的因子，并设计出可扩展的数据结构来表达多项式。
第二单元（多线程电梯）：核心是并发交互设计。思维从单线程的顺序逻辑，跃迁至多线程的并发世界。设计的重心转向了生产者-消费者等并发设计模式的应用，以及如何通过synchronized等同步机制保证共享资源的线程安全，实现线程间的有效协作与解耦。
第三单元（JML规格）：核心是契约式设计。架构设计在JML规格的强约束下进行，重心从“创造结构”转向“在契约下高效实现”。这促使我深入思考算法与数据结构的选择，通过缓存、动态维护等手段进行性能优化，深刻理解了接口与实现分离的价值。
第四单元（UML建模）：核心是模型驱动设计。思维回归到软件工程的顶层视角。通过UML，在编码前对系统的静态结构、动态行为和交互流程进行系统化建模。这是一种“设计先行”的开发模式，让我更加注重系统的整体性、可维护性和结构清晰度。

2. 测试思维

第一单元：测试思维主要是数据驱动的黑盒测试。通过编写自动化脚本，生成海量的、覆盖各种边界情况（如0，多个+ -，叠括号）的随机数据，并与外部标准库（如sympy）对拍，验证程序输出的正确性。
第二单元：测试思维转向并发问题的专项测试。面对多线程的非确定性，测试的重点是设计压力场景和特定时序的输入，以尽可能复现死锁、活锁和线程安全问题。学会了通过分析线程日志（TimableOutput）来定位和调试并发bug。
第三单元：测试思维进化为规格驱动的白盒与灰盒测试。JML规格成为了测试的“圣经”。一方面，通过Junit进行单元测试，确保每个方法严格遵循其requires和ensures子句。另一方面，在集成测试中，针对规格的复杂部分和性能瓶颈设计数据，验证实现的鲁棒性。
第四单元：测试思维是模型驱动的系统化测试。UML模型不仅是设计蓝图，也是测试指南。类图指导单元测试，状态图用于设计覆盖所有状态和有效转换路径的测试用例，顺序图则直接对应着集成测试的场景，验证对象间的交互是否符合预期。