目录

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

在第十三次作业的作业要求部分，便提到：

在这里，我们建议同学们按照 “设计程序架构->绘制 UML 类图->编程实现” 的顺序完成作业，以达到对于程序架构的设计和抽象能力的训练。

在完成第十三次作业时，我也遵循课程组的建议，先设计架构、绘制UML类图，然后具体编程实现。

本单元的图书馆模拟系统要求比较复杂，但是架构还是比较清晰的。

为了帮助捋清思路，我首先结合题目描述绘制了借书、还书、损书的流程图，在该过程中，我更加清晰了图书馆每个部门的职责、部门与部门之间的交互关系以及借书、还书的时序问题。

在类的设计上，我也是按照题目描述，为图书馆的每个部门（书架、各类图书管理员、自助机器、后勤处）各开了一个类。这样设计，虽然类的数量较多，同时类与类之间有多种关联关系，需要实现有关消息传递的接口，但是逻辑和流程比较清晰，封装性好，在迭代时不容易出错。

在类中方法的设计上，我也是按照流程图中每个部门的职责为每个类设计了相应的方法，并且考虑了类与类之间的关联关系，然后绘制得到了第一版UML类图。说起来简单，其实为了得到第一版UML类图也花费了不少时间，也许是自己平时思考的习惯，在思考代码时总喜欢“一镜到底”，在设计UML类图也陷入了这个误区，总想把UML类图中的属性和方法设计得尽可能完美，因此花费了大量时间，也有悖于本单元对于架构设计的训练目标。因此在今后需要更加训练自己抽象问题、从高视角设计架构的能力，毕竟架构师和程序员考虑问题的视角是不同的。

然后是根据第一版UML类图以及流程图实现具体代码，尽管在设计UML类图时认为自己已经考虑得非常严谨，但在具体实现时还是遇到了数据结构不合适、需要定义新的类、定义新的属性、实现新的方法等等问题，果然实践是检验真理的唯一标准。于是在编写完代码后，又在第一版UML类图的基础上进行修改得到了第二版UML类图。在第二次、第三次迭代时，我都是采用了先画流程图，然后根据流程图进行代码的迭代，之后修改UML类图，并完成了状态图、顺序图的绘制。

综上来看，自己第一次作业在绘制UML类图上花费了大量时间，类的数量也比较多，但是对第二次作业的迭代提供了很大的便利，因为逻辑比较清晰，迭代起来也不容易出错。由此可见，一个清晰的架构多么重要！

下面这张图更清晰地体现了我在本单元作业中的建模与开发流程。

本单元作业的架构设计

UML类图

UML状态图

UML顺序图

本单元在架构设计上主要是根据题目描述为每个行为主体（学校、学生、书架、三类图书管理员、图书管理处、自助机器、后勤处）以及借阅信息和预定信息分别定义了一个类，并在主函数中实现请求的接收以及图书馆在闭馆后、开馆前、整理日时的活动，控制整个时间顺序。各个类根据各自的职责定义具体的属性、执行具体的操作。在类与类的关联上，如A类想要调用B类的方法，那么我便将B类的一个对象设为A类的一个属性。还需要注意的是，不同的学校拥有的是一套不同的图书馆体系，因此我在School这个类里定义了所有的部门以及学生。

代码与UML模型间的追踪关系

如在【本单元所实践的正向建模与开发】部分提到的，在本单元第一次作业中，我首先设计了第一版UML类图，然后根据类图和手绘的流程图，并结合题目描述进行具体代码的编写，之后修改得到第二版UML类图。在第二次和第三次迭代作业中，我都是首先根据流程图修改代码，再根据代码完成类图、顺序图、状态图的绘制。其实最好的是先绘制类图、顺序图、状态图，因为这三种图从不同的视角描述了图书馆模拟系统，然后再根据这三种UML模型完成具体代码的撰写，最后再对UML模型进行调整。

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

第一单元中课程组对于架构也给了一些提示，即表达式——项——因子三级，其中表达式因子、三角函数因子等需要继承因子类，此外，还需要设计Lexer类和Parser类。但是，自己在第一单元尤其是第一次作业中缺乏清晰的架构思维，也没有为后续的迭代预留空间，而自己又不愿重构，导致后面的三角函数和导数相关的增加开发只能在一份比较烂的架构上迭代。我想这也由于自己算法思维大于架构思维导致的，在第一次作业中只考虑性能以及单层括号的情况，而忽略了良好的架构的设计，虽然第一次作业性能分很高，但是后面两次作业都无力回天。其次是自己在第一单元作业中类与类之间的耦合度也比较高，类的职责不清，导致有些相同的功能在不同的方法中重复地实现，造成代码冗余。

