*看来这就是旅程的终点了。

零 前言

​ OO也要落下帷幕了吗？

​ 对于我这种喜欢回顾的人而言，这种总结让人并不好受。哪怕我平日里没有这么热爱这些脑海里的点点滴滴，现在这些不堪回首的过去都成为了令人不舍的记忆碎片。

​ 感觉这就是这个学院和其他学院很大的区别之一吧，有些课的魅力貌似并不是由分数和考试定义的，它们是专业重课，但是又不是考完就当包袱丢掉一样的存在，临近结课的我无时无刻、无法停止地思考：这是我这辈子最后一次这样学习这样一门课程了。🙂

​ 最后一篇OO博客，总结Unit4并回顾整个学期的学习！🚩

一 正向建模与开发

正向建模与开发是指在软件开发过程中，根据需求说明书或业务逻辑，通过抽象分析构建系统模型，以指导后续的设计、开发和测试流程。

此外，正向建模与开发需要开发者对用户需求有全面的理解，并在UML设计和代码编写中进行反复迭代。

​ 我们可以理解为，正向建模与开发就是先打草稿再上手敲码，但是在真正完成项目的阶段性目标与迭代性任务的时候，我们需要在UML设计与代码编写中“反复横跳”。但是笔者感觉我们第四单元考察的更多是单元一开始的UML构造与设计，在后续的迭代中，同学们都认为比较一边改代码，一边画图比较顺手。我在后续的迭代中也选择了代码与建模同步交替进行。

二 架构设计总结

​ 本单元作业通过三次迭代，逐步构建了一个功能丰富、逻辑复杂的图书馆管理系统。整个开发过程遵循了面向对象的设计思想，从一个基础的借阅系统，逐步演进为一个包含高级整理策略、用户信用体系和多种交互模式的综合模拟平台。架构设计的核心在于识别并封装稳定的业务实体，并通过不断迭代来应对新增的需求。 - MainClass：作为贯穿三次作业的程序入口和控制器。它的职责始终保持专一：负责与官方I/O包交互，解析指令并将其分发给LibrarySystem。这种设计有效地将用户界面/输入处理与系统核心业务逻辑分离开来，使得业务逻辑的迭代不影响程序的入口结构。 - LibrarySystem：系统的核心管理者，在三次迭代中始终扮演着中介者的角色。 - 第一次迭代，我们建立了基础的图书和学生管理，提供了处理借阅、预约、归还等基本请求的统一接口。 - 第二次迭代，随着“热门书架”和“阅览室”的引入，LibrarySystem 的职责扩展到管理不同类型的书架 (booksOnNormalShelf, booksOnHotShelf)，并实现了更复杂的开馆整理逻辑，包括根据“上次开馆”的热门行为对书籍进行分类。 - 第三次迭代，指导书让我们进一步集成了信用分和借阅期限的管理。LibrarySystem 负责在 processOpen 和 processClose 这两个关键时间点，执行周期性的状态结算，如检查逾期、处理预约未取和阅读未还的信用分扣除，体现了其作为系统核心和规则执行者的角色。 - Student：代表学生实体。它的设计经历了显著的跨越，也是我们迭代的核心之一。 - 第一次迭代，Student 主要负责管理其持有的书籍和预约状态，并提供基本的借阅/预约资格判断。 - 第二次迭代，为了支持“阅读”功能，增加了记录“正在读书”状态的属性 currentReadingBook。 - 第三次迭代，Student 演变为一个更完整的用户模型，新增了信用分 creditScore 属性和相关的增减方法。同时，为了管理借阅期限，我们在其内部维护了一个 Map<BookCopy, LocalDate> borrowingRecords 来精确记录每本书的借出日期，使其能够支持逾期判断。所有权限检查方法（canBorrowBook, canOrderBook , canReadBook）都集成了信用分校验。 - BookCopy：代表每一本物理存在的书籍副本。它始终是状态模式的核心实践对象。 - currentLocation 属性随着迭代不断丰富，从最初的四种位置扩展到六种（增加了普通/热门书架和阅览室）。 - BookCopy 专注于执行状态转换和记录移动轨迹，将复杂的决策逻辑上交给 LibrarySystem。 - 数据类 (POJOs): - BookInfo , Appointment, MovementRecord: 这些类在三次迭代中保持了高度的稳定性，职责清晰。它们作为纯粹的数据容器或简单状态机，为核心实体类提供了必要的信息支持，证明了良好封装和单一职责原则在应对需求变更时的健壮性。

​ UML模型与代码设计之间的追踪关系是双向且多维度的。类图定义了“有什么”，对应代码的静态结构；状态图定义了“如何变”，对应单个对象的动态行为；顺序图定义了“对话双方”，对应多个对象间的交互协作。在本次作业的实践中，我们通过严格遵循命名、类型、可见性和关系的对应，以及利用 @Trigger 注解等机制，在这代码设计与UML模型设计之间建立了一座坚实的桥梁。

​ 1. 类图与静态代码结构的追踪关系

