2019年北航OO第四次博客总结<完结撒花>

一、UML单元架构设计

1. 类图解析器架构设计

1.1 UML类图

这次作业的目标是要解析一个UML类图，首先为了解耦，我新建了一个类UmTree进行解析工作，而Interaction类仅仅作为实现接口的一个类。其次，通过观察输入发现，这单元作业的输入是乱序的json对象，如果不将这些数据其有效的组织起来，之后的查找将变得非常麻烦。因此，我们需要将其组织成有效的数据结构。

1.2 树形结构

经过思考后我发现，可以用一个树形结构来表示一系列的umlelement，对于一个类图，首先有很多类。每个类又有许多属性与方法，而每个方法又有参数和返回值的类型，这样就形成了一个树形结构。由于每个类需要存储属性，方法，所关联的类，所实现的接口，以及父类；每个接口需要存储父类；每个方法需要存储返回值和参数。因此，我重写了umlClass,umlInterface,和umlOperation类来满足我的查找需求。我们通过对json对象的解析来构建我们的树。当我们的树构建好后，一切也就迎刃而解了。

2. 类图，顺序图，状态图综合解析与检查

2.1 UML类图

这次作业增加了对UML类图规则的检查和状态图、顺序图的解析，因此我建了三个包分别存放与类图解析相关的类，与顺序图解析相关的类和与状态图解析相关的类，然后主类在src目录下，显得结构清晰明了，易于管理。另外，由于java中checkstyle的限制，我将上次作业的接口实现类作为我这次接口实现类的一个属性，可以有效的降低代码行数。

2.2 具体架构

对类图的查询与上次相同，而对于顺序图的查询，我构建了一个sequenceTree并重写了umlLifeLine类，因为需要存incoming的信息数量。而对于状态图，我构建了一个stateTree并重写了umlState类，存储了每一个类的直接后继，这样在我们查找某个状态的所有后继状态的时候，就可以直接用BFS将其遍历。而对于各种检查，也就变成了在图上DFS,BFS的各种操作，简化了问题。

二、架构设计与对OO方法理解的演进

1. 第一单元表达式求导

我们的第一单元作业是表达式求导，这也是与我们的寒假作业有所衔接的。这个时候对于OO完全处于懵懂的状态，第一次多项式作业只写了一个类，完全是面向过程的编码。逐渐第二次作业，第三次作业，加上了三角函数求导和嵌套之后发现再用原来的面向过程写法是完全无法完成作业的了。也就是在这两次作业中，我逐渐认识到了继承，接口，抽象类等等将面向对象思想运用到了作业中。第二次作业我用了一个derivative的求导接口，并让三角函数类，常数类，和幂函数类都实现这个接口，并且抽象一个底数类base，是三角函数、常数、和幂函数的父类，这样对上可以统一处理，对下可以通过子类细化，感觉是一个不错的架构。在当时的研讨课上，也渐渐明白了什么是工厂化方法，什么是抽象厂，对架构的设计帮助很大。

2. 第二单元多线程电梯

第二单元的重点在于如何编写多线程的程序并保证线程的安全。其中，如何划分线程，如何让线程之间公共访问的变量保证线程安全，是一个重点与难点。在这一单元，我明白了什么是线程，线程其实就是一个对象，它的模板类继承了Thread类或者实现了Runnable接口。和大部分同学不同的是，这一单元的第一次作业是我完成的最困难的一次作业，一开始不知道如何划分线程，划分后又不知道如何让其停止。后来我对架构为三线程架构，main线程+电梯线程+调度器线程。这里调度器线程仅仅负责开关门时的上下门，而电梯线程负责其他时刻电梯的运行，又因为在日常生活中电梯没有人需要运送了其实就可以停止运行了。参考这点后，我把电梯设置成了守护线程，使得所有线程得以平稳结束。在后两次作业中我基本上都沿用了第一次的架构。第三次作业三部电梯的架构和第一次的架构是一样的，这也让我感受到了面向对象的延展性和封装性。

3. 第三单元地铁线路

第三单元中我们从第一次的PathContainer到Graph再到最后的Railway，算是完整的体验了一次一个实际项目从理论层面上不断添加需求，不断细化，不断联系实际的过程。在这之中，架构设计就显得尤为重要。在这单元作业中，我们还认识到了时间复杂度对于编程开发来讲也是必须要考虑的因素之一，充分理解了java的各种容器的功能与使用场景。这一单元的主题JML，但实际上从我们编码的角度来看，设计的重点落在数据结构与算法上。既然关键在算法，那就要把与算法无关的一些繁琐的构建图的流程与算法实现剥离开。我专门创建了一个图的类用于实现各种算法，当存在多种需求时，只需要实例化三个图，传入不同的参数计算即可。

