OO_Unit4:UML建模

exspecta 学生 2024-06-12 13:16:54

OO_Unit4: UML建模

正向建模与开发

本单元作业强调的是采用UML进行正向建模，也就是建议我们先勾勒出类图、状态图、顺序图等框架，然后再进行代码的具体设计。其优势包括：

减少错误：通过详细的设计和建模，可以在早期发现并解决潜在的问题；

沟通协作：UML提供了一种标准化的交流方式，帮助开发团队和相关者更有效地沟通和协作。

架构设计

本次作业实现的是一个图书馆系统，包括书籍的借还，续借，预约，捐赠等流程，这些流程是较贴合实际的，作业体验也给我一种比较人性化的感觉（包括延期到周日、os考试周的工作量稍小等）。

关于本单元作业架构设计，我将书籍所在的几个地点作为类，通过类之间的交互完成所要求的功能。我认为需要注意的有：

认真理解题意。本单元思维量较之前不那么大，但依然有很多实现上的细节要注意，最后debug时找出的大部分错误也都可以归因于没有完全看清或理解题目。同时也要充分利用官方包提供的信息。
选择好的数据结构。同前几个单元一样，通过选择合适的数据结构、进行适当的封装可以达到事半功倍的效果。

最终UML类图如下。

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

指能够从UML模型追踪到实际代码实现，反之亦然。这种关系确保了设计与代码实现的一致性，有助于管理变更、提高开发效率和降低维护成本。具体的：

类图和类：类图中的每个类应对应代码中的一个类或接口。类的属性和方法应与类图中的定义相一致。

顺序图和方法实现：序列图展示了对象之间的方法调用顺序。每个调用应在代码中有相应的实现，保持调用顺序和逻辑一致。

状态图和状态转移：状态图中的每个状态和转移应对应代码中的状态机实现。状态转移条件和事件触发应在代码中得到正确实现。

三次作业中通过这三种图的绘制，可以清晰地理解和管理UML模型设计与代码实现之间的追踪关系，确保代码实现过程的规范性和一致性。

四个单元架构设计思维的演进

在oo四个单元的磨练过程中，整体上思维的进步当然还是很大的。

首先就是完成项目的过程中能够以更长远/宏观的视角进行思考，而非拘泥于代码细节的选择。相比之前较为简单的面向过程的一些代码实现，oo繁杂的要求使得我不能想到哪便写到哪，而是每次都要先把代码整个的架构在脑海中过一遍再动笔，这对于我的思维也起到了一些锻炼的效果。

此外，这门课的作业也是很考验我们的细心程度和思维能力。电梯多线程的特性使得我们必须熟悉程序到底是如何跑起来的，无脑设断点查询中间量的值在这里不再那么灵验；我也观察到自己很多同学的错误是由于手残打错或者不少低级的错误导致的，一方面是没有进行充分的测试，一方面也是考验我们完成作业的细心和专注程度。

四个单元测试思维的演进

从第一次作业学习生成jar包自动化评测，到之后的每一次作业都白嫖大佬们的评测机进行测试，所幸结果不算差，真的很感谢辛苦编写评测机甚至开源的同学们。

在测试的过程中在生成随机数据的基础上，也需要重视边界条件和一些基本情况的测试。例如我在hw1就犯下了前导0处理错误的情况，这本身是一个较为明显的错误，但由于我过分依赖随机数据，导致了我强测第一次也是唯一一次正确性挂了，现在看来真是有些可惜了。。对于基本情况，也可以采用一些手捏的数据，实现较为客观的覆盖率，防止随即评测出现奇怪的测不出来很明显错误的情况。也是本着这样一种充分测试的思想，我们第三单元要求使用Junit进行测试。

测试一定是oo作业不可缺少的一部分，但比起编写代码后充分的测试，我们也需要重视在完成代码的整个过程中始终保持着严谨认真的态度，这样才能将犯不必要的错误的概率降到最低。