2025_OO_U4总结_课程总结

[肖心宜23230603]

2025_OO_U4总结_课程总结

---

一、正向建模与开发的实践总结

1.正向建模的具体实施路径

在本单元的学习与实践中，我主要按照“需求分析 → 用例建模 → 类图 → 代码实现”的正向建模路径推进系统开发任务。首先，在动手编码前，我会初步画出类图的大致结构，明确系统中需要设计哪些类，以及各类所需实现的核心功能与职责。这一阶段不仅帮助我理清了系统的整体架构，也为后续的模块划分和功能实现提供了明确的指引。在完成类图设计后，我依据已有架构开展具体的代码编写工作，实现了从建模到开发的自然过渡。

至于状态图和顺序图的绘制，我的做法是在代码实现完成后，基于已有的程序逻辑和交互流程反向绘图。这种方式有助于我更好地理解系统运行中的动态行为，也进一步验证了程序设计与建模之间的一致性。通过这一系列流程，我对UML建模在软件设计中的实际意义有了更深入的体会，也提升了将抽象设计转化为具体实现的能力。

当然可以，以下是围绕主题**“所遇到的建模难点与解决方式”**撰写的拓展内容，紧扣课程背景和正向建模实践过程，可用于汇报或课程报告中：

2.所遇到的建模难点与解决方式

在正向建模的实践过程中，我也遇到了不少挑战和难点，尤其集中在图与代码之间的一致性维护方面。

首先，状态图与顺序图的绘制存在明显的反向建模难度。由于是在代码完成后再画图，一些流程容易遗漏或表达不清，尤其是在涉及复杂状态转换或多对象交互的场景中。为了解决这个问题，我尝试边调试边记录关键行为，将方法调用与状态变化一一对应，再转化为标准UML图。这种方法虽然耗时，但显著提升了建模的准确性和系统理解的深度。

另外，在实现过程中还遇到了建模与代码之间不一致的情况。有些类在设计时预设了较多功能，实际编码中却发现部分功能并不必要，或者实现方式与预期不同。为了解决这种“偏离设计”的问题，我学会了以迭代方式调整模型，即在实现中发现问题后及时回头修改类图，从而形成了“设计-实现-优化”的良性循环。

总体而言，这些建模过程中的难点虽带来挑战，但也促使我进一步理解了UML工具在软件工程中的价值。通过问题导向的学习与反思，我在建模思维、工具使用和系统整体把控能力方面都有了显著提升。

---

二、架构设计与UML模型对比分析

1.架构设计简述

(1)核心设计原则

• SOLID原则：

  • 单一职责原则（SRP）：每个类职责明确，例如Book管理书籍信息，User处理用户行为，BookShelf管理书架等。
  • 开闭原则（OCP）：通过继承（如HotBookShelf扩展BookShelf）和接口隔离实现扩展。
  • 依赖倒置原则（DIP）：高层模块（如Library）依赖抽象（如BookShelf接口），而非具体实现。

• 高内聚：

  • 模块内聚性强（如AppointmentOffice仅处理预约逻辑）。

(2) 分层架构

• 表现层：

  • Main类：处理用户输入（命令解析）和输出（通过PRINTER）。

• 业务逻辑层：

  • Library类：核心业务逻辑（借阅、归还、预约等），协调各模块。

• 数据访问层：

  • BookShelf、AppointmentOffice等：管理数据存储和操作（如书籍的增删查改）。

(3) 关键模块与职责

模块	职责
Book	封装书籍属性（ID、状态、借阅记录等），提供状态管理方法。
User	管理用户行为（借阅、预约、信用分），处理权限和信用分逻辑。
BookShelf	管理书架上的书籍，支持按ISBN查询、添加/移除书籍。
HotBookShelf	继承BookShelf，扩展热门书籍的特殊管理逻辑。
AppointmentOffice	处理预约书籍的存储和逾期检查。
BrOffice	管理借阅归还办公室的书籍临时存储。
ReadingRoom	管理阅览室内的书籍。
Library	核心业务逻辑，协调各模块完成借阅、归还、预约等操作。

(4)设计模式应用

• 工厂模式：

  • Library.initial()通过Book构造函数初始化书籍，隐藏创建细节。

