OO第四单元(UML)单元总结

OO第四单元(UML)单元总结

　　这是OO课程的第四个单元，也是最后一个单元。这个单元只有两次作业，相比前三个单元少一次作业。而且从内容上讲这个单元的作业目的以了解UML为主，所以相对前三个单元比较简单。

一、作业分析

　　1.第一次作业

　　　　第一次作业的目的是实现一个UML类图解析器，这个解析器需要接受由UML图生成的类图信息并根据要求返回相应的结果，是以了解UML类图为目的的作业。

　　　　

　　　　由于UML解析器的输入是按照starUML中存储类图信息的方法来存储的，所以这次作业的目的其实是了解类图的存储方法，即starUML所采用的树状存储。在了解每一个元素在类图中的存储方式后整个做也可以说是相当于完成了一半，所以了解UNL存储架构和建立自己程序的UNL信息存储架构是本次作业非常重要的一环。我了解UML存储方式的方法非常的简单，就是在starUML中画一个图，再用写字板的方式打开，然后结合搜索功能了解其存储结构。之后的自己程序的架构我基本按照UML的存储方式，即构建了ClassNode类用于存储attribute之类的信息，而对于还有下属元素的operation和association则也创建一个Node类用于存储。有一点不一样的是我将Class和Interface用同一个类ClassNode来存储，因为我看这两个元素所储存的元素差不多，这也为我之后的作业造成了很多麻烦。

　　　　解决了架构问题，接下来的就是算法的问题。由于要求的方法中有很多需要遍历继承树和关联树的，考虑到是统计个数，因此我对于遍历的要求多采用BFS算法进行遍历，再用HashSet来进行结果的存储从而排除重复。而对于AssociationEnd的处理，我将reference是这个类的associationEnd存在这个类下面，而所有association作为一个数组存在每个ClassNode下面，这样查询关联时就是根据associationEnd找到association再根据AssociationNode的信息找到对端信息。

　　　　

　　　　

　　　　我这次的架构基本按照UML图的存储结构进行设计，这样有一个优点就是稳，至少架构不会崩，没有重构的风险。而在细节设计上我采用了以空间换时间的设计，一个类尽可能多的存储他需要的信息，就像association的信息我每个类都存了一份。

　　2、第二次作业

　　　　这次作业的目的是在上次作业的基础上拓展解析器，使得能够支持对UML顺序图和UML状态图的解析，并能够支持几个基本规则的验证。是一次以了解UML状态图和顺序图为目的的作业。

　　　　

　　　　这次作业的架构设计依旧和上次一样是参考UML本身的存储方法设计的，即将顺序图InteractionNode和状态图RegionNode以和ClassNode一个级别的类存储，而StateNode则用于存储状态的信息和它所能直接到达的状态的id队列用于进行遍历。由于考虑到考期的问题，这次作业要求的顺序图和状态图要实现的方法并不深入，甚至说这两个图中许多的元素在这次作业中并没有用到。相对的，这次作业的难点主要集中在那三个模型有效性检验方法上，对于循环继承检验由于是以搜索为目的所以我采用的是DFS算法，而以遍历为目的重复继承我才用BFS。从图的角度讲，循环继承检验是遍历图上每一个点，如果这个点有到自己的的路径则他在循环中，重复继承则是如果一个点有两条路径通向一个点则是重复继承。

　　　　

　　　　

　　　　这次的思路依旧和上次作业差不多，状态图由于region和statemachine在功能上有所重复所以合成了一个类，另一方面由于有很所元素这次作业并没有用到所以在类的设计上也做了相应的简化，忽略了那些用不到的类。由于之前将类和接口存在了一起所以这次构建图的时候必须用一个type属性将两者区别开。

二、四个单元中架构设计及OO方法理解的演进

　　1、第一单元

　　　　这是OO学习的第一个单元，这个单元我可以说是完全没有架构设计，每一次作业都在重构。也是这个单元的作业让我认识到了框架延展性的重要性，重构的原因基本都是因为没法再上次作业的基础上实现新一次作业的要求。另外由于这是面向对象的第一个单元，也是了解面向对象理念的第一个单元，所以虽然每一次作业都在重构，但是写出来的代码还是逐渐从面向过程转变为面向对象的。

　　　　总而言之，第一单元在架构上的收获是：1、面向对象的思维　　2、框架延展性的重要性。　　3、不好好做架构设计真的很容易写出屎山

　　2、第二单元

