OO第四单元总结&课程总结

正向建模与开发

正向建模与开发是一种系统化的方法，旨在通过明确的需求定义、详细的规划和逐步的构建过程来创造高质量的软件或系统。在OO前三个单元中，已经涉及了正向建模的相关内容（比如说总结必画的UML图），只是并没有系统地、完善地学习。而在本单元中，我们认真学习了正向建模与开发的方法论，设计并开发了一个图书馆管理系统。正向建模为我这单元代码结构的设计提供了很大帮助，让我走出了前三单元“边想边写，边写边改”的困境。通过创建模型，代码设计变得规范化、模式化，减少了出错的频率。

本单元采用的是UML（Unified Modeling Language，统一建模化语言）#进行正向建模与开发，在三次迭代开发中，我们采用了类图、状态图和顺序图逐步完成了正向建模的工作。

• 类图描述了系统中对象的类型以及它们之间存在的各种结构性关系。

• 状态图描述了对象在其生命周期中各种状态、状态之间的转换过程、触发状态转换的各种事件(条件)及执行的动作。

• 顺序图描述了对象间的交互活动，关注对象之间消息传送的顺序。

在我的开发过程中，我采取的是“正向建模-编写代码-修正模型”的方式。这样的开发方式的好处是，在代码开发前有一个宏观的架构，体现出正向建模的优势；在代码开发后，能结合实现中出现的问题，对模型进行调整，体现出开发中的灵活性。

架构设计

类图

“昨日困惑难解意，今朝豁然已贯通”，忆往昔岁月，UML类图在前三单元都被我使用过。但是，我还没有真正领悟到它的真谛。如今，我自己亲手绘制UML图，让类图与程序设计的紧密结合，领悟到了设计与实现相交融的美感。

架构分析

在三次作业中，我的架构都是以“图书馆”这个核心部分作为主体，由图书馆串联所有的借还、预约、捐赠等操作。这样设计的好处是，借还处、预约处、读者等，都可以通过直接与图书馆互动，实现相应的业务。而图书馆也可以相应的业务进行初步分类，打包给其他类进行处理。如此各司其职，相互协作，让整个业务清晰而流畅。

• Main类主要负责输入和输出，将所有的请求交给Library类处理。

• Library类是本架构的核心，通过一个实例化对象，分析所有请求并将其分发给业务代码，同时作为各个部门进行信息交互的中心。

• Rent、Drift、Reader、Mark类是图书馆功能中的具体部分，实现了图书馆特定的业务，并管理着实现这些业务所需要的数据。

• Book类负责管理图书馆中的基本元素——书。Book类可以有多个实例化的对象，采用封装的思想，封装了如bookId，dateTime，copies等各种多样的属性，并提供了outdated等一系列方法供其他类调用。Book屏蔽了书本内部实现细节的复杂性，体现了分层设计的理念。

总体来说，本次的架构设计以图书馆为核心，以图书为基本机构，以书架、借还处、预约处等业务类相互协作工作为依托，构建起了一套职责清晰、处理高效的图书馆管理系统，便于进行一步的拓展和修改。

代码与UML的追踪关系

正如前文中提到的那样，代码设计与UML设计是设计与实现的关系。由于我在实际开发的过程中，采用了“正向建模-编写代码-修正模型”的方式，所以，我能够保证代码准确地实现了UML模型中所描述的系统结构和行为，并根据代码的实现细节，对UML图中的一些进行完善，体现了“可靠性”和“完备性”。

如此一来，代码设计能够完全与UML模型设计相对应：代码设计能够实现UML模型设计中的功能和结构，与模型设计保持一致；UML模型设计能够灵活地根据代码实现作出调整，进行修改和完善。通过不断地分析和验证它们之间的追踪关系，我们就能更好地实现系统需求，提高代码质量和开发效率。

架构设计思维演进

在OO第一节课上，老师就已经强调，北航培养的人才不是流水线上的“工人”，而是堪当大任的工程师。因此，我们这门课的名字并不叫“Java程序设计”，而是叫“面向对象设计与构造”。设计与构造，强调我们要有“架构设计”的能力，有系统分析的能力，有宏观的，全局化的视野。接下来，我就结合自己四单元的学习经历，来谈谈我自己在架构设计中思维演进的过程。

• 在U1中，课程组通过”递归下降“这种词法解析方式，让我们初步学习到了层次化设计的思想。以往我在程序设计时，往往采用以”函数“为基本编程单位的面向过程的方式。经过本单元三次迭代，我明白了面向对象编程与层次化设计在复杂工程中的重要性。面向过程的编程方式也许可以在第一次任务中能勉强应对，但是在后续指数函数、自定义函数的面前，还是显得心有余而力不足。大量函数的堆积，不仅复杂度高、调试不易，而且难以维护和拓展。然而，采用面向对象的方式，把表达式分为项、因子等基本元素，再用一个词法解析器分层解析，职责内部清晰明确，而且极易拓展和修改。可以说，U1开启了我层次化设计和面向对象编程思想的大门。

