OO-Unit4-Summary

正向建模

正向建模需要在开发的过程中梳理需要的逻辑流程与结构，根据逻辑构建其各个部分之间的关系并分析大概的流程等。

本次作业需要模拟一个图书管理系统，功能很复杂，需要缕清每个类之间的关系与图书管理的流程。

我在本次作业中最困难的便是厘清图书管理的流程，本次指导书比较含糊不清，之后更新了思维导图，结构便更清晰了一些，果然，图和代码还是比文字更清晰。回来吧，我的JML

第一次作业我本尝试先画图再写代码，但是后期发现这难以考虑所有细节，最后还是修修补补，不过提前画类图可以想好大概的流程，在写代码的时候效率也很高，有一个相互补充，互相指导的关系。

第二第三次作业主要是类图和流程图,由于指导书的缘故,在状态图和流程图上的精力并没太多,但是依旧还是有一定的收获,包括在电梯单元的流程图也让我感受到了流程图的清晰

课上实验倒是让我们对整个顺序图与流程图的理解更加深刻.

UML模型与代码设计的追踪关系

上述是hw15的最终框架,作业的过程中出现过一次小规模重构,在第一次作业中,我的library是类似于bookshelf的一个单纯的book的存储器,其主要工作都是由scheduler搞定,在实现了多个图书馆之后改成了全程由library实现而scheduler负责library之间的交互.

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

架构思维进步还是很大的。

第一单元时，还纠结于具体使用何种数据结构，纠结于是用HashMap还是ArrayList去存储各种因子，其实最重要的还是Factor，Expr，Term架构的关系，具体的容器都有对应的解决方法，即使各个容器之间的实现方式有差异，但基本还都是可行的。因此我们需要考虑的还是整体的结构，只要考虑清除递归下降的具体理解和各个因子之间的关系，细节也是顺其自然。

第二单元初期，我对架构的理解还是有些不到位，我没有考虑清除电梯和调度器之间的联系。我的scheduler直接决定了elevator的toFloor，这时我对架构的理解还是不清晰。于是我之后重构了，实现了elevator和scheduler之间的分离，并且较好的实现了并行运行。

第三单元没有框架

第四单元，我起初采用了scheduler调度书本的架构，在引入了多个图书馆之后，scheduler负责调度library，library继承了之前scheduler的功能。

四个单元之后，我着手写代码也不是直接就开始写，而是先思考框架之后再动笔。从认知层面提升较大。

四个单元测试思维的演进

测试是软件设计的重要部分，写的代码越多越意识到最好的测试是写代码时的严谨态度，保持一个严谨的代码态度要才是最重要的。

第一单元，因为之前玩MC把电脑的java搞坏了。。。没法使用命令行编译jar包，没有使用自动化评测机，主要靠手捏数据测试，死的非常惨。

第二单元，每次都使用了自动化评测机，在第一次测试的时候出现了一些超时的情况，误以为是评测机的错误，没有意识到可能存在的死锁问题，导致了第一次作业出现了一定的错误，在此之后使用自动化评测机，没有出现太大问题，但是还是出现了一个在高并发时出现的小问题，但是尝试了其他人的评测机之后问题减少了很多。

第三单元，自己编写了数据生成器和对拍脚本，由于第三单元存在异常处理。数据生成非常简单，只要保证一定的数据限制即可。在自行编写测试系统之后，本单元正确性没有出现问题，但是在最后一次作业中的qlm指令中，我没有采用堆优化，出现了一个点的超时。这也提示了我在测试的时候不能仅仅依靠随机生成，还应当手捏边界数据。OKtest采用手捏穷举了每个ensure。

第四单元，第一次作业自己和同学对异常做了处理：包括且不限于某个人没有借到某本书的情况。在这样的情况下，数据生成就十分简单，直接假定每本书都被人借走即可，做出了一定测试，没有出现问题，后两次作业由于各种缘故，只采用了手捏，可能是课程组手下留情，没有出现问题。

测试是OO课程收获比较大的一项技能，第一单元和第二单元首次作业因为不熟悉或者没有使用评测机扣掉了强测的绝大多数分数，在此之后强测基本没有出现问题。在第三第四单元均采用了自己写的生成器＋对拍器，也发现了很多bug,意识到最好的测试还是养成一个严谨的编程习惯，但是测试的本领也是必须学会。

课程收获

• 测试

• 写代码之前优先考虑框架

• 好的抗压能力

• 复习了图算法

• 逐渐谨慎的编程习惯