272
社区成员




漫长的OO历程,终于到此结束了。
本篇文章将简要介绍本人在本单元中,利用UML进行正向建模的经历,并对一学期以来的课程经历做一个简要回顾。
Main
类负责处理输入Library
负责“分发指令”给各个下属类,同时起到“中转数据”的作用Bookshelf
等为Library
的下属,负责完成具体指令User
、Book
分别为读者、书本的状态信息,对应实现了一些查询/状态转移方法AppointmentInfo
类,用于记录预约请求的有关信息事实上,我的正向建模过程并没有使用StarUML这款可视化建模工具,而是在草稿纸上,仿照UML的基本格式“打草稿”:
对于架构设计:
在更新架构设计时:
架构的设计与迭代流程大概是这样。
至于状态与流程图,打草稿结果与UML画出来的结果近乎一致,在这里也就不再展开了,只需注意转移规则与方法关联的问题。
就我个人体验而言,我认为直接让大模型进行正向建模的效果差强人意。具体表现为,大模型会因幻觉,出现脱离于当前问题上下文的设计:如类与继承关系。
出于这一原因,本人的正向建模大部分由我本人完成。至于大模型的作用,我仅是让大模型生成了初步的正向建模模型。
大模型辅助建模,我主要是在实验课上实践。总结实验课上的经验,我的经验如下:
更具体而言,要让大模型做架构设计,总体分三步:
在OOPre反复重构的心理阴影下,我在本学期OO正课开始,就对正向建模的过程较为重视。当然,四个单元下来,设计思路还是有长进的。
四个单元下来,我的测试思维基本稳定;但在U3时,我的单元测试思维得到了强化。
具体而言,我当前的测试思维是:
从U1刚开始的高度紧张、焦虑,到U2中期后的逐步驾轻就熟,我认为本学期OO课程为我带来的最大收获,是面对困难任务时心态的转变。
自大学入学以来,我面对困难任务,要么是想捷径,要么是找合理的办法规避。要自己动手解决时,我往往对着问题焦虑地发愣:因无法完成任务而焦虑,因焦虑而无从下手。本学期的OO课程帮我打破了这一恶性思维闭环,鼓励我先放手大胆尝试,再考虑能不能做成。
这一思维模式的转变确实为我带来了好处。在第二单元中,我尝试了使用oolens
未介绍的ReentrantLock
,并从头完全设计了一套自己的电梯运行/调度策略。电梯单元任务的确艰巨,但在那一单元我大胆尝试,受益匪浅。可以说是万事开头难吧,但最重要的始终是试着迈出第一步,然后坚定的走下去。
另一收获是构建属于自己的评测机的经验,这也可以算是敢于尝试的一大成果吧。我构建评测机也是始于第二单元。随后,我逐步探索出了多进程并发评测,以及AI构建数据生成器/Checker的整个工作流程。收获还是颇为显著的,在构建好评测机后,除了Hw5评测机构建完成时间太晚、Hw9心浮气躁不用评测机翻车以外,其他次作业都没在强测里出问题。
由此,我也感受到了充分测试,对于程序开发的重要意义所在。在开发完一个功能后,第一假设应是“这个程序有bug”,而不是写完后就骄傲自满,完全不做测试,或是简单的“目视法”找bug。测试思维,也算是OO课程给我的一点收获吧。
我的抽象思维与建模能力也得到了提升。 U1、U2每次作业的正向建模,以及对后续迭代需求的简单预测,为我减少迭代开发量做出了重大贡献。U4时,我针对问题的建模能力也较前两个单元成熟了许多,在正向建模上花费的时间比之前少了不少。
在此,我由衷感谢OO课程组的各位老师与助教,本学期以来的陪伴与支持。没有你们的无私奉献,相信我是不会获得上文这么多收获的。再次,Большое спасибо!