BUAA OO 第四单元总结

[22230604-艾俊辰]

BUAA OO 第四单元总结

一、程序结构

第二次作业加入了图书预约部分，第三次作业加入了扣分系统

1.代码思路

相比上一届的代码，本次的书不再有烧毁等情况，换言之，书自身状态在任何地方都是一样的，其不同的状态（可借、不可借、被预约）都是和他所处的位置有关系。因此可以想到根据书所处位置进行不同类的建立。

同时，考虑到打工人的怨念开关门的合理性，我们选择将所有闭馆之后的操作堆到早上。曾经也考虑过将所有操作放到晚上或者一部分在早上、一部分在晚上，发现因为开馆时间不定，所有需要算过期与否的书都需要在开关之前再查一遍方式出现太久不开馆导致上一次闭馆没过期的书已经过期却无人收走的情况出现。贼这样的情况下，晚上的整理其实很鸡肋。同时所有查询等操作都不会在闭馆之后、开馆之前进行，因此早晚操作本身的地位是等价的，干脆将所有操作都放到早上，一劳永逸。扣分同理。

这里出现了一个很有意思的问题，即如何判断预约的书过期和漂流角的书变为正式书籍所带来的加减分的先后关系，最终也没有很好的解决办法，毕竟不同结果是不同的实现方法导致的，而每一种其实都符合题目要求。感觉下一届的解决办法是把分数上限取消掉。

2.分析结果

最丑陋的一集

必须承认，这个单元抱着“反正就最后一次作业了”的心态没有好好架构，后续的迭代尽量做到改动最小，所以本着既然Borrow类里存储了最多的数据那么在Borrow类继续存方便共享的想法堆了很多粑粑，其复杂度直逼用来实现函数的Library。不过相比前几次作业，这一次架构清晰很多，做到了低耦合，唯一高内聚的程度太高了……

二、架构设计体验

1.正向建模与开发

正向建模是这个单元才开始的吗？似乎并不是，每一次写代码之前，无论有意无意，都一定有从理解题意-抽象模型-分出需要建的类-开始写代码的过程，这个单元将这个过程强制可视化了。

不可否认，虽然这个过程在现阶段看来有些麻烦，但在日后面对更加复杂、更加庞大的工程时，能够让自己和其他阅读者都快速理解结构、达成协作。

2.代码与UML模型的追踪关系

代码和UML模型之间的追踪关系是指代码中的元素（类、方法、属性等）与UML模型中的元素之间的对应关系。这种追踪关系可以通过以下几种方式实现：

(1)注释：

在代码中可以使用注释来指定与UML模型中元素的对应关系,可以在代码中使用注释来标识某个类或方法与UML类图中的哪个类或方法对应。

(2)命名规范：

通过在代码中使用特定的命名规范，可以表明代码中的元素与UML模型中的元素之间的对应关系。使用相同的命名规范来命名类、方法和属性，以便与UML类图中的元素进行匹配。

三、bug分析

三次强测均没有bug，总体而言非常顺利，卡得最久的还是整理的时间问题所导致的计算方式，即到底应该算几天。

另一个bug就是图和代码不匹配，还出现了过几天再看中测就有bug报错的抽风现象，应当实时注意。

这个单元一定需要注意，不能够赌博这一块后面不会改所以可以偷懒……问就是前面说预约可重复第三次作业说预约有限制，又开始打补丁，真是（扶额苦笑

最后，不看讨论区和群消息的人会很惨，因为你并不知道你和助教的理解是否一致

四、思维演进

1.架构设计

在第一单元中，我开始接触和理解层次化设计的思想。通过对表达式结构进行建模，我学会了如何使用适当的模型和层次结构来表示复杂的多项式表达式，并实现括号展开、函数调用和化简等功能。这个过程中，我意识到层次设计的重要性，将复杂的问题分解成不同的层次，以提高代码的可读性和可维护性。另外，互测的恐怖也让我意识到，实现在性能的好坏中起了决定作用，而双重循环等显然是成本巨大的。

在第二单元中，我们进行了多线程实时电梯系统的设计。在这个过程中，我体会到了所谓“原子性”的重要性。多部电梯进行交互，如何确保电梯对请求的行为不被打扰就是整个单元都在研究的事情。自由竞争被禁止，不得不开始写调度，也发现调度策略是性能的决定性因素。现在回过头去看，当时的调度策略一团乱麻（怪不得不如模6呢）方向应该也在考虑范围之内。也算是一种进步吧。