• U2的电梯作业，主要完成以电梯为主题的多线程代码。多线程这个概念在操作系统的理论课中曾有提及，但是并未有所实践。经历了电梯单元的三次作业后，我对线程间的架构设计，尤其是流水线架构有了深入的体会。在这个单元，我学会了多线程协作的架构设计，明白了如何设计一个线程安全，不会产生死锁的架构。在U1的基础上，拓宽了自己的知识面，增强了架构设计的实战技能。

• U3的JML，即规格化设计，本质是一种“契约”。它的核心思想就是按照“契约”完成制定函数的功能，并完美契合函数的各种要求。通过对规格化的学习，我明白了如何有效地与他人合作。有了规格化语言作为渠道，代码设计可以变得更加清晰，多人开发配合得也会更流畅。

• 在U4，也就是本单元中，我学习了正向建模工具。我认为，正向建模相比与JML来说，视角更加宏观。正向建模可谓是OO课程的集大成者，没有之前层次化设计、多线程设计、规格化设计的积累，就没有“顶层建筑”般的类图、状态图、顺序图设计的大局感。正向建模完全脱离了具体的代码实现，而是强调从程序的对象、状态上进行设计。完成U4的三次作业后，我终于体会到了宏观设计对具体实现的指导性作用。毋庸置疑，这样的设计方式不仅用于java程序设计上，甚至可以作为”方法论“指引其他的工作。因此，我的思维终于跳脱了程序的实现细节，而转向关注顶层结构的设计与构造。我想，这才是面向对象这门课所要教会我们的东西。

总结4个单元的迭代开发经历，可以说是收获满满。从个人单道程序开发，到多线程配合协作，再到多人协作契约化编程，再到跨领域交流的正向建模与开发，OO课程从微观到宏观，逐步建立起了我的层次化思维，协作思维，契约思维。这些思维不单单指导了我在程序设计方面的实践，对其他方面也颇有裨益。

测试思维演进

设计与测试，一个绕不开的话题。一个不正确的设计，是没有意义的；一个经受住无数测试考验的设计，才是真正好的设计。所以，对程序的测试非常重要。OO四个单元的编写过程，也是我测试能力逐渐积累的过程。

• U1中，我初步体会到了OO课程弱测、中测、强测、互测多轮测试的方式。当时我还十分疑惑，为什么简单的一个程序还要经历反复的测试呢？后来，我才体会到，OO课程这样的设计，就是要让我们的程序能够在小数据、大数据、边界数据等不同数据类型中，都不出现问题。U1中互测中，永远不鲜有你想不到的数据。虽然第一单元仅仅停留在“对拍式”的测试，但是也启发了我对不同测试方式的思考。

• U2中，我掌握了多线程测试方法和思路。多线程中，测试的主要难点在于bug的不可复现性。一个不小心犯下的错误，可能需要几个小时的耐心寻找。在本单元的互测和bug修复中，我与同学和助教交流，并结合自己的思考，探索出了控制变量法，打桩法，跟踪变量法等多种不同的调试方式。根据不同的问题，精准、快速地定位到产生bug的地方。U2极大地提高了我测试程序的能力，让我在今后的测试中更加游刃有余。

• U3中，我主要学会了如何测试一个程序“是否满足规格”，用的是Junit单元测试的方式。需要注意的是，满足规格不仅是判断程序是否能顺利地完成应有的功能，而且要判断程序的性能是否过关。在U3中，我学会了用“IntelliJ Profiler”这种Idea自带的工具来分析程序的运行时间，快速定位性能过低的方法。除此之外，我还了解了黑箱测试、白箱测试、单元测试、功能测试、集成测试、压力测试、回归测试等概念，在结合OO课程组的测试方式，我瞬间领悟到了其中的深意。OO课程组的测试流程，不就是覆盖了这一套流程吗？

  黑箱测试：弱测、中测、强测、互测（随机构造数据进行测试）

  白箱测试：自测、互测

  功能测试：弱测、中测、强测、互测

  压力测试：强测

  回归测试：bug修复

  因此，我对大规模工程的测试方法，有了更系统的了解，测试思维变得立体和全面。

• U4中，课程组引入了“图测试”这种测试方式，又增加了测试方式的种类。

OO课程中的互测环节，极大的调动了我们手动构造数据，阅读程序查错的积极性。第一、第二单元，我也自己搭建评测机，对可能出现的大规模数据，进行压力测试。一学期的OO课程结束后，我的测试能力有了很大提升。

课程收获

一些建议

• 优化一下评测机的速度，尽量避免高强度并发测试（hw15强测6s，bug修复0.6s），尽量改成均匀测试。

• U4单元多一些starUML的使用指导，加快同学们的上手速度。

OO课程终于结束了~

总体来说，收获还是很丰富的，我稍微计算了一下，我四单元的总体代码量超过了5000行。经过四单元的开发，我对Java这门语言和面向对象设计已经有了很深的理解。并且通过与同学们的研讨，我知晓了很多已经没想到的思路和经验。OO这门课的压力确实很大，但是它极大增强了我们的设计能力和代码能力，为我们今后的工程实践打下了坚实的基础。