第二单元的架构较第一单元来说更加清晰了，设计了三个线程类和一个队列类，首先明确了各个类的职责，即应该设计哪些线程，哪些数据被共享读写，以及线程间的协作关系应该是怎样的。但是还是存在一些不足，这是一门面向对象的课程，自己还是摆脱不掉面向过程的思维模式，对于电梯的状态、电梯的运行策略并没有单独地写一个类进行封装，电梯类承担了大量的功能（460行代码），架构的可扩展性不够强。

第三单元考察的是我们阅读规格并实现具体代码的能力，大体架构已经提供给我们了，但是具体细节还需要我们设计。本单元也是我第一次重构代码，在做本单元第一次作业时我还没有很好地体会到规格与实现相分离的思想，无论是数据结构的选取还是算法的实现都是完全按照规格编写的（主要是对本单元的要求理解不清，以为要原汁原味地按照规格撰写代码），造成时间复杂度非常高。于是我从实际情况出发，选取了合适的数据结构（对本单元来说是HashMap）以及时间复杂度低的算法（并查集以及动态维护思想）对代码进行了重构，重构后代码清爽多了。

第四单元的抓手就很少了，我们需要根据题目描述自己设计架构，我也是尽量做到了类的职责分清，各司其职，每个类的代码行数都很均衡，不再出现像第一单元类耦合度高和第二单元某些类功能臃肿的现象。

总的来说，我在架构设计上慢慢改正了类的职责不清、耦合度高、类的职责太多等问题，逐步建立起了面向对象的思维。

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

这四个单元的测试大部分都是依赖大佬的评测机以及手捏的边界数据进行测试的，自己只能针对部分边界情况做小数据的测试。自己在这学期的OO学习中也没有学会评测机的编写，python还需从零学起。因此，自己在测试思维方面还是存在还大的不足的。但是，值得一提的是，自己在测试的积极性方面是越来越高了，在前期写OO作业时对自己的作业非常自信，做的测试比较少，直到经历了第二单元痛苦的debug后，自己才慢慢意识到测试的重要性（其实还是有些功利的思想在里面的），在后两个单元的测试中，不放过任何一个测试数据，可以说做了比较充分的测试，尽管对于TLE还是很难测出来。自己缺乏测试思维应该是长久积攒下来的漏洞，在程设、数据结构、CO以及OS中仅仅依靠评测机的反馈，以及现有的测试数据debug，自己在手捏边界数据上还是思想比较懒惰，今后要加强训练自己捏数据的能力，更希望的是自己能够写出一套评测机来，写代码是一门艺术，捏测试数据同样也是一门艺术，它对于思维能力的锻炼和提升是巨大的。

课程收获

一学期的OO终于接近尾声，自己这学期在OO上投入的时间还是不少的，Java代码的编写能力大大提高，面向对象的思维也在逐渐建立，弥补了自己上学期未能顺利完成OO Pre的缺憾，但是自己在Java的一些用法和细节方面的知识还是需要大量补充的。

在这门课程的学习过程中，有许多大佬陪伴，他们或分享经验和技巧、或为大家搭建体验感很好的评测机，他们为我提供了很大的帮助，也激励着我向着更好的自己前进。

自己在前两个单元曾多次想过放弃，觉得自己这一周做不出来了，但是感谢身边人的开导，让我逐渐走出内耗，实干才是硬道理，也确实是这样，代码空想是想不出来的，当你开始实际编写时，灵感便会喷涌出来，这就是所说的“下笔如有神”吧！

自己通过这门课程，也算是较为独立地实现了四个小项目——表达式化简、电梯调度系统、人际关系网络（图算法）和图书馆模拟系统，还是很有成就感的！同时自己在这个过程中，不仅体会到了面向对象的思想，还学到了很多其他的东西，比如递归下降、电梯调度算法、JML规格、UML模型等等，课程内容丰富多彩。自己当然也学到了很多小技巧，慢慢地向一个计算机人靠拢。

此外，互测房里的激烈互刀，研讨课上的分享交流，迭代形式的单元作业以及每单元的博客总结，再加上6系水群里的欢声笑语，还有最后的颁奖典礼，这门课充实丰富，和常规课大不一样，给我们每个人都留下了满满的回忆，虽然平时压力很大，但在北航有幸体验到这门课程，体验到别出心裁的课程模式，也是非常幸运又值得的了！

总之，这门课程让我逐渐走出了内耗，勇敢地接受结果的不完美，面向过程和问题，而不是成绩。此外，自己还存在着不足，比如对自己的要求低，不精益求精，不认真耐心思考，思想懒惰等等，这些问题在OO中都有所暴露，这也是我今后需要改正的地方。

最后，感谢OO，来日方长！