OO第四次博客作业

OO Unit4及课程总结

随着第四单元作业的结束，本学期的OO课程正式完结。一个学期，四个单元，8次实验，11次代码作业，16次理论授课，OOP这门课程从多个角度带我认识了面向对象设计的思想精髓并在实践中不断加深、锤炼面向对象的思想。付出总是有回报，每次绞尽脑汁地思考架构，换来的是设计能力的大幅提高和足以让我受益终生的体会。下面首先对第四单元的作业架构进行一些讲解，然后具体讲述OO课程中的收获。

本单元各次作业架构设计

  • 第十三次作业

    • task：

      本次作业最终需要实现一个UML类图解析器，可以通过输入各种指令来进行类图有关信息的查询。 主要任务就是对输入的uml元素进行建模和存储，并且对外提供查询接口。

    • 架构设计

      • 这次作业的查询只涉及到类图的查询。

      • 整个类图结构通过MyModel类来管理和对外提供查询接口。

      • 然后具体由stack package中的classTree和interfaceTree来对class和interface这两种主要元素进行管理。

      • 为了便于管理class和interface的属性、操作、关联等元素，建立了manager package。设有attributeManager、associationManager、operationManager三类分别对属性、关联、操作进行管理。

      • element package中是经过包装的uml元素类。
        整个架构主要分为四个层次，总体上看是一颗树的结构，这样能够对uml元素进行合理的管理和查询，而且便于扩展。

        1

    • 类图

      下图具体给出了本次作业的类图，从中可以看到与架构图基本对应的各个类和具体的属性、方法。

      first_struc1

  • 第十四次作业

    • task：

      在上一次作业的基础上，增加了对顺序图和状态图的管理和查询指令，而且增强了类图管理的一般性，允许不合理的类图的出现，需要按照一定规则来检查类图是否合理。

    • 架构设计

      • MyUMLGeneralInteraction类管理所有uml结构，并且对外提供查询接口。
      • umlclass package对类图结构进行管理。
      • umlstatechart package对状态图结构进行管理。
      • umlcollaboration package对顺序结构进行管理。

    second_struc_highlevel

    • 类图

      下图具体给出了本次作业的类图，从中可以看到与架构图基本对应的各个类和具体的属性、方法。

      • MyUmlCollaborationInteraction、MyUmlClassInteraction、MyUmlStateChartInteraction分别是第二层次的顺序图、类图、状态图对外提供的查询接口。
      • MyUmlStateMachine对状态机中的元素进行管理，MyUmlState类是对UmlState、UmlPseudostate、UmlFinalstate三个类的抽象包装，使得能够对所有状态类型进行统一管理。
      • MyUmlInteraction类对顺序图中的元素进行管理，MyUmlLifeline类是对UMLLifeline类的包装，增加了一些额外的数据域使得其能够满足外部信息的查询。
      • 类图结构中新增了inheritMap类，这个类记录了类和接口的继承、实现关系，能够检查是否出现了循环继承。

      second_struc1

在四个单元中对架构设计及OO方法理解的演进

在我看来，OO课程最重要的两点在于面向对象思想与架构设计能力。

  • 面向对象编程是一种重要的编程模式，它模仿现实世界中实际生活的模式——每个对象管理自己的数据，进行自己的工作，对象之间传递消息用于交互，当这种模式应用在编程中时，能够使得整个程序结构更加规则化，不同程序分工明确，耦合度低，增强了可维护性。正是由于这些特点，面向对象设计思想才能在工程中被广泛应用。
  • 光有抽象出对象的能力还不够，还需要能够合理分配对象的功能，管理对象之间的交互，使得由各个对象构成的整体的系统能够以一种极为优雅的方式去运行，这就涉及到了整体架构的设计。架构的设计是从宏观的、整体的角度来看待的，只有通过无数次的训练才能有良好的架构意识。

在四个单元的作业中，这两点得到了很好的体现。

  • 第一单元逐步引入不同的项和组合规则，重点在于如何设计抽象的层次，使得对于所有的项能够统一的处理方法（求导）。在最后一次的作业中，对于架构设计的要求也变大，为了能够对嵌套形式的项进行求导，最好的架构应该是形成一颗多项式树，然后从根部开始向下递归求导，这样能够快速而且优雅的实现我们的目标。（一开始并没有想到这个架构，看到助教在指导书里给出的这个提示信息的时候感觉很震惊）
  • 第二单元重点在于多线程编程，以电梯为核心，重点攻克了多线程调度和数据并发访问的问题。在这个单元学习到的设计模式有生产者-消费者模式、订阅-发布模式。这一单元对于对象的抽象要求较低，电梯、调度器等都是显而易见的对象类，在架构设计方面，我认为这一单元强调的是扩展性。第三次作业相对于第一次作业的需求量几乎成倍数提升，这就要求我们在第一次作业设计架构的时候不能贪图简单，而是要深远思考，为可能的将来需求预留一些模块，在架构上多加考虑（本人第一次作业为了方便，没有对楼层进行建模，直接用数字表示，后来多人排队的时候就需要重构了）。
  • 第三单元强调契约式编程，以JML规格为基础，在理解JML规格之后完成对代码的实现。从这一单元开始，我们的作业形式就变成了“填空形式“，输入、输出操作都由助教给出的官方包解决，我们要完成的就是核心功能。这一单元对于架构能力的提升我认为除了对地铁线路图的架构设计外，更多的是阅读官方包代码带来的。地铁线路图的架构综合前两单元，在功能性、可扩展性上都有一定要求。至于官方包的架构，大概是让我看到了差距所在，虽然整体上来说实现的功能并不复杂，但是整个功能完全被拆解了，每个类之间的耦合度极低，而且分为大量的抽象层次，上层接口完全屏蔽了下层的复杂性。仔细的阅读了官方代码后，我对于抽象层次、封装的理解也更深了。
  • 第四单元的uml元素管理和查询是所有作业中工作量最大的，从前文的架构设计和类图中可以看出，核心在于针对诸多不同类型的对象构造层次和关系 ，这里就不再赘述。

