OO第四单元及课程总结
OO第四单元及课程总结
一、第四单元架构设计
第四单元基本架构已经搭好，只需要我们建立UML元素之间的关系，便于查询和检查。
已有架构
UML图中的所有基本元素已经建立好了对应的类，输入数据，便可以解析为对应的类，这些元素的类都是UmlElement类的子类。但这些数据是散乱的，需要我们用自己的数据结构去重新整理。
各种异常类也已经有了定义，抛出异常时调用构造方法即可。
源代码中不乏各种接口的实现，枚举类的使用，在写代码时应注意查看和应用。
预处理
- 首先要搭建好各种自己定义的数据结构
- 为方便查询，定义存储所有对象的
HashMap容器，以元素id为索引（要注意HashMap遍历的顺序并不是存入的顺序，所以UmlMessage为保证是按顺序的，应采用ArrayList） - 需要补全的构造方法中依次读入所有的数据，构造方法中传入的都是
UmlElement对象，需要通过instanceof关键字判断到底是哪种类型的对象，然后存入HashMap。 - 输入的数据不一定是按顺序的，所以在所有数据读取完后再一一建立他们之间的逻辑关系，以防找不到reference的情况
UML类图架构
根据UML类图的层次关系，自己构建MyClass、MyInterface、MyOperation类，将类图的元素填入其中，结构如下：
MyClass包含本来的UmlClass，父类superClass，以及类中的属性方法接口，方法和接口中的结构也依次展开。几个查询根据class的结构不难完成。
UML状态图架构
仍然按照状态图的层次关系，定义自己的数据结构。
一个region即为一个状态图，主要包含状态states和transitions两个重要的元素。通过MyState中的nextStates即可描述整个状态图的结构，MyState中也记录有MyTransition是为了方便查询转移条件、触发器等。
我将UmlPseudostate、UmlState、UmlFinalState统一用MyState来表示，用type属性作区分，简化代码结构。
UML时序图架构
结构依然清晰明了，至于具体容器的选择，取决于查询该属性的方式，只需要遍历的属性我都用ArrayList，需要具体查询的就用HashMap。
CheckUml的部分实现
R002：针对下面给定的模型元素容器，不能含有重名的成员
需要将class中的属性，另一端UMLAssociationEnd 的属性放到一起进行查重，应注意association不一定只是类与类的关系，类与接口也会有association。
R003：不能有循环继承
采用深度优先搜索算法以每一个点为起点进行遍历，一旦找到环就退出搜索，搜索时应回溯并记录路径，将路径上的点全部标记，计入答案。
R004：任何一个类或接口不能重复继承另外一个类或接口
此题其实只需要考虑接口，依然以每个点为起点进行遍历，与上题不同的是搜索结束只需要标记起点。
R009：一个状态不能有两个条件相同的迁出
此题应明确trigger与guard的先后判断关系，应当是trigger触发事件可能引起状态改变，如果满足guard的条件，则发生转移。因此应先判断trigger（即UmlEvent）是否相同。
二、架构设计思维及OO方法理解的演进
面向对象简单来理解就是以类为单位进行编程，将具有相关功能的结构封装起来。面向对象的基础是对类的设计，这是每一个单元作业都需要充分考虑的。每一个类中要有什么元素，不同类之间是怎样的关系。
前两个单元可以说练习的就是类的设计：第一单元要将因子、项、表达式设计成合适的类，有趣的一点在于表达式本身也是一类因子，因此就会出现递归一样的结构，另外为了统一表达式的计算，还需要有一个通用的类，以便将所有类型的表达式都表示成一种形式。这些其实就是类及其关系的设计。第一单元第一次作业，由于我的架构比较混乱，导致了一次重构，重新整理思路后，代码才比较清晰。这启发我写代码之前一定要先想清楚程序的框架，不要盲目地写代码。
第二单元的多线程其实也是类之间的协调运作。老师反复强调，需要一个控制器线程来协调电梯的运行。控制器线程有利于使程序逻辑清晰，也更加符合实际。自由竞争固然也是一种策略，但从架构上看还是显得有些混乱。所以面向对象一定是建立在好的类结构上的。
第三单元JML的学习深入到类内部的属性和方法上。采用这种逻辑语言是为了避免自然语言的多义性，使表述更加精准。JML告诉我们类的方法设计不能太过复杂，如果用jml语言都很难描述，说明设计是不太妥当的。JML让我从方法设计者的角度上进行考虑：前置条件、后置条件、哪些变量不能被赋值、方法前后应该满足怎样的关系。JML为代码的具体实现指明了方向，也为调试程序的设计限制了数据。
第四单元更加综合，通过一个UML解析器的实例，让我们进一步领略了面向对象的设计。UML的相关知识更是超越了Java语言，更加的通用，是架构无法避开的内容。
总的来说，通过四个单元的学习，在开始编写代码之前，我的思维更加谨慎了，我会先考虑好整个程序的整体框架再开始动手。对于一个类，我会考虑它应该包含哪些核心方法、与其他类之间的联系、是否方便查询……面向对象很像是不同的类，各司其职，相互配合完成工作。面向对象其实培养的也就是这种模块化的思维，要把万物都抽象为类和对象，把一个类看成是一个整体，这个类向外表现为一种状态，我们看这个类其实看的就是它的状态，他的状态可以是通过属性来反应，也可以是通过方法的返回值来反映。从架构者的角度来看，我们只需要关心一个类的状态就可以了，无需在意内部的细节，这样更有利于大型项目的开发。
三、测试理解与实践的演进
不得不说自己对测试的理解还是有很大变化的，以前认为就是随便试一点数据，对了就算是对了，就像第一单元，自己构造的表达式化简出来符合预期就是对的。
几次作业之后，对测试的新看法就是覆盖率，我知道要把所有的情况都测试一遍，才不至于被别人hack。从手工造数据开始，我发现手工生成数据确实工作量很大，后来也是不断在讨论区或是与别的同学交流，我开始自己写程序自动测试。自动测试就好像是一个新世界，只要保证了覆盖率，增大数据强度，就能通过无休止的生成数据然后对比答案帮你测试。我是尝到了甜头的，第二单元的某几次作业都没有被hack，反而我hack到了很多人。此后我几乎每次都写评测机。
三四单元我接触到了单元评测这一概念，可以用Java自带的JUnit，也可以是用类似的方法分单元进行测试。单元测试的好处在于针对特定的功能进行测试，而不是像以前那样直接仍一组数据进去，错了就到处找bug。这样可以保证每一部分的正确性，而且只针对特定功能，测试代码写起来也更加方便。结合第三单元JML的语句，还可以对方法执行前后的前置条件、后置条件、不变式进行判断，可以说JML为单元测试给予了极大的方便。
总之我的程序测试能力是在不断提高，逐渐掌握了通过编写自动化程序进行测试，对单元测试也有了一定的认识。在测试中，也反过来促进了我程序架构的设计，这两者是相辅相成的。
四、课程收获
最直观的收获是我学习了一门语言，经过多次作业的锻炼，我从完全不会Java到能熟练的运用Java。对Java语言的学习，最难的是假期的Pre阶段，几乎什么都不懂就开始类与对象了，于是就在网上疯狂学习Java的基础知识，可能也正是这种压力，让我很快上手。然后就是多线程那一单元，也是啥也不懂就要开始用多线程，看了很多视频，才渐渐知道怎么写。
第二是学习了JML语言，与其说是一门语言，不如说是一种思想。这种专门用来描述属性、方法的代码我是第一次见。也在此基础上知道了前置条件等一大堆东西，让我联想到了OS代码中的Pre-Condition和Post-Condition。老实说JML读起来和写起来都挺费劲的，但这确实是一种思想，虽然费劲，但是精确描述了方法的功能，也是让我开了眼界。
第三是UML，刚开始写单元博客老是要让用UML类图来说明结构，开始真就StarUML都用不明白，后来渐渐知道了UML类图的结构，画法等等也都逐渐熟练起来。但最让我收获的还是第四单元自己写UML解析器，以前对UML的理解还停留在UML就是一张图，写了解析器就知道UML其实是很多元素构成的，mdj文件也不是什么高深的文件，和json结构类似。自己去架构解析器，让我深刻认识到了UML中元素的内在联系。
当然面向对象，Java只是一种表现形式，面向对象的思维才是最重要的。荣老师反复让我们去感受面向对象，有面向对象的那种感觉，类表现的就是一种状态，对他的操作其实是状态的改变。从外部看一个类，就只需要关心它的状态，内部实现可以忽略，站在一个架构者的视角去设计程序，然后在编写具体内容的时候又把自己当作是一个普通程序员。
五、改进建议
建议一
这门课对于一个完全没有接触过Java的人来说，上手难度有些高，建议假期的Pre可以早点发给同学们。Pre中所讲的东西也有些高深，需要一定的Java基础才能看明白，所以Pre里面可以给一些基础的教程，比如列出一些博客、视频。
建议二
互测的冷却时间感觉不太恰当，因为如果要提交多次的话，可能全天时不时就要登平台交一次数据（像我一般半个多小时就能跑出好多hack数据，但是却要交一天），有些影响正常的生活安排。当然课程组这样设计肯定有一定的考虑，我认为可以减少冷却时间或者直接用互测提交数据最大次数来取代冷却时间。
建议三
研讨课一个组的同学可能真正认真在讨论的就两三个人，如果大家都不太愿意分享的话确实不太好上台分享。另外每组分享的时间有时也不够。我认为可以减少每次上台分享的组，而尽量让所有的同学都上台发言，或者随机抽取没有发过言的组上台，这样讨论划水的现象就会好很多。
