BUAA_OO第四单元UML图解析
BUAA_OO第四单元UML图解析
一、本单元的架构设计
第一次作业只需要解析类图，首先将元素按种类区分，然后自己设计了class，interface，operation，association类，class和interface是一级，内置operation，association还有官方的attribute，还要记录对端的associationEnd以便查找。
第二、三次作业中加入另外两种图，就将其他两种图以类似的方式，按照原UML图的结构进行解析存储，然后每类图设置一个总解析器进行解析。总接口只需要调用需要查找的图的相关方法即可查找，节省主函数的行数，主接口主要负责check去分担各类接口的代码量。
二、四个单元中架构设计及OO方法理解的演进
Unit1
第一单元从一开始只有两个类，十分面向过程，到最后每一种函数一个类，进行面向对象编程，我第一次尝试运用了面向对象的方法。第一单元的设计十分优秀，用三角函数、幂函数等一眼就可以理解区分的类教会我要如何去进行面向对象的编程。此外，递归求导的需求让我不得不采用面向对象的方法来处理。
最后的架构为先对表达式进行预处理，然后从多项式到项到因子层层拆分，其中多项式到项也可以看作为加法求导类，项到因子是乘法求导类。最后再把因子分为三角函数，多项式因子，幂函数进行递归求导。
Unit2
第二单元为多线程编程，有了上一单元的教训，我一开始就设计了调度器类，等待队列类，电梯类，楼层队列和主函数几个类。直到最后一次作业，我也没有加入其他的类，可见构架还是比较成功。美中不足的是单个电梯的调度器直接放在电梯内部了，导致电梯类的功能有点复杂。
这一单元的架构设计主要是方便多线程运行，主要是怎样设计架构可以使多线程运行顺利，没有冲突，且协调好各个线程。
Unit3
第三单元根据已有的接口和JML来完成，不需要自己设计的架构。对于侧重于不同功能的数组需要使用不同的容器，对于复杂的方法可以进行简单拆分，减少方法的长度和复杂度。
架构方面有Person，Group，Message，Network等类，Network为整个集合并与外界进行交互，Group为特定Person的集合，Person和Group内有Message互相传递。
Unit4
第四单元是UML解析器，接口也给定了一定的架构设计，我设计了类图、状态图、顺序图三种分别的解析器，然后写了自己的Class，Interface，Operation，State，StateMachine等类，用来实现虽然源代码本身具有但是功能欠缺的类，其他的类可以用源代码中的类直接实现。层次构架接近原UML中的类图。不同之处在于顺序图中生命线存储了Message，状态图中某个状态存储了后继状态等。
本单元作业虽然要求的是一些查询功能，但实际上还是需要我们自己去把UML元素一个个分出来，在代码中构建UML图，再在架构中进行查询运算。由于有些解析代码写的很复杂，如果不把重复方法提出来单独写很容易造成行数超标的结果。
三、在四个单元中测试理解和实践的演进
在检测bug方面，我一般会自己构造一些简单的覆盖多种情况的数据进行测试，但是常常有覆盖不全面的可能。
第二单元中在多线程调试时，学会通过查看多线程死锁在哪个地方来debug，解决了单步调试无法复现bug的问题。最后的单元中借用了同学的数据以及讨论中做错题的经验，检查自己是否有同样的问题来解决问题。剩下的靠分析自己的代码逻辑等找到问题。
四、课程收获
- 代码能力的提高：每周将近400行代码的写作量让我写作代码、理解代码的能力有大幅度提高。一开始看见大量代码的任务会有一些畏惧心理，觉得自己理不清这么多的代码，但是上手实操之后，一步步把代码写出来，也就能完成单元任务了。
- 代码风格的改进：一开始我是不太在意代码风格的，只要能成功运行就可以，但是oo课程组一直有代码风格的要求。后来我才理解如果类或方法的行数过长，会造成阅读困难。当一个方法结构复杂不能在规定行数内写完时，应该拆分为几个小方法，每个方法承担一部分功能，看起来也比较清晰。对于命名规则的要求也让其他人能一眼就看出这是类名、属性名或是其他。
- 面向对象思想的确立：拿到一份需求首先想的不再是如何用算法完成，而是会一个部件一个部件地摘出来，思考如何架构可以使思路清晰，便于使用，而不是想到哪写到哪。
- 测试的重要性：写完一遍自我感觉良好的代码居然有如此多的bug，不测不知道，一测吓一跳啊。
五、 三个具体的改进建议
- 第一单元的设计虽然好，但是第二次作业的难度会让很多人望而生畏，一上来就给出这么难的内容会让人害怕接下来的oo学习，虽然接下来的内容并没有那么难。
- 在上机测试结束后提供答案，可以方便同学纠错和清楚自己的问题。
- 在对于测试有重大影响的更新时，应该在课程群里通知，不然有些人可能没有注意到通知，造成重测等不必要的麻烦。
