309
社区成员
发帖
与我相关
我的任务
分享面向对象第四单元总结博客
面向对象第四单元总结博客
一、本单元的正向建模实践——两阶类图的作用
第四单元的核心不是"写出一个图书馆系统"，而是先建模、后实现。
- 一阶类图（uml_pre.mdj）：在写代码之前提交，目的是逼着自己先想清楚"系统里有哪些实体、谁持有谁、谁负责处理什么请求"。比如一开始就确定了
Library作为唯一调度者持有六个地点类（BookShelf/AppointmentOffice/...），User、Book、Reservation作为数据层。这一步把"行为"翻译成"职责分配"。 - 二阶类图（uml_ultimate.mdj）：代码完成后提交，要求与代码逐字一致（R2–R5），并与一阶类图要有一定的相似度。
两阶类图最关键的作用是制造了一个**"设计—实现"的闭环约束**：一阶图防止不思考就动手；二阶图防止写飞了之后图沦为废纸。新需求先落到模型上（多一个类、多一条 User→BorrowRecord 关联），再落到代码上，而不是在代码里随手加个字段。
二、架构设计与 UML 模型的追踪关系
本单元最终架构是一个中心调度器 + 分层职责：
- 管理层
Library：handleRequest按请求类型分发，持有所有地点。 - 地点层：六个地点类各自只管"收书/给书/查在架"。
- 数据层：
Book、User、Reservation、BorrowRecord。
代码与三类 UML 模型的追踪关系非常直接：
| UML 模型 | 追踪到代码的什么 |
|---|---|
| 类图 | 类 = Java 类，属性/方法/可见性逐字对应（R2），关联 = 成员属性引用（R5） |
| 状态图 | Book 的 6 个位置状态 = LibraryBookState |
| 顺序图 | 预约/取书消息链 = 真实方法调用链，消息名 = 真方法名 |
三、引导大模型完成复杂场景的正向建模
用大模型辅助建模，我的体会是它擅长"填表"和"对照规则核查"，但不擅长"凭空决定架构"。有效的引导方式：
- 先喂规则，再让它建模。把评测规则（类图 R1–R5、顺序图 R1–R4）作为硬约束输入，模型生成的图才不会违规。例如顺序图那四条规则一旦明确，模型能自己核对"消息链首尾相接""跨类要有关联"。
- 让它做一致性核查而非创作。最高效的用法是"代码已写，请逐条核对类图属性/方法/可见性是否与代码一致"——这是易错的活，但模型很擅长。
- 把决策权留给自己。架构层面的取舍（要不要抽
BorrowRecord、信用分判定放User还是Library）必须由人来定，模型只负责把决策展开成完整的属性/方法清单。
四、四个单元架构设计思维的演进
- 第一单元（表达式求导）：从"一个大函数搞定"转向递归下降 + 表达式树。
- 第二单元（多线程电梯）：思维从"功能"转向并发边界与职责隔离——生产者-消费者、共享数据加锁、线程只通过队列通信。架构第一次需要为"正确性"而非仅"功能"服务。
- 第三单元（JML 规格）：转向契约式设计，先读懂规格再实现，学会让数据结构服从规格的复杂度要求（容器选择、缓存）。
- 第四单元（UML 正向建模）：完成了从"写完再说"到**"先建模、职责先行"**的闭环。明确了单一调度者、分层、关联即引用这些可被工具校验的设计原则。
整体演进是：功能正确 → 并发正确 → 契约正确 → 设计可追踪。
五、四个单元测试思维的演进
- 第一单元：手造边界样例 + 对拍（用 sympy 等做参照）。
- 第二单元：从"看输出对不对"升级到验证时序与不变量（线程安全、无死锁、输出顺序合法），测试不再是单点比对。
- 第三单元：JML 让测试有了"标准答案"——可以基于规格做约束式/随机化测试，并关注性能边界。
- 第四单元：转为模型一致性自检——用评测规则当 checklist 逐条核对图与代码，相当于对"设计"本身做测试。
测试对象从"结果"逐步上移到"性质"和"设计"。
六、课程收获
- 学会了正向建模这条工程主线：设计先于实现，且设计要可被验证。
- 真正理解了 OO 的内核不是语法，而是职责分配。
...全文
请发表友善的回复…
发表回复
