Thus, the end begins.
Part 01 第四单元(UML)架构设计
第四单元两次作业均是对UML类图、顺序图、状态图的解析。第二次作业在第一次作业的基础上进行了扩展，主要是增加了对顺序图、状态图的解析以及解析之前的检查。
第一次作业中，考虑到接口和类在查询指令中的地位不平等，将其分开进行管理，这一点在第二次进行解析前检查时很不方便，因此建立了新的MyPreCheck类专门用于重复继承、循环继承规则的检查。
查看原图1
查看原图
第一次次作业的核心类分别MyUmlClassInteraction, 第二次的MyGeneralInteraction类继承了第一次的MyUmlClassInteraction。为了避免回溯或者类似编译使用的难以扩展的自顶向下式的语法分析，选择在构造方法中两次遍历UML类图解析解析之后的条目信息，逐条判断类型交给相应的类处理。
第二次作业中，为了实现针对状态图和顺序图的查询指令，使用MyStateMachine, MyInteraction类将其与之前实现的功能隔离，方便测试。针对循环继承，考虑有向图的强连通分量求解方法，使用Tarjan算法解决(UMLRule008)；针对重复继承，考虑到Java类之间的继承始终为树型结构，采用DFS遍历以继承、接口实现关系为有向边的图，寻找重复访问节点的方式处理(UMLRule009)。
Part 02 架构设计&OO方法理解演进
A 多项式求导
- Java oop课程的第一个系列项目，第一次作业几乎是按过程式编程的方式，只有一个Main类和一个静态类。后面随着需求的增加，每次都需要对架构进行大的调整。在进行求导结果优化时，本地测试发现多层遍历导致CPU时间过长，彼时由于功力尚浅，直接取消了优化模块。
对类、对象等的理解经历了从无到有的过程。过程略显挣扎但感觉入门还算容易。
B 电梯系列
- 开始尝试减少迭代时架构上的大规模变动，首次尝试Java多线程编程。关于多线程访问控制的理解来源于操作系统课程中关于PV操作以及数据库课程的理论部分，与实际编程的体验还是有蛮大的差距，在实操过程中出现过比如轮询等待或是进程没有正常结束等问题。
用惯了Synchronized之后就不太想用线程安全的容器，感觉还是错过了很多值得尝试的内容。
C JML系列(地铁系列)
- 私以为这个单元是整个系列里面最容易但也最不喜欢的，主要是由于Google和Baidu到的JML相关的工具包使用体验极差。甚至一度怀疑JML是个没人用只有理论价值的东西。
Anyway, 在这次作业中首次尝试了对算法(主要是Floyd)模块的封装，并深刻地体验了数组运算和自行构造的数据结构运算之间显著的速度差。整个单元的架构设计个人不是很满意，有一种为了扩展而扩展，把本来应该分开的数据或是操作放在同一个自行构造的类下面，虽然没有强测火葬场，但是在自行调试时遇到了很多困难。
D UML系列
- 第四单元的内容，Finally，对UML类图的解析过程中看了不少的类图样例，也在一定程度上体会到了一个好的架构对编码体验、维护体验的重要性。在类图、顺序图、状态图的一致性检查部分，体会到了在设计层面进行规范的重要性（而且比草稿纸上画好就开始写的方式要高效得多）
这一个单元的指导书给我带来了不少的困扰，一方面是因为我对UML的一些细节理解不够清楚，另一方面就是讨论区的帖子更新会带来一些变动，不过再也不用担心一处改动整体重构的灾难性事件了。
Part 03 关于测试
A 多项式求导
手动测试为主，设计边界测试点，逐个手动进行测试，确实起到了一定的效果（比如发现正则表达式爆栈的问题并进行了解决）
B 电梯系列
- 主要还是手动测试，但是增加了对运行时间、CPU使用情况的检查(使用JProfiler)
构造测试样例更加全面，不过肉眼识别结果正确性还是十分辛苦，觉得脚本测试还是十分必要的
C 地铁系列
- 使用JUnit进行测试，然后发现如果Junit测试样例构造不全面可能效果还不如手测
- 使用Python脚本生成测试样例和答案，与Java程序运行结果自动化比较，作为Junit测试的补充
算是从黑盒白盒两个方面进行了较为全面的测试
D UML系列
- 把规则理解错的情况下使用Junit会导致越改越错
手绘类图、顺序图、状态图构造测试样例时似乎没有考虑到很多边界情况
扫描二维码关注公众号，回复： 6570603 查看本文章
Part 04 课程收获
- 学会了基础的Java编程
了解了一点关于OO设计和测试的内容，但是感觉并没有把很多原则之类的应用到实际编程中去
Part 05 关于课程的建议
- 建议一：在理论课讲授设计原则等内容时，增加一些基于实验或作业中的项目具体代码的例子，比较符合原则、不符合原则的设计之间的区别，提供更多的使用范例，不然感觉学了跟没学差不多
- 建议二：没有互测的OO课是不完整的！少了很多挑bug改bug的乐趣。不过似乎高工后面改了培养方案之后就没有这个问题了。另外就是大三的同学没有研讨课机会这一点真的很难受啊，本来希望在课程中更多地积累实际开发的经验，但是只学大二课程本身内容就显得有点鸡肋。
- 建议三：关于讨论区与指导书的问题。建议建立一个统一的要求更新渠道，将指导书和认证回答、暖心帖、要求说明等相关更新放在其中，与讨论区分隔开，这样就不需要在讨论区中一篇一篇看帖子一条一条看回复来求证自己是否正确理解了指导书的要求。
- 建议四：关于需求增加，可以在单元开始时给出一个大致方向的说明，更方便最初设计成可扩展的模式，让前期可扩展架构设计有的放矢。