BUAA-OO-2025-U4

周文康-23371395 2025-06-15 23:51:22

一、正向建模与开发

当OO课程推进到第四单元时，"正向建模"四个字曾让我头皮发麻——每周一打开指导书就开干代码的习惯被彻底推翻。三次迭代作业都要求先画UML再写代码，起初像戴着镣铐跳舞。但经历U1的疯狂重构、U2的线程漏洞、U3的JML规格地狱后，我终于明白U4的良苦用心：通过类图理清模块边界，状态图固化行为逻辑，顺序图打通交互链路，用完整的架构设计避免不必要的错误。
实践中最深刻的体验发生在第三次作业。当信用系统需求砸来时，我只需要简单地添加一些方法就能解决——这些其实早就在架构设计中预演过，相比前几个单元每次迭代改到怀疑人生的体验，简直是降维打击。

二、架构设计

最终的架构设计如图，经历了以下三次迭代：

1. 基础借阅系统（第一次迭代）

核心设计是中心化调度：Library作为总控枢纽，连接Shelf（书架）、BOR（借还处）、AO（预约处）、User等处理类。关键在于：

所有请求由Library统一路由
模块间仅与Library通信，禁止跨模块调用

2. 阅读场景扩展（第二次迭代）

新增ReadingRoom和热门书架时，惊喜发现原有架构的弹性，

只需把热门书架和阅览室作为独立模块接入Library，然后在实现一些方法就行

3. 信用分系统（第三次迭代）

信用分机制也验证了正向建模的力量，"预约-逾期-扣分"流程都能够轻松地在原有架构上迭代。

三、大模型辅助建模

血泪教训

初期直接扔指导书给Ds老师生成的类图惨不忍睹，类和属性都奇奇怪怪的，关系更是乱七八糟的，所幸通过实验学会了一些使用技巧提高效率，如下示例：

Prompt设计技巧

场景拆解

你作为软件架构师，请基于以下需求设计类图：
- 核心实体：Book(User, BOR, AO, Shelf)
- 关键行为：借书需检查用户权限和书籍状态
- 约束条件：B类书每人限持1本
以mermaid语法输出类关系，标注多重性和导航方向

渐进修正

现有设计问题：
1. CreditSystem应关联User而非Book
2. 缺少OverduePolicy接口实现差异化逾期计算
提供改进方案并解释设计原则应用

代码联动

根据以下类图生成Book类的Java骨架：
重点实现：
- 状态迁移方法加@Trigger注解
- 用Enum管理ShelfLocation
忽略getter/setter，专注业务逻辑

四、架构设计演进

U1表达式战场：在递归下降和多项式展开间反复横跳，被sin((x+x))的优化逼到重构3次。
U2电梯战争：生产者-消费者模型是救星，但双轿厢同步改造时CountDownLatch用错导致死锁。
U3规格帝国：JML的ensures和assignable像法律条文，被迫学会用缓存优化queryGroupValueSum()。
U4建模觉醒：终于理解“架构是约束的艺术”——当类图规定Library单向依赖模块时，代码自然高内聚。

五、测试思维进化

单元	测试方式
U1	基本都是手搓测试样例
U2	开始用大模型辅助生成一些符合规范的数据
U3	学会用JUnit单元测试测试方法正确性
U4	学着使用交互式评测，搭建评测机进行评测

最大的认知进化在于：测试不仅是验证程序正确，更是检验设计一致性，符合架构设计的好的程序才能保证在各种边界条件下不出错。

六、课程收获：在OO宇宙中成为更好的自己

还记得U2电梯单元的一个夜晚，饿着肚子调试到凌晨三点。但当终于de出多线程bug的瞬间，那种攻克难关的喜悦比什么都更炽热。OO教会我的不仅是各种面向对象编程的思想和代码的熟练度，
更是直面复杂系统的勇气。当在图书馆系统里同时处理借阅、信用、逾期计算时，我想起U1被括号支配的恐惧——原来所有成长，都是过去经验的递归展开。