4. 第四单元UML解析

第四单元的UML解析在上面已经说得比较详细了，这里就不再多说了。主要思想是，针对不同的图有不同的类负责管理，管理不同图的类没有耦合关系。构建成树的形式后查找就变得轻松了许多。

三、对测试的理解与实战的演进

1. 对测试的理解

我觉得测试是开发中的重要一环，同学们可能很多人将来都会从事软件工程相关的行业，在开发一个软件的一个过程中，相当重要的一个阶段就是测试。没有很好测试的系统，就算架构再清晰，编码再优美，也没有办法投入使用。而且还可能会导致一些非常严重的问题的发生。对于我们的课程来说，测试不仅仅会让你有一个更好的分数，更重要的是培养我们测试的习惯，会使我们受益终身。

2. 测试实战

针对课程来讲，我们的测试包括自我测试和互测，这里主要说下互测。对于第一单元多项式求导：先自动生成测试样例，将同一组数据同时给同组所有人跑，跑完后将得出来的结果输入matlab中带入x=1.1，再将得到的结果比较即可；第二单元多线程电梯：首先使用python开启一个子进程，启动待测程序。然后，通过sleep完成定时输入，和第一步骤中开启的子进程通信，最后检测输出是否符合要求即可；第三单元和第四单元就是使用python随机生成指令进行对拍即可。

说完了上面这些测试，当然还有一种单元非常重要的单元测试，也就是junit4,通过一些asset语句来检测以方法为单位的错误，可以精准定位bug，非常实用。

四 、课程收获

1. java编程能力

当然首先的收获就是java编程的能力啦，当然这只是很不重要的一个能力了，从一个java小白到一个可以写2000行没有bug程序的另一个小白是一个很大的进步呢。

2. 多线程编程能力

实际生活中多线程几乎是必不可少的，掌握了写多线程程序的能力对我们之后帮助巨大。

3. 工具的使用

通过本学期的学习，我学会了使用各种工具来辅助我们的编程。比如checkstyle检查代码风格的工具，matrixReloaded查看代码复杂度的工具，还有类图生成，UML建模，线程监控工具等等，这些工具将会很好的帮助我们的编程。

4. 规范化的编程

之前写的程序都是完成任务得到正确的结论即可。通过这门课我才真切的意识到编程规范的重要性，从UML，到细化的JML，最后到编程时的checkstyle，一步步规范我们的代码。规范的代码在小组合作开发时必不可少。

五、对OO课程的建议

1. 第一单元降低作业难度，选择更能体现OO思想的作业

我们知道，OO课是一门让北航6系人都觉得很难很肝的课。原因就是因为它的难度很大，代码复杂度很高。第一单元的多项式求导我写的也是非常辛苦，但其实好多时间都花在解析输入，处理字符串，等等与OO没什么关系的地方了。我认为不应该为了追求难度而追求难度。比如上学期的计组课设，我是一个经常会因为考试紧张而发挥不好的人，好多次课上我明明已经很好的掌握了这部分的知识点但由于课上紧张失误导致下周还要做相同的project，导致感觉忙了一学期也没学到什么，这样其实并不比简单一些更有助于同学们的理解和学习。如果将第一单元的难度大幅降低，并选取一个特别明显的使用能体现面向对象思想的元素的主题，我觉得虽然难度降低了，但是同学们对OO思想的理解一定会好很多的。

2. checkstyle的改进

本学期课程组引进了checkstyle来对代码风格进行评价，但其实有很多弊端，很多时候同学们都是为了把程序写到60行以内无所不用其极，最后其实完全违背了老师和助教们让我们方法行数少的初衷，另外就像什么lamda表达式，stream的使用，表驱动编程等等，用这些来衡量才能真正的提高代码的质量。编程是一项艺术，期待老师和助教的智慧来解决这个问题。

3. 企业课

这学期来看企业课的位置比较尴尬，来的老师讲的东西和我们平时课上将的东西不太一样，感觉也许可以请一些老学长来讲？既学过OO课还有实战经验的那种，感觉会好一些。