面向对象第4单元博客

[李彦臻-24373418]

oo第4单元博客

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

在完成第四单元作业的过程中，我先根据题目描述画一阶类图，将系统拆分为不同组成部分，明确每个组成部分的功能；之后编写代码并调试；最终根据代码调整类图并画相应的状态图和顺序图。画一阶类图可以帮我梳理清楚程序结构，明确设计哪些类、类的属性和方法、类之间的关联关系，之后参照一阶类图写代码可以避免不必要的重构，而且画完类图后已经对每种方法的行为有明确的预期，可以加速代码编写，也能让我更明确在编写代码时遇到的困难是架构设计导致的还是具体的算法或语法不熟练导致的，能够更快借助AI工具解决。

最终代码和UML对比

第四单元作业的架构遵循了明确的分层职责与面向对象思想。MainClass 作为系统入口，仅负责解析指令并向内部分发请求；核心调度任务全部由LibraryManager统一处理，进行日期推进管理、通过 arrangeBeforeOpen()与arrangeAfterClose()方法开闭馆整理，驱动借阅、预约、取书、阅读、归还、续订及评分等全流程业务；Book和User分别模拟了书和用户实体，管理了信用分、借阅期限、预约信息以及书籍的移动轨迹；Bookshelf（包括NormalBookshelf和TreasuredBookshelf子类）、AppointmentOffice、BorrowAndReturnOffice、ReadingRoom和GradingPlace，模拟了书籍所在的六类物理位置，与 LibraryBookState枚举中的状态一一对应。在代码中借助了@Trigger和@SendMessage等注释建立了和UML图的映射。在顺序图层中，通过@SendMessage逐层标记从MainClass到LibraryManager，再到User、Book以及各个Office的消息链。总体来说，类图中的协作关系、状态机中的迁移逻辑以及顺序图中的消息流和代码能实现双向追踪，保持一致。

引导大模型在复杂场景中完成架构设计

在引导大模型在复杂场景中完成架构设计时，不能直接把指导书喂给AI，一次性生成设计，而是让它初步构造有哪些类，再让大模型明确状态转换路径，之后一步步明确设计。在实验课上我也学到了一些写prompt的方法，比如要指定大模型的角色，给出答案模板和样例，要求大模型不断反思自己生成的内容并给出思考依据。通过不断和大模型交互得到最终的设计。

架构设计思维演进

在第一单元中我的收获是初步破除了面向过程编程的思维方式，适应将多项式拆成因子、项、表达式等不同类型和层级的对象再进行递归处理的面向对象编程思路。在对表达式运算时大量采用递归的方法让我深刻意识到代码功能解耦合非常重要，也初步意识到要先有好的架构设计，才能实现每个类都各自独立负责某项功能，进而达到解耦合的效果，把问题的解决有效拆分为几个简单的步骤，降低写代码的难度。在第二单元的多线程设计中，重点需要处理多线程并发问题，需要明确临界资源，通过“生产者-消费者”模式管理临界资源。第二单元中设计的dispatcher可以避免多个乘客和多个电梯直接相关，将分配和捎带逻辑进行解耦，形成两级“生产者-消费者”，简化线程冲突的分析。第三单元主要是根据JML进行代码实现，我意识到需要通过明确前置条件、后置条件和不变量来规范设计，也进一步明确架构设计和代码实现应该相分离。第四单元中先画UML再写代码的模式强制规范了先设计再实现的过程，在设计时先从宏观角度拆分系统功能，理清各部分之间的关联关系，明确建模后再进行开发。

测试思维演进

在第一单元中我的测试主要依靠根据各种情况构造边界测试样例进行试验，但由于各种情况的枚举不够完全，我没能很有效地检查出程序中的bug。第二单元我一方面借助了同学编写的评测机进行较大规模数据的测试，一方面靠自己分析代码行为并和AI交互避免线程冲突，但是没有想到可以构造全部分配给同一部电梯的极端压力情况。第三单元可以直接根据JML的每一条规范设计有据可依的测试，其中对于方法的pure属性或assignable规定的测试尤其重要。第四单元的测试根据状态图构造样例，测试各种状态转换行为是否正确。

课程收获

由于我确实代码能力基础较差，且配置和学习正确使用AI工具的过程也不幸很慢很艰难，本学期的oo课程作业刚一开始完成质量确实很差。但是在不断赶作业ddl的过程中我慢慢适应了作业的代码量，也学会了正确拆解问题和分析题目的方法，虽然现在可能依然不擅长编程，但通过oo课程的学习和训练、助教的帮助以及研讨课中学习同学们的思路，相比自身有明显的进步，也在第三单元和第四单元初步体会到了规格化开发和工程化开发的规范开发方式。