OO第四单元总结

OO unit4

part1 总结本单元作业的架构设计

本单元的任务框架是读入一系列建立UML模型的指令，然后再进行一些静态查询，问题大致可以氛分为建模和查询两个部分（第三次作业的模型有效性检查也是一种静态查询），比较独立。

建模部分

我并没有在MyImplementation中直接存储一些存储元素的容器，而是全部存入MyMap类，查询也通过调用该类来完成。在第一次作业中这个设计并没有显现出太多价值，但是这个设计非常有效的避免了我的代码在第二第三次作业的时候被checkstyle制裁。

读取各个uml元素建模的时候，因为元素是乱序输入的，并且有些种类的元素之间存在依存关系，所以我采取了三次遍历来建立模型。第一次作业读取类图元素，第二次作业读取顺序图和状态图元素，整个过程大同小异。读取顺序如下表

 build1build2build3
类图 UML_CLASS, UML_ASSOCIATION_END, UML_INTERFACE UML_ATTRIBUTE, UML_OPERATION, UML_ASSOCIATION, UML_GENERALIZATION, UML_INTERFACE_REALIZATION UML_PARAMETER
状态图 UML_STATE_MACHINE, UML_REGION UML_REGION, UML_STATE, UML_PSEUDOSTATE, UML_FINAL_STATE, UML_EVENT UML_OPAQUE_BEHAVIOR, UML_TRANSITION UML_EVENT, UML_OPAQUE_BEHAVIOR, UML_TRANSITION
顺序图 UML_COLLABORATION, UML_INTERACTION UML_INTERACTION, UML_ENDPOINT, UML_LIFELINE UML_MESSAGE, UML_ENDPOINT, UML_LIFELINE

读入次序更多参考了UML图本身的结构，实际实现时进行了微调

 

 

 

第一次循环读入时的元素大都是UML图结构中比较顶层的元素，比较独立；后面的元素更加依赖前面读入的元素，这样便于在前面读入的元素的结构中存储关系信息，便于后面查询。比如，像UMLGeneralization这种关联父类和子类的结构，自然是在UMLClass和UMLInterface全部读入之后再读入更为方便。

如果官方包中的类不方便实现后续需求(存储一些“冗杂信息”以供查询)(之所以说是冗杂信息是因为很多信息通过parentID/reference等等属性+循环都可以得到)，便自己写一些MyUmlXXXXXX类，将UmlXXXXX类作为一个元素，体现了封装的设计思想。

public class MyUmlClass {
    private final UmlClass originUmlClass;
    ......
    private MyUmlClass parentClass;
    private final HashMap<String, MyUmlClass> childClasses;
    private final HashMap<String, MyUmlInterface> interfaces;
    ......
    public MyUmlClass(UmlClass umlClass) {
        this.originUmlClass = umlClass;
        ......
    }
    
    public String getId() {
        return originUmlClass.getId();
    }
}

读入一类元素两次，则第二次是为了补充存储一些“冗杂信息”，比如第二遍读入UMLEvent就是将trigger和transition关联。

容器结构方面，基本采取HashMap<String, UmlXXXXX>或者HashMap<String, MyUmlXXXXX>的结构，key--ID便于唯一索引各个元素，value--实例便于调用。

查询部分

对静态结构进行查询的过程，每个函数相对独立，对数据结构和算法课程所学的知识有一定要求（？），我自己运用了一些dfs/递归套娃，只要弄清题意+多查查资料，实现起来不会有太大的问题。

 

part2 总结自己在四个单元中架构设计思维及OO方法理解的演进

第一单元

OO第一单元作业的主题是读入内容位表达式的字符串，然后进行表达式的解析与化简。表达式解析的重点在于对表达式结构进行建模，表达式化简的重点在于基于建模进行单变量表达式的括号展开与简单优化，体会到了层次化设计和面向对象的思想。

第二单元

三次作业的整体实现思路都是使用了生产者-消费者模型。标准输入不断读入请求，放入共享对象缓存 列，这是生产者；所有电梯取出并完成队列中的请求（完成的过程就是将乘客送往目的地的过程），这是消费者。 三次作业的整体架构，我都参考了第三次课上实验的生产者消费者的整体架构，通过isEnd信号来依次结 束输入进程、调度进程和清空了对应缓存队列的电梯进程，使用wait-Notify的方式进行编程。

学完第二单元最大的想法就是多线程和面向对象程序设计并不是独立的，一定不可以拆开来看，本来现实中的需求基本都是多线程的。

第三单元、第四单元

虽然第三四单元是比较简单的，但是我确实对我帮助更大的，也最大程度得将面向对象和层次化设计的思想具象化了出来。朴素的设计思想其实写代码的时候都有感觉，但是如何将抽象的东西落到实处，也是需要一些规范来限制。当工程规模增大，程序员脑海中再精美的架构设计，没有规范的限制，也无法真正实现。同时，根据小组作业的经验，没有JML和UML这样的工具，合作便会变成1+1<2的亏本买卖。

三四单元的架构是课程组提供的，经历了第一二单元自己做架构吸收这些简介清晰的架构变得很容易，越是容易越说明架构清晰水平高哈哈。好的架构规范并不是为了炫酷个人的编程技艺，而是一切实际项目的基础，总之学习完这两个单元我对技术行业的理论规范有了全新的认识，不再像以前一样对规范有一些偏见。

 

