OO第四单元博客总结

肖顺-20376047 学生 2023-06-20 18:47:57

本单元的正向建模与开发

本单元的目标是建立一个简单的校际图书馆借阅系统，涉及的情境错综复杂，因此需要首先理清思绪，搭好架构，之后再着手实现架构的细节。

阅读指导书时，为了理清各种情况的业务流程，我维护了一张流程图，来辅助自己的架构设计。下面是hw14的业务流程图：

其中也很容易能看出从hw13迭代下来的痕迹，只是在校际借阅、图书管理处的部分新增了内容。

在构建流程图的过程中，我会同时思考自己的架构设计。在书写self-machine的业务逻辑时，思考self-machine的相关操作和属性，来决定是否设计self-machine这个类，以及它应有哪些属性和方法；当书写闭馆后的校际借阅和校内预定的业务逻辑时，思考如何实现请求的暂时搁置和之后处理的模式，需要设计什么类、哪些方法来实现，诸如此等，初步设计好我的UML架构图。

当有了一版基本的UML架构图初稿后，便可以开始写代码实现了。如果业务逻辑中有特别复杂的情况，还可以画一些顺序图、状态图来辅助思考。写代码的过程中会发现有很多地方在思考架构时没思考到的细节，或是遗漏的点，补上就好了。最终完成业务的实现。

本单元架构设计

本单元最终的UML图如下：

其中，MyDate类负责时间的记录和输出，在Main类中被调用tick()方法而增加日期；Main类的main方法负责主要的业务顶层逻辑实现，在borrowingLogic和returningLogic等几个方法实现次顶层的业务逻辑实现，将各繁杂的业务逻辑拆分成各个独立的小模块、小方法。Library、Book、Student都是实体类，其功能和属性与现实常理相匹配，每个学校一个Library，其中存放本校的Book和预定列表等等，等于将图书管理员、预定管理员等业务逻辑集成在了这一个类里，因为它们很多地方都相通，需要用到相同的属性和方法。StateTrans类是一个输出类，专供状态图检查和输出状态信息。SuspendRequest类和TransportInfo类是实现闭馆校际借阅和校内预定以及校际运输的类，通过一个生产者消费者的模式，将本校图书馆无书的请求搁置到闭馆后处理，将当天的运输信息保存下来待到第二天开馆前处理。这就是整个的业务逻辑框架。

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

在代码的书写过程中，往往为了更细致的业务逻辑要求和状态图、顺序图评测的要求，而新增一些属性和方法，甚至是类（StateTrans类就是这么新增的）。因此，在书写代码前就大差不差地将最终UML模型设计设计好是比较困难的，或者说代价较大的，需要开发者对业务逻辑的各流程有亲身体验过一般的熟悉程度，在作业的实操中，是没有尽快开始代码开发，边开发边修正架构来得高效的。

所以这个追踪关系就是：先开始UML图先跑一会，跑一会不跑了，代码设计开始跑，代码设计会经历所有的打卡点而UML图不一定，所以随时UML图都得跑一会来补卡，如此，代码设计永远引领着UML图的设计，永远领跑在了前面，直到最后。

架构设计思维的演进

第一单元

在第一单元中，初识OO，但在第一次实验的代码启发下，也算是初始的面向对象的层次化设计的思想，以及文法的表述，也是非常体现层次化的思想的，因而还算顺利地完成了第一单元的层次化设计。在此，我对层次化设计的理解就是“表达式下含项，项下含因子”的三种层次，逐层分解，每一层是上一层的基本组成部分。

第二单元

第二单元主要专注的是多线程的设计模式，在此我学习了很多多线程的交互模式，譬如生产者-消费者模式，流水线模式等等，对层次化设计的理解也更加丰富，层次化也可以是更抽象概念的层次，譬如主从关系的层次，继承关系的层次等等。

第三单元

第三单元的架构设计空间较小，顶层的程序框架也基本由课程组官方包搭好了，我们要做的只是按照规格逐个实现各个方法，同时要设计较好的数据实现、策略或算法来降低程序的时间复杂度。第三单元的工作重点也就在JML规格的阅读理解和OKtest，以及算法优化方面的工作了，对层次化设计的理解是验证性的，是被动性的。

第四单元

第四单元注重的是UML图的绘制，同时课程组也尽量在设计一个复杂的情境来让同学们先搭UML架构后实现代码。第四单元可以说是层次化设计的验收阶段，是面向对象知识的综合运用，大家设计的架构也是非常不同的，有的同学面向过程的部分非常多，而有的同学能实现对象间高内聚低耦合的交互，这都是提前设计架构与层次化设计知识综合运用的结果。

测试思维的演进

第一单元

在第一单元中，我主要通过手动构建特殊输入或极端输入来卡房友，以及卡TLE；在第二次作业中也自己简单写了一个数据生成器来帮助构建随机大数据，然后手动地测试，然后发展到比较两个包的输出的测试，以及在第二三次作业后开始有大佬在讨论区发评测机。第一单元的探索也就到此。

第二单元

第二单元有点儿特殊，主要是多线程bug的难以复现性，给测试和实际Hack造成了些许不一致。但主要还是这一点，第二单元的测试是带时间戳的模拟实时测试，是存在多线程的并发带来的bug的测试，但这一单元的测试整个单元都是依赖的讨论区的评测机，大佬们的评测机写得真的很好。

第三单元

第三单元的测试和第一单元类似，在第三单元的博客总结中特别讨论了测试相关的术语，比如黑箱测试，单元测试，回归测试等等。这一次博客作业让我对测试有了更全面的了解和总结。

第四单元

第四单元的评测方面比较困难，由于涉及到mdj文件的评测，难以对mdj文件进行全面的测试。因此业务逻辑的测试和UML图的测试就分开了，UML图测试主要依赖于中测的结果，以及靠肉眼观察，直接遍历；而业务逻辑的测试，实际上也无啥区别于其他作业的特点，倒是有一个特别之处就是hw14之后的测试就很难进行了，毕竟在很多方面你不知道这两个包出现的不一致之处，哪一个是课程组的意思，或者这属不属于主干逻辑，因此我在hw14和hw15没有过多的测试，好在强测也确实注重主干逻辑，并没有很坏很坏的数据点。