在第三单元中，我们致力于实现社交关系系统中不同消息类型以及相关操作。这个单元的学习目标是理解JML规格在面向对象设计与构造中的重要意义，并掌握利用JML规格提高代码质量的能力。此外，如何实现JML也是一个值得探讨的话题。

在第四单元中，我们以图书馆模拟系统为例，锻炼了我们在程序架构的设计和抽象能力。通过这个单元的实践，我学会了使用UML图来进行系统的正向建模，并通过图书馆模拟系统的设计，培养了我的设计能力、抽象能力和对系统架构的理解。这个过程中，我意识到良好的架构设计能够提高代码的可维护性和扩展性，为将来的软件开发工作打下了坚实的基础。

2.测试体验

第一单元：在表达式结构建模的单元中，我开始了解测试在软件开发中的重要性。我学会了编写针对多项式括号展开、函数调用和化简等功能的测试用例。通过测试用例的设计和执行，我能够验证代码的正确性，并发现潜在的问题和错误。此阶段针对互测还在抄样例阶段，被hack得很惨，慢慢学会了如何构造一条很强的数据。

第二单元：在多线程实时电梯系统的单元中，我进一步加强了对测试思维的认识。由于多线程系统的复杂性，我学会了设计针对不同线程交互和协同的测试用例。通过模拟电梯系统的运行场景，我能够检查系统的并发性、同步性和正确性，确保系统能够按照预期进行运行。互测当中大家都互通有无，造出来了诸如在50s有大量人上电梯等到魔鬼数据，也学会在后面的迭代中利用已有数据进行自我测验，避免互测被hack（虽然每次都有新发现）

第三单元：在社交关系系统的单元中，我对测试思维的重要性有了更深入的认识。我学习了如何使用JML规格来定义和验证类的行为和约束。通过编写JML规格的测试用例，我能够确保代码符合规范并满足预期的功能和性能要求。这个过程中，我开始注重测试的全面性和覆盖率，通过数据全覆盖对代码中可能存在的边界情况进行测试，并学会了利用不对称、不平衡的数据构造检验特殊构造。

第四单元：在图书馆模拟系统的单元中，我将测试思维应用到了系统架构的设计中。通过对系统的各个模块进行测试，我能够验证模块之间的交互和功能的正确性。

通过这四个单元的学习和实践，我的测试思维逐渐从简单的功能测试扩展到并发性、规范性、集成性和性能等方面的测试。我意识到测试是软件开发过程中不可或缺的一部分，能够帮助我发现问题、改进代码，并提供可靠的软件解决方案。我将继续不断提升测试思维，以确保我开发的软件具有高质量、可靠性和可维护性。

3.课程收获

在这几个单元的课程学习中，我有以下收获：

系统设计和抽象能力的提升。

UML图的绘制能力的提高。

架构设计思维的培养。

测试思维和质量意识的增强。

团队合作和沟通能力的提升。

五、心得体会

写到这里有些感慨，这门学长学姐嘴里如洪水猛兽、占据了我整个学期大部分生活的、传说中的OO，就要落下帷幕了。“轻舟已过万重山”，虽说经常开玩笑说低头一看没上船，回头看，身后也是青山数重、斜阳一抹，算得上是好风景。

一路上磕磕绊绊，走得实在不算容易，在第二单元通了人生当中为了学习而通的第一个宵，认识了很多大佬，收获了相互鼓励的同行者，见识了6系的恐怖实力，度过了相当充实的一个学期。在这里尤其感谢我的室友、我的战友wy，没有他，我也许早就在路上放弃了无数次；也感谢遇到的可爱助教们，真的帮助了我很多（从os帮助到航概怎么不算呢）；也感谢deep oj的存在，让我的OO不那么坎坷，不然可能连中测都过不去。更多的感谢不再赘述，感谢每一个人，没有你们就没有今天的我与OO。

最后感谢我自己吧，没有放弃、没有妥协，没有修不了的bug，只有勇敢的狗狗.jpg。OO不仅仅是代码能力和代码思维的提升，心态也有很大的进步。现在的我面对很多问题都抱有“没事，问题不大”的稳如老狗心态，总能解决的，解决不了就解决提出问题的人（恶魔低语

山高路远，未来的路还很长，一山放过一山拦，请且行且歌、大步向前吧！