2026面向对象第四次博客作业

汪子涵-24371126 2026-06-25 23:07:06

2026面向对象第四次博客作业

一、正向建模与开发实践及两阶类图的作用

在本单元的实践中，我们经历了从“面向代码编程”到“面向模型编程”的思维转变。正向建模与开发的核心思想是“先设计，后实现”，即将思考的过程前置，通过UML（统一建模语言）等工具，在动手编写代码之前，先从宏观架构、类间关系、状态转移和消息交互等多个维度刻画出系统的蓝图。这种方式极大地降低了在复杂业务逻辑中“边写边改”带来的试错成本和架构崩塌风险。

在这个过程中，两阶类图发挥了至关重要且截然不同的作用：

一阶类图：
一阶类图是在仔细阅读指导书、理解业务需求后绘制的。它的主要作用是领域抽象和确立骨架。在这个阶段，我们不需要关注具体的实现细节（如使用 HashMap 还是 ArrayList），而是关注系统中有哪些实体（如 LibraryManager, User, Book, Bookshelf, AppointmentOffice 等），以及它们之间的基本关系（如关联、依赖、继承）。一阶类图强迫我站在更高的抽象层次上思考问题，确保我们的业务逻辑和对象划分在概念上是合理的，为后续的编码指明了大致方向。
二阶类图：
随着编码的深入，往往会发现一阶类图中的某些设计过于理想化，或者缺少了实现某些复杂逻辑所需的辅助类、中间状态和辅助方法。此时，我们需要在代码实现的基础上，对一阶类图进行迭代和细化，形成二阶类图。二阶类图的作用是代码映射和架构固化。它真实地反映了系统最终的物理形态。通过对比一阶和二阶类图，我们可以清晰地看到设计与实现之间的鸿沟是如何被填平的，也能促使我们反思初期设计的不足，从而提高架构设计能力。

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

1. 架构设计总结

本单元的图书馆管理系统具有明显的模块化特征，整体架构可以分为以下几个核心部分：

控制中心（Core）： 以 LibraryManager 为核心，作为整个图书馆的管理者，负责接收并调度来自外部的指令。UserManager 负责管理所有用户实体。
业务部门（Departments）： 包括 Bookshelf（普通书架）、TreasuredBookshelf（精品书架）、AppointmentOffice（预约处）、BorrowReturnOffice（借还处）和 ReadingRoom（阅览室）。这些类各自封装了内部的图书管理逻辑（如增删查改）。
实体与状态（Entities）： 包括 User（用户，记录信用分、借阅状态、预约状态等）、Book（图书），以及辅助记录的 BorrowRecord 等。
通过这种模块化设计，各个部门职责清晰，减少了类与类之间的强耦合，符合单一职责原则。

2. 代码设计与UML模型设计的追踪关系

在正向建模中，UML模型不再是简单的“示意图”，而是具有强约束力的设计契约。最终的代码设计与UML模型之间存在着严密的追踪关系（Traceability）：

元素级别的映射： UML类图中的每一个类（Class）、接口（Interface）、枚举（Enum）在Java代码中都有对应的 .java 文件或定义。类图中的属性名、可见性、类型，以及方法的签名（名称、参数类型、返回值）在代码中得到了精准的复现。
关系级别的追踪： UML中的关联关系（Association）在代码中体现为一个类持有另一个类的引用（如 LibraryManager 持有 UserManager 和各部门的实例）；泛化/实现关系在代码中体现为 extends 和 implements 关键字。
行为与交互的追踪： UML状态图中的状态转移（Transitions）和触发器（Triggers）在代码中被 @Trigger 注解严格标记，且 Guard 条件对应了代码中 if 判断的业务逻辑。UML顺序图中的生命线（Lifeline）和消息传递（Message）则通过 @SendMessage 注解与具体的方法调用（如 LibraryManager 与 User 之间的 orderNewBook 和 addOrder 调用）一一对应。
这种追踪关系确保了设计文档与代码实现的高度一致性。

三、使用大模型辅助正向建模的体验与方法分析

在本次复杂场景的架构设计中，我尝试使用了大语言模型（LLM）来辅助正向建模，体验深刻。大模型在处理繁杂规则、提供代码框架和解决UML语法细节上具有极大的优势，但在面对庞大且高度耦合的业务逻辑时，如果不加引导，很容易产出偏离需求甚至产生幻觉的输出。

总结而言，引导大模型完成复杂架构设计任务，需要掌握以下策略：

Context 投喂：从宏观到微观的规则输入
在让其设计架构前，首先要将复杂的业务场景（如官方包说明、各类图书借阅限制、信用分增减规则）进行结构化拆解，以清晰的 Prompt 喂给模型。可以先让模型总结规则，确认其理解无误后，再进入设计阶段。
分步设计：先核心，后细节
引导模型设计架构时，应采用“迭代式”问答（参考上机训练的内容）。
- 第一步（找实体）： “根据上述图书馆需求，请帮我提取系统中的核心领域对象（类）有哪些？”
- 第二步（建关系）： “请帮我分析 LibraryManager 与 User, Bookshelf 之间的关系应该是组合还是聚合？”
- 第三步（细化属性方法）： “针对借阅流程，User 类和 LibraryManager 类分别需要提供哪些方法？请给出方法签名。”
  通过这种抽丝剥茧的引导，大模型能生成非常有逻辑的一阶类图框架。
