OO 第四单元作业总结

[丁梓星-20374272]

正向建模

在设计领域中，正向设计是从概念、模型，产生实物的过程。与正向设计相反的是逆向设计，是先有实物，通过对实物的观察（扫描、获取三维坐标点）获取实物的模型，然后对模型进行再次创新。

软件工程中，正向建模是一种自顶而下的软件设计过程。从高层次的总体功能出发，对每个层次的功能进行分解和细化，逐步达到对底层细节的设计，以实现对整个系统的全面把握。

正向建模有清晰的层次结构和元素关系，可以考虑到系统中的各个角色和各种业务场景，可以达到更全面的系统分析和设计。

本单元围绕图书管理系统，模拟图书馆中包括借书、还书、书籍修复、书籍整理、校际借阅等多个复杂功能和场景。通过UML类图绘制，我先明确了各个情况下的书籍位置状态转移图，并依此完成了图书馆各个部门的功能设计。

完成 hw13 时绘制的状态转移图如下：

设计架构

对象类包括Book, Shelf, Student，以及几个图书管理部门。根据图书的状态转移需求设计架构结构。

hw13类图结构：

最后形成的 hw15 的类图结构：

随着设计需求的推进，三次作业迭代中修改的内容主要有：增加了继承结构；强化了分级代理的协作结构。

类的继承

hw13中各个图书管理员类的责任各异，实现中几乎没有共性的重复功能和结构，当时觉得没有构建父类的必要。

在 hw14 中，添加了多个学校的场景，因此所有的管理员可以共享学校信息自身所处的学校信息，简化设计。除此之外还有重复的校内和校外书本存储结构，及图书整理和图书运输的功能。因此添加了统一的父类 Librarian。

分级代理式为主，中心控制式为辅的结构的类协作模式

在多个学校图书馆的背景下，使用了一个图书馆系统 LibSystem 类，统一读取命令，分发到对应的图书馆执行；在 LibSystem 中进行时间管理，对各个图书馆的整理、校际运输操作进行统一调配。

各个部门之间的数据传递（图书运输等），通过各个类的关联关系完成，即一个类中可以包含另一个类的实例，调用其方法实现功能。比如整理书籍的功能，ArrangingLib中包含其他几个管理员类的实例，分别调用他们的 arrange() 方法后，将他们传回的图书整理上架。

因此，在完成一个功能时，往往需要形成 图书馆系统 -> 图书馆 -> 图书馆的某个部门 -> 图书馆的另一个部门 -> Student，Book 类 的消息传递（函数调用）链，整体呈现分级代理模式。

但在各个图书馆实现功能时，往往需要根据指令类型，调用各个部门的功能实现，存在一部分的中心控制式协作。

比如，预定购买图书的消息路径（UML顺序图）如下。

架构设计推进

面向需求和对象编程

第一单元的多项式合并架构设计时，我对对象的概念还不是很熟悉，在设计的时候关注的更多是如何以最简洁的结构实现最复杂的功能，关注的是代码底层的设计细节——数据的抽象和组织形式。

第二单元的电梯设计，在一个生活的具体场景中设计程序的运行，引导我们从设计需求和功能流程的角度设计，设计程序的结构。同时了解了并发场景的设计模式，在多 client 请求处理、工作流结构的基础上，在每次作业中逐步优化代码结构，以更合理的代码结构避免错误的发生。

第三单元强调规格的重要性，在标准化的规格编写中，了解到了在程序设计中需求的重要性，并深切体会到了需求和设计分离的思想。

至此，最后完成的第四单元作业就把面向对象的思想融会贯通起来，将文字表述的应用场景，先根据需求抽象成层次化的模型，组织各类的方法时更多处于贴合生活实际的考虑，以此预测系统未来的迭代方向。在完成整体架构设计，保证模型能够覆盖作业需求后，我再分离的思考各个函数功能的实现方式。第四单元作业完成的速度很快，hw13的结构也很好的继承至hw15，重构大大减少。

高内聚和低耦合

在4个单元的迭代中，我的类结构逐渐变得更加清晰，每个类的属性和方法复杂度也大大降低。

这也和整体的代码设计有关。在前几单元因为架构设计只得其形，在实现过程中更多的面向功能而不是面向对象，往往代码组织随意，功能实现复杂。

通过构架的优化设计，类的规模、代码方法的耦合度也降低了很多。

这是第一单元的代码度量平均值：

这是第四单元的代码度量平均值：

测试思维推进

第一单元的测试采用的是大部分手搓 + 借助大佬评测机。第一单元的设计场景下，如果程序基本能够正确运行，那么大部分出错场景都在极端数据上。列举想得到的极端情况，手动构造符合条件的数据，是我第一单元的主要测试方法。

第二单元和第三单元就越来越依靠与自动化工具，少数情况自己构造随机生成代码覆盖不到的极端情况测试功能。

其实后面几个单元都是在白嫖评测机，没能有太多对构造数据思考。这也是这门课我比较遗憾的点。

课程收获

现在回头再看第一第二单元的代码，其中可以优化的地方数不胜数。一开始代码结构的不完善，除了设计思想的不够成熟，也是因为对 Java 语言和并发控制的不熟悉。我觉得oo课一个很大问题就是先导知识的不完善，对 Java 的使用、语言特性等介绍太少。虽然上学期有开设先导课，但真的是很难抢。而且我觉得我和身边上过先导课的同学，在前两周的代码设计真的有很大的差距。希望先导课能够开放更多名额，或者课堂中多介绍一些代码工具的使用。

oo的理论课大多以介绍概念为主。虽然和作业都是围绕着同一主题展开，但是理论课有些太过抽象和晦涩，设计模型、设计理念的介绍有些简短或者没能结合实际理解。理论课和课后作业的差距很大，理论课只能提供一个方针指导，大部分的学习发生在完成作业和每两周一次的实验课中，而不在理论课上。

但这学期确实实打实的领略到了面向对象思维模式的内涵。几个单元从对象、类的层次设计，并发设计，规格设计，规格设计几个层次，从细节到整体，从局部到抽象，展示了代码设计的基本要点，并切实的影响到了我的设计思路。

这学期在数据构造上的造诣不深，一方面是因为精力有限，一方面也是工具的不熟悉和编程思想的不完善。编程能力和效率还有待提高。