其他分享
首页 > 其他分享> > BUAA_OO_第四单元总结

BUAA_OO_第四单元总结

作者:互联网

BUAA_OO_第四单元总结

  本单元作业主要针对UML模型进行建模于分析。

架构设计

  本单元架构主要以类似于递归下降的方式来分类分批次的逐步解析为主。

flowchart LR A[输入] --> B(分类储存) B --> C{解析} C --> D[类图] C -->E[状态图] C -->F[顺序图] D -->G[属性] D-->H[变量] D-->I[继承和实现] D-->J[关联] H-->K[操作] G-->|添加并检查正确性|L[类和接口] I-->|更新继承和实现的相关方法|L K-->|添加并检查耦合度|L J-->|添加并检查重名|L E-->M[状态] E-->N[事件] N-->O[迁移] M-->|添加|P[状态图] O-->|检查各方法和状态迁移|P F-->Q[结束] F-->R[生命线] Q-->S[消息] R-->S S-->|更新生命线并检查正确性|T[顺序图]

BUAA_OO_期末总结

架构思路和OO方法

  OO课程四个单元的架构思路各不相同。第一单元使用了递归下降解析表达式,第二单元主要是利用多线程来实现电梯调度,第三单元主要就是跟着JML规格书写,第四单元又重回解析方法,解析UML。
  每个单元动手前,我都会先花上几天的时间去思考架构。等到得出一个比较清晰的结构后才会开始着手去操作。这样使得我这个学期在代码的迭代上花费了比较少的精力。大部分作业都可以直接新增方法实现。
  而对于OO的方法来说,我目前仍只能稍微对代码中的对象进行一定程度的封装。对于内聚耦合等问题都没有过考虑。

测试理解与实践演进

  本学期的四个单元的测试我都是通过手动构造和自动测评的方式来实现的。在完成代码后先构造测评机,通过大量的数据测评来验证我程序的正确性。然后通过手动构造比较极端的的数据,来检测程序的性能。
  测试在我看来主要是为了检测程序的正确性和性能问题而进行的。一个合理的测试能够保证程序的有效性。在数据构造时,通过确定的规格、利用随机的方式将所有可能的输入进行组合,可以对于各种情形进行验证。虽然这样对于特定的情况可能会出现纰漏,并且需要很长的时间进行验证,但是总体上来看仍有较强的实用性,同时构造方式简单。除此之外,也可以进行相应的特定组合进行验证,辅助随机测试。例如将生成每一种情形下确定的异常输入,进行错误判断等。
  总而言之,通过不同方法组合来构造测试,可以较好的验证程序的正确性。

课程收获

  首先,OO给我带来了代码书写的挑战。如何正确的处理一份较长的代码,是我两年的学习中第一次遇见的问题。动辄上千的代码让我在书写时就会产生遗忘,如果没有及时记录和注释,很难在第二天写代码时迅速的反应过来程序完成到了什么程度。代码量的增大使得我更加适应了一种新的代码书写习惯,真正的架构到书写、测试的全过程体验。
  其次,OO给我带来的是对于规范的理解。JML、UML的规范是我们对于一个代码工程的整体架构,清晰的规格带来的是清晰的思路和较低的上手难度。同时代码等规范的界定虽然让人十分厌烦,但是在回顾工程和迭代开发上使得对代码能够被更快速的重新理解。一个规范化的代码形式和架构形式,使得代码的难度大大降低。
  最后,OO给我带来的是架构的认识。第一次遇见这么庞大的代码,一个好架构的优点便体现出来。一个好的架构能够帮助我理解代码,快速书写,同时也节省了迭代的麻烦。快速书写、快速定位错误、避免重构,让我觉得这学期我在OO在课程上相较于一些同学更加轻松,为我节省下了大量的时间与精力。

改进建议

  1. 问题背景可以在更加详细的介绍一下。例如第三单元的JML可以更加详细的介绍社交网络的具体部分,包括网络中的节点、价值、路径等问题。这样涵盖了每个单元三次作业基本背景可以防止第一次作业思路跑偏,引起重构问题。同时也能够方便预测每单元迭代所增加的需求,为迭代留下空间。
  2. 指令的例子可以更加详细一些。例如第四单元最后一次作业查询属性和关联问题可以在指导书中就给出吏部,不用在测验中去理解。而且重复继承的错误判断的例子也可以给出输出,这条指令的输出和例子不相关,第一次看指令时带入了循环继承的输出,以为是需要输出重复继承的路径,后来才看明白。
  3. 可以在预习中增添多线程的部分,便于第二次单元的理解。感觉第二单元多线程的引入过于迅速,如果没有相关的预习和实践知识,完成第二单元第一次作业时可能无法迅速抓住重点。

标签:OO,架构,--,代码,BUAA,解析,单元
来源: https://www.cnblogs.com/wwz-buaa/p/16411129.html