• 状态模式：

  • Book的bookState（BOOKSHELF、USER等）驱动不同行为。

• 策略模式：

  • User.tryBorrowOrder()根据不同书籍类型（A/B/C）应用不同的借阅规则。

---

三、大模型辅助下的正向建模体验与策略总结

1. 不同使用场景下大模型辅助的体验

(1) 场景一：生成简单代码

在一些规模较小、复用性较高的功能模块中，大模型在代码生成方面展现出了显著优势。例如常见的工具类方法、接口模板，或是 toString、hashCode 等方法的自动实现，都可以高效生成，减少了大量机械性的编码工作。

案例分享：在第二单元（U2）作业中，我使用大模型直接生成了处理楼层变化的相关代码，涵盖了计算楼层差值、实现楼层上升/下降等功能模块。只需给出清晰的功能描述，大模型便能输出结构清晰、逻辑合理的函数体，大大提高了开发效率。

使用体验：整体而言，大模型在这类简单逻辑的代码生成中，具备良好的复用性和细节处理能力。不仅节省了编写时间，也在一定程度上提升了代码的规范性和可读性，为后续的维护和扩展打下了良好基础。

(2) 场景二：解释复杂信息

案例分享：

• U2，大模型帮助我理解 wait/notify 的行为机制

• U3，大模型解析JML规格，辅助个人理解