　　　　OO第二单元的主题是多线程，也是四个单元中难度较高的一个单元，而这个单元的作业我完成的比较轻松，其原因很大一部分是因为我架构做的好。这个单元的第一次作业由于要求比较简单所以我基本上是没做什么架构的，而第二次作业由于初露多线程的锋芒并且助教明确暗示下次作业会有多部电梯，所以我在写代码前仔细思考了框架的延展性以适应第三次作业。第二次作业设计出的框架很大程度上参考了老师在课上提出的那些设计模式。第二次作业完成后的第三次作业我几乎没花什么力气就完成了，可以说第二次做的架构十分的有用，也让我意识到了一个好的架构能为我省下多少力气。

　　　　总而言之，这个单元在架构上的收获就是：1、设计模式的学习的重要性　　2、一个好的架构设计真的很有用　　3、功能解耦的重要性

　　3、第三单元

　　　　第三单元的主题是JML（算法），虽然在上个单元中由于架构我尝到了不少甜头，但在这个单元的设计中我依然吃了瘪。因为我以为这个单元是学习JML所以每次作业的联系不会很紧密，事实证明我错了，不仅每次作业的联系很紧密还和JML没什么关系。这个单元的作业让我认识到了架构不仅仅要延展性好，还要适于搭载各种算法，或者说设计时计划在架构中实现的算法。临时改算法的结构很可能就是重构，而我则由于一开始选用的算法会超时而重构了一次，而且由于重构的时间紧迫所以又写出了屎山。

　　　　总而言之，第三单元的收获是：1、算法是架构的一部分，要在设计时就选择好　　2、架构要利于算法的实现

　　4、第四单元

　　　　第四单元的主题是UML，这个单元的架构其实没什么好说的，因为我基本从头到尾都是按照starUML中的结构设计的。另一方面，这个单元由于要实现的方法非常的多，所以可以说是我方法解耦设计的最认真也是最好的一个单元，设计的架构十分清晰

　　　　这个单元的收获是：1、学习好的架构对设计架构也很重要　　2、功能解耦可以使架构清晰

三、四个单元中测试理解与实践的演进

　　1、第一个单元的测试一开始因为代码量比较小所以都是以读源码找bug为主，为自己程序测试的方法也是随便想几个数据进行测试。后来第三次作业的时候代码量剧增，所以采用了自动生成数据的方法进行测试。

　　2、第二单元开始工程的体量就不是在能读的范围内了，而且经过第一单元的作业我也意识到了规模测试的重要性，因此第二单元的作业以自动生成数据测试为主，并且可以调整参数进行压力测试。由于结果正确性很难保证，因此正确性检验采用和别人对拍的方式来验证，从而将其用于检查自己的程序和查别人的bug

　　3、第三单元的测试和第二单元没有太大的区别，唯一的区别就是测试变成以对拍为主了

　　4、第四单元没有测试，由于烤漆的原因也没有自测

四、课程总结

　　OO课程虽然难，但总体上的收获还是很多的。第一单元的主题是求导，是一个让我们入门java和面向对象的一个单元。不得不说这个单元最后一次作业难度真的很高，感觉开学这段时间是一学期中最忙的时间，不过学到的东西也是最多的。从第一次作业的一星期入门java，到第三次作业一星期入门面向对象，第一单元的作业为之后的学习打下了很好的基础，对面向对象初步的理解和对架构重要性的认识都是在这个单元形成的。第二单元是多线程电梯，是将第一单元所学的东西付诸实现的一个单元，这个单元带来的更多的是经验上的收获，在这个单元我第一次做出了一个很成功的架构（似乎是唯一一次）。同时，这个单元学习的许多设计模式也使我受益匪浅，也让我认识到了一个好的架构往往是多种设计模式相结合的。第三单元是JML，是我们第一次接触规格设计语言，在这个单元中我学习到了规格设计和编写代码，设计架构之间的关系，也让我认识到了算法是所有语言的基础。第四单元的UML是建模语言，让我学习到了如何通过图形来表达架构设计。

　　感觉一个学期的课程下来，收获最大的是对架构的理解，换句话说，是对大规格程序的理解。在学习OO之前，我们一直接触的都是一些500行以内的小程序，可以使用面向过程的思路很好的解决，而OO课中我们接触的，往往在三次连贯的作业后可以达到千行级别，代码规模不能同日而语。同样，编写这样规模的代码，转换思路是很重要的，而OO课为我们提供的面向对象，架构设计，功能解耦的思路是对我大有脾益的，可以说OO课提升了我对工程级程序的认识。

五、课程建议

　　1、JML单元感觉和算法的关系更大，作业设计上可以降低难度提升与JML的联系

　　2、UML单元既然临近期末还是降低作业体量，多些看图说话或画图的作业比较好

　　3、希望减少互测房间大小，人太多虽然可以引导同学自动测试，但也会让人不想去测这么多人