对比四次博客中的四次作业的架构图和类图，可以明显的看到我个人在面向对象抽象思考和架构设计能力方面的提高。总的来说，OOP不仅要对实际的数据、行为进行抽象，还要注意代码的可维护性、可扩展性，二者相合才能达到完美。

在四个单元中对测试理解与实践的演进

  • 第一单元、第二单元中主要增加了我对于边界测试的理解，对于输入，要多维度的考虑边界情况，不仅仅是像最大的32位整数这种，还有一些特殊输入，有可能会涉及代码中一些数据结构的边界。
  • 然后就是对于基于代码逻辑进行测试的方法。为了了解程序的功能是否正确完整，最好的方法是读代码，将实际要求和代码中对该功能的实现逻辑部分进行对照，检查是否有错误之处，然后可以对这些疑点设计测试用例来验证是否真正出错以达到测试的目的。
  • 第三单元让我学习到的是压力测试。在实际生活中，程序不仅有正确性的要求，还有性能的要求，对于一个经常被使用的操作来说，要尽可能保证每一次操作耗时极低。压力测试就着重测试了程序的性能，同时也测试了程序在较少计算资源和较大数据量的情况下是否仍然正确执行。
  • 第三单元还让我学习到的是针对规格的测试。从根本上来说，测试就是给定输入看输出，而规格所描述的就是对输入、输出的要求和限制，因此基于规格可以快速而且较为完整的设计出测试用例。
  • 综合第三单元和第四单元的官方代码，我学习到的一点是关于异常情况的测试。设计一个程序，需要考虑所有可能的输入，即正确输入+错误输入，在保证正确输入能够合法输出的基础上，我们还需要程序能够对错误输入进行处理和响应，因为我们不期望我们输入一些不合法的数据时，却不知道为什么不合法。

OO课程收获

  • OO课程一直在强调的设计方法和设计思想，比如，对数据和行为进行抽象的思想和方法，架构优化和扩展的方法，层次化设计的思想等等，经过这么多次课程和作业的强化，已经深刻的印在我的脑海里。
  • 架构设计能力大大增强，每单元的作业都以扩展的形式进行，对架构的可扩展性设计能力大大提高；设计结构逐渐复杂，代码量逐渐增大，对架构的整体思考能力、优化能力大大提高。
  • OO课作业的代码量还是相当可观的，大量的代码撰写提高了我的代码水平，对代码风格的严格要求也让我渐渐懂得了如何去写规范的、可阅读性强的代码。而且穿插在各次作业中对于学过的算法的应用也让我了解到算法与实际工程结合的方式。总体上来说，我的工程能力和工程素养得到了提高。
  • OO课程的学习拓宽了我的视野。不论是契约式编程、JML、UML、JUnit等都是之前完全没有接触过的，通过OO理论课的学习和具体实践，让我对一些现代工程工具和方法有个更多的了解。

课程改进建议

  • 阅读好的代码是提高自身能力的重要途径，在本次课程学习中，虽然的确公布了部分优秀的代码，但是我认为公布的时间太晚，有可能一个单元结束过了两到三周才公布，这样引起的问题是：同学们首先又有了新的代码作业，可能没有时间来阅读；也可能过了两到三周，前一个单元的内容已经模糊了，阅读起来有困难，降低了积极性。

    因此我觉得最好在每个单元最后一次博客作业的周期内就能把优秀代码公布出来。

  • 讨论区中关于作业要求的问题大体上分为两类：有歧义类和特例类。

    歧义类问题尤为关键，一旦解释发生变化就可能导致实现的大量修改。但是我觉得大部分这种问题是可以在指导书阶段就避免的。助教和老师可能都觉得，很多同学提出的问题都很显然，但是同学们的经验没有那么丰富，每个人的知识架构、对问题的理解也不同，因此光从文字角度来描述需求是很容易引起歧义的。但是样例是直观易懂的。为了避免歧义，我觉得可以在指导书中增加样例的数量，给出在普遍情况下的样例。

    对于后者，我觉得通过讨论区大家齐心协力就够了。

  • 虽然强测样例都是公开的，但是有的样例阅读起来难度太大。。。。为了能够更好地学习测试方法，增强测试理解，希望每个单元末尾，能够给出一份本单元测试用例设计的思路和测试用例的分类树。

posted @ 2019-06-18 22:10  匿堕帷幄  阅读(266)  评论(0)  编辑  收藏  举报