• 提出需求，让大模型回答是否有可用的已有的类or模块(比如LocalTime这样的）

使用体验：

• 可以问答互动：确认自己是否理解正确

• 更严谨、更注重细节：在自己的理解的基础上

• 简化工作：学习新的类，避免重复造轮子

(3) 场景三：bug 修复

• 分析潜在的风险，给出适当的优化建议。

  • ** 案例分享** ：LinkedList方案 -> LinkedSet + 链表方案

• 解释报错信息，快速定位错误类型。

  • ** 案例分享** ：比如，理解空指针（NullPointerException），越界（ArrayIndexOutOfBoundsException），数字转换（NumberFormatException）

  • ** 使用体验**：在大模型的帮助下，快速了解报错信息的含义，快速定位问题，有助于在调试、修改的时候有方向感。

2. 大模型使用策略的进步

(1) 从“指令堆砌”到“结构化对话”：

起初只会问“这段代码哪里错了”，后来学会带上上下文、需求、预期输出

(2) 从“依赖答案”到“辅助思考”：

不再“照搬代码”，而是先有思路，用模型来对比、验证、补全比如，U2的Floor相关写法其实是直接照搬的，后面会让LLM推荐合适的数据结构、算法等来辅助完成

(3)学会筛选模型建议：

从不同模型的回答中找出逻辑合理、适配当前代码结构的解决方案
比如，上面说到的LinkedList方案时刚开始写代码时GPT给的建议，后面修改时参考了DS的方案

---

四、架构设计思维的演进总结

本学期四个单元的编程任务在复杂度和设计要求上逐步递进，我的架构设计思维也在实践中不断发展和完善。每个单元都带来了新的挑战，也促使我在系统划分、模块职责、接口抽象等方面不断思考与优化。

1. U1：递归解析 —— 从算法逻辑到初步架构感知

第一个单元的核心任务是实现对嵌套表达式的递归解析。在这一阶段，我主要关注算法的正确性与边界处理，尚未形成完整的模块划分思维。不过，在尝试将递归逻辑封装进类方法的过程中，我初步体会到“职责单一”的设计原则，也开始有意识地将复杂逻辑分解为多个函数协作处理。

2. U2：多线程设计 —— 并发控制与模块解耦

第二单元引入了多线程并发问题，对架构设计能力提出了更高要求。我开始关注线程安全、调度逻辑与数据共享的边界。在设计过程中，我尝试将调度器、楼层请求队列、电梯实体等模块分离，使各自职责更明确，同时通过合理使用 wait/notify 保证线程之间的同步。这一单元的完成，使我对“组件解耦”与“并发架构”有了初步的实践经验。

3. U3：JML规格驱动 —— 契约设计与形式化思维

第三单元要求使用 JML进行接口规范化设计，这让我更深入地理解了“先定义、后实现”的契约式编程思想。在这一过程中，我开始反思之前接口设计中存在的模糊与歧义，并尝试用形式化语言精确描述类和方法的行为。这种设计方式迫使我在编码前思考清楚边界条件与异常处理，也提高了后续实现的鲁棒性与可验证性。

4. U4：UML正向建模 —— 全流程架构建模与实现对齐

最后一个单元将设计推向系统级别，要求从需求出发，完成类图、顺序图、状态图多视角建模，并据此实现代码。相比前几个单元，这一阶段更加强调架构的整体性与一致性。我尝试从用例建模切入，推导出类的划分与关系，再逐步实现具体功能。这个过程让我理解了如何将抽象设计落实为具体代码，也真正体会到良好建模对系统可维护性与扩展性的支持作用。

总的来看，我的架构思维从单纯的逻辑实现逐步扩展到模块划分、接口规范、并发控制和系统建模，形成了较为完整的软件设计框架。这一演进过程不仅提升了我的代码质量，也为我日后参与更复杂的软件项目提供了宝贵经验与思路。

---

五、测试思维的演进总结

随着四个单元任务的不断深入，我的测试思维也在逐步发展。从最初的功能性验证，逐步过渡到结构化测试、边界分析、异常处理验证，直至理解契约式测试与可复用测试框架的构建。以下是各单元测试思维的演进过程总结：

1. U1：功能验证为主，边界测试意识初步建立

在第一个单元中，测试主要集中在验证解析结果的正确性。起初我采用简单的“输入—输出”对照方式进行验证，但很快意识到边界情况（如嵌套层数过深、符号嵌套出错等）容易被遗漏。因此，我开始尝试构造覆盖不同语法结构的测试样例，逐步建立起基本的边界测试意识。

2. U2：并发场景下的行为验证

第二单元引入多线程机制，传统的“静态输入—输出验证”已不足以覆盖所有情况。面对电梯调度中线程切换的不可预期性，我开始重视测试的覆盖性与稳定性。通过插入日志和模拟并发请求等手段，我探索了更具可控性的测试方法，并关注系统在极端并发状态下的正确性与响应速度。

3. U3：基于规范的契约式测试

在JML规格引导下，我开始以“前置条件—后置条件—不变量”的视角进行测试设计。这促使我在编码前就思考“哪些输入是合法的”“输出必须满足什么特性”，从而有的放矢地设计测试用例。这种形式化的测试思维不仅提升了测试的严谨性，也帮助我发现了许多潜在的逻辑漏洞与边界缺陷。

4. U4：结合建模的多维度测试验证

在最后一个单元中，随着系统复杂度提升，我开始尝试从建模结果出发设计测试策略：通过顺序图验证对象交互流程、通过状态图检查状态转换完整性，并利用类图推导关键路径与方法调用关系。这一阶段，我开始构建模块化测试用例，注重可复用性和覆盖率，并使用断言等机制提高测试的自动化水平。

---

六、课程收获与反思

通过本学期四个单元的学习与实践，我在编程能力、面向对象思维、调试测试技巧以及大模型辅助开发方面都得到了显著提升，也为未来参与更复杂系统的开发打下了坚实基础。

1. 编程与设计能力的提升

在持续迭代的作业中，我不仅熟练掌握了 Java 的面向对象特性，还逐步建立了模块化、层次化的开发思维。通过UML建模、架构设计训练，我对系统设计的整体把控能力有了系统性提升。

2. 测试与调试能力增强

面对各类逻辑错误与运行问题，我从最初依赖手动测试转向构建系统测试用例，并熟练掌握了断点调试、日志分析等方法。这一过程中，我更加意识到测试环节对保证代码质量的重要性。

3. 理解并实践了大模型辅助开发

在多次作业中，我尝试借助大语言模型生成工具函数、接口模板或优化建议。模型在处理结构清晰的小任务时非常高效，也让我体会到以“开发者视角”提问的重要性，提升了模型交互效率。

4. 面向复杂系统开发的信心

通过完整的“建模—实现—测试—优化”流程，我逐步具备了从需求分析到架构落地的综合能力。这让我在面对更大规模、更复杂的系统开发任务时，具备了更强的信心与方法储备。

这门课程不仅提升了我的编程与设计技能，更让我系统体验了软件开发的全过程，为将来走向专业开发实践打下了坚实基础。