BUAA OO2025 Unit4

[吴长骏—23373290]

BUAA OO2025 Unit4

总结本单元所实践的正向建模与开发

本单元实践的正向建模与开发围绕图书馆管理系统展开，从需求分析出发，通过 UML 类图进行领域建模，再依据模型完成代码实现，形成完整的软件开发流程。首先进行需求分析，明确图书馆借还、查询、整理等功能模块及借阅 / 预约流程、图书移动限制等业务规则；接着开展领域建模，识别图书、副本、用户、图书馆等核心实体，设计实体属性与方法，梳理实体间的关联（如 Book 包含 Copy 的聚合关系、Library 管理 Book 和 User 的组合关系）及依赖关系，构建 UML 类图。

正向建模的优势体现在通过 UML 类图明确系统结构、提升代码可维护性并提前暴露设计缺陷，但也面临模型抽象难度大、需维护模型与代码一致性及处理复杂业务逻辑（如预约有效期计算）等挑战。实践中需解决类图与代码不一致问题。通过本次实践，掌握了从需求到建模再到编码的正向开发流程，理解面向对象设计原则，未来可进一步引入设计模式、完善异常处理和优化性能，以增强系统的健壮性与可扩展性，正向建模的工程化思维为大型项目开发提供了重要方法论基础。

总结架构设计，并对比分析最终的代码设计和UML模型设计之间的追踪关系

代码实现阶段，各实体类依据类图设计编写，如 Book 类管理副本列表、提供查找副本等方法，User 类封装借阅和预约状态及能否成功借书的校验逻辑，Library 类作为核心管理类协调借还、预约等业务流程并处理开馆 / 闭馆整理，其他类如借还处，预约处，阅览室，起到的作用大多很小，只作为一个存放书籍的特殊集合，相当于弱化版的User类。关键业务逻辑实现涵盖借阅与预约规则（如 A 类书不可借阅、B 类书每人限 1 本等通过 User 类方法校验）、图书移动与整理等关键流程。

整体来看，代码与 UML 模型保持了高度的追踪性，模型中的每个类、属性、方法及关系均在代码中得到落地，确保了设计与实现的一致性，体现了正向建模的工程化流程。但在实际的作业完成过程中，往往会出现一些问题，比如设计时首先反而要考虑能否通过评测，再兼顾代码实现是否方便合理，往往不断的进行来回修改，真的十分麻烦，感觉反而没有起到简化任务的作用，也可能由于任务逻辑较为简单，在心里就想好该怎么写了。

根据大模型辅助正向建模的体验，总结分析如何引导大模型在复杂场景中完成架构设计任务

首先需向大模型清晰传递需求的功能性边界（如图书馆管理系统的借还、预约、整理流程）。例如，在图书馆场景中，需明确说明 “A 类书不可借阅”“预约保留 5 天” 等规则，并要求模型围绕这些规则设计实体与逻辑。通过具象化场景用例（如 “用户借书失败的多种情况”）引导模型识别核心实体（如 Book、User）及其交互，避免模型陷入泛化设计。同时，可通过追问补充细节，促使模型考虑架构的扩展性。
在领域建模阶段，采用从概念到细节的分层引导策略，先识别核心实体并明确其唯一标识和关键属性，再梳理实体关系并通过示例验证确保符合业务逻辑，最后针对每个实体定义行为逻辑并结合规则约束细化方法。同时，利用 UML 建模语言规范输出，要求模型为每个类指定属性可见性、方法参数类型和返回值，使用正确的 UML 符号表示关系，并通过时序图或状态图补充复杂逻辑描述以避免歧义。

大模型的初始设计可能存在过度理想化或遗漏边界情况，需通过迭代验证优化架构，基于需求文档中的测试用例检查模型是否覆盖所有场景，评估性能与可维护性并引导模型优化，调整不符合编程语言特性的设计以确保代码可实现性。还需主动注入工程知识校准设计，在处理对象创建逻辑时提示模型考虑设计模式，要求模型遵循编码规范并示例化正确写法。大模型在复杂场景中完成架构设计的关键在于知识整合能力和逻辑推导能力，可快速融合需求描述、领域规则和工程模式生成整体架构，深入分析业务逻辑的依赖关系并推导相应的类方法与交互流程，但模型输出仍需人工批判性验证，关注边界情况处理和性能瓶颈，主动指出问题，并让大模型寻求解决，通过 “需求引导 — 模型生成 — 验证调整” 的循环提升大模型在复杂场景下架构设计的准确性与实用性。

总结自己在四个单元中架构设计思维的演进

在四个单元的学习实践中，我的架构设计思维经历了从基础认知到系统构建、从理论模仿到创新应用的逐步深化过程。最初，OOpre的提升毕竟有限，只是初步引导我们进入面向对象的世界，对架构设计仅停留在概念层面，通过第一个单元的学习，初步掌握了面向对象的思维模式，第一单元的表达式解析计算也是非常艰巨，非常复杂的任务，迭代过程需要进行的修改非常多，代码规模很庞大，当时设计往往停留在望而却步不知如何入手的困境，不过好在最终还是很顺利了。

进入第二个单元，在电梯多线程控制的情景下，多线程条件下需要有更清晰的架构设计和一以贯之的设计思路，更要明确好每个部分的职责，当时更愿意简单思考之后，直接上手些代码，并在过程逐步修改，最终完成整个作业，我觉得结合代码的思考确实很高效。第三单元，jml规格单元设计上不需要出力，只要按照规格完成就好，编写代码的过程中也更好理解了面向对象的特性，第四单元强调利用uml进行模块化设计，再编写代码，确实觉得不是很方便，但在更复杂的业务条件下，利用UML设计图的设计方法应该才是更好的解决方案。

总结自己在四个单元中测试思维的演进

这学期几乎没有进行什么针对性的有效测试，没有精力去学着搭建评测机，不然也不会强测丢这么多分了。一开始就是随便编一些数据测一下功能。后面自己编的测试尽可能囊括每一个小功能小细节的测试。第三单元学到的junit单元化测试应该是一个很不错很有用的措施。

总结自己的课程收获

在六系的第二个学期又快结束了，太好了太好了太好了，这学期面向对象同样挑战满满，学到了很多知识，不过可以参考自学的资料也很多，其实感觉最难的是一个单元的第一次作业，从无到有的搭建整个结构，还需要有留有一定的扩展性，以应对未知的功能扩展，课程组在课程难度设计上还是比较合理的，在一定程度上问题都能自己很顺利的解决，最终完成了这么多次作业还是很有满足感的，没想到自己感觉啥也不会还是都自己坚持过来了。

感觉不太合理的地方就是时间规则上，互测的时间感觉没必要拉那么长，感觉很多人就是base分够了就结束了，bug修复开始的时间比下一次作业开始还靠后，中间的空窗期很浪费时间，而且感觉很多节假日的延期很没必要，打乱正常节奏，个人感觉反而有点不适应。。周三上机这个环节个人感觉也没什么帮助，就电梯单元的第一次实验上机给了我架构上的启发。。感觉研讨课也很趋于形式了，唯一感觉有用的一次是电梯单元同组同学分享出来一个可能的bug发现我自己也有。。