16071070_陈泽寅_期末总结

面向对象编程学期总结

1、总结本单元两次做业的架构设计

单元概述：

本单元介绍了UML类图的知识与用法，而且经过StarUml软件来生成相应的UML垒土、状态图、时序图来进行相应的验证。UML语言：统一建模语言（英语：Unified Modeling Language，缩写 UML）是非专利的第三代建模和规约语言。UML是一种开放的方法，用于说明、可视化、构建和编写一个正在开发的、面向对象的、软件密集系统的制品的开放方法。UML展示了一系列最佳工程实践，这些最佳实践在对大规模，复杂系统进行建模方面，特别是在软件架构层次已经被验证有效。下面讲一下本单元所学到的一些理解。

第一次做业

此次做业主要是进行类图的解析。主要的思路就是从UmlClass和UmlInterface进行创建层次结构，而后根据UmlAttribute、UmlParameter以及Umlssociation等进行建模。进行两遍扫描，第一遍扫描，首先将全部的类，接口等UmlElement记录下来，第二遍扫描将全部的类、链接关系等创建起关系。本次做业的解析过程没有什么难点。主要是怕TLE的错误，所以咱们的想法是将一些能够重复使用的东西存起来，方便往后查询的时候直接使用

类图

这里主要须要介绍的是InterOrClass这个接口，因为第一次做业涉及到了类和接口的问题，所以必需要区别这两类，可是这两类之间有不少共享的相同点，若是分红两部分来处理则会有不少的冗余操做，所以咱们设计了一个InterOrClass接口，咱们使咱们的UmlClass和UmlInterface类都实现这个接口，而在这个接口里放共同的函数这样就可使咱们的代码简单明了。

Bug分析：

本次做业未出现Bug，也是对个人理解的一种确定。

第二次做业

第二次做业重要是在第一次做业的基础上加入了有关状态图和顺序图的分析，而且对于代码进行三种规则的验证。在状态图和顺序图的方面，整体来讲逻辑仍是比较清楚的，依照上次做业的方法就能够作个大概，重点仍是先理解各个元素的含义,主要的难点在于类图的三个规则的验证。尤为是008和009规则的验证。首先讲008规则，因为008规则要识别全部的成环的类或接口，所以我使用了DFS的深度优先递归搜索算法，而且记录下已经遍历的节点，当识别到一个节点已经在当前路径内，则咱们将成环的一些点删去。对于009规则，咱们使用相似的算法，识别出重复实现的接口，而且对于这些接口，实现其的类也算作矛盾类予以删除。对于009规则存在不少种复杂的状况，讨论区已经阐明，此处不一一赘述，在构造数据集进行测试的时候，须要注意覆盖到每一种状况。

类图

此次的设计思路与建模方式与第一次做业相同，而且针对UML顺序图和UML时序图的查询也都相对比较简单，所以在解决了上述三个check规则以后就一路畅通无阻。

Bug分析：

在中测过程当中，我出现的Bug是对于009规则的查询存在遗漏的状况，即CLASSA实现了IA,IB,而后IA,IB分别继承了同一个IC，这样CLASSA就是违反了009。

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

心得

刚接触面向过程的编程的时候，内心仍是挺惊慌的，由于内心尚未从面相过程的思惟中转变过来，固然这样的转变也不是一朝一夕就能完成，老实来讲，最后一个单元的架构中，我依然存在不少的面相过程的编码习惯，这也说明了咱们仍是须要一段很长时间的练习才能彻底造成面相对象的思惟。下面讲一下我在每一个单元中的思路历程。

第一单元

该单元是进行多项式的求导，第一次做业的惨痛教训我至今难以忘记，因为第一次写代码，写的彻底就是面相过程的形式，所谓的‘类’，也就是套了一个类的空壳子，里面的代码彻底就是按照面相过程的形式进行的，所以在该单元第二次做业时，全部的代码都须要进行重构，这就让我下定了决心要好好理解面向对象，当时的想法就是多建立类，将类类分离，每一个类各司其职，将其耦合度下降，虽然理论上都知道，可是在操做起来时仍是存在不少不熟练的问题。在第三次实验，带有递归的求导时，我以为是我真正意义上第一次比较好的使用了接口、类的含义的一次实验，我将求导与类分离，这样每一个对象只关心本身的事情，所以最后的强测也比较满意。总的来讲，第一个单元的几回尝试，让我初步了解了面向对象的思路以及构造之法，至于代码能力，还须要增强训练。

第二单元

第二单元的做业是有关电梯调度的做业，此次的训练核心是多线程的运用。在这三次做业中，我主要是针对当前的状况经过不一样的调度算法进行调度，将电梯做为一个单独的线程。该单元我以为是几个单元中最难的一个单元，由于多线程的理解的确有点困难，好在仍是挺过来了，也收获不少。主要的思想就是创建Elevator,Dispatcher,User三个类，而后每一个类完成本身的职责，而且互相联系。难点就在于如何联系，前两次我使用暴力轮询的算法，可是这样的话会致使RTL的问题，所以最后一次做业我对每个可能会发成轮训的地方，咱们都采用wait,notify的方法来进行解决，这样能够大大减小CPU的不必的使用时间，大大增长了程序的执行效率。还有第三次做业中的调度策略须要进行划分，这对于类的架构设计要求就更高了，须要你明确每一个类的职责，否则在多线程中就会出现不少难以描述的问题。总结，第二单元让我更加明确了类的职责，也搞明白了多线程的一些问题。

