2025面向对象OO第四单元博客

[张恒鑫-23371164]

面向对象第四单元博客

---

一、正向建模与开发

OO第四单元的主题是UML正向建模，旨在从抽象的系统设计（如类图、用例图）出发，逐步推导出具体的代码实现，这需要我们先从逻辑设计出发，再生成可执行代码。

我们在第四单元的三次作业中需要依次完成类图、状态图与顺序图。

1. 类图：系统静态结构设计
   因为害怕后期会遇到大规模的修改，在代码实现前我没有绘制一个完整的UML类图，而是先简单的建好了核心类，在类中添加了几个核心方法。然后在后续代码的具体实现中，不断完善建模。
   我认为自己一开始的架构还是比较合理的，在后续的迭代开发中没有经历大规模的变动。
2. 状态图：对象的状态行为设计
   因为状态图是在第二次作业提出的任务，在这时我们已经有了第一次作业奠定的整体框架。因此围绕代码去设计状态图是比较舒服的。我们在状态图中需要追踪Book的状态，其状态的集合对应着代码中BS、AO等枚举变量，相应的状态转移路径的Trigger就是我们设计的borrow等方法。
3. 顺序图：对象间的消息交互
   与状态图同理，根据我们已有的代码架构去设计顺序图也是很舒服的。顺序图的作用是让我们理解对象间交互的全部流程，包括嵌套的方法调用等。在后续的debug环节，我们可以很好的利用这一点检查是哪个环节有误。

二、架构设计

架构分析

我最终的类图如下：

这里我采用了Library作为核心类，管控BookShelf、AppointmentOffice等部门类，而Book类则是流转在各个组件类间的对象。从层次上看，Library负责接收各式请求，然后找到对应的Book和部门，由部门类实现具体的需求并修改Book的状态。

值得一提的是，由于题目中的动态测评的特殊性。有很多方法我们是不必具体实现的，比如borrow这一动作，可以看出我并没有在User类中设计一个完善的容器。这是因为在还书的请求中我们可以直接获取书籍的bookId，因此我使用的方法是在Library类中备份全部的书籍，直接添加书籍的记录。

追踪关系

• UML类图 → 代码架构：初始UML定义了Library、BookShelf、AppointmentOffice等核心类及其关系，后续实现具体代码时反过来修改UML类图；
• 状态图 → 状态行为：状态图反映了Book的状态转移关系和其触发方法；
• **顺序图 → 对象间交互(方法调用链)**：顺序图通过逆向生成UML验证了调用关系的正确性。

三、 大模型使用经验

一些可能有用的方法：

• 分层拆解，分步提示：将复杂任务拆解为多步骤，引导模型逐步推理。如在使用大模型分析题目情景时，可以先让其提取出核心类，再分析类之间的聚合关系。
• 角色扮演：为模型赋予专业角色，提升回答权威性。
• 迭代优化：在大模型给出初版代码后，我们可以自行检查一遍，将不合理的地方交给大模型重新生成，这时我们可以提出更多细致的要求来确保结果的准确性。

在第四单元我主要是使用大模型进行代码的填充，如当我需要某个类时，我可能会先定义好其属性并给出一些空方法，随后交给大模型生成具体代码。这些简单的任务大模型的准确率还是可以的，一定程度上也能帮我节省时间。

四、架构设计思维的演进

1. 第一单元：递归下降法(分治思想)
   第一单元的主题是多项式，说实话如果没有接触OOP教学的递归下降法我第一单元费的功夫肯定还要多一些。通过把一个多项式由Expr拆成Term和Factor，体现了架构设计中很重要的分治思想，由此实现化繁为简。
2. 第二单元：线程安全
   第二单元我们要实现多线程的电梯。为了避免发生死锁这样的线程问题，我们在代码设计时更需要关注线程之间的协作问题。与单线程程序不同，在多线程设计中，两个分别正确实现的类在交互时也可能触发死锁。这需要我们设计更严谨的控制语句进行解耦，确保多线程的稳定。
3. 第三单元：规格设计
   在第三单元围绕JML展开，其最大的意义是给我们提供了一个精确描述方法行为的数学语言。在架构基本被JML确定的情况下，我们所遇到的主要问题是代码的超时问题。这也就引出了我们在架构设计上的考虑：如何在确保方法正确性的情况下优化性能。此时我们的架构考虑就需要综合全局，平衡增添属性和查找属性的开销。
4. 第四单元：设计先于实现
   第四单元的主题是从抽象的系统设计出发，逐步推导出具体的代码实现。此时我们是先有架构设计再有具体实现。

五、测试思维的演进

1. 第一单元：采用Python脚本生成的方式构造大量数据进行黑盒测试，其背后原理是通过大量数据覆盖程序的每一个分支，以期找到一定的Bug。
2. 第二单元：手动构造边界条件用例检查是否会死锁；构造压力测试数据检查调度策略是否合理。
3. 第三单元：对具体方法采用单元测试，在测试方法时同时检查是否满足方法规格的ensures子句等；编写自动化生成数据脚本，构造压力测试数据检验程序是否进行了合理优化。
4. 第四单元：第四单元的数据比较简单，可以通过状态图和顺序图逆向生成测试程序，如在实现预约功能时，逐步检查调用链中的每一个方法是否正确等。

六、课程收获

收获

经历了四个单元的学习，我对于面向对象的思想有了更深入的理解。在设计程序时我会优先设计一个合理的架构，并在此基础上实现具体的代码。
当然在这个阶段我们可以借用llm工具来实现，这使我使用大模型辅助代码生成的能力也有了很大的提升。
此外，在代码的具体实现过程中，我也了解了很多面向对象的思想。如常说的高内聚、低耦合，我不再是使用一个几百行的main方法，也学会了根据方法之间的联系和复用程度进行设计。
这为我提供了一个良好的编程习惯。最后对于测试部分，我了解了对于一个程序需要进行哪些方面的测试(回归性测试、单元测试、压力测试等)，也使用junit和自搭的测评机实现了程序的测试，效率比起之前靠瞪眼debug有了很大提高。

心得

我的OO课程过的还是比较曲折的，因为自己有主持团的排练任务，周六的下午到晚上会被占用，这正好和OO的最后冲刺时间重合掉了，周中的排练也可能会占用一些时间。尤其是一、二单元，每次交OO都像是一场战争，甚至有一次因为熬夜写OO第二天犯了肠胃炎去医院挂了一天水，但即便如此那一次的OO还是没有写完(悲)。我想OO不但教给了我一个有用的技能，更是一定程度上磨砺了我的心性吧。我大概一辈子也忘不了面向对象设计与构造这门课了！