OO第四单元及学期总结

第四单元两次作业的架构设计

第一次作业

类图：

树形结构：使用Operation类管理UMLOperation以及parent为该UMLOperation的参数（UMLparameter）；使用Class、Interface两个类分别管理UMLClass/UMLInterface以及parent为该UMLClass/UMLInterface的属性UMLAttribute、操作（Operation）以及其拥有的类间关系（关联/继承/实现）等；用顶层的myUmlInteraction类管理Class和Interface，并完成要求的操作。
构建：在MyUmlInteraction类的构造方法中，通过多次遍历传入的UMLElements，完成上述树形结构的构造。
实现功能：对于相应的功能，只需在相应类中实现应有的方法，并且MyUmlInteraction类调用该方法即可。

第二次作业

第二次作业我沿用了第一次作业的架构设计，只是针对新的需求和新类型的UmlElements，增加了新的类来管理（StateMachine和Interaction），并实现相应的方法

类图：

感谢课程组对UMLElements的限制和说明，这次新增的关于状态图和顺序图的6个需求都不难，只需要新增加类来管理新的元素，实现相应的方法供MyUmlGeneralInteraction类来调用，并且在构造函数中完成对新类的构造即可。
个人认为本次作业的难点在于三个检查规则
- R001：很简单，只需要遍历每个类，看它的属性是否与其AssociationEnd是否有重名即可。
- R002：是否有循环继承。考虑两种情况下的循环继承：1）类继承类，2）接口继承接口。
  
  对于每个类/接口，用DFS判断是否有环即可。注意在递归过程中，可能会出现中间有环的情况（A-B-C-D-B-......）
- R003：是否有重复继承。
  
  由于限定了类只有单继承，因此不会出现类重复继承类的情况。
  
  1.考虑接口之间的重复继承，将存在重复继承的接口和每个接口继承的接口保存下来。2.对于每个类，考虑a)其实现的某一个接口是否重复继承了其他接口，b)其实现的所有接口继承的接口是否有继承。
  
  判断接口之间的重复继承，我最初考虑的是判断每个接口到其他每个接口的独立路径条数，超过一条则说明存在重复继承。但交流之后发现可以使用LFS方法判断，只需将LFS遍历到的节点放到一个集合，如果之后访问到的点仍在这个集合，则说明有重复继承。
这次作业的不足之处：没有把需要用到的图运算方法单独抽象出类。堆积在了MyUmlGeneralInteraction类中使得其杂乱没有条理，代码不够优雅。

架构设计以及OO方法理解的演进

架构设计是整个流程中一个非常重要的环节。一个清楚、优雅，扩展性强的架构设计可以使我们又快又好的完成代码，而不是每次面对新需求都需要推倒重来。架构设计在这门课中贯穿了始终，就个人而言，除了第三单元JML规格化设计对于架构设计的要去不是很高之外（官方已经实现了主干逻辑），其他的几个单元做好架构设计都是必要且重要的。

在这四个单元中，我一直试图理解并使用面向对象的思维方式来进行架构设计。在第一单元中，前两次作业还好，第三次作业尝试失败，因为我无法将输入的解析过程用面向对象的方法来实现。第二单元的多线程作业，架构设计的重要性就极为明显，如何保证线程安全，进行线程间的同步互斥也要纳入考虑范围。利用一些现有的设计模式，可以帮助我们更好的完整架构设计，比如在这个单元，就可以使用生产者消费者模式，工厂模式等设计模式来对问题进行抽象。第四单元完成的是UML图的解析处理。由于UML本身描述的就是面向对象语言的各种组成元素之间的关系，所以只要对面向对象语言的一些元素之间的层次关系有所理解，架构设计也就不难了。

个人感觉，在架构设计时，一个重要任务就是准确实别类及其具有的属性和能实现的方法，并且整理出类之间的交互关系。一个优雅的架构应该能妥善的处理上述内容，并且在此基础上具有一定的可扩展性。一个类过于冗杂肯定是不对的，它应该只拥有和管理他本身必须管理的属性，而将一些不必须的东西交给其他类来管理，而它本身只要保留调用接口即可。