​ 类图是我们画的第一个建模图，它主要描绘了系统的静态结构，它与代码的对应关系最为直接和基础。它其中能体现出类/接口/枚举/属性/操作/关系多种维度的映射。

​ 2. 状态图 与对象动态行为的追踪关系

​ 状态图描绘了BookCopy的生命周期和状态变迁，它与代码中特定对象的行为逻辑紧密相连。

​ 3. 顺序图 (Sequence Diagram) 与对象交互的追踪关系

​ 顺序图描绘了多个对象之间为完成某个功能而进行的一系列消息交互，它与代码中一个public方法的执行路径相对应。

三 大模型辅助设计体验与总结

​ 大模型辅助正向建模主要集中在第四单元的学习中，其实核心在于如何让大模型“嚼碎”指导书，再“阶段性”地完成一个个目标。在使用大模型的过程中，我感觉大模型非常适合正向建模，当我们把指导书扔给它们，再明确地告诉他们需要做什么，他们可以将指导书预设的场景按照我们的需要进行设计，在本单元则体现为构建UML图。但是他们也会犯错或者制造误解😶，我们需要用更加高效精炼的提示词让它帮助我们完成工作。

​ 那我们的主要任务可以分为以下几点：

• 为其设定角色定位，提供充足必要的信息后，提出明确的任务目标。

• 我们自己或者让大模型对复杂场景的任务进行细分，并严格按照我们划分的结构推进对话内容。

  ( p.s.不建议直接让它产出最终结果，正如实验所说，大模型需要不断像人类一样审视、修正自己的错误 )

• 根据它的反馈与我们产生的疑问、思考，进一步与其讨论、对其追问，一步步满足我们最终的需求。

四 架构设计思维总结

​ 我们OO正课经历了四个单元的酸甜苦辣，各个单元难度不一，但可谓各有特色~感谢猪脚们的悉心设计😊

• 第一单元：高度层次化设计 本单元的主题是表达式解析。我们学习了通过递归下降构建表达式树，也是首次遇见parser。最难忘的就是debug环节，看着调试的代码在expr ，term，factor之间跳转，才慢慢明白这种层次化设计的好处，只有明确了这我们的设计结构，才能顺利的找到bug。

• 第二单元：并发协同安全挑战 本单元的主题是多线程设计。面对 BUAA-OO牢电梯 ，所有人在那段时间仿佛都在全力OO，在电梯策略方面八仙过海。我学习并使用了经典的生产者-消费者模式，学会了使用锁保证线程安全。电梯单元十分贴合现实的属性也让我很感兴趣，感觉真的在完成一项小型项目一样。

• 第三单元：面向JML优化复杂度

  本单元给出了完整的JML规格要求，使用大模型可以快速完成所有代码的编写，并保证正确性。但是核心挑战其实是算法与数据结构的选择，在不同算法下，时间复杂度也大不相同，在实际编写代码，也能直观地感受到不同数据结构给程序带来的大幅优化，尤其是面对一些特定的强测试点。

• 第四单元：正向建模协同设计

  本单元的核心是做UML模型图。图书馆管理系统的主题不仅提升了我们使用大模型的能力，而且让我们感受到了类似于瀑布模型的软件开发思路，为我们以后参与大项目打下了基础。

五 测试思维演进总结

​ 这学期一开始便得知了测评机的重要性，但是第一单元的特殊性，我们发现朋友间对拍可以解决很多问题，所以改了改往年学长的pipeline便拿来使用了。后来在第二单元深深地依赖了舍友的评测机，确实如诸老师所说，第二单元没有评测机真活不过去😭。在此之后的三四单元又没有那么需求评测机了，第三单元和舍友对拍也能解决绝大多数问题，第四单元的测试强度较低，没有评测机程序压力也不大。

​ 从上学期到这学期最后，我逐渐明白了手动构建测试点的局限性，此外测评机的数据生成器强度也很重要，量大且精才能最大程度上发挥评测机的作用，尤其是一些边界数据、针对性较强的数据。

六 课程收获总结

​ 完结撒花，感谢陪伴！🎉🎉🎉

​ 完结撒花，感谢陪伴！🎉🎉🎉

​ 完结撒花，感谢陪伴！🎉🎉🎉

​ 一学期下来确实学了很多知识，也更加熟悉面向对象编程了，从OOpre懵懂地入门，到现在回头感慨万千，谁说这OO**的，这OO太棒了！OO虽然是COOOOS的一员，但又完全不同于另外两门，快乐的上机、丰富的测评机制以及独特的讨论课，都共同构成了特色的OO课程！感谢老师们与助教们的悉心付出，助教每一次及时答疑、每一次抓紧修bug，我们都看在眼里😉过程磨难但仍愿频频回首，一路是我们的足迹，一路是难忘的见证！

​ 这一学期学到的东西大部分涵盖在以上字段中啦！我们从设计、编码到测试各个方面都变得更加无懈可击！

​ 期待多年后还会不经意地邂逅OO，回见啦！👋

---

• ← Previous Post
• Next Post →

---

---