BUAA OO 第四单元总结暨课程总结

BUAA OO 第四单元总结暨课程总结

第一部分：正向建模与开发

正向建模要求我们进行透彻的需求分析并通过 UML 可视化模型呈现，学习模型化设计思维方式，有助于我们理清需求、设计、实现层次的结构和行为：通过类图按数据和行为提取抽象形成抽象层次结构，通过顺序图确定哪些对象参与交互及对象需提供的操作从而识别类之间的关联关系，通过状态图进一步完善类的行为，在这个过程中建立了关联层次，实现层次设计。

本单元中一个比较理想的 UML 正向建模流程如下：

• $\text{STEP 1 }$ 需求分析：理解题意，确定题目要求的实现。
• $\text{STEP 2 }$ UML 类图正向建模：做好数据的 抽象，在抽象简化和抽象冗余之间做好取舍；在数据之前的 耦合程度 做好取舍。从而明确需要设计的类以及它们之间的关系。这就从 数据结构 层面把握了架构。
• $\text{STEP 3 }$ UML 状态图和顺序图正向建模：通过状态图建立对象的生存周期模型来描述对象随时间变化的动态行为，从而帮助梳理关键 类的状态和迁移；通过顺序图描述对象之间消息传递（方法调用的时间顺序），从而帮助完善 类的职责和关联关系。这就从 行为结构 层面把握了架构。
• $\text{STEP 4 }$ 编程实现：coding!。
• $\text{STEP 5 }$ 程序测试：继续保持第三单元反复强调的单元测试、压力测试、回归测试等等。

不同于前面 3 个单元的“正向建模”可能仅仅实在草稿纸上写写画画，第三单元使用 UML 真正采取了 正向建模*的开发过程。根据亲身实践，个人认为好处有三：

• 在整体设计与具体实现之间做好取舍。在前 2 个单元，我就很容易陷入细节。比如第一单元中“同类项怎么合并”，第二单元“这个地方线程安全怎么解决，我是用逻辑锁还是物理锁”等等。而使用 UML 正向建模，则在整体设计和具体实现之间做好了取舍，不至于“只见树木，不见森林”。
• 利于团队协作。草稿纸上的写写画画私人性实在太强，统一建模语言利于团队合作，加快开发效率。
• 利于迭代和锁定 bug。迭代过程中，你拿着那千行代码实在难以快速明确要干什么，但凭借 UML 可视化模型，可以快速回顾已有设计基础，并明确架构设计的“变与不变”。适用于 bug 锁定也是同理。

第二部分：本单元的架构设计

UML 类图如下：

架构分析

如图，一颗标准的“五叉树”……

• Handler 类作为核心类，负责根据请求的种类 派发请求，并调用各种 private 的私有方法 $\text{handleXXX}$ 处理请求；
• Student、BookShelf、AppointmentOffice、BroAndRetOffice 和 DriftCorner：作为 Handler的有机关联部分，向下 进行各个地点图书数据的增、删、改、查，向上 为 Handler 提供调用接口方便处理。

架构不足与反思

