OO Unit4总结

董远翔-24373414 2026-06-24 13:50:03

一、本单元正向建模与开发总结

第四单元的核心是从“代码驱动”向“模型驱动”转变，即正向建模与开发。在以往的开发中，我们往往习惯于先构思核心逻辑，边写代码边重构，最后再为了应付文档要求去逆向生成类图。而在本单元，UML真正成为了代码的蓝图。

在这个过程中，两阶类图发挥了不可替代的桥梁作用：

第一阶：领域概念类图
- 作用：剥离实现细节，专注于业务逻辑和需求本身。在这一阶段，我们只关心系统中有哪些实体（如 User, Book, Library），以及它们之间的自然关联、组合与聚合关系。
- 实践体会：这一阶类图帮助我们在宏观上理清了需求边界，避免了过早陷入数据结构（如用 HashMap 还是 ArrayList）的纠结中。它回答了“系统是什么”的问题。
第二阶：具体实现类图
- 作用：在领域模型的基础上，引入设计模式、具体属性类型、方法签名以及辅助类（如解析器、工厂类等）。这是对领域模型的工程化降维。
- 实践体会：在这一阶段，我们将抽象的关联关系具象化为类中的引用或容器，将业务动作细化为方法的出入参。有了第一阶的骨架，第二阶的填充变得极具目的性，它回答了“系统怎么做”的问题。两阶类图的递进，有效抹平了自然语言需求与机器代码之间的巨大鸿沟。

二、架构设计与UML模型追踪关系分析

本单元的图书管理系统架构设计，严格遵循了“高内聚、低耦合”的原则，并以状态机和类图为指导进行了系统划分。

架构设计总结：

控制层：负责解析外部输入指令，调度各个子系统。

业务逻辑层：以 Library 为核心，管理 Book 和 User，内部集成了借还书、预约、漂流等核心规则。

状态管理：针对图书的生命周期（如：在架、被借阅、预约中、维修中），严格使用状态图进行约束，避免了非法的状态跃迁。

代码设计与UML的追踪关系：

类与属性的 1:1 追踪：代码中 src 目录下的每一个实体类，其类名、可见性修饰符、成员变量，均能与UML第二阶类图精确对应。如果在编码阶段发现需要新增管理类（如发现 Library 过于臃肿，需要拆分出 BorrowManager），必须先回退修改UML，再推进代码，确保模型永远是代码的“Single Source of Truth”。
方法行为与顺序图的追踪：复杂的交互逻辑（如用户触发借书动作后的库存校验、扣费、状态更新）在顺序图中定义了消息的传递顺序。代码中的方法调用栈严格遵守了顺序图中的 Lifeline 交互路径。
状态流转与状态图的追踪： UML状态图定义了图书或系统的各个合法状态及触发事件。在代码中，这部分被映射为 switch-case 逻辑或状态模式。任何在UML中未定义的跃迁，在代码中均作为异常情况抛出，确保了系统状态的绝对安全。

三、大模型使用经验总结

在本单元的正向建模中，大语言模型成为了一个极具潜力的架构助手。但在复杂场景下，如果仅给出宽泛的提示词，大模型往往会生成过度设计或偏离业务的“套路化”代码。以下是我总结的引导策略：

角色注入与边界界定：不要直接让模型“写一个图书管理系统”。应首先设定其角色（“你现在是一位拥有10年经验的系统架构师”），并明确领域边界（“不涉及数据库连接，仅在内存中通过面向对象方式模拟”）。
分步进行两阶建模：
- 投喂需求文本，要求模型仅提取“名词实体”和“动词行为”，构建第一阶领域模型。
- 确认实体无误后，要求模型基于面向对象原则分配职责，探讨是否需要引入设计模式，构建第二阶实现模型。
强约束条件的注入：在Prompt中必须明确绝对不可违背的红线。例如，明确指出系统状态机流转的刚性规则，要求模型在生成类的方法签名时，必须考虑到状态合法性的前置校验。
提供UML DSL输出：引导模型输出 PlantUML 或 Mermaid 格式的代码，直接在渲染工具中可视化其设计的架构。通过可视化的图表，人类开发者可以快速发现逻辑漏洞，并精准地将错误信息反馈给大模型进行迭代修正。

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

回顾整个学期，我的架构设计思维经历了四次显著的蜕变：

第一单元（多项式解析）：从面向过程到面向对象的破局。初期的代码充满了长篇大论的 if-else 和硬编码。通过本单元，我初步理解了递归下降、层次化设计以及类的单一职责原则，学会了将复杂表达式抽象为因子和项的组合，摆脱了“大主类”的低级写法。
第二单元（多线程电梯）：理解并发与解耦。这是思维跳跃最大的一环。从单线程的线性思维转向多线程的并发思维。通过生产者-消费者模型、观察者模式，我学会了如何让不同的对象在共享内存下安全协作。架构的重点变成了“锁的粒度”、“共享对象的安全封装”以及严格的状态隔离。
第三单元（JML社交网络）：学会契约导向与接口隔离。本单元让我认识到，架构不仅仅是画框框，更是制定契约。基于JML，我学会了分离“接口定义”与“内部实现”。架构设计变成了定义方法的前置条件、后置条件和副作用，同时在内部实现中为了满足性能要求，灵活运用图论算法和并查集优化。
第四单元（UML与图书管理）：系统级视角与模型驱动。不再是拿到需求就写代码，而是站在系统工程师的高度，用两阶类图、状态图和顺序图进行正向建模。架构设计成为了一种“规范表达”，代码只是设计水到渠成的产物。

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

如果说架构决定了系统的上限，那么测试就决定了系统的下限。

第一单元：黑盒与边界测试。测试思维停留在手工构造边界数据（如前导零、多重括号、大数运算），主要依赖 Print 语句和简单的对比脚本。
第二单元：压力测试与死锁防范。多线程的不可复现性打破了常规测试的幻觉。测试思维升级为构建高并发的数据生成器，并编写评测机分析日志中的时序问题，重点排查线程饥饿、死锁和轮询现象。
第三单元：契约驱动与单元测试。引入了 JUnit 框架，测试思维变得更加微观和严谨。针对 JML 契约，逐一编写单元测试用例验证前置条件的阻挡和后置条件的满足，开始关注代码分支覆盖率。
第四单元：模型验证与集成测试。测试不再仅针对单一方法，而是针对系统的状态机和业务流。通过构造复杂的用户行为序列，验证系统状态是否能按 UML 状态图预期流转，实现了从代码测试向模型逻辑测试的跨越。

六、课程收获与总结

2026年的OO课程是一场充满挑战的修行。它不仅让我熟练掌握了Java语言和各种设计模式，更重要的是，它系统性地打磨了我的工程素养。我深刻地认识到：“写代码”仅仅是软件工程中极其末端的一环。真正优秀的工程师，其核心竞争力在于面对模糊的复杂需求时，能够通过严谨的正向建模理清实体边界，利用契约规范模块交互，在多并发环境下保障系统稳定性，并拥有运用大型工具提升工程效率的能力。

...全文