BUAA_OO第四单元总结

[高悠然-22371242]

OO第四单元总结

正向建模与开发

什么是正向建模，即在代码编写前，根据任务要求想好需要哪些类，采用什么架构，提前建好模型，根据自己建的模型，编写代码，虽然可能在写的过程中会有所修改，此时可以反向修改建好的模型。虽然在建模时会耗费一定时间，觉得不如直接上手来得快，但建模的过程是让自己认真思考自己的方法正确与否的过程，减小重构的可能。
不过本单元，由于前面只要求了类图，所以一开始我只是根据类图进行正向建模，并没有考虑特别多状态图与顺序图，也因此在第一次正确的框架确定后，状态图与顺序图有点根据代码生成的意味，这也导致我在写状态时发现，很多状态比较模糊，没有很好区分开，消息也没有各司其职传递，耦合度增高。

架构设计

类图

本次作业我的类图如下：

我的整体思路在第一次便确定，后续基本未改变。我按照题目要求，划分了书架、借阅处等，他们每个类都有一个容器，存储该地点所有的书（相当于把书当作了一种状态量），每个地点承担一部分的操作属性，比如在书架中有查询书的数目的方法，借阅处中有将逾期的书删除移到书架的方法。且这些类都是静态方法，然后我通过一个控制类Controller，将每个类的功能整合在一起，形成了各个指令。
这里需要说明一下我的用户处理方法，我建了一个静态的user类用于存储总的student，student是在读到学号时进行创建，如果之间没有，就加到user，这样就实现了对student单例实现并集合到一起。

追踪关系

在建模时，我先构建好了一开始的几个地点类，决定采用课程组给的bookid而不去新建书类，不过在后续实现过程中发现这种实现起来不大方便，因为bookid只是记录了书的标签，没有记录书的状态，因此需要在地点类同步存储书的状态，所以中间想到可以把地点也当作书的状态，通过书类进行存储，不过因为不想重构，加上想按照自己一开始的想法，把书当作状态量，就没有进行大的修改（只增加了非正式书的类），不过写起来应该是两种状态一起记录更加容易。
其次是关于student，一开始我并没有想到使用一个静态的容器去存储student，但其实有时候会需要调用其他的学生，因此在写代码时，又重新返回修改关系。
总体来说就是先根据基本模型确立框架，但是实现时，我们会处于新的考虑或者方便性进行修改。比如我在构建控制类时，只是写了几个与指令直接相关的方法，但其实最后还是加了很多额外的方法。不过整个过程是相互促进正向反馈的，可以减少很多因为思绪不清导致的重写过程，或许这也是UML的一大魅力与作用。

架构设计思维演进

第一单元
在第一单元时，虽然经受过OO先导课的洗礼，但是在面对第一单元时还是毫无头绪，借鉴了学长学姐的博客后，以及实验所给出的架构，构建了第一次作业。整体采用递归下降的思路，我们可以把一个表达式拆分为几个部分：因子、项、表达式。对表达式进行递归下降解析，我们会发现变成项，项再拆分变成因子，即使是表达式类型的因子，仍然类似的递归解析，与之前同理。最后我们根据表达式的数学特性，总可以表示成多项式的形式，构建一个最后的基本类，aex^n的形式。整体来说，这个单元给后面的做了铺垫。每一个递归下降的内容都可以作为一个类，同时由于他们之间的关联性没有那么大，或许是我这四个单元聚合度最高，耦合度最低的一个单元了。

第二单元
这个单元总体架构方面比较简单，因为是多线程，根据课程组建议，使用生产者消费者模型，控制器使用单例模式，实现不同线程之间的交互。在调度方面，我并没有实现影子电梯，而是利用一定的评分分配后，直接随机分配，所以在这方面并没有花费太多的时间。但是在死锁、轮询等重构了很多次。因为一开始理论知识的不足，采用了无脑上锁的方法，后续随着电梯增多，电梯的属性可能也需要成为共享对象，我进行了重构，不过在最后一次作业时，因为一点粗心，不小心删了一行第二次作业修改的代码，使得强测直接爆炸。总的来说，这个单元的多线程是最折磨的一个单元，但这个单元也让我掌握了多线程相关的编写方法，结合OS的内容，受益良多。

第三单元
这一单元总体架构并没有特别多的要求，按照课程组给出的编写即可。在这个单元中更主要的是对于JML语言的学习，规格化的语言，让我们仔细思考了任务的需求与前提，同时又给了我们实现的方法的自由度。

第四单元
这一单元的架构在上面已经介绍，我这个单元的架构设计其实主要参考了第二单元的多线程的设计，主打的是各司其职。不过这个单元的架构想法也不难想，主要是选择书作为观察的对象还是选择地点。主要是UML的建模方法，这一单元我觉得比JML还是实用得多，也感受到了提前建模的方便与正确度。

测试思维演进

第一单元

• 这一单元我先是参照学长们的博客，写了随机生成的评测机，不过过于随机，其实效果不好，最后其实先手列了一些具有特殊性的式子或者具有普遍性的式子，保证基本构成能正确处理，然后随机生成。正确性的检验使用的sympy库。

• 后面由于作业的复杂度（sympy不是很好用），借鉴了讨论区的一个同学的对拍法，将两个同学生成的数据相减，如果为零，则可以说明两人相同。

第二单元

• 从这一单元后就基本以来dpo了，并没有自己进行大数据的测试。

• 这一单元我自己的测试主要是针对死锁与轮询的测试。根据群里助教发的轮询测试方法，在第三次作业时成功拯救了我的轮询问题，通过打印的朴素方法，看是否循环过多的进行。死锁参考了评论区的同学的方法，现根据代码查看，然后通过共享对象的共享情况，构造可能会发生死锁的数据。

第三单元

• 这一单元的测试我采用了课程组的junit，我编写了一些方法的测试方法，针对JML的条件与后置条件，逐条测评。最后采用评测机的数据大规模测试。

• 这一单元与之前不同的是这应该是第一次卡时间，我使用IDEA的cpu运行时间分析功能，构建极端数据点，先构建一个比较大的图，然后找那些时间复杂度较高的方法，通过一条指令多次输入，查看时间。

第四单元
这一单元的测试就比较简单，我通过打印出每个时间点的状态进行查看，然后用的dpo测试。不过代码比较简单，我还是决定一行一行查。

总体我在测试上由于dpo的帮助并没有花费太多时间，主要在于极端数据点的构造以及debug。每次作业都采用的黑箱测试，代码量少时会去重读代码。

课程总结与收获

• 第一次在一个任务中写那么多代码（以后可能更多），磨练了耐心以及对于代码的格式等的构建，好的代码结构才能让自己在后续迭代时不出错。
• 学习并深刻体验了面向对象的思想，这种方式的编写符合我们的逻辑，写起来也没有那么枯燥，甚至让我不再想碰C。
• 总体来说我还是很喜欢OO课的（多靠OS衬托），不过这段时间也让我感受到了时间管理大师的精髓，痛并快乐着，最后还是要感谢课程组的老师与助教以及平常帮我的同学orz！