OO_U4 - UML

彭子峻-23373334 2025-06-11 00:00:08

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

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

整体架构

Pasted image 20250610221243.png

  • Main类负责处理输入
  • Library负责“分发指令”给各个下属类,同时起到“中转数据”的作用
  • Bookshelf等为Library的下属,负责完成具体指令
  • UserBook分别为读者、书本的状态信息,对应实现了一些查询/状态转移方法
  • 对于预约,我设计了一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课程组的各位老师与助教,本学期以来的陪伴与支持。没有你们的无私奉献,相信我是不会获得上文这么多收获的。再次,Большое спасибо!

...全文
30 回复 打赏 收藏 转发到动态 举报
AI 作业
写回复
用AI写文章
回复
切换为时间正序
请发表友善的回复…
发表回复

272

社区成员

发帖
与我相关
我的任务
社区描述
2025年北航面向对象设计与构造
学习 高校
社区管理员
  • Alkaid_Zhong
加入社区
  • 近7日
  • 近30日
  • 至今
社区公告
暂无公告

试试用AI创作助手写篇文章吧