part3 总结自己在四个单元中测试理解与实践的演进

首先非常遗憾的是整个OO课程下来我还是没有自己动手搭建一个评测机。可能是畏难情绪作祟，也可能是因为写代码本身就让本菜鸡焦头烂额（不过不做测试的代码没有灵魂）。在研讨课上，很多大佬也分享了自己写评测机的经验，希望自己可以利用暑期的时间开展一些自学。

四个单元我主要采取的方式还是静态debug+手搓数据测试+与朋友对拍（比起计组时期直接使用讨论区的强的不行的数据可能还是有一些进步吧，哈哈。。。）。

  • 静态看代码debug在需求比较简单的时候还是很有效的，我会逼着自己一字一句地去扣指导书，一句一句地去看代码，几乎可以避免所有因为对理解题意不充分而来的错误，但是我自己对JAVA官方包的理解也不算很透彻，对JAVA很多底层实现也是一知半解，基于错误的知识推理、哪怕逻辑是正确的也没有办法保证正确。基于这种方法养成了一些好习惯，很少再写出来一些空指针错误的代码等等等等。

  • 手搓测试数据在我看来其实和静态看代码没有太多提高，有点像写JML，关键是要分清楚每种条件下程序的执行方式再加上一些边界条件的特判。

  • 与朋友对拍的过程也是交流的过程，对测试有很多的帮助，最直接的就是发现对方和自己的bug（写到这里突然觉得和测试没什么关系）

  • 值得一提的是三四单元我尝试使用了Junit，没有评测机搭配用起来还挺费劲的，但是深刻领悟了单元测试的重要性。单元测试，避免bug没办法定位的问题。保证每个部分的正确性也就保证了程序整体的正确性，这个思想与设计的层次化和封装思想也很有异曲同工之妙，这个思想对于从前只会使用一堆数据黑箱测试的我来说是降维打击。

  • 第四单元，使用了StarUml绘制图像，再转换为数据测试，算是半手动的尝试了基于实现功能而不是直接输出数据的测试

  • bug修复数据保留一周的课程设置，促使我养成了回归测试的习惯，毕竟在迭代开发的时候也许会牵一发而动全身，如果不做回归测试的话就不能确认基础功能的正确性

  • 养成了边写代码边写日志的习惯，便于后期测试

 

part4 总结自己的课程收获

我在做三四单元的时候翻了翻去年学数据结构时写的代码（实在有点惨不忍睹），甚至现在倒回去看第一单元的代码，也觉得结构乱七八糟，缺失一种整体结构的有序之感，这正说明了OO课对我的帮助十分巨大。

第一个收获自然还是写代码的能力。整个学期的作业量加起来怎么着也有5000行了，实践是一定会带来进步的（尤其是在菜鸡的起步阶段）

第二个收获是，OO课程的学习将大一程序设计和数据结构的内容融会贯通了。OO课并没有细致的讲解一门语言的语法，并没有分门别类地讲解每种经典算法可以解决哪些问题，但是之前学习的基础的知识融合进了OO作业的实现中，比如JML单元每周作业基本上都有图算法的实现，容器的选择的优劣自然也与数据结构基础有关，如何谋取性能分也需要实现时规划时间复杂度。做OO第一单元作业的时候其实我有小小抱怨一下，觉得课程设计揠苗助长，历经折磨结课后我才明白，考概念填空和一个萝卜一个坑的算法题，应该不会比查stackoverflow更令人印象深刻，有探索的过程才有进步。

第三个收获是，OO课程让我体验一把根据需求（指导书）实现项目（课设）的完整过程，当然也仅仅只是过程。跟助教询问指导书细节的过程，从写代码到测试的过程，写文档的过程......做出来的内容也许是幼稚的，但我觉得作业的实现过程是非常面向真实开发场景的，学习的过程比起以往的课程，痛苦感加倍，成就感也加倍了。

第四个收获是，OO课程让我明白了设计架构的重要性和设计规范的重要性（夸爆JML和UML单元！！！）（上中文网络搜JML和UML看到基本只有北航6系的学长学姐发的博客，这个时候感到很幸运）

第五个收获是，OO课程让我有了更多跟同学讨论、向大佬学习的机会。前者的讨论质量也比较玄学，但是大佬的分享是期期精品！！！互测单元可以看到别人的代码设计，非常值得学习！

第六个收获，荣文戈老师上课的时候分享了挺多在业界上班的趣闻，很有意思哈哈哈

 

part5 立足于自己的体会给课程提三个具体的改进建议

  1. OO第一单元的第一次作业在有pre的的前提下难度也是陡增的而不是平滑过渡的（至少对于我这个菜鸡而言），如果能降低一点第一次作业的难度或者改进一下pre的作业设置也许会更好。

  2. 个人觉得可以将UML、JML单元前置，多项式单元实践---UML，JML单元结合理论更深入理解层次化设计思想---电梯实践，这样的顺序会不会更好一点呢？并且这样的话电梯单元就是在操作系统上完进程部分之后，对并发的理解会更好。

  3. JML，UML单元可以减为两次作业，电梯单元第一、第二次作业降低难度的同时增加作业周数

  4. 博客周取消，将时间分配给前面的代码作业周

posted @ 2022-06-29 14:02  myyyyyy47  阅读(18)  评论(1)  编辑  收藏  举报