第三单元

该单元我认为是在四个单元中比较简单的一个单元，主要的目的是对JML规则进行理解，咱们根据JML规则进行代码的撰写。但其实JML的规格理解仍是其次，主要的提高是对于类与类的数据结构的架构设计以及时间复杂度的合理把控。由于在此次做业中我就出现了RTL的错误，所以咱们必需要合理构造数据结构对数据进行存储。在第三次做业时，因为存了不少不须要的重复节点，致使时间复杂度太高，致使不少的节点时间超时让我悔恨至极，所以在第四次做业中我很认真地对算法和数据结构进行了设计。总的来讲，这个部分我学到了不少关于数据结构以及查询效率方面的内容。

第四单元

见第一部分，主要收获和第三单元相似。

3、总结本身在四个单元中测试理解与实践的演进

这个单元主要阐述我对于测试数据以及实践演示的理解，在第一单元的时候我还不了解本身构建测试集的重要性，每次都是觉得中测过了以后强测就稳了，却不知好几回强测都挂了不少点，而这缘由大都是由于一个很简单的小问题，而这些问题也正是因为本身没有构建测试集而形成的问题。所以从第二单元开始我就本身构建测试集，先整理好有哪些边界条件，或者可能出错的问题，而后针对这些问题一一构造数据集进行测试。针对电梯单元，我特地用python编写了测试脚本，能够模仿评测机，对输入自动解析，而且在相应的时间节点重定向入标准输入。可是还要注意有一些设计上的bug是数据集可能没法测试出来的，这些问题在多线程中是多发的，所以在设计多线程时，最主要的步骤仍是在设计的时候就想清楚一切，而不要过度依赖测试集。

针对第三单元，我使用了Junit对每一个方法进行了单元测试，这个好处就是你能够着眼于局部，对每个函数检查其正确性，使测试覆盖面更加全，而且更加容易定位错误的发生位置。同时学习了OpenJml来对JML语言进行规范化的验证，同时也用Jprofile对生成的代码运行时的内存资源等进行调研。明白了JVM虚拟机在运行时的CG等机制。针对第四单元，咱们学习使用StarUML对UML进行设计并验证，明确了各类图与图、类与类之间的联系。同时编写Junit单元测试真的对于接口方法实现的正确性验证起到很大的做用。

4、课程收获

一、让个人思想从面相过程向面相对象进行转化，之前难以理解或者毫无思绪的一些建模情景，如今均可以经过面相对象的思想来进行简化，这无疑是对我编程道路上的一个跨越。

二、收获了框架设计的重要性，之前编写代码都是想到什么写什么，如今经历了一系列OO实验的洗礼，深入明白了设计的重要性，千万不要急于编码，要先把做用、规格想清楚，而且注意代码的可扩展性再进行编码。

三、类与接口的设计，类的设计越简单明了越好，每一个类承担的责任越少越好，类与类之间尽可能减小交集，减小耦合，这样在进行扩展的时候就能减小代码的修改。

四、对JML规格的认识，代码在编写以前，先肯定接口、方法的规格，这样有助于写代码的时候明确代码的输入输出以及异常状况，这样既有助于本身的代码撰写，也有利于团队合做时其余人编写代码时的理解。

五、认识了代码风格的重要性，学会了使用pycheck，曾经在编写代码的时候，我不会顾及代码的风格，想到哪写到哪，一个函数可能写个一两百行，一个函数处理了不少的方法，每一个函数显得十分臃肿，即不明确其功能，在维护或者扩展时也显得十分困难，如今每一个方法的功能明确，职责分离，利于实现以及维护，一样也对阅读者比较友善，他人容易阅读代码。

六、最后就是对于测试验证的理解更加深刻，之前对于测试验证的过程不够重视，草草了事，通过该学期的磨练，认识到了测试验证的重要性，毕竟之后的工做是服务于客户，为了客户的良好体验，必需要覆盖到每一种可能发生的状况，保证程序的健壮性，在任何状况下都不crash。

5、立足于本身的体会给课程提三个具体改进建议

一、对于起点难度的把控：

我以为本学期四个单元的做业对于能力的提高确实比较大，可是可能每一个单元的难度把控不是很规范，好比第一二个单元难度比较大，而且开学的时候你们对于JAVA都比较陌生，可能编码比较困难，所以我建议在课程开始以前先对JAVA的一些基础知识进行教学，或者前两个单元给比较长的时间，让咱们同窗有一个比较好的过渡和比较充分的了解JAVA的时间。

二、课上实验改进：

课上实验的内容的确比较结合咱们的编程以及学习内容，可是每次实验以后咱们的结果就石沉大海，得不到任何的反馈，甚至连本身错了，对了都不知道，而且也没有任何的讲解，我认为没有反馈的训练就比较乏力，就好比梯度降低算法也是靠反馈来优化参数，只有错了再优化咱们的能力才能提高，所以我但愿可以在每一次实验课后将咱们的结果进行反馈，而且在理论课的时候简单地讲解一下上次实验的内容。

三、关于强测机制：

我以为强测的时候可能过多的测试点都是有联系的，每每有些同窗都是由于一个小小的错误致使一半的测试点所有错误，这样的话可能让同窗会有点沮丧，而且可能由于这样而拉不开层次差距，建议之后的测试点之间的耦合性下降，使同窗们的分数之间有层次感。

六:展望

本学期OO带给了我不少心得东西，也但愿OO课程组能认真采起同窗们的反馈，将这门课作的愈来愈好。