• 如图，Handler 显然已经太过臃肿，代码行数也已经逼近 500 行；
• 这是因为在设计之初没有考虑到图书数据维护的可扩展性，一个数据结构只是单一地追踪一种信息，导致后面基本上每新增一种请求，就不得不增加一个数据结构来满足要求；
• 部分原因是因为临近期末，其他课程的大作业和考核层出不穷，使得我分身乏力。 :(

第三部分：架构设计思维的演进

第一单元 — 层次化设计

启程！这次势必一雪 OOPre 的前耻

第一单元是我成长最光速的单元。

回头看，“往日暗沉不可追”，是 OOPre 那臃肿的代码“不忍卒读”、历历在目、刻骨民心。

向前看，开学第一天作业就铺面而来，疾风骤雨之后是焕然的新生。我也算真正从面向过程步入到了面向对象。

第一单元的题目情境天然提供了一个 “层次化设计” 练手的好机会，要求利用递归下降算法处理表达式，形式化语言描述让表达式结构一目了然。抽象 层次结构利用继承和接口，通过对一组类共性行为的抽象结果使行为设计和行为实现相分离，减少代码冗余性。在第一单元设计中，表达式由项组成，项由因子组成，因子包括常量因子、变量因子等，可建立抽象层次，都实现 factor interface，简化引用并抽象出所有实现共性的接口（向下重用和扩展）。

第二单元 — 多线程设计

难度巅峰！很痛，也很快乐

第二单元的主题是多线程。线程、共享、交互形成了面向并发和协同抽象的层次结构，通过 synchronized 关键字、读写锁等线程互斥方式，保证线程安全，通过 wait、notify、join 等线程协作方式保证并发行为的协同和效率。

多线程设计要求保障 线程安全，而 设计模式 又是软件工程的基石。设计模式（Design pattern）代表了最佳的实践，是软件开发人员在软件开发过程中面临的一般问题的解决方案。这些解决方案是众多软件开发人员经过相当长的一段时间的试验和错误总结出来的。设计模式是一套被反复使用的、多数人知晓的、经过分类编目的、代码设计经验的总结。使用设计模式是为了重用代码、让代码更容易被他人理解、保证代码可靠性。在第二单元中，我们就实践了“生产者-消费者”模式。

第三单元 — 规格化设计

苦涩……感觉做了超长篇的阅读理解

规格化设计分为数据规格和方法规格，数据规格为类所管理的数据内容及其有效性（invariant，constraint），方法规格为类所提供的操作，要规约前置条件 require、后置条件和副作用，另外注意子类与父类的规格关系。规格与实现分离是指将规格说明与具体实现分开，以实现更好的灵活性、可维护性和可扩展性。比如说在第三单元中规格定义了 people[] ，在实现时为了获取方便我们使用 HashMap 进行存储。虽然规格对数据和方法进行了描述，但只对模块接口进行规约，没有限制模块内部细节设计，所以数据容器的选择、中间数据的存储和检索、规格的层次化以及算法的选择依然是需要在实现中思考的问题。

第四单元 — 模型化设计

尾声！自己全设计来画上圆满的句号

模型化设计指先使用系统化的模型语言来表示设计结果，进而开展设计与实现，通过类图按数据和类提取抽象形成抽象层次，通过顺序图完善类的职责和关联关系，通过状态图完善类的行为规格设计，进行正向建模。

第四部分：测试思维的演进

第一单元

我在第一单元对测试的认识还没有那么系统。

• HW1 和 HW2 通过自己搭建评测机，实现中等规模压力测试，这对初步扫清简单 bug，增强底气是非常重要的。
• 但是这还不够。在第一单元的互测中，hack 命中的往往数据强度不一定很大，但是是一些“刁钻”的 corner case。

总之，通过第一单元，我对测试有了一定的初步认识，并在互测中体会到了 **边界测试 ** 的重要性。

第二单元

第二单元的互测场面那就大了……

比如大名鼎鼎的“围师必阙”互测数据。其背后实质反映了大部分人都只关注调度 “分给谁” （从而在心里默认了一定要把人分出去），而忽略了换一个角度考虑到底 “分不分”。

又比如 RESET 在开头或者在末尾，一些同学可能就暴露出线程安全问题。

以上，通过第二单元的强测尤其是 “百家争鸣、“百花齐放”、“百舸争流”、“千帆竞发”的互测，我体会到了 全面测试 的重要性。

第三单元

第三单元正式对测试有了系统的认识。

黑盒测试、白盒测试、单元测试、集成测试、系统测试、压力测试……

通过第三单元的互测，我体会到了 压力测试 的重要性；并且在 JUnit 评测的经历中，体会到了测试不仅要关注 数据强度，也要关注 数据本身的多样性。

第四单元

本单元的测试非常简单，一方面是构造大量随机数据进行黑箱测试，另一方面便是针对题目中日期相关的要求进行边界测试。

第五部分：课程收获

“回首向来萧瑟处，归去，也无风雨也无晴。”

大象希声，大音无形。疾风骤雨过后，内心多的可能不是心潮汹涌，而是风平浪静。

OO！还是 OO！

从严寒到酷暑，从第一单元到第四单元，不管怎样，我自身的 编程水平 肯定有了质的飞跃，绝非大一那个还在“程设”上摸爬打滚的自己了。这背后可能是 OO 课程强度的训练，也可能是某一次痛彻心扉的 debug 经历。日月光年，厚积薄发。

然后再说 更高层次 的一些东西，层次化设计 $\rightarrow $ 多线程设计 $\to$ 规格设计 $\to$ 模型化设计，我绝不敢说自己有多高程度的掌握，我深知自己还绝非有着手持“金刚钻”的水准。但收获也肯定是不少的，或多或少，但我相信可能现在还掌握不强的一些东西会埋下一颗种子……

OO！不止 OO！

OO 不是 Java，Java 也代表不了 OO。

OO 不是和 C、Python、Java 一样的编程工具，而是 一种思想，一种方法论。就像 OS 中，我们将 console、file、pipe 等等都 抽象 成了“一切皆文件”，并以句柄的方式给用户以提供 接口。这也是面向对象的体现。

OO 课程结束了，但 OO 作为一种思想将在旅途中长久相伴。

最后

感谢老师和助教们的辛勤付出，感谢 OO