面向对象第四单元博客作业

李昀达-ZC061022 2026-06-23 20:51:31

前言

随着第四单元最后一次强测和互测的尘埃落定，历时一学期的“面向对象设计与构造（OO）”课程终于迎来了终章。从第一单元面对表达式展开时的手忙脚乱，到第二单元多线程电梯里的高并发调试，再到第三单元契约式编程的严谨规约，最终在第四单元，我们真正步入了“正向建模与开发”的系统化工程大门。

本文将针对第四单元的 UML 正向建模实践进行深度解构，并对全学期的架构演进、测试思维蜕变及大模型辅助设计体验进行系统性回顾。

一、本单元所实践的正向建模与开发

在过往的开发习惯中，我们往往倾向于“代码先行”——拿到需求后直接敲代码，遇到架构问题再不断修补，最后利用工具逆向生成 UML 图。而本单元彻底颠覆了这一模式，强制我们实践了正向建模与开发（Forward Modeling and Development）：先建立模型（思维蓝图），再依据模型指导代码实现。

两阶类图在正向建模过程中的作用

本单元的核心工具是两阶类图（Two-stage Class Diagram），它将设计过程清晰地拆分为两个阶段，承载了不同的工程价值：

第一阶段：概念类图（Conceptual Class Diagram）
- 核心作用：专注于业务领域的实体抽象与关系建模。在面对复杂的 UML 元素解析需求时，概念类图帮助我们脱离 Java 具体语法的束缚（如暂时不考虑使用 HashMap 还是 ArrayList），而是聚焦于元模型之间的本质关系（如 MyClass 与 MyInterface 的继承与实现关系，MyStateMachine 与 MyRegion 的组合关系）。
- 工程价值：防止开发者过早陷入编码细节，确保系统的骨架符合“高内聚低耦合”原则，从根本上杜绝了因方向性错误导致的后期毁灭性重构。
第二阶段：实现类图（Implementation Class Diagram）
- 核心作用：在概念类图的基础上，注入技术实现的工程细节。这一阶段需要明确每个类的属性类型、方法签名、可见性修饰符（+、-、#），以及为了支撑业务逻辑而引入的辅助类和数据容器。
- 工程价值：它是模型通往代码的桥梁。一个高完备性的实现类图可以做到“所见即所得”，在编码阶段几乎只需按图索骥地直接翻译成 Java 类的定义，极大地降低了编码时的随机性和出错率。

二、本单元作业的架构设计与 UML 模型追踪关系

1. 三次作业的架构设计演进

面对扁平、无序输入的 UmlElement，我的架构设计采用了“多级分步解析 + 装饰器拓展 + 图论工具解耦”的策略：

层次化包装（Element Wrapper）：不直接操作官方的 UmlElement，而是建立了自己的包装类（如 MyClass、MyInterface、MyStateMachine 等），让它们内部持有官方元素，并构建纵向的嵌套关系。
多轮迭代解析（Multi-pass Parsing）：
- 第一轮：解析顶级容器（UmlClass、UmlInterface、UmlStateMachine、UmlInteraction），在内存中建立这些核心实体的实例。
- 第二轮：挂载内部基本元素（UmlAttribute、UmlOperation、UmlState、UmlLifeline），并将其分配给对应的父级容器。
- 第三轮：连接跨元素的关联关系（UmlGeneralization、UmlInterfaceRealization、UmlTransition、UmlMessage），激活整个关系网络。
正规性检查解耦（Rule Checker Decoupling）：将 R1 至 R8 的规则检查逻辑独立为 UmlRuleChecker 类，内部调用封装好的图论算法工具类 GraphUtils（基于 DFS 环路检测和拓扑排序），保证了核心解析器的纯粹性与高可维护性。

2. 代码设计与 UML 模型设计之间的追踪关系（Traceability）

最终交付的代码与 UML 模型呈现出极强的动态追踪与映射关系：

UML 模型组件	Java 代码实现组件	追踪与映射关系详细说明
UMLClass / UMLInterface	`MyClass.java` / `MyInterface.java`	完全追踪：模型中的每个类/接口在代码中都有完全对等的类定义，作为实体的核心。
UMLAttribute / UMLOperation	类的属性（如 `fields`）与方法签名	完全追踪：其名称、类型、可见性在代码中通过 `private`、`public` 严格对齐。
UMLStateMachine / UMLTransition	`MyStateMachine.java` 内部邻接表	结构映射：模型中的状态机拓扑在代码中转化为基于 `HashMap` 构建的图结构。
R2 / R4 环路与重复实现规则	`GraphUtils.java` / `UmlRuleChecker.java`	行为衍生：UML 静态图无法表达算法逻辑，代码中的图论搜索类是为了支撑模型中“正规性约束”而延伸出的具体行为实现。

对比分析：最终的代码与模型在结构骨架上达到了 95% 以上的一致性。极少数的偏差在于：为了保证强测中的查询效率，我在代码中大量使用了 HashMap 进行 O(1) 的索引，而在 UML 模型中，这些仅体现为基础的组合或关联关系。这种高度的追踪性使得需求变化时，只需修改模型即可精确锁定代码的修改范围。

三、大模型辅助正向建模的引导策略

