BUAA_OO_Unit4

[任晓林-23371399]

Unit4

正向建模与开发

本单元我们采用了正向建模与开发的方法。其核心思路是先构思清晰再进行搭建

在这个过程需要明确的需求定义，把需求与设计对应起来，确保需求不被遗漏或误解。在设计的时候就可以思考合理性、全面性，降低了后期修改成本

本单元我们需要根据需求搭建好类图，明确每个类的属性和方法，再进行下一步的搭建。

在本单元中此过程如下

• 进行业务需求分析（用户管理、图书管理、借阅归还），并识别出核心实体（Library,User等）
• 定义类、属性、操作： 明确每个实体的数据结构和方法
• 明确实体间的关系（继承，关联等）
• 以顺序图验证交互逻辑的正确性，以状态图管理Book的状态
• 画出UML类图，并进行直接编码

这样做具有很多优势：

• 架构合理：在编码前获得对整个系统的架构的认识。这避免了“边做边看”导致的架构混乱和后期重构成本。

• 提高代码质量与可维护性：类图确保了对象职责单一、关系清晰。状态图指导了健壮的状态管理。顺序图保证了方法逻辑符合预期流程。这些都直接导致了代码结构清晰、逻辑严谨、更符合设计规范。

• 促进协作，团队之间便于沟通

• 降低开发风险，可以更早的发现问题

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

1. 整体架构设计

• 核心：Library 类作为中央调度器，处理所有命令、状态转移和部门协作。
• Book（书籍状态）、AppointmentBook（预约记录）
• 管理书籍：CirculationDesk（借还处）、ReservationDesk（预约处）、BookShelf（普通/热门书架）
• 入口：Main 解析输入命令并调用 Library。

下面是我的类图

2.对比分析最终的代码设计和UML模型设计之间的追踪关系

UML设计元素	代码实现追踪	一致性分析
类图		覆盖全面，高度一致
核心类	Library, Book, User, BookShelf 等完整实现	类名、属性和方法一一对应。
类关系	聚合关系：Library 包含 BookShelf, ReservationDesk 等实例	完美映射（如 Library中reservationDesk 管理预约记录
状态图		精准刻画书籍转移
状态节点	LibraryBookState 枚举值（如 BOOKSHELF, USER）	代码完全实现所有状态。
转移触发条件	用户动作（如 returnBook()）触发转移，整理动作如（如 circulationDeskToShelf()）	转移逻辑在 Library 实现。
转移路径完整性	覆盖主要路径（如 书架↔预约处↔用户）	路径覆盖完整
顺序图		交互流程匹配
用户与部门交互	Main 接收命令 → 调用 Library → 部门协作	核心交互流程匹配（例：预约→取书流程在 getOrderedBook() 实现）。
消息	方法实现对应上消息传递	与顺序图的调用链一致

当然，以上是我在写完代码后对UML模型进行修改之后的结果

在第一次设计结束后有很多地方可能无法与代码对应，比如

• 数据结构的选择：有时候可能会因为实际代码的需要进行调换
• 方法的新增：在实现过程中可能会发现有一些需要进行辅助的方法

其实还有很多，所以很多同学会先写代码再画类图，当然这不符合我们这个单元的设计思想

设计不合理极大一部分原因是我们的经验不够，无法根据经验得知最需要的架构、方法等，这需要我们在实践中学习

根据使用大模型辅助正向建模的体验，总结分析如何引导大模型在复杂场景中完成架构设计任务

总结来讲就是

分步引导 + 多方案对比 + 明确约束 + 严格验证 = 有效利用大模型辅助复杂架构设计。

1.分阶段给提示词

• 复杂设计不能一股脑儿把所有需求丢给它说“设计个架构”。它容易漏东西或者跑偏。

• 需要进行分步骤提问，先理解需求，再分离业务实体，分析需要的方法，分析类之间的关系

2.多生成几个比一比

让大模型生成并不耗费精力，但是我们可以在比较中选择最适合的架构

3.让它明确一些条件

比如在前几次告诉他还书是一定能还的，但是借书有各种各样的条件，让它明确各部分条件

4.自己验证

如果使用大模型一定要看它是不是对的，自己再思考一遍，才能保证正确性。

