2025 BUAA OO Unit4/课程 总结

[张泰尔-23371186]

一、Unit4单元总结

1.本单元所实践的正向建模与开发

本单元通过实践UML正向建模，核心贯彻了“设计驱动开发”（Design-First）的理念，即在编码前利用类图、状态图和顺序图分别构建系统的静态结构、定义关键对象的生命周期状态迁移、以及模拟对象间的动态交互时序。这种可视化建模方法显著提升了设计质量：类图作为系统骨架避免了冗余并明确了依赖；状态图通过规范状态转换规则预防了逻辑漏洞；顺序图则验证了交互流程的可行性，提前暴露协作问题。但由于是第一次接触starUML有一定学习成本，所以还是先完成的代码再做的图。。

2.最终架构设计 

最终类图如下：

 3.最终的代码设计和UML模型设计之间的追踪关系

类图与代码完全对应；顺序图描述的是用户预约到取书的流程；状态图是一本书籍的所以状态转换路径，其中状态直接映射于官方包中书籍状态的enum类；

二、大模型辅助

专业Prompt模板适配场景

• ROSES框架明确角色边界，通过Scenario限定业务上下文；

• COT思维链拆解设计步骤（例：“①识别核心类→②定义状态→③绘制消息流”），避免模型跳跃性错误；

三、在四个单元中架构设计思维的演进

经过面向对象设计与构造四个单元的学习，我的架构设计能力经历了显著的曲折演进。最初在第一单元，由于缺乏经验，设计的架构可以说比较糟糕，层层嵌套的方法调用导致调试与迭代异常困难，这无疑是一次深刻的教训。进入第二单元，我吸取了前车之鉴，在编码前投入了更多时间进行架构设计，整体结构清晰度虽有提升，但初次接触多线程编程的挑战带来了新的问题：为了实现线程间安全的交互功能，不得不引入比预期更多的同步控制逻辑，反而增加了代码的局部复杂度。第三单元虽然无需自主设计架构，但通过严格实现JML规格要求，极大地锻炼了我对异常行为处理和契约化设计的理解，弥补了之前对边界情况考虑的不足。而第四单元则是对前几单元所学架构设计能力的综合考验，得益于积累的经验（以及可能相对明确的需求），最终成功设计出了更清晰、可维护性更好的架构。回首这四个单元的磨练，我深刻体会到层次化分解设计思想以及合理运用设计模式的巨大价值，学会了在设计过程中主动控制每个类的单一职责与合理规模，并时刻警惕异常流程与边界条件的重要性，收获可谓非常丰厚。

四、在四个单元中测试思维的演进

在第一单元，测试思维可以说相当原始和被动——基本依靠手动构造几个简单案例运行看结果，调试过程如同大海捞针，一个深藏的方法调用错误就能耗费数小时，效率低下且覆盖严重不足，这为后续的迭代埋下了巨大隐患。惨痛的教训促使我在第二单元多线程电梯设计中转变思路：虽然架构清晰度有所提升，但面对线程交互的不可预测性，我深刻意识到仅靠手工测试远远不够，于是开始主动引入JUnit单元测试框架，针对关键同步控制模块（如调度器、队列访问）编写了大量并发测试用例，并学习使用日志和断点辅助定位竞态条件。尽管因经验不足，部分测试用例的设计冗余或针对性不强，但自动化测试的引入显著提升了问题定位速度和代码信心。进入第三单元JML规格实现，测试思维迎来了质的飞跃：严格的契约化要求迫使我必须前置思考所有可能的异常行为和边界条件（如参数越界、空指针、无效状态迁移），并依据JML规格逐条编写对应的验证测试。这不仅极大锻炼了对“异常驱动测试”的理解，也让我学会了如何将模糊的需求转化为可验证的测试断言。最终在第四单元的综合架构设计中，我得以融会贯通前三单元的经验，并熟练运用JUnit等工具实现自动化回归。回顾这段历程，我深刻体会到：健全的测试不是编码后的补救措施，而是驱动设计合理化（如降低耦合以提升可测性）、保障软件质量的核心支柱；从“事后调试”到“测试先行”，从“手动碰运气”到“自动化覆盖”，这正是测试思维走向成熟的必经之路。

五、课程收获

经过四个单元的磨练，我对于层次化设计、多线程编程和测试策略有了更加深入的理解与体会。从第一单元面对复杂指导书时的茫然无措、跌跌撞撞，到第二单元在多线程挑战中逐步摸索出架构设计的门道、建立起解决问题的信心，再到面对第三、四单元规格化实现与综合架构设计时的愈发从容与游刃有余，我真切地感受到自己的代码能力与工程思维实现了显著的跃升。这段旅程虽有艰辛，但收获满满。