OO-Unit4总结

[刘梦琨-24231215]

OO-Unit4暨全课程总结博客

一、本单元正向建模与开发实践及两阶类图的作用

正向建模与开发实践

在本单元的图书馆模拟系统中，我们体验了完整的“正向建模与开发”流程。与以往直接上手写代码不同，这次我们在编码前，首先需要通过分析需求，绘制UML类图，确定代码的整体架构，在根据UML类图进行代码实现。这个过程的核心步骤包括：

1. 需求分析与概念抽象：使用UML类图进行建模，需要准确识别出所需的类及对应的方法。首先识别系统中的实体（如用户、各种类型的图书、书架、借还处等）并建立对领域业务的模型化理解。根据题目中规定的具体的业务流程（如预约、借阅、逾期处理等），抽象出系统的核心方法。
2. UML模型构建：确定好类和方法后，只需分析类之间的关系（如继承、组合、依赖等），就可以构建出完整的UML类图。
3. 依据模型开发：在整体模型确立后，根据UML类图进行代码实现即可。

两阶类图在正向建模过程中的作用

本单元强调了两阶段的类图设计。两阶类图是指代码编写前后所绘制的两个类图。第一个类图是根据题目需求分析设计出的架构图。第二个类图是在代码实现完成后，根据实际代码结构绘制的类图。两阶类图的作用在于：

• 第一阶类图：是本单元训练的重点，主要是在需求分析阶段设计的概念级类图。它侧重于从业务角度抽象出系统的核心类和方法，强调了系统的功能需求和业务逻辑，而不涉及具体的实现细节。通过设计第一阶类图，我们能够体会正向建模的核心思想，即先从业务需求出发，构建一个清晰的系统架构。
• 第二阶类图：是在代码实现完成后，根据实际代码结构绘制的类图。它反映了代码实现的细节和实际的类关系。通过比较第一阶和第二阶类图，我们可以评估设计与实现的一致性，发现设计中的不足或实现中的偏离，从而进行调整和优化。
  通过编写两次类图，我们可以更好反思设计与实现之间的关系，提升我们在正向建模过程中的设计能力和代码实现能力。

二、本单元作业架构设计及UML与代码设计的追踪关系

架构设计总结

本单元以图书馆模型为核心，经历了三次迭代（HW13 -> HW14 -> HW15），系统功能逐步从基础的借还、预约，扩展到了阅览室、图书积分、漂流处理等。
主要模块包含：

• 核心控制模块：Library类作为总控，负责接收外界时间流和指令。
• 场地与存储模块：Bookshelf（普通书架）、TreasuredBookshelf（珍藏书架）、AppointmentOffice（预约处）、BorrowReturnOffice（借还处）和ReadingRoom（阅览室）等，实现了图书在各个物理或逻辑地点的存放。
• 流转层与记录模块：新增了BookRouter与TraceManager对书籍的运输与借阅轨迹进行追踪。
• 用户模型：User类记录了每个账户所借阅的书籍和信用分（BookScore）。

整个架构采用了高度的面向对象原则，各个区域只负责各自的状态管理与图书移入移出，依赖于总控制类的调度和职责分配。

UML模型与代码设计的追踪关系

最终的代码设计与UML模型设计保持了高度的一致性与追踪性。

1. 类图层面：代码中的各个实体类和工具类及其继承/组合关系完全对应于UML设计级类图。例如 UML 中的对象模型在代码中被书架、预约处等类分别实现或继承，属性的命名和数据类型也保持同步。
2. 状态图层面：对于书籍的状态（如在书架、在预约处、在漂流站、在用户手中等），代码中的状态变量或书籍所处的不同容器精确体现了状态图中的每个节点；书籍在借阅、归还、逾期处理时执行的方法严格对应状态图的转移条件（Transition）。
3. 顺序图层面：在某个具体的业务流程（如用户借书流程）中，代码内对象的方法调用链完全契合顺序图中的消息传递过程。
   这种严密的追踪关系使得代码逻辑非常清晰，而在后续迭代中，我们也能直接通过修改UML模型来指导代码的重构或新增逻辑。

三、四个单元的架构设计思维演进

回顾四个单元的历程，我的架构设计思维经历了显著的演进：

1. Unit 1（表达式求值）：当时主要是关注如何解决功能需求，采用了递归下降解析器设计，开始体会到“面向对象”封装数据的优势，但整体思维仍偏向过程式，类的设计较为生硬。
2. Unit 2（多线程电梯）：理解了并发与交互。架构设计的核心转移到了线程安全与协同，学会了使用锁和调度器分离。此时，架构设计的重点是解耦、以及明确各个对象的职责（楼层、电梯、调度器互不干涉）。
3. Unit 3（JML规格与社交网络）：关注契约式编程与接口规范。不再是由自己随意设计所有的功能层级，而是根据给定的规格（JML）进行实现。懂得了怎样在明确的规范下进行底层数据结构的选择和算法的优化，理解了接口和实现分离的架构意义。
4. Unit 4（UML与正向建模）：提升到系统与业务的宏观建模的抽象。在前三单元的代码能力基础上，学会了“先设计、再编码”。这是一种从高层到低层、从宏观到细节的设计思维，能够在一个系统构建前就规划好各个模块的功能与边界。

四、四个单元的测试思维演进

测试能力的培养是这门课非常重要的一环：

1. Unit 1（黑盒与对拍）：以基于正则的随机数据生成器进行黑盒对拍为主。由于没有掌握其他测试方法，在边界数据上常常考虑不够全面，主要通过穷举随机样例来盲测。
2. Unit 2（死锁与并发测试）：测试变得更加棘手，多线程带来的不确定性使得以往单纯的对拍无法覆盖所有情况。除了构建随机生成器，还学会了通过阅读代码寻找可能发生死锁或线程不安全的临界区。开始关注“压力测试”和“正确性边界”。
3. Unit 3（JUnit与单元测试）：正式接触了单元测试工具 JUnit。我的测试思维从“整体跑样例”转为了“针对每一个方法进行边界值分析与断言验证”。基于契约，利用 JUnit 覆盖各个方法的正常情况、异常抛出，使得排查 Bug 的范围缩小，极大地提高了 debug 效率。
4. Unit 4（场景与业务流测试）：纯粹的单元测试已无法完全覆盖复杂的业务流测试，需要针对系统的核心业务流程（如预约-借阅-归还-逾期-信用分）编排特定场景测试。这时候测试思维升级为检查“系统集成行为的正确性”。

五、课程收获总结

这一学期的OO课程无疑是充满了挑战与收获的：

1. 代码能力的提升：从原本写几百行代码都觉得费时费力，到现在可以相对轻松地构建一个较为复杂的系统。
2. 工程化思维的建立：我深刻认识到了先设计后编码（UML）、契约式编程（JML）、良好的代码风格（Checkstyle）以及规范的测试（JUnit）在现代软件工程中的核心地位。在编写代码中，认识到了LLM的作用以及对软件工程带来的深刻的变革，但是在不断地迭代、测试中，也意识到了LLM的不足。
3. 问题排查能力：经历了强测与互测的洗礼，在面对多线程或性能优化的挑战时，锻炼了通过单步调试及抽象分析等手段剥丝抽茧定位问题的能力。