2026-BUAA-OO-U4-单元总结

一、总结本单元所实践的正向建模与开发重点分析两阶类图在正向建模过程中的作用第四单元和前三个单元最大的不同在于它不再是直接写代码而是要求我们先进行 UML 正向建模再依据模型完成代码实现。整个流程大致变成了阅读指导书理解图书馆业务规则抽象领域对象绘制一阶类图根据类图完成代码在实现过程中补充状态图、顺序图最后通过二阶类图检查代码与模型之间的对应关系。本单元的图书馆系统虽然算法难度不高但业务状态较复杂。图书可能处于普通书架、精品书架、借还处、预约处、阅览室、用户持有等不同位置用户可能进行借书、还书、预约、取书、阅读、归还、评分、续订等操作第三次作业又增加了信用分、借阅期限和逾期判断。因此如果直接写代码很容易把大量逻辑堆在一个类中。在一阶类图阶段我主要完成了领域对象的划分Book表示 ISBN 层面的图书BookCopy表示具体副本User表示用户Reservation表示预约记录Location及其子类表示图书馆中的不同地点LibraryManager负责全局业务调度。两阶类图在正向建模中起到了“前后校验”的作用。一阶类图负责提前约束设计在编码前一阶类图要求我先思考类的职责和关系。例如如果没有区分Book和BookCopy后续的轨迹查询、借阅期限、预约指定副本都会很难实现如果没有抽象Location不同地点之间的图书移动逻辑也会产生大量重复代码。二阶类图负责实现后的反向校准实现过程中代码会自然地出现一些新属性和新方法。例如第三次作业中我在User中加入信用分和阅读日期在BookCopy中加入应还日期和逾期惩罚标记在Limit中统一封装权限判断。二阶类图的意义就在于检查这些实现细节是否仍然符合最初的架构方向。两阶类图形成设计闭环一阶类图让我在写代码前建立系统骨架二阶类图让我在写完代码后反思系统是否偏离原设计。这样 UML 就不只是提交材料而是真正参与了“需求分析—架构设计—编码实现—反向检查”的全过程。二、总结本单元作业的架构设计并对比分析最终的代码设计和 UML 模型设计之间的追踪关系本单元最终代码大致可以分为五层。输入解析层这一层主要包括MainClass和CommandHandler。MainClass负责初始化图书馆、读取馆藏并循环处理输入命令CommandHandler负责把官方输入命令转换为内部方法调用例如借书、预约、取书、阅读、还书、续订等。这一层不直接处理复杂业务只承担“命令分发”和“结果输出”的职责。业务调度层核心类是LibraryManager。它维护全局的图书、用户、地点和预约队列并负责主要业务流程例如borrowBook借书returnBook还书orderBook预约pickBook取书readBook阅读restoreBook归还阅览室图书renewBook续订open / close / arrange开馆、闭馆和整理流程。这个类相当于整个系统的调度中心负责协调各个对象之间的状态变化。领域对象层这一层包括Book、BookCopy、User和Reservation。Book保存 ISBN、类别、所有副本和评分BookCopy保存副本编号、当前位置、持有者、移动轨迹、应还日期等User保存持有图书、当前预约、阅读图书、信用分等Reservation保存预约用户、预约图书、送达副本、失效日期等。这种设计把不同层次的信息分开ISBN 级别的信息属于Book副本流转信息属于BookCopy用户状态属于User预约生命周期属于Reservation。位置管理层我用抽象类Location表示地点并派生出BookshelfTreasuredBookshelfBorrowAndReturnOfficeAppointmentOfficeReadingRoom各地点都维护自己持有的图书副本集合。这样图书移动时只需要从旧地点删除、加入新地点并调用BookCopy.moveTo记录轨迹即可。规则辅助层Limit用来封装借阅、预约、取书和阅读的规则。例如A 类书不可借阅和预约B 类书同一时刻只能持有一本C 类书同 ISBN 只能持有一本借阅和预约需要信用分大于 80阅读 A 类书需要信用分大于 40。从 UML 到代码的追踪关系来看整体是比较清晰的。类名一阶类图中的核心类在最终代码中基本都得到保留。职责CommandHandler负责输入分发LibraryManager负责业务调度领域类负责维护自身状态。状态状态图中的书架、预约处、阅览室、借还处、用户持有等状态对应代码中的LocationType。消息顺序图中的对象交互对应代码中从CommandHandler到LibraryManager再到User、Location、Reservation的调用链。当然最终代码和 UML 不可能完全一致。代码中会出现一些私有辅助方法例如removeFromCurrentPlace、moveCopyTo、applyOverduePenalties等它们更多是实现细节不一定需要在一阶类图中过度展开。整体来看本单元代码与 UML 模型之间基本达到了“核心结构一致、实现细节补充”的状态。三、根据使用大模型辅助正向建模的体验总结分析如何引导大模型在复杂场景中完成架构设计任务在第四单元中我使用大模型的重点从“辅助写代码”转向了“辅助建模”。这次体验让我意识到大模型可以帮助整理需求和检查遗漏但不能直接替代架构设计。比较有效的使用方式如下。先让大模型拆解需求而不是直接生成类图对于图书馆系统可以先让它把需求分成几类实体对象用户操作图书状态整理流程信用分规则时间和过期规则。这样可以避免一开始就得到一个看似复杂但不一定正确的类图。要求它说明每个类的职责比如不能只让它列出Book、BookCopy、User还要让它解释为什么Book和BookCopy要分开为什么预约要抽象成Reservation为什么地点可以抽象成Location哪些逻辑应该放在LibraryManager哪些逻辑应该下放到对象自身。控制输出粒度大模型有时会过度设计生成很多 Service、Factory、Strategy 类。对于 OO 作业来说过多的类反而会增加复杂度。因此我会限制它不要设计过多无必要的类类图中的类要能在代码中真正落地方法和属性要能对应题目中的实际业务。让它做反向审查在完成一阶类图后可以让大模型检查是否覆盖借书、还书、预约、取书是否覆盖阅读、归还、评分是否覆盖信用分、逾期、续订是否覆盖图书轨迹查询是否存在职责过重或状态归属不清的问题。人工做最终决策大模型生成的方案经常“看起来合理”但不一定符合评测细节。比如日期计算、预约失效、闭馆整理、信用分上下界等规则必须自己根据指导书推演。因此大模型更适合当“需求整理器、方案生成器、遗漏检查器”而不是最终设计者。我的总结是在复杂场景中使用大模型关键不是问“帮我写一个架构”而是分阶段引导它完成需求拆解、领域抽象、职责划分、模型审查。最终的架构取舍仍然由自己完成。四、总结自己在四个单元中架构设计思维的演进四个单元下来我的架构设计思维经历了一个逐渐成熟的过程。第一单元从字符串处理到对象建模第一单元是表达式解析与化简。最开始我关注的是怎么把表达式算对后来逐渐把系统拆成词法分析、语法解析、表达式结构和多项式计算等部分。这个单元让我理解到复杂问题不能一直用字符串硬处理而应该抽象成对象和层次。第二单元从静态结构到动态协作第二单元是电梯调度。这个单元让我意识到架构不仅包括类之间的静态关系还包括线程之间的动态交互。调度器、请求队列、电梯线程、共享资源之间需要正确协作否则就会出现死锁、忙等或调度错误。第三单元从功能实现到规格约束第三单元是 JML 规格化设计。这个单元让我认识到代码不仅要能运行还要满足清晰的契约。方法的前置条件、后置条件、副作用范围都需要被严格理解。架构设计也不只是“怎么写方便”还要考虑对象状态是否满足规格。第四单元从代码驱动到模型驱动第四单元要求先画 UML再写代码。这让我真正体验到正向建模的意义。类图帮助我确定对象职责状态图帮助我理解图书流转顺序图帮助我梳理对象交互二阶类图帮助我检查代码是否偏离设计。总体来看我的架构思维经历了第一单元学会分层和抽象第二单元学会并发协作第三单元学会契约和状态一致性第四单元学会正向建模和模型追踪。从“能写出代码”到“能设计系统”这是这门课对我影响最大的地方。五、总结自己在四个单元中测试思维的演进我的测试思维也随着四个单元逐渐变化。第一单元以输入输出正确性为核心表达式单元中测试主要围绕表达式等价性展开。我会构造括号嵌套、负号、指数、函数、选择因子、求导等样例检查输出是否正确。这个阶段的测试更偏黑盒。第二单元开始关注并发时序电梯单元中很多 bug 不是每次都稳定出现。比如死锁、线程唤醒错误、请求分配错误都和时序有关。因此我开始通过批量数据和特殊场景测试程序例如大量请求、维修请求、换乘请求、双轿厢冲突等。第三单元按 JML 规格设计测试JML 单元让我形成了更系统的测试方法。测试时不仅要看返回值还要检查前置条件是否正确处理后置条件是否满足对象状态是否正确变化pure方法是否没有副作用assignable限制之外的状态是否保持不变。这让我从“测结果”转向“测契约”。第四单元按状态流转和模型设计测试UML 单元中测试重点变成了业务流程和状态转移。例如借书后图书是否从书架移动到用户还书后是否进入借还处整理后是否回到正确书架预约满足后是否进入预约处取书后是否由用户持有阅读后是否进入阅览室逾期、续订、信用分变化是否正确。这一单元让我意识到UML 图也可以成为测试依据。类图帮助检查对象职责状态图帮助检查状态覆盖顺序图帮助检查对象交互。因此我的测试思维大致经历了从测输出到测场景到测规格再到测模型和生命周期。测试不再只是提交前的查错工具而是帮助理解需求和验证架构的重要手段。六、总结自己的课程收获完成四个单元后我最大的感受是OO 课程很累但确实让我从“写程序”逐渐转向“设计系统”。知识层面的收获四个单元分别训练了不同能力第一单元表达式解析、递归下降、对象抽象第二单元多线程、调度策略、线程安全第三单元JML、规格化设计、JUnit 测试第四单元UML、正向建模、状态图和顺序图。编码层面的收获以前写代码时我更关注功能是否能跑通。现在我会更早考虑类的职责是否清晰数据应该归属于哪个对象状态变化是否集中管理未来迭代是否容易扩展是否存在过度耦合。比如第四单元中区分Book和BookCopy、抽象Location、用Limit封装规则都让后续新增功能更加自然。调试层面的收获遇到 bug 时我不再只是盲目输出调试而会先判断问题类型是解析问题是状态更新问题是并发时序问题是规格理解问题还是架构职责划分问题。这种分类思维让定位 bug 的效率提高了很多。工具使用层面的收获我也逐渐学会了更合理地使用大模型。它可以帮我整理需求、生成测试思路、检查遗漏和分析设计风险但不能完全替代自己的判断。尤其是 OO 作业中很多细节和边界条件必须自己认真推演。工程思维层面的收获这门课让我真正理解了抽象、封装、规格和模型的价值。好的架构不是为了让代码看起来复杂而是为了让系统在需求变化时仍然可维护在出现 bug 时能够快速定位在多人协作时能够明确责任边界。总的来说四个单元构成了一条完整的训练路径表达式单元让我理解对象抽象电梯单元让我理解动态协作JML 单元让我理解规格契约UML 单元让我理解正向建模。经过这门课我对“面向对象设计与构造”有了更真实的理解先理解需求再抽象对象先明确职责再编写代码先建立模型再追踪实现先设计测试再相信程序。这是我在 OO 课程中最重要的收获。