OO第四单元博客总结

[龙毓凡-24371411]

一、本单元正向建模与两阶类图的作用

本单元实践的是模型驱动开发，即先构建精确的UML模型，再据此生成代码。在这一过程中，两阶类图构成了正向建模的核心轴心。

第一阶段为初步设计类图，侧重于领域概念建模，仅关注核心实体（如类、接口、操作）及其泛化、实现、关联等静态关系，暂不涉及异常、存储或具体算法。该阶段的作用在于将需求转化为清晰的业务结构，避免过早陷入实现细节。第二阶段为细化实现类图，此时引入设计模式与实现策略，明确方法的完整签名、可见性及返回值，并补充缓存、工厂等辅助类。该阶段的作用是建立设计与代码间的契约。两阶段的分工实质上是将“系统应包含哪些对象”与“这些对象如何协作实现功能”解耦，使得代码编写阶段只需严格遵循第二阶段的类图进行填充，显著降低了认知负载和重构风险。

二、架构设计及与UML模型的追踪关系

UML模型与最终代码之间存在明确的结构追踪和行为追踪关系。在结构层面，UML模型中定义的每一个元类（如UmlClass）在代码中都有对应的封装类，其属性、ID和父级引用均与模型保持严格一致，实现了元模型层到实现层的直接映射。在行为层面，顺序图和状态图中描述的活动顺序在代码中体现为方法调用栈的有序执行，验证流程与模型中的交互顺序完全对应。值得注意的是，最终代码是UML模型的超集：模型仅约束静态关系和逻辑约束，而代码额外增加了缓存策略、异常处理及算法优化，这些精化并未破坏模型定义的一致性，而是在保证语义正确的前提下提升了运行效率。这种追踪关系的建立，使得模型发生变更时能够快速定位受影响的方法，有效降低了维护成本。

三、引导大模型完成复杂架构设计的策略

利用大模型辅助架构设计时，直接给出开放性问题往往导致结构混乱或产生幻觉。基于本单元实践，有效的引导策略可分为三个层次。第一层是任务分解，不要求模型直接生成完整代码，而是先让其将复杂验证任务拆分为若干个独立子模块，利用人类的设计直觉预先划定功能边界，防止模型过度泛化。第二层是状态契约显式化，针对关键算法要求模型清晰描述数据状态的转换过程，并据此设计缓存结构，这一做法能充分发挥大模型在逻辑推理方面的优势，避免产生隐含副作用的代码。第三层是反事实检验，让模型主动构造违反当前架构设计的极端样例，并追问对应的拦截机制，若无法拦截则修正架构。这种“自我博弈”能提前暴露架构的薄弱点，比单纯的正向生成更能高效迭代出健壮的设计。

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

第一单元表达式求导时，架构设计仍停留在面向算法阶段，将数据用线性结构传递，封装与解耦意识薄弱。第二单元多线程电梯调度成为一个转折点，生产者-消费者模式及调度器单例的引入，使我意识到设计模式在并发场景下的核心价值，思维重心从“数据计算”转向“状态同步”。第三单元基于JML规格的开发，迫使架构严格遵循契约式设计，接口的划分不再凭主观直觉，而是依据前置和后置条件进行精确规划，架构的规范性显著提升。第四单元的正向建模则促使思维上升至模型驱动的全局高度，设计决策不再依赖感性经验，而是通过模型的结构自洽性推导出必然结论，实现了从“实现导向”到“模型导向”的根本转变。

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

第一单元的测试主要依赖手动构造样例，验证方式粗放，覆盖不够系统。第二单元面对并发不确定性，开始编写高压力随机测试脚本并配合日志分析，测试目标从“检验正确性”扩展至“检验稳定性和可复现性”。第三单元引入JML后，测试转向基于形式规格的单元测试，依据等价类划分和边界条件进行设计，重点关注前置异常和后置结果的匹配，测试覆盖率的度量也从行数转向分支和异常路径。第四单元则演进为基于模型的验证，不仅检验输出正确性，还通过结构检查脚本确保代码实现未偏离UML模型，测试的定位从“发现错误”上升为“保证一致性”。

六、课程整体收获

通过四个单元的连续训练，我完成了从“编写程序”到“构造系统”的认知跃迁。最大的收获在于建立了面向复杂问题的架构思维：面对任何业务需求，第一反应不再是局部实现方案，而是模块划分、契约约束与状态流转的整体设计。同时，对形式化规格（JML、UML）的价值有了切身体会，精准的契约是抵御架构腐化的关键，也是团队协作的基础。此外，在高强度的调试与互测中积累了高效定位异常的能力，对设计模式的应用也形成了肌肉记忆。这些收获将贯穿后续的工程实践，构成了面向对象设计与构造课程最核心的长期价值。