OO总结博客.Final
OO总结博客.Final
（1）总结本单元两次作业的架构设计
两次作业有着很好的扩展和继承关系故而两次合在一次说。
本次作业难度不是很大，其重难点在于弄清每个元素之间的联系和层次上的顺序关系，之后用自己的数据结构储存层次信息，同时便于后续的查找和查询。
在这里给UMLElement分四个层次：
第一层次：UMLClass，UMLInterface，UMLStateMachine，UMLInteraction.
第二层次：UMLAttribute，UMLOperation，UMLParameter，UMLRegion，UMLLifeline.
第三层次：UMLPesudostate，UMLState，UMLFinalState.
第四层次：UMLAssociation，UMLAssociationEnd，UMLInterfaceRealization，UMLGeneralization，UMLTransition，UMLMessage.
可以看到每一个层次都是以上一层次或者更上一层次的元素ID作为自己Parent域内容的。由此可以很自然的建立数据结构，即由上层元素建立自己的类并且内部细化储存结构来储存其内部元素，在顶层之上的总体统御类里建立查找系统（指HashMap），来对元素进行查找，值得注意的是我在建立数据结构时没有把所有的信息都储存，而是大部分只储存了ID，在需要查找时在外部的id2element（HashMap）中获取element内容。这样能简化储存的数据结构，同时也对应了查询操作都是在外部进行，减少了状态，参数彼此转递的花费，但是也提高了查询的操作成本（由于都要回到顶层查询）。
有了对Element的层次了解，建立结构就是将输入的数组遍历四次，依次建立起各层的结构，值得注意的是，由于Association与AssociationEnd在同一层次而又有互相依赖关系，在第四次遍历只是储存起来，之后遍历Association与AssociationEnd将其填入到相应的CLass与Interface中。
在此给出两次作业的UML类图：
而作业里的大部分操作都可以很好的完成，有一些需要额外的数据结构支持，比如classname2id是一个类名到id的映射，但是由于可能会有类名重复故而对应的是一个arrayLIst。
但是问题出现在RULE的判断上，在判断是否有环的过程中，起初使用的是DFS，但是带标记的DFS会存在多个环有重合部分时不能找出全部的环的情况，而不标记的DFS不能预测会出现什么样的情况，或许能做到但是也会有极高的复杂度。最终选择了Tarjan。
而判断是否有重复继承的过程，我选择了用递归查找，即在查找某个类是否有重复继承时先看其所有继承的list集合是否为空，不为空则为还未建立则由其继承的类或接口相加，从而递归完成这个过程。可能这样的复杂度很高，每次每个类的查找都将其所有的继承，间接继承都统计在一起，看其转化为Set后size是否改变，但是实现起来较为简单。
BUG情况：
第一次强测，由于没有理解查找类中元素属性的对应的classname应该为其所在class，导致错误。
第二次强测，由于对类中属性可见性的计算出现理解性错误而导致出错。
综合：反复阅读指导书，明白每个指令的具体用处，输入输出规范，不明白的地方多讨论，避免出现理解性错误。
总体情况还是不错的。
（2）总结自己在四个单元中架构设计及OO方法理解的演进
第一单元：
最初的作业里（指第一次作业）里很难看到面向对象的影子，反而像将c生硬的塞到了java的躯壳里，而到了第一单元最后一次作业，逐渐明白了面向对象，每个对象各司其职又互相联系，完成数据结构和功能的统一体。
第二单元：
本次的电梯作业，让我更好的明白了对象这个实体所应该具有的功能，同时也了解了java内的多线程思想，和线程之间的交互工作。同时也了解到一个好的结构的重要性，从而能将第一次作业的结构通过扩展来完成后续的要求。
第三单元：
本次的地铁系统，可以说是一个数据结构向的作业，其主要考核目标是对各种操作复杂度的拆分和耦合，同时建立起相应的数据结构来完成空间换时间的思想，避免出现极大的复杂度单元。同时实践了JML的使用，明白了规格的重要性。
第四单元：
本次作业我感觉重点在对所要完成需求的结构要有很好的理解，对其结构理解透彻后才能更好的完成架构设计，这是一个互相促进的过程，也是一个了解UML类图的过程。
演进的话就是从无设计到有设计，从乱架构到合理架构，从无对象到有对象，从多线程交互困难到可以实现一定的交互的过程。
（3）总结自己在四个单元中测试理解与实践的演进
测试往往是以输入的角度来完成的，但是我个人感觉在以输入角度来完成测试之前，首先要保证每个逻辑单元的正确运行，即首先要判定框架和逻辑是正确的，测试才有意义，从而需要很长时间的静态检查，要保证每个逻辑单元都能正确处理其得到的输出，给出期望的输出，这样同时也是将测试区域给分割化，避免出现对整个程序的测试，这样如果又多个问题，对问题来源的追溯就会及其复杂，同时也避免测试的盲目性。
可以说在本次OO的学习中我更加深入的了解到架构和逻辑的检查是与输入测试同等重要的，并且二者是可以同时进行并且相互测试的，同时在测试时要能找到出错的最小输入串，从而能很好的定位到bug位置。
而在测试了逻辑的合格后，要需要测试边界情况和程序的鲁棒性，即对错误输入的包容性。同时还要避免出现对Java的各种实现之间不理解的bug，譬如有将ArrayList作为参数传入后对ArrayList不新取一个而直接重用导致的各个传入的ArrayList其实是一个的这样的bug。
而实践则是从没有规范的随心测试，到有规范的每个逻辑单元的测试，到使用工具完成对拍器，使用junit的过程。
（4）总结自己的课程收获
1.面向对象的思维
2.多线程的设计与实现
3.会应用一定的设计模式
4.UML的使用
5.JML的使用
6.JUnit的使用
7.代码风格
8.测试的完成
（5）立足于自己的体会给课程提三个具体改进建议
1.课程组能够与同学之间有更好的更高效的沟通，或者是对规范的给出有更好的覆盖，避免出现同学对规范的确认有问题->问老师助教->统一解答，这样的一点点的完成过程。
2.能够对各单元对难度和复杂度进行合理的安排，个人感觉多线程应该是较为重要的一个部分，但是多线程感觉只是浅尝辄止。在烤漆周有一个UML的作业，难度不大，但是非常复杂需要耗费很多时间去理解其中的结构分布，或者能够给出一个对UML学习的官方指导书。
