OO_Unit 4 大结局

[赵婉彤-24373243]

Part 1

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

OO_pre 的惨痛教训告诉我在着手写代码之前理清楚架构是非常有必要的，但具体怎么理是个问题。我在前几个单元的训练中已经形成了一套自己的设计习惯，大致上是设计文档 -> 手绘草图 -> 代码骨架 的流程，所以刚开始接触 UML 这种很高级但很死板的模式就让我有点消化不良了。所以我依旧遵守了自己的设计习惯，把 UML 的绘制放到了最后的最后 —— 完全由 AI 完成。

架构 && 对比分析最终的代码设计和UML模型设计之间的追踪关系

图书管理系统涉及到两方：人和图书馆，书（BookCopy 类）和预约（Appointment 类）被他们用来周旋，Library 类作为人和图书馆之间的沟通渠道，一方面管理图书馆麾下的 BorrowReturnOffice、Bookshelf、AppointmentDesk 和人员信息表 UerTable，一方面为人类读者提供各种办理业务的接口。

我的 UML 是跟着代码一起更新的，每个 HW 只在最后更新一次。

大模型辅助正向建模

我很快意识到大模型不太会画 UML，而且鉴于我没有去学 UML 的规则，我也没法指导大模型学习。
把学长/学姐的 UML 源码和我写好的代码一起喂给 AI 是一个相当不错的选择，虽然很偷懒。

Part 2

架构设计思维的演进

其实这个单元有点让我想起来了先导课的魔法大陆，都很重视代码的层次、功能约定、和接口。我记得当时代码设计的一团乱，什么方法、功能都乱糟糟的堆在一起，更别说层次化设计了，最后 IDEA 导出的类图让人看一眼就掉 san。值得庆幸的是，在经过一个学期的学习后，在递归下降和多线程的折磨后，这种功能式的系统已经不会让我茫然无措了。

测试思维的演进

在这个学期开始之前，我对评测机的实践水平停留在计组的评测机，也就是少量的模块化指令和跳转指令生成 加 大量的无脑枚举，靠暴力生产所有指令组合。

表达式月的评测机（这是唯一一个非指令流式的），唯一一个纯手搓的评测机，我学会了分析各种错误点，主动设计引爆隐藏 bug 的表达式模式，撰写从弱测到强测的数据生成器，搭建结构完整（评测入口、测试模式选择、好看的 GUI）的评测机。

电梯月的评测机，这是一个多线程评测的评测机，同一个数据点会分别给每一份代码运行多次，允许线程间轮转，以模拟尽可能多的情况，应对错误难以复现的问题。问题是多线程导致不同数据点、不同 jar 包间存在互相影响（一个死锁导致其他测试也 TLE）的可能。

JML 月的评测机，这是一个针对 CTLE 的评测机，为了省事我甚至都没有赋予它正确性检测的功能。列出所有容易 CTLE 的指令，然后逐一设计诱导 CTLE 的场景，这又是一种与之前完全不同的模式。

UML 月的评测机，唯一一个纯 vibe 的评测机（甚至没有打开代码看过），感觉这是最简单的一个单元，也是最朴素的一个评测机。

综（课程收获）

从表达式月兴致满满 + 精力旺盛、被程序架构可以达到的优美程度折服，到电梯月愉快地写了所有能想到或者看到的调度算法然后性能大比拼，到 JML 月接触了主题设计致力于给代码和 vscode 调色、学会撰写清晰（稍微有点长）的提示词而不是暴躁地跟 AI 吵架，到 UML 月力竭开始偷懒全职撰写提示词。贯穿了整个学期的面向对象为我带来极大的知识上和技术上的收获和精神上的愉悦。