BUAA-OO Hw16 Unit4&OO课程总结

[冯泽昊-23373323]

BUAA-OO Hw16 Unit4&OO课程总结

目录

• BUAA-OO Hw16 Unit4&OO课程总结
• 前言
• 总结本单元所实践的正向建模与开发
• 总结本单元作业的架构设计，并对比分析最终的代码设计和UML模型设计之间的追踪关系
• 根据使用大模型辅助正向建模的体验，总结分析如何引导大模型在复杂场景中完成架构设计任务
• 总结自己在四个单元中架构设计思维的演进
• 总结自己在四个单元中测试思维的演进
• 总结自己的课程收获

前言

最后一次博客作业，也不搞一些弯弯绕绕的，下面每个二级标题即为技术博客的要求

总结本单元所实践的正向建模与开发

Unit4单元需要我们完成一个图书管理系统的设计，同时让我们实践正向建模与开发的模式。

按照我的理解，正向建模和开发应该是先通过头脑风暴、架构设计完成模型，然后根据模型进行开发。

在前三个单元中，我们其实也是先在头脑中完成架构设计，然后才开始编写代码，不过本单元我们依托StarUML软件进行正向建模，并且要求我们至少使用UML类图、状态图和顺序图描述模型的构建，每种图描述的侧重点都有所不同。

• 类图：核心视角为系统的静态结构，主要描述了核心类、类的属性与方法、不同类之间的关系（继承、聚合、组合等）。
• 状态图：核心视角为系统中单个对象的动态行为，描述了核心类的状态、转移、事件、条件、动作。
• 顺序图：核心视角为系统中多个对象在场景中的动态交互，描述了对象/生命线、消息（同步/异步）、激活条、时间。

UML图可以让我们的架构设计更加形象具体地展现出来，并且方便共享和理解。

课程组希望我们通过“正向设计->代码编写->架构优化”的方式完成作业要求。但是本单元模拟的图书管理系统需要完成的要求比较简单，正向建模与开发的优势不是很明显。

第一次我的作业采取的是课程组要求的方法。后两次迭代作业因为迭代需求不多，并不复杂，我采取的形式是先在头脑里完成主要逻辑的设计，然后根据设计完成代码编写，最后修改UML图。

总结本单元作业的架构设计，并对比分析最终的代码设计和UML模型设计之间的追踪关系


最底层的类为 Book 类，每个 LibraryBookId 唯一对应一个 Book 对象， Book 内部存储书籍有关信息，包括书本Id，移动轨迹，预约人Id、预约时间、借书到期时间等信息。

中间 BookShelf 、 BorrowAndReturnOffice 、 AppointmentOffice 、Student 、 ReadingRoom 类并列，都是存储 Book 的容器，每个类提供存取 Book 的方法，并且根据根据实际业务需求，不同类内部会有不同的属性和方法用于处理书籍在此处的行为，与 Book 类进行交互。

顶层 Library 类用于处理与系统IO( MainClass )的协作，并且 Library 类内部实例化所有中间层容器类，处理整理时各个容器之间的协作关系。

对于不同的UML图，追踪关系的表现不太相同，我们可以参考指导书和官方评测机的标准进行理解。

• 类图：图中对象与代码中的类、属性、方法与关系一一对应。
• 状态类：代码是否包括状态图的所有状态转移路径，并且转移的条件是否一致
• 顺序图：检查 Lifeline 、 Message 是否与代码一致。

在我的代码架构中，我的每一个对象、每一个对象的属性和方法都能在UML类图中找到对应的 <UMLClass> ，并且对象之间的关系也与图中一一对应。我的状态图和顺序图写的比较潦草，基本满足追踪关系，但并没有完全覆盖到程序所有的状态转移和消息传递，因此我在这里也就不展示和分析了。

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

我使用大模型辅助的次数不多，本单元作业仅在第一次作业中使用大模型辅助正向建模。

如荣老师所言，当前大模型对于理解业务需求到生成代码这一部分表现其实不尽人意。因此，让大模型读取场景和需求后一次性生成的代码质量似乎并不高。

在引导大模型完成架构设计时，我们需要为大模型提供题目背景和需求，不过建议对要求进行强调和提炼。

想要大模型生成更高质量的结果，我们可以为大模型设定合适的身份，明确任务描述，采取诸如实验提到的CoT范式，为大模型的生成提供模板，帮助大模型更好完成核心架构设计。更重要的是，我们需要审查大模型生成的结果，在效果不好时让大模型根据一定的原则进行反思迭代。

总结自己在四个单元中架构设计思维的演进

• Unit1

  从OOPre过渡到Unit1，面对一个全新的工程，我更关心功能分解和类的职责划分。递归下降的方法需要我们对类进行属性和行为的合理封装。自己在当时也考虑过导数的运算展开应该是放在表达式解析部分还是后面的多项式初步合并部分，这也就是关于业务逻辑与代码架构，类的行为之间的权衡与思考。

