OO第四单元与课程总结

一、第四单元架构设计

　　第一次作业

　　　本单元第一次作业涉及到的是简单UML类图中关于类和接口的元素查询与管理。于是新建了MyUmlClass类和MyUmlInterface类，分别管理

　　 UML类和UML接口的相关元素。至于类之间与接口之间的继承与实现关系，也一并记录在MyUml中，即在MyUml记录所有的父类（直接父类和

　　 间接父类）以及子类（直接子类与间接子类），因此所有的查询功能都最终通过MyUmlClass与MyUmlInterface实现。本次作业主要的问题在于

　　 给出的输入并不是按我们所希望的顺序的，即可能存在UmlOperation在对应的UmlClass之前出现在输入中的情形。这导致我们此时无法将它加

　　 入对应的MyUmlClass类中，我的解决方法是先将所有类和接口读入，即先建立好所有的MyUmlClass元素。

　　第二次作业

　　　 而第二次作业则是新加了关于状态图与顺序图的管理与建立。于是需要新建MyUmlStateMachine类和MyUmlInteraction类，分别用于记录管

　　 理状态图与顺序图。而事实上这两个类与之前的UmlClass与UmlInterface类并没有任何的信息交流，所以直接在原基础上增加类，而不需要修

　　 改原先已经写好的类。

　　

 

　　 第三次作业

　　　最后一次作业则是关于输入的规范性检查。这并不需要新增任何类进行管理，事实上只需要在MyUmlClassOrInterface中增加检查函数即可。

　　 所以在架构上与第二次作业并没有任何的区别。由于我前两次作业采取的都是直接将继承与实现关系，以及子类与被实现关系全部记录在了

　　 MyUmlClassOrInterface中，所以此次作业基本不需要在类中增加新的attribute，直接对已有的属性进行检查即可直接得到是否符合Rxxx规范。

　　 当然我采用了缓存机制，即在每次加入元素或继承关系的时候就进行一次规范性检查的结果缓存，即对每个类都维护一个规范性判断变量。

 

二、四个单元的架构及OO方法的演进

　　第一单元

　　　第一单元的内容是多项式求导问题。由于是第一次接触java，思路还没有从面向过程往面向对象转变过来。这导致在写代码的时候容易出现一

　　 main到底的情况，同时也十分不利于迭代开发，这也导致了我基本每次作业都需要重构一遍，浪费了很多的时间。

　　　 本单元在架构上并不复杂，主要用到的就是求导接口的实现，让我们初步熟悉了接口的方便性以及便于管理的特点。总的来讲不存在架构上的

　　 难点。最为麻烦的地方反而是WF的判断，其次是各种正则表达式的了解与使用。

　　第二单元

　　　 第二单元的内容则是多线程电梯问题，可以采用普通的生产者消费者模式。至于整体的架构，一般是将一个电梯作为一个线程，可以采用电梯

　　 自行进行乘客运输，也即调度与策略分开；亦可以通过调度器线程统一安排每一部电梯的载人策略。我采用的是前者，使用dispatcher类调度器

　　 负责请求的处理与分配，即负责将每一个请求具体分配到某一部电梯；而Elevator类电梯负责行进的方向与决策，即电梯内维护一个请求队列（

　　 seek类），通过请求队列，由电梯自行决定上楼或是下楼或是停下或是开关门。而至于比较麻烦的换乘问题，我则是交由dispatcher类进行处理，

　　 即在接收到请求的时候就决定好是否换乘，如何换乘；如果需要换乘，则将该请求拆分成两个请求投入。通过这样的架构，将调度与策略分开，

　　 我对于算法的优化就变得十分方便，可以自由地切换各种不同的电梯运载策略，scan、look等，也可以将我自行设计的优化算法与已知的算法进

　　 行比较，择优使用，因此本单元我的性能分拿得比较高，基本近乎满分。

　　第三单元

　　　 第三单元是JML，整个单元并没有在架构上涉及许多内容，基本上是根据JML对函数的描述在写。只要理解好JML的函数需求补全函数即可而本

　　 次单元考察的重点也同样没有放在架构或是JML上，而是主要在考察有关于上学期图论的算法。至于架构，区别仅仅在于构建网络的时候，存储使

　　 用到的是HashSet还是ArrayList，后者会严重影响查询性能，甚至导致TLE。综上来讲，我并不认为JML这个单元很好地进行了面向对象的训练，

　　 只是简单地对上学期的内容进行了重复，且与JML并没有太多的关联。

 