5.先给一个框架，让它往里填充东西是更合理的方式，让其能更容易生成符合我们思想的架构

架构设计思维的演进

简单回顾一下四个单元的架构

第一单元：递归下降解析：词法分析(Lexer) + 语法分析(Parser)

​ 分层抽象：Expr（表达式）→ Term（项）→ Factor（因子）

​ 统一多项式表示：Poly（多项式容器） + Unit（多项式基本单元）

第二单元：

生产者-消费者模型：生产者：InputHandler（输入线程）

​ 缓冲区：RequestTable（请求队列）

​ 消费者：Elevator（电梯线程）

策略解耦：Strategy接口提供调度建议（LOOK算法）

第三单元主要是契约式设计：通过JML规格约束行为

第四单元正向建模与设计，架构不再多言

在四个单元中，在第一个单元中我主要是学习了学长的架构，看学长的博客，先学习递归下降的思想，然后自己一点点想怎么搭建；在这一单元中我面向对象的思维不是很足，设计架构的经验也不够，出现需要改动的情况

这一单元主要掌握递归下降的思想，如果真的掌握好了的话，我认为架构是水到渠成的，但是第一次作业确实给我造成很大的困难。达到高内聚低耦合还是有一定难度

在第二单元中我主要学习了生产者消费者模型，这一单元对于多线程的设计对我而言难度很大

怎样避免死锁，怎样达到进程的同步，怎样保证执行顺序，多线程给我带来很多问题

在设计架构之前，我先学习了基础的一些知识，然后思考怎样实现

这一单元我的进步很大，我学习了生产者消费者模型，并初步进行多线程的探索，架构设计也比上一个单元更加优秀，达到了各司其职的效果

在第三个单元，其实我们需要掌握的是契约式设计，实现的代码要覆盖全面JML规格。这一个单元对于设计的要求我认为不是很大，实现代码也只需要进行“翻译”JML，架构上要求不突出。主要考点是算法，动态维护，把之前的BFS的算法应用进去，并查集等等，这一单元主要是如何进行优化。

在第四个单元，我们采用了正向建模与开发的方法。这一单元对于架构设计的要求不高。我很快就完成了设计。在之前的基础上，架构设计的更好，能够达到各司其职，基本上达到了“高内聚低耦合”。这一单元主要是了解正向建模的思想，在大型工程中会发挥用处

测试设计思维的演进

在第一个单元，我的测试还停留在自己捏造一些数据，尽可能让它覆盖全面，思考一些边界程序，但有些时候思考并不够全面，往往在编代码时忽视的点手动编写测试数据的时候同样会犯。

在第二个单元，我学习了搭建评测机。这一部分对我的多线程作用很大，帮我找到了很多bug

加强数据强度是测试中比较关键的点，需要尽可能增强特殊数据的情况，比如6部电梯5部电梯UPDATE

在第三个单元我认为比起搭建评测机，更重要的是对它进行压力测试，思考什么样的数据会让它超时

对于可能会超时的部分我们构造极限数据，测试其运行时间。比如： 对于测试qtvs,构建一个较大的关系图，添加入同一个tag，然后不断询问qtvs； 对于测试qcs,构建一个较大的关系图,不断删关系，加关系，询问qcs等等

在这个单元进行了一些junit测试，单元测试也是具有它的优点的，可以帮助我们测试一些容易出错的方法

在第四个单元，我只进行了简单的覆盖功能的小数据测试

课程收获

人生天地之间，如白马过隙，忽然而已。课程来到了尾声。回想当时第一个单元的第一次作业，我当时真的觉得自己无法达到课程标准，但是一个学期下来，好像也没有那么难。第一次写代码量这么大的代码，第一次真正感受面向对象的思想。回顾一个学期，有压力带来的急躁，有强测低分带来的难过，也有顺利通过的喜悦。花费了很长的时间但是也的确学到了很多东西。面向对象的思维，如何解析需求、设计合理的架构，编写java，学会契约式设计，学会正向建模的思想，学会测试，学会debug，学会找到bug，甚至是学会使用大模型。学到的知识是不会骗人的。

OO的旅程来到末尾，但学习的旅程还有很长。编写OO的过程也许会成为我宝贵的回忆。每一个结束都潜藏着一个新的开始，希望有更好的明天。