在复杂场景下，如果直接向大模型（LLM）索要代码，往往会得到臃肿、面向过程或充满幻觉的产物。通过本单元的实践，我总结出了一套引导大模型完成复杂场景架构设计的核心策略：

上下文锚定与角色规范（Context Anchoring）

拒绝宽泛提问。首先将官方给出的 UML 元素所属关系图（元模型定义）以及具体的 Rule 文本作为精确上下文喂给大模型。设定其角色为“资深软件架构师”，并明确限定约束：“请遵循面向对象设计原则（SOLID），只输出顶层类图结构设计与关联关系，严禁编写具体的方法内部逻辑”。
两阶渐进式提示词（Two-stage Prompting）

完美契合正向建模的思想，分步引导：
- 第一步（聚焦概念）：“面对无序输入的 UML 元素，为了实现多轮解析并理清继承关系，请帮我设计第一阶段的概念模型。列出需要哪些 Wrapper 类，以及它们之间的组合关系。”
- 第二步（聚焦落地）：“现在概念模型已确定。请在此基础上，为 MyClass 注入合适的数据结构以支持高效的方法查重，并考虑如何设计接口以引入图论算法来检查循环继承。”
约束性指令注入（Constraint Injection）

在提示词中显式声明设计模式约束。例如，在设计状态机转移和触发器逻辑时，输入指令：“为了确保未来扩展新增状态类型时符合开闭原则，请使用状态模式（State Pattern）设计该模块”。通过这种方式，成功约束了大模型，避免了其生成面条式的 switch-case 代码。

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

纵观整个学期，我的架构设计思维经历了一场从“局部到整体”、“静态到动态”、“直觉到理性”的深刻蜕变：

第一单元 (表达式展开) -> 第二单元 (多线程电梯) -> 第三单元 (JML规格) -> 第四单元 (UML正向建模)
[面向对象转型: 递归下降]  [并发空间构建: 线程安全]  [契约式编程: 规格规约]  [模型驱动开发: 全局架构观]

第一单元（表达式展开）——【面向过程向面向对象的转型】
- 起步状态：最初的代码带着浓厚的 C 语言面向过程色彩，试图用一个大类解决所有问题。直到重构引入递归下降算法后，才第一次真正体会到“对象自治”与“高内聚低耦合”的威力，学会了将词法分析（Lexer）、语法分析（Parser）和各种因子（Factor、Term、Expr）抽象为独立的类。
第二单元（多线程电梯调度）——【动态并发与线程安全的空间构建】
- 思维跨越：架构从“静态的类关系”跃升到“动态的线程交互”。为了解决复杂的线程同步与死锁问题，我深入实践了生产者-消费者模式与调度器模式。设计思维开始从关注“数据结构”转变为关注“线程生命周期”、“共享资源的保护边界（锁机制）”以及“线程间的协同通信”。
第三单元（JML 规格）——【契约式编程与自顶向下的工程理性】
- 规范约束：这一单元让我明白了什么是“契约式编程（Design by Contract）”。架构设计不再依赖模糊的直觉，而是严格遵守规格的前置条件、后置条件与不变式。设计思维开始收敛，重点在于如何运用高效的数据结构与算法（如并查集、堆优化 Dijkstra）在不破坏契约的前提下追求性能极限。
第四单元（UML 正向建模）——【模型驱动的全局架构观】
- 终局升华：思维彻底上升到模型驱动开发（MDD）的宏观视角。我学会了直接从需求切入抽象模型，利用两阶类图、状态图、顺序图三位一体地锁定软件的静态结构与动态行为。至此，写代码不再是盲目的试错，而是模型在代码空间中的具象化投射。

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

代码是架构的体现，而测试则是代码的生命线。四个单元下来，我的测试思维同样完成了自动化与多维度的升级：

第一单元：【黑盒探针与边缘试探】
- 主要依赖手动编写边界用例（如极深的嵌套括号、连续正负号）。测试思维局限于“撞大运”，效率极低。后期开始接触自动化测试，搭建了基于 Python 随机数据生成与 SymPy 库对拍的简易评测机，初步确立了自动化回归测试的意识。
第二单元：【时序注入与并发容错测试】
- 多线程的不可复现性让传统静态对拍失效。测试思维转向时序控制与鲁棒性验证。通过编写测试脚本在特定时间点精准注入乘客请求，进行高并发压力测试，并利用线程堆栈日志（Thread Dump）追踪是否存在死锁、电梯超载、接人逻辑死循环等并发引发的逻辑漏洞。
第三单元：【规格对齐与白盒单元测试】
- 测试思维向白盒测试与契约验证转型。深刻意识到黑盒测试对极端图结构的无能为力。开始严格根据 JML 规格的各个分支（normal_behavior 和 exceptional_behavior）编写 JUnit 单元测试，利用 Coverage 工具追求分支覆盖率与条件覆盖率的极限。
第四单元：【模型一致性与元模型测试】
- 测试对象不再仅仅是代码的输出结果，而是模型本身的合法性与解析器的规范还原度。通过构建违反各类 UML 规范的极端 JSON 模型（如深层多重接口实现的重名冲突、隐式循环继承），来测试自己的正规性检查引擎是否完备。测试思维上升到了元模型（Meta-Model）的层次。