　　第三单元

 

　　　 第四单元考察的是UML，这个单元十分注重架构，一个好的架构可以使我们的查询变得更加简单。同上一个单元差不多，只需要我们补全关键的

　　 部分即可。而至于架构上的设计，许多人采用的是建立图的方法，而我采取的是顶层元素包含下层元素的方法，即，将UmlClass、UmlInterface、

　　 UmlStateMaachine、UmlInteraction这样的顶级元素新建一个类，将其对应的下层元素存储在他们的attribute中，至于顶级元素之间的关联关系，

　　 我则也是全部记录在他们对应的attribute之中，即一个顶级类中不仅记录了它的子类，还记录了它的父类和同级关联类，这样以来，我们就完全可以

　　 将查询任务全部下放给顶级元素，而不需要在交互界面编写复杂的逻辑。这样的架构，我认为可扩展性很好，以此次为例，在从第二次作业扩展到第

　　 三次作业的时候，我基本上直接使用顶级元素内已有的信息就能完成顶级元素的格式检查，甚至不需要增加新的属性记录信息。

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

　　第一单元

　　　 写第一单元的时候刚接触java，对于其它的语言也没有很好的理解，所用的测试数据基本上都是手搓，即自己根据边界条件构造特殊数据，例如0

　　 之类的，抑或是在不同的地方加上括号，加上多重括号等等。整体上来讲，这样的测试方法，不及自动生成数据并自动测试的覆盖面广，但是能够考

　　  虑到特殊的边界数据。而自动化生成并测试，则是容易找出WF等格式解析的错误。因此，这两种测试手段相结合，才能够很好地覆盖到每一个可能

　　  出错的地方。

　　  第二单元

　　　　第二单主要涉及的是多线程，而出现的bug也基本都是很难复现的多线程bug，采用自动化随机生成数据的话很难找到问题，特别是时序的bug很

　　   难被随机数据覆盖到，所以我仍旧使用的是手动构造数据，并且在初始状态一次性大量投放，这样能够更好地考察各个线程在应对大量数据时的处

　　　理情况和线程的安全性。

　　  第三单元

　　　　由于是补充函数，第三单元我采用的是JUNIT进行局部化测试，然而JUNIT的测试强度极低，根本测不出bug，加之本单元的中测也根本没有半点

　　　参考价值，以致于我在进行测试后交错了代码版本都没能测出来，中测数据点仍旧全对，最后第一次JML作业强测爆炸。

　　  第四单元

　　　　第四单元是UML相关的问题，所以我采取的方式是在starUML中自行画图，然后用相应工具进行导出来进行测试的的。在构造和分析测试数据的

　　   时候就要求我们需要对每一个函数功能进行理解。本单元的测试相对简单。

四、课程收获

　　　通过一个学期的OO课程学习，我已经基本掌握了面向对象的编程思维，也熟悉了JAVA语言的各种语法规则以及多线程任务的编写，而最重要的

　　还是编写代码时要遵循的原则，例如SOLID原则等。还有JAVA的一些代码风格规范，只有遵循这些JAVA开发规范，才能在将来的团队式开发中，不

　　至于让别人读不懂你的代码，也不容易在迭代开发的过程中，改着改着改出奇怪的错误。其次是我的编程能力，这个东西嘛，纯粹靠多写多总结，在

　　编程中发现自己容易出错的地方，并给自己加以警醒。最后是自学能力的提高，这学期的OO要想完成得好，光靠课上讲授的知识还是不够的，我们还

　　需要在课外自行查找一些资料进行学习，这对我的自学能力有不小的提高。

五、具体改进建议

　　1.第三单元JML感觉主要是在考察算法，而不是JML的理解，与对应的课内知识有些脱轨。

　　2.第三单元的中测实在是太弱了，虽然不推荐将平台当成测评机，但是就连交错代码版本都能中测全对强测爆零这种事情还是太扯了一点。

　　3.OO平台上的指导书有时会和github上的有区别，例如数据限制等。。。

六、线上学习体会

　　　对于OO课程来说，我感觉线上学习与线下学习差别并不大，一是由于理论课内容与实际作业联系并不紧密，二是作业内容基本都是线上提交，

　　是线上还是线下授课区别并不大。唯一的不足之处，就是研讨课可能缺少了讨论了氛围，大家在线上讨论的时候都不是特别积极，线下可能会好一

　　些。不过对于老师和助教们来说，为了我们线上授课的良好体验，他们的工作不减反增，在此感谢课程组一学期的辛勤付出！