通过第四单元的学习，我发现通过画各种UML图，我们能够更好地理解和分析需求，并且落实一些实现和交互细节，这对于我们的架构设计是非常有帮助的。

测试理解与实践的演进

各单元测试方法

第一单元：检查边界条件与特殊字符，重点在于程序的鲁棒性。简单的使用一些自动化测试方法，提高效率
第二单元：至今尚未掌握多线程测试方法，自己没有测试，全靠评测机。
第三/四单元：单元测试，针对每个方法进行测试，尽量保证覆盖全面，考虑到各种情况以及边界条件。

我对测试的理解

无论在实际的软件开发还是我们的作业需求中，测试都是非常重要的一个单元，针对不同代码，使用与之匹配的测试方法，进行充分的测试是保证程序正确性的一个重要条件。在本学期的作业完成中，我对测试的态度明显不太重视。完成作业交评测机AC之后，测试一般都是草草了事。在互测阶段，也比较佛系，基本只是针对自己当时遇到的几个坑点随缘测试，导致互测基本不见成效。在之后的代码开发中，应当给与测试更多的重视，才能完成更完善，更鲁棒的代码。

课程收获

面向对象思维

第一条不写这个有点对不起课程名字。
- 万物皆对象大概是一个入门思维。相较于C语言等过程式语言，面向对象的这个思维更符合我们对现实生活的认识。在逐次作业的实践中，我对这种思维加深了理解（感受到了用类来管理类所具有的属性以及其能实现的操作的方法的便利）。
- 如何准确识别一个类、其具有的属性和方法以及如何完成类之间的交互是我们要考虑的重中之重。
- 面向对象的三大特征：封装、继承与多态。利用它们，我们能更快、更好、更优雅的写好代码。
学习了JAVA语言。
程序的鲁棒性以及异常处理

第一单元让我深刻理解了程序如果没有鲁棒性基本就废了。

用户输入很多时候不符合条件，如何处理这些异常，如何确保自己的代码的健壮性是我们在设计时就要考虑到的问题。这就要求我们能够考虑到各种各样可能发生的错误情况，并且针对不同的情况想好不同的异常处理方式。一发生异常就终止程序是万万不可取的（想想美国坠毁的航天飞船），妥善处理异常时我们应该学习和掌握的。
规格化方法和注释说明的重要性

虽然JML有些过于繁琐，不过不得不说，正确的JML规格的确能从理论上保证程序的正确性，并严格限制代码的实际完成。然而，JML的书写和阅读体验均不佳，个人认为如果只是用于完善代码，JAVAdoc等注释已经完全足够，过多学习JML还不如要求写JAVAdoc
架构设计以及测试的重要性。

这两点在上面已有提到，在此不再赘述。

改进建议

传授评测方法（每人发一个评测机）
完善课上实验机制，适当调整课程重点

相较于每周的大作业，我认为课上实验的内容能更好的帮助我们理解上课讲授的内容。不可否认，通过这学期这么多次的大作业，我们的编码水平得以提高，但是就我个人而言，我对面向对象的理解远远不够到位。而我认为每次课上实验的内容都很棒，每个单元都紧跟上课的节奏，自己动手写代码理解继承和多态、debug、分析多线程、写规格、设计类图，这些能让人更深入的理解知识本身。然而这学期的课上实验给我的感受是十分不完善，每次题目只会在课上实验的时间段放出，上课结束老师也不会再就实验做更多讲解，也没有参考答案放出，十分不利于学习。希望之后可以完善课上实验的机制。实验结束后让大家一直能看到实验题目，并就课上实验内容进行一定的讲解（或给出参考答案以及思路）

希望之后能更加重视课上实验，并布置一些相关作业（建议把课上实验改为课下小作业，给我们留更多时间去理解掌握课上知识），同时适当减轻每周大作业的难度和规模。
在JML和UML单元，加强对应的书写规格/画图练习

个人认为自己动手书写规格/画UML图能更好的掌握相关知识。所以希望能适当布置作业并讲解。