BUAA_OO_Unit4 单元总结

[林钰展-23371235]

一、Unit4单元分析

1、正向建模实践

本单元提倡我们先根据需求设计uml类图，再根据uml类图实现具体的代码，以体验正向建模的过程。不过，由于感觉直接先简单想好大致的框架与流程，上手实践再发现架构设计的不足，比对着类图凭空想象每个类的属性、每个方法的作用来的更快更好，我还是采用了先完成代码再填充uml类图的邪道。话虽如此，我也清晰地体会到uml类图、状态图与顺序图对于程序架构的强大表达能力。uml图在向别人呈现自己的设计思路时确实比自然语言清晰明了得多。

2、架构设计

最终的类图如下：

总体架构就是Main类调用Library类实现各种不同的请求，Library类负责管理在架的图书、所有用户以及各个部门，每个部门管理当前在该部门的图书并与Library类交互。值得一提的是第二次迭代中hot bookshelf的实现，我并没有新增一个书架实现图书在bookshelf与hot bookshelf中的移动，而是在Library类中增加了一个记录当天热门图书的isbn的HashSet，当isbn号在该HashSet中的图书移动时，改变对应的输出即可，算是减小改动量的便捷实现方法。第一次作业与第三次作业比较固定，按需求直接实现即可。

3、代码设计和UML模型设计之间的追踪关系

代码设计和UML模型设计之间的追踪关系表现为uml类图中的每个类、类的每个属性与方法在代码中都有对应的具体实现，类图还展示了类与类之间的各种关系。状态图表现了在代码执行时书籍可能的所有状态以及发生状态转移的条件。顺序图表现了在完成预约、取书请求时，类与类之间的信息传递与交互。总之，UML图将较为抽象复杂的代码设计以图像的形式清晰具体地呈现了出来。

二、大模型辅助

在四个单元中，我没有直接使用大模型进行直接的架构设计与代码编写，而是将其作为一个精确的搜索引擎，询问我在写代码过程中遇到的各种问题（如多线程synchronized关键字的具体用法）。理由是使用大模型直接编写代码存在出错的可能，人为纠错费时费力，如果想要读懂它的代码逻辑则更是如此。
对于引导大模型在复杂场景中完成架构设计任务，可以采用实验中提到的roses或cot方法给出提示引导。不过，在研讨课上，我们小组一致认为这些引导的效果不尽人意，不如直接把需求全丢给大模型，让其直接生成来的好。总的来说，我认为现阶段使用大模型辅助存在可能出错、架构设计不好等问题，进一步引导的话可能还会产生反效果，浪费时间，也不能真正锻炼我们架构设计的能力。不过对于未来进入到能熟练设计架构的阶段来说，掌握使用大模型辅助设计的能力确实是有必要而且省力的。

三、在四个单元中架构设计思维的演进

第一单元由于缺乏经验，设计的架构可以说比较糟糕，最终的poly类具有非常高的复杂度，层层的方法调用也导致debug与迭代进行的较为困难。第二单元吸取了第一单元的惨痛教训，在写代码前花了更多时间在架构设计上，最终虽然总体架构清晰，但由于第一次接触多线程设计，在一些线程交互功能的实现方面比预想的加了很多控制，增加了代码复杂度。第三单元虽然不需要设计架构，但是通过对jml要求的实现，让我增加了对于处理异常行为的经验。第四单元在我看来就是对架构设计能力的综合考验，根据前几单元的设计经验，最终设计出了不错的架构（当然也有可能是需求比较简单）。经过四个单元的磨练，我深刻感受到层次化设计以及设计模式的重要性，懂得在设计过程中合理控制每个类的复杂度，并注意异常与边界情况，收获颇多。

四、在四个单元中测试思维的演进

本课程我最大的缺憾就是因为嫌麻烦而没有写评测机，只依赖自己构造的边界数据进行测试，确实有很大不足，造成了一定的强测与互测失分。第二单元多线程的测试不能依赖逐步调试，程序的输出不确定；第三单元强调用junit编写测试代码进行单元测试，让我体会到不同测试方式的特性，也提高了一些自动化测试的能力。

五、课程收获

说到课程收获，就不得不提2周一次的研讨课，不在此细究其是否真的能有帮助，但我认为记录人与主持人的角色完完全全沦为形式，成为加分的工具，对于研讨交流没啥实质帮助。
经过四个单元的磨练，我对于层次化设计、多线程、测试思路有了更加深入的理解，从第一单元面对复杂指导书的摸爬滚打，到第二单元逐步建立自信，再到面对后面两个单元的从容不迫，也切实感受到自己的代码能力有很大的提升。非常感谢OO所有老师与助教的辛勤付出！