BUAA OO Summary4

OO Unit4 Summary

Part1：架构设计

以类图为例，封装MyImplemention类，实现UserApi的接口，同时关联classDiagram、sequenceDiagram、stateDiagram，在各自的diagram中实现功能，MyImplemention负责调用。
对于ClassDiagram而言，通过唯一的id映射uml模型元素，并进行图的创建，对于getClassCount()这种方法，可以直接在ClassDiagram中实现，对于getClassOperationCount(String)这种方法，在MyClass中进行二级实现，并由ClassDiagram调用。这种思路同样运用于诸如MethodDuplicatedException这种在类的基础上对方法做检查的二级异常的抛出
对于各种uml模型，进行再封装，实现自己的uml模型以满足额外uml解析的需要。
时序图与状态图类似。
对于检查重名的问题，通过再开一个HashMap容器，映射名字与多个重名元素来解决

Part2：架构设计思维及OO方法理解的演进

• Unit1
  核心在于理解表达式运算过程中抽象实例的概念，在此基础之上构建对象。
  其中第一次作业解法比较多，可以单从多项式的角度出发，但难以实现对后两次作业的扩展。根本原因在于可以不断有新的算子产生，需要在多项式、三角函数的基础上再一次抽象。
  此外，递归解析也是很重要的方法，核心在于“一切皆是表达式”。表达式与算子的整体与分割关系是需要特别弄清楚的。
• Unit2
  这一单元侧重点在于多线程，个人困难点在于轮询和共享对象的确定上，特别是轮询，存在不可复现的特征，往往难以排查，这单元还很大程度上学习了不少Profile工具用以诊断、评估程序以及性能分析
• Unit3
  这一单元侧重点在jml，实际上更像是告诉我们对于工程来说如何扮演好架构、需求与实现的关系，以及沟通的桥梁（课程采用jml）。不过我们的核心在于实现，课程组出题。这一单元温习了不少图论的算法。
• Unit4
  这一单元是uml图的解析，面向对象的特征似乎显得更加明显了，或许是因为经过之前的洗礼罢。

Part3：测试理解与实践

实际上，对于第一个单元，由于个人还在熟悉java的道路上，所以没有经过系统的测试。
对于第二单元而言，则是采用对拍的方法，并通过电梯与乘客的状态演变进行评测机的撰写。
对于第三单元而言，我则是专注于测试数据的生成与另一套代码的实现。对拍的条件不是一直都有的，或许总有自己干别人没干过的工程的时候，一旦没有完成同一项任务的第三方，两套方法实现就显得重要了。而这一单元的图论又由多算法可言，实现不同的算法，在结果上相互印证，增加可信度。
第四单元的时候，进入考期，个人比较繁忙，加上没有互测的要求，对于测试就比较落下了。

Part4:课程收获

课程内容特别充实，在代码量之中锻炼自我，头秃。但是最后的成就感还是很强的。

Part5:改进建议

• 第一单元难度太大。从四个单元的角度来说，OO的作业并没有明显的递进关系，各单元之间是平行关系。但第一单元一上来就给了一个下马威，递归解析的要求略高，立马就丧失信心了，而且害怕OO作业，而后面几个单元则不会。
  解决：pre与第一单元具有强连贯性，一个是要把pre作业的重要性观念强化给同学们，否则之前较少接触java的同学上手第一单元很痛苦，最好给pre赋分，拥有总分的一定占比，同学们才意识到pre的重要性。并且第一单元考虑降难度，或者第一单元第三次作业设为额外加分。
• 研讨课积极性不高。
  其实这始终与OO这么课程没有太大关系，大学不少课程都是这样。可以一直感受到课程组鼓励每一位同学表达、抒发自我，但最终始终是少有的几位同学不断起主导作用，其余同学不会有太多变动。
  解决：整学期固定分组，每人每次研讨需完成不同任务？
• 研讨内容存在重复:
  研讨时每组均有同学上台，但很容易遇到小组观点与之前的观点一样的情况，但最终还是不得不硬着头皮再讲一遍，有几分不适。
  解决：像有几次研讨课，不同组就有不同的要求，所以最后重复会少的多，如果可以，课程组再费心给研讨课多设几种小组任务？