• Unit2

  该单元的主题是多线程开发，我们需要特别关注模块间的交互、多个线程之间的并发，线程的协同处理以及数据的冲突与保护的问题。在这个单元中学会锁与同步块的使用的同时也更加体会到了封装的重要性。

  这个单元线程交互的模式采取了生产者-消费者的模式。在 strategy 类这种未来可能需要变化、优化的类预留了接口（虽然最后没有用上），为后续迭代开发预留了空间。

• Unit3

  采用JML进行代码开发，虽然我们没有亲自完成大量JML的编写，但是我体会到了JML对工程开发的巨大作用。JML的思想也点拨了我后续代码架构的构思，包括但不限于：如何通过前置条件后置条件和副作用描述一个方法、如何保障前置条件和后置条件的充分必要性、如何划分关键类职责。

• Unit4

  在一次UML正向建模实践中，我感受到如何更好地自顶而下地看待问题，进行架构设计，实现模块职责分离和系统整体协同。同时，对于更大型的模型设计，我们可以采取其他建模工具进行可视化的建模，便于团队协作和理解，确保设计与实现相统一。

架构的优化和能力的提升是在不断重构中实现的。

总结自己在四个单元中测试思维的演进

首先还是先回顾一下自己四个单元的测试方法：

• Unit1借用室友的评测机进行黑盒测试，主要通过输出对拍实现测试功能。

  由于表达式的语法结构和我们实际生活中使用到的数学表达式不太一样，我还尝试自己构造了一些极端样例，包括针对程序逻辑功能的测试样例与针对程序运行效率的样例。

• Unit2自己尝试在学长的评测机的基础上修改使其符合要求，主要是通过输出模拟电梯状态是否符合要求实现测试功能。

  由于自己对电梯的移动约束考虑不周，自己和自己的的评测机都忽略了电梯双轿厢更新后量子电梯移动的情况，导致我的电梯在这种情况下移动速度过快，评测机也不能很好地检测出问题。这也让我明白如果想要使得评测机覆盖各种情况是十分困难的，并且评测机的状态机模拟思路最好是与程序的实现思路不同，否则受限于自己对认识的理解，评测机很可能也检测不出自己程序的Bug。

  因此，测试时最好要与其他人交流协作，包括但不限于分享易错细节、交换评测机进行评测。

• Unit3借用室友的评测机进行黑盒测试，但主要还是通过人力与大模型协作的代码走查。

  这个单元主题是JML，规定了许多函数的前置条件、后置条件和副作用，因此十分适合单元测试（Junit）。而实际上我们测试重心应该也包括性能方面，于是我采用瞪眼法，在拿不准的程序逻辑方面会询问大模型。

• Unit4借用同学的评测机进行黑盒测试，同时辅以单元测试。

对于测试思维的变化，自己反思如下：

• 重视测试：接触的工程越大就越感觉一次写出没有Bug的代码是十分困难的。代码质量的保障不止在编写代码、架构设计上，还需要全面且充分的测试。
• 掌握更多的测试策略，包括回归测试、集成测试、单元测试等方法，并且根据实际情况选择合适的测试方法以提高代码的质量和测试的效率。
• 测试数据的设计：包括压力测试，比如在高并发场景下短时投入大量数据；边界测试，比如在边界条件附近构造数据点进行测试；针对细节和易错点进行测试数据的构造。

总结自己的课程收获

实打实，码力提升。毕竟自己动手写了这么多代码，囊括了四个项目。如荣老师所言，写多少行代码就有多少经验。

面向对象方法与思维的深化，这一部分应该是潜移默化的。同时也学习到了很多设计模式之类的东西，虽然目前没有用上，以后也可能用不上，但是这些东西在我心里埋下了种子，以后再用就是老熟人了。

如何用好大模型进行辅助。这个部分应该是今年最新加上的，在实验部分尤为突出，自己原本也没想到可以用这么多方式调教AI让AI的回答质量更高，学到了。

测试思维的提高。课程安排中测、强测和互测，软性要求我们不断进行测试，在实践中提升自己的测试能力。在Unit3中也是掌握了各种测试的方法和形式。

信息整合能力提高。自认为自己是一个创新能力不强的人，每次看完指导书后我还是翻了很多学长学姐的博客，分析架构的优劣，选择自己认可的架构进行实现。

团队协作能力提高，主要体现在自己在课下和室友聊的OO内容比较多，协作完成评测机的实现与相互Debug过程。自己现在也更倾向找佬们相互扶持完成程序与任务。

研讨课的讨论、博客的撰写，都对我的表达能力提出了要求。自己也是在课程的过程中不断尝试提高自己表达的精度和信息量。

虽然对我来说OO课程已经临近尾声，但我仍然希望能把自己的经验，踩过的坑，发现的窍门通过博客传递给即将要上OO课程的学弟学妹。

最后，由衷感谢面向对象设计与构造课程组的各位老师与助教以及同行的同学们，感谢你们本学期以来的陪伴与支持。