精准定位：利用大模型解决UML与代码转换的痛点
在绘制状态图和顺序图时，经常会遇到概念不清或工具使用障碍的问题。例如，当遇到“在代码中 LibraryManager 并没有直接作为局部变量存在，顺序图的 Lifeline 该如何画”时，向大模型清晰描述代码现状和 StarUML 工具的约束（如 obj: User 命名规范），大模型能够迅速给出正确的画法和 @SendMessage 的注解占位方案。
人工审核与纠偏
大模型生成的架构和代码片段可能会忽略某些隐蔽的边界条件（如 C 类书的同 ISBN 约束，或者闭馆后逾期的扣分结算时机）。因此，必须由开发者主导架构的最终决定权，对大模型生成的类图设计进行语义完整性检查和相似度审查，发现偏差及时通过 Prompt 予以纠正。

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

第一单元（表达式解析）： 这一单元是架构思维的启蒙。我最初习惯于写大类和大方法，后来逐渐理解并应用了层次化设计。通过引入递归下降算法和AST（抽象语法树），我懂得了如何将复杂的问题拆解为可递归的子问题。架构上，学会了分离解析逻辑（Parser/Lexer）和表达式实体（Expression/Term/Factor），初识了多态。
第二单元（电梯）： 这一单元的核心是多线程并发与同步。在这个阶段，架构思维从“静态”转变为“动态”。我不再只关注类的静态属性，而是重点思考线程安全、锁的粒度和死锁预防。通过使用生产者-消费者模型、观察者模式以及将调度策略与电梯运行解耦，我学会了在多线程环境下构建松耦合、高内聚的系统。
第三单元（JML与契约式编程）： 这一单元重点在于规格与实现分离。架构设计的重点转向了“契约”。在实现复杂的网络图算法时，我不再急于编写代码，而是先阅读和理解JML规格，理解前置条件、后置条件和副作用。这让我懂得了接口的意义——接口定义了“做什么”，而类负责“怎么做”，实现了真正的面向接口编程，同时在性能与架构之间寻找平衡。
第四单元（UML与正向建模）： 最后一个单元是架构设计的升华。系统性地引入了UML类图、状态图和顺序图。架构设计不再是头脑中的抽象概念，而是变成了可视化、可追踪的模型。我学会了先自顶向下进行正向建模，理清实体关系、对象状态转移和消息交互流程，最后再落实在代码上，实现了“模型驱动开发”。

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

随着课程的推进，我的测试思维也经历了从“被动修Bug”到“主动保证质量”的转变：

第一单元（黑盒与手工测试）： 刚开始，我更依赖于构造一些边缘数据进行手工黑盒测试，或者使用 Python 编写简单的对拍器。测试往往是在代码写完之后才进行，属于典型的“后置测试”，对一些复杂的嵌套表达式容易遗漏测试用例。
第二单元（并发场景与自动化测试）： 多线程引入了极大的不确定性，手工测试彻底失效。我开始学习编写自动化测试脚本，利用大量随机生成的数据投入多部电梯中运行，并通过离线 Checker 验证电梯行为的合法性。此时，我意识到压力测试和边界时序测试（如同时刻投喂大量请求）在并发场景中的必要性。
第三单元（白盒与单元测试）： 结合JML规格，测试进入了更严谨的阶段。我开始使用 JUnit 编写单元测试，针对复杂图算法（如最短路径、并查集）进行边界测试。测试思维从单纯的关注输入输出，转变为验证代码的执行状态是否严格满足规格约束（如验证 Pure 方法无副作用）。
第四单元（基于模型的测试与集成测试）： 在正向建模中，测试不仅仅是对代码的测试，也包含了对模型的测试。通过状态图遍历检查所有状态转移路径的完备性，通过顺序图检查消息时序的正确性。在代码测试方面，注重对整个图书馆模拟系统的集成测试，验证各个“部门”与“用户”交互时的状态一致性和时间流转的正确性。

六、课程收获总结

这门课程不仅在教授Java，更是让我们学习系统化的工程实践。

工程化思维的建立： 从最初的一两百行代码，到现在能从容应对数千行、多模块、多线程的复杂系统，我深刻体会到了“高内聚低耦合”、“单一职责”、“开闭原则”等设计原则的价值。
工具与生态的掌握： 熟练掌握了 Git 版本控制、JUnit 测试框架、StarUML 建模工具以及大语言模型（LLM）的辅助编程。这些都是现代软件工程师不可或缺的工具栈。
抗压能力与时间管理： 经历过多线程难以复现的Bug、经历过性能优化的痛苦，也经历过重构代码的阵痛。在一次次的迭代和互测中，我学会了如何在有限的时间内平衡功能实现、架构设计与测试保障。
对契约和规范的认识： JML和UML让我认识到，在大型团队协作中，口头沟通和自然语言往往是模糊的，唯有严谨的规格、标准的图形语言和规范的文档，才能保证软件开发的准确无误。

...全文