BUAA面向对象设计与构造——第四单元总结
（1）总结本单元两次作业的架构设计
第1次作业：UML类图的查询
这次作业的重点我认为在于理解类图本身的含义，搞懂每个UML元素的作用和各个参数的意义。
在实现接口的MyUmlInteraction类中，我以class.getId()为key值，建立了所有类的hashmap，来存储类图的信息。首先在构造函数里一个一个元素地识别并存储。这里我遍历了三遍，因为助教说不保证模型语句的前后顺序，因此我的设计是分三遍识别：
第一遍UMLClass，UMLInterface，和UMLAssociationEnd，将每个类的name与id建立name2Id映射，方便之后解析查询指令中传入的name；id与类建立classList映射，因为id是唯一的；name与同名类出现的次数建立classTimes映射，用于之后识别重复类。对于UMLAssociationEnd，以end的id与类的id建立end2Class映射，这样可以在后来建立关联关系的时候找到对应的类。
第二遍UMLAttribute，UMLOperation，UMLAssociation，UMLInterfaceRealization，UMLGeneralization，这些信息都直接存入MyClass类中，具体属性设置见之后的类图。
最后一遍UMLParameter，这是因为parameter-operation-class是一层层依赖的。
这样可以保证每个元素所依赖的上一层元素都比自己先识别。
作为类图中是最主要的元素，为了将UMLClass和它相关的属性、方法、关联关系、继承关系和实现关系等元素与类本身联系起来，我建立了一个MyClass类，在UMLClass的基础上，将它的各种关系都记录在里面，方便查询。
我设置了一个type属性来判断这是一个类还是接口，接口可以多继承，类不可以，其他地方这二者区别不大，因此我都使用MyClass来存储的。对于属性、方法、关联这些的统计，都是直接返回对应容器的size。而顶级父类、实现的接口这些较复杂的查询，基本都是通过递归来实现的。此外我对一些问题设计了xxxChecked，一旦查询过一次之后就设置checked为true，这样以后再查询就不需要多余的递归和遍历，可以直接返回结果。
第2次作业：UML顺序图的查询、UML状态图的查询和UML类图的有效性检验
和上一次类似，我针对状态图建立了MyStateDiagram和MyState两个类，来分别记录顺序图中的信息（MyStateDiagram有些复杂是因为当初老师说起始状态和终止状态要合并）。在MyStateDiagram中设置了statesList来建立状态id与状态类的映射，transtitionList记录了所有的迁移id。
状态的个数和迁移的个数都很好统计，后继状态的查询我是把状态看作点，迁移看作边，用图论的思想计算可达矩阵postState来实现的。
针对顺序图建立了MySequenceDiagram和MyLifeLine两个类，这两个类比较简单，顺序图的三条指令都是直接统计就可以了。lifeList记录了LifeLine的id与MyLifeLine的映射，messagesList记录了所有的消息。对于每条消息，相当于是target端的lifeLine的incoming消息，将他们加入对应MyLifeLine的incomingMessage中。如此一来，三条查询指令都是直接返回容器的size就可以了。
我认为这次最复杂的是类图的有效性检验。
UML008是通过递归实现的，每个类调用父类的方法，并且要把之前经过的所有类都当作参数ArrayList
UML009本来也想递归，但是有些复杂，因为既要记录路径数目，又要记录路径的起点终点。最后也是通过类似于图论的方式解决的。把类和接口看作点，继承和实现关系看作边，如果点到点之间有多条路径，则构成了重复继承或重复实现。
（2）总结自己在四个单元中架构设计及OO方法理解的演进
第一单元是多项式的求导。在第一次作业中，我完全没有构造类的想法，还是集中在如何设计变量，如何构造方法。后两次由于多项式本身的特点，我构造了Expression，Term，Factor等类，但主要还是由题目的要求迫使我选择这种设计，我自己本身对于面向对象的设计还不太清晰。这次主要学习了java的基本概念，以及Hashmap和Arraylist这两个我在之后被多次用到的容器。
第二单元是模拟电梯运行。这次我认为是最难的一次作业了，因为针对于线程的编程还是头一次。线程的debug过程非常困难，所以与其一点点debug，不如在写代码的过程中理清思路，注重细节。这次作业主要学习了同步和互斥访问，预防线程死锁以及线程的wait，sleep，notify和notifyall。进一步了解了线程的工作原理和锁的配置，而且更注重于类与类之间的信息传递与配合。
第三单元是针对JML的理解，实际解决的是图论问题。这一单元主要是每次需求的扩充，到这里的时候我几乎不需要重构了，这是很大的一个进步，在每次写代码时都考虑一下以后的需求增加。这次还学习了Junit自动检测。
第四单元是解析UML图。这次是针对主要的几个元素建立了单独的类，其他元素加入到这些类中当作属性。这次写起来就很顺手了，各个功能分配到不同的类中完成，最后在总合起来，思路很清晰，架构也比较直观。
（3）总结自己在四个单元中测试理解与实践的演进
我们这学期没有互测环节，所以测试方面可能还稍显薄弱。
一开始不知道如何系统的测试，基本是想到什么难的测试点就测一下，最后再测一下边界条件，而且都是手动输入。后来开始用程序自动生成测试代码，比如第三单元的路径问题，就可以用程序生成几千行的测试代码，这样比较全面，也具有随机性。
而且也不是上来就测试代码，先再次阅读指导书，明确编程目标，从头捋一遍代码，检查是否符合需求，从而保证了代码没有大的偏差。之后再通过生成的一系列代码，尽量完备地进行测试，力求覆盖全部情况。
（4）总结自己的课程收获
最大的收获就是学习了java语言以及建立了面向对象的编程思想。我在这之前没有写过什么像样的c++程序，稍微大点的项目都是用的c或者python，完全是面向过程的思想。而通过这一学期循序渐进的训练，我逐步掌握了一些面向对象的设计思想。这几次作业的代码量不少，锻炼了我全局性考虑代码的能力，使我具有了减少冗余代码的意识。此外也学习了很多辅助工具，例如代码风格检查，监控线程工具、JML规格语言和UML画图工具等等，让我对java语言和面向对象有了更全面的认识。编程不是只局限于代码本身，前期的理解与设计，后期的检测与完备，辅助工具的配合，都是很重要的。
（5）立足于自己的体会给课程提三个具体改进建议
建议：
1. 有一些关键性问题或者边界条件的确定，助教或者老师是在某个同学的帖子中回复的，这让其他人不太容易找到，官方帖希望更新的更及时。
2. 有几次没有按约定时间发布指导书，有点浪费了周末这么适合写oo的大好时光。
3. 建议课后公布上机课的答案，或是向学生个人反馈分数。
这学期的oo课程设计采取每个单元一个主题，三次作业依次增加需求和难度的方式很适合我们从易到难的学习和训练。最后感谢课程组的付出！