OO_U4 - UML

[彭子峻-23373334]

漫长的OO历程，终于到此结束了。

本篇文章将简要介绍本人在本单元中，利用UML进行正向建模的经历，并对一学期以来的课程经历做一个简要回顾。

整体架构

• Main类负责处理输入
• Library负责“分发指令”给各个下属类，同时起到“中转数据”的作用
• Bookshelf等为Library的下属，负责完成具体指令
• User、Book分别为读者、书本的状态信息，对应实现了一些查询/状态转移方法
• 对于预约，我设计了一AppointmentInfo类，用于记录预约请求的有关信息

正向建模

事实上，我的正向建模过程并没有使用StarUML这款可视化建模工具，而是在草稿纸上，仿照UML的基本格式“打草稿”：

对于架构设计：

• 根据问题，抽象出需要的类
• 根据每个类所需要实现的功能，规定好必须实现的属性和方法
• 根据属性、方法与类之间的交互逻辑，确定类之间的聚合/继承等关系

在更新架构设计时：

• 确定是否加类
• 是否有属性/方法的更改
• 是否有类之间关系的更改

架构的设计与迭代流程大概是这样。

至于状态与流程图，打草稿结果与UML画出来的结果近乎一致，在这里也就不再展开了，只需注意转移规则与方法关联的问题。

与最终设计的追踪关系

• 类图：正如上文所言，本人采取的建模方式是先建模出必要的架构，再在其基础上进行具体实现。因此，初始的UML设计，与最终实现还是有细微差别。也就是说，我的开发过程中，有具体设计反过来添加UML中属性/方法的状况。好处是，这有利于加快开发效率，避免过度拘泥；坏处是，UML按理不该修改，但我们事实上改了。
• 状态/流程图：我的状态/流程转移，都是基于初始设计中的必要方法的；因此，最终实现是与初始设计一致的。

大模型辅助正向建模

就我个人体验而言，我认为直接让大模型进行正向建模的效果差强人意。具体表现为，大模型会因幻觉，出现脱离于当前问题上下文的设计：如类与继承关系。

出于这一原因，本人的正向建模大部分由我本人完成。至于大模型的作用，我仅是让大模型生成了初步的正向建模模型。

大模型辅助建模，我主要是在实验课上实践。总结实验课上的经验，我的经验如下：

• 与实验指导书相反，我选择尽可能减少Prompt的规模。实践证明，当前主流大模型已足够在简明的Prompt下，生成令人满意的答案。
• 我只向大模型传入了当次任务的指导书，以及一个简明的Prompt.
• 这个Prompt内，主要是对指导书内一些没有显式声明的限制条件进行补充；以本单元为例，图书馆开馆时间不一定连续就是一个隐形条件。
• 在指导书足够清晰明了，介绍了所有要求与限制的情况下，我的Prompt甚至简单到只有三个字：“帮我做”。

更具体而言，要让大模型做架构设计，总体分三步：

• 设计总体架构：开什么类，类之间怎么交互
• 细化类：需要什么属性和方法
• 具体实现：开始编写方法内逻辑即可。

设计思维的演进

在OOPre反复重构的心理阴影下，我在本学期OO正课开始，就对正向建模的过程较为重视。当然，四个单元下来，设计思路还是有长进的。

• U1：初级阶段；对当前问题进行正向建模，不充分考虑未来可能的扩展方向；这导致我在Hw2时出现了一次代价较高的重构。
• U2：吸收上一单元教训，在Hw5时前半周投入大量时间，用于设计后续作业通用的架构，以及电梯调度/运行策略；这一决定确有收获，后续迭代相对轻松；但全过程并未对进程间交互流程进行正向建模，导致Hw5多处出现死锁，强测失利...
• U3：按照规格按部就班；这应该是正向建模完成后的正常开发流程，我在此体会到了何为“规格与实现分离”。正向建模实质上就是设计规格，反过来改正向建模架构，严谨而言是不应发生的。
• U4：正式进行正向建模。发现自己正向建模的思维仍然不够严谨，出现了反向改正向建模架构这种事情。这其实也反映了我的正向建模仍然不够抽象，这可能是我日后需要锻炼的地方。

测试思维

四个单元下来，我的测试思维基本稳定；但在U3时，我的单元测试思维得到了强化。

具体而言，我当前的测试思维是：

• 回归测试：当前修改，不应影响原有功能的正确性；
• 针对边界条件测试：明确开发过程中遇到的边界条件，在实现一个功能后，即对其进行边界条件测试；
• 随机测试：随机生成数据，评测机灌水式测试；虽然简单暴力，但从扩大测试范围的角度确实有用；
• 压力测试：主要针对U2；评测机多进程并发评测，测试设计是否合理。
• 单元测试：更细颗粒度，针对某个方法进行测试。

课程收获

从U1刚开始的高度紧张、焦虑，到U2中期后的逐步驾轻就熟，我认为本学期OO课程为我带来的最大收获，是面对困难任务时心态的转变。

自大学入学以来，我面对困难任务，要么是想捷径，要么是找合理的办法规避。要自己动手解决时，我往往对着问题焦虑地发愣：因无法完成任务而焦虑，因焦虑而无从下手。本学期的OO课程帮我打破了这一恶性思维闭环，鼓励我先放手大胆尝试，再考虑能不能做成。

这一思维模式的转变确实为我带来了好处。在第二单元中，我尝试了使用oolens未介绍的ReentrantLock，并从头完全设计了一套自己的电梯运行/调度策略。电梯单元任务的确艰巨，但在那一单元我大胆尝试，受益匪浅。可以说是万事开头难吧，但最重要的始终是试着迈出第一步，然后坚定的走下去。

另一收获是构建属于自己的评测机的经验，这也可以算是敢于尝试的一大成果吧。我构建评测机也是始于第二单元。随后，我逐步探索出了多进程并发评测，以及AI构建数据生成器/Checker的整个工作流程。收获还是颇为显著的，在构建好评测机后，除了Hw5评测机构建完成时间太晚、Hw9心浮气躁不用评测机翻车以外，其他次作业都没在强测里出问题。

由此，我也感受到了充分测试，对于程序开发的重要意义所在。在开发完一个功能后，第一假设应是“这个程序有bug”，而不是写完后就骄傲自满，完全不做测试，或是简单的“目视法”找bug。测试思维，也算是OO课程给我的一点收获吧。

我的抽象思维与建模能力也得到了提升。 U1、U2每次作业的正向建模，以及对后续迭代需求的简单预测，为我减少迭代开发量做出了重大贡献。U4时，我针对问题的建模能力也较前两个单元成熟了许多，在正向建模上花费的时间比之前少了不少。

在此，我由衷感谢OO课程组的各位老师与助教，本学期以来的陪伴与支持。没有你们的无私奉献，相信我是不会获得上文这么多收获的。再次，Большое спасибо!