BUAA_OO Unit4课程总结

[黎欣妍-23371341]

OO第四单元总结

整体架构

正向建模与开发

在本单元的代码架构中，我借助UML图进行正向建模，但我没有严格的使用StarUML进行类图、状态图之类的绘制，而是直接手画草稿图，辅助完成的正向建设计代码架构的过程。
主要流程：
1.阅读代码，绘制状态图明晰作业要我们干什么：这个单元是完成一个图书管理系统，主要任务概括起来就是把书籍（在不同的流程中）在书架、用户、预约处等地方转移。
2.确定代码需要的类以及属性、方法，绘制类图。

• 类
  显然每个不同的存储书籍的地方要分别建一个类：Bookshelf,User,Returnplace,Appointoffice,Readroom
  一个统管书籍在不同地方转移的类：Library
  一个Book类封装book的属性和equals等方法
  最后是Mainclass
• 属性方法
  我在代码架构的时候在类图中之列出大概需要的方法，比如Library类里的几个容易确定的跟几个流程一一对应的方法（Borrowed，Returned，...），剩余的大部分方法是在边写的过程中根据需要逐渐添加的。

代码——UML模型追踪关系

由于本单元每次作业迭代所需要加的内容比较少且容易确定，所以在hw14,hw15这两次迭代中，我采取的是直接简单列个什么流程需要增加什么操作的草稿，便开始修改迭代代码，最后再对UML模型图进行更新。

大模型辅助正向建模

在本单元中，我使用大模型的主要功能是教我画UML图，以及搜集更好用的UML绘制插件，比如plantUML,这个插件可以通过编写代码的方式生成UML图，比StarUML方便，plantUML语法也是问AI快速上手的。

架构设计思维演进

在四个单元的训练下我的代码架构思维得到了一个提升
U1：第一单元还没太认识到代码架构的重要性，或者说是太急了，还没有完全想清楚就急于上手，最后的结果是hw1的代码架构出现严重问题，导致写hw2的时候进行了重构，由于时间比较紧，hw2作业强测出现了很多bug，吃了不少亏。
U2：第二个单元在写代码之前更加谨慎了，虽然做不到完美的预测后面的代码实现所需要的架构，实现的过程中也进行了一些调整，但通过先参考学长博客的设计，构思自己的实现架构，比如运行和调度两个逻辑分别需要建哪些类，有哪些线程，以及哪些线程之间会有怎样的交互（画了一张线程和共享资源的图来辅助理清），并且尽可能的考虑可能遇到的问题，在这些过程之后再开始实现代码，这样在后续的实现中碰到的问题就比较少了，即使有，更多的是比如题目的理解、忽略的细节、没考虑到的情况等非架构性的问题了。
U3：第三个单元的JML让我体会了规格化设计的思维，由于JML的规范，自然而然后续代码实现完美的符合架构设计。
U4：第四个单元体会的是借助UML图建模的方式辅助架构设计，为我们提供了一个很好的架构设计的思维方式，更加深了我对于架构设计重视和熟练程度。

测试思维的演进

U1：纯粹构造多样化的表达式来测试代码的正确性。
U2：也是构造样例，但是由于多线程导致了一些bug无法复现的问题，所以有的样例可能会运行多次，以及为了测试出死锁等问题，会针对性的构造一些线程交互频繁的样例。且由于这个单元的输入要求比较容易被AI理解（相比第一单元形式化表示的复杂），所以我也使用了AI来帮忙构造测试样例。
U3：这个单元主要是通过Junit局部测试来检验某个方法的正确性。
U4：由于这个单元比较简单，所以就简单构造了几个样例确保正确实现了相应的功能。

课程收获

在这个学期的OO课程学习中，首先是学会了面向对象和封装的思想。我也深刻的体会了代码架构设计的思维，同时熟练了debug的技巧，而且感受到了同学之间互帮互助的重要性，虽然在debug的过程中经历过几近崩溃的时刻，比如不会写评测机，有些bug光靠自己构造的几个样例根本de不出来，好在室友的一个数据让我发现了bug，顺利通过评测。抛开课程内容本身，我认为在这个课程中我锻炼了自己遇到问题解决问题的能力，从刚开始的碰到bug就手足无措，只会肉眼de，de不出来就哭天喊地，到后来的借助各种手段，构造数据、借助大模型、求助同学积极的解决问题，以及代码实现中遇到各种在架构时没考虑到的问题，通过与同学交流讨论最佳方案，在这个不断构建、不断修正的过程中，让我提升了自己解决复杂问题的能力。