总结本单元两次作业的架构设计
第一次：
第一次作业的整体架构如上，我用staruml工具画出来架构图的大概，一些细节的信息略去不表。
总体来说就是用一个factory创建和管理进入的element，给的element存在各种类名的区别，由此我用instanceof对其进行判断，然后对每个element封装一个class，这个class都继承共同的父类TreeNode，表示希望和staruml内部一样，将内容建成一棵树，每个TN都可见其父子，由此进行各种图操作。
ClassTn和InterfTn与其他不同，因为他们都可以被继承，也可以继承别人，也就是说它们需要有额外的父元表达继承关系，而且它们都可能是Gener的两端。ClassTn是最复杂的，因为其中要管理operation和attribute，还有关联对端，这需要借助类名以container结尾的一些类进行管理和查找。
对于连接型的elem，都是在所有elem都给完以后，再进行一趟遍历将其两端的元素进行对应操作，这是因为在初始时，有可能对端还没有给出。
第二次：
对于UML002的改进，其实就是将umlAssociateEnd看待为attribute(其实我也一直认为关联对端有名字的就应该当成那种ArrayList之类的容器所形成的属性)。这样就可以直接利用之前对attribute判重的container了，不过这里会出现查找属性时的不匹配，毕竟本来关联端不是属性，找到了就不对了，小问题。
对于UML008，需要增加一个GenerableContainer类，管理类和接口。主要使用tarjan算法判断连通分量，所有会有stack、dfn、low和ind。
对于UML009，也用GenerableContainer类进行判断，但是要求对GenerableTn接口，要有havDupInterf操作进行判断，而这个主要依据是接口继承集不相交，而且havDupInterf有传递性。在实现时，借助了之前接口继承表查询时的暂存和递归方法。
其他两个图各自有一个类继承至TreeNode，其下子类为图元，与之前做法相同。RegionTn直接交给上层StateMachintTn管理translation和state，起始和终止状态都继承了StateTn，而StateTn则管理了其可达状态，通过递归的方法进行可达状态查询。
顺序图主要给interactionTn管理和查询lifeline，而lifeline的role则是与类图的attributeTn进行关联。在所有元素录入后，将所有interactionTn的msgList进行遍历，以计算incomingMsg。
四个单元中架构设计及OO方法理解的演进
第一单元作业做得比较复杂，主要就是因为组合模式用得不好，中间函数的返回值都没有进行适当的封装，也没有层次，但是类还是分开了。
第二次作业主要时对运行时程序得理解，其实就是用生产者消费者的观念封装一些容器，然后整个变成一个流水线。优化的时候，该得到的数据都得到了，但是没有很好地算法来模拟，所以最后的得分不高，所以算法为王。
第三次作业是看uml写实现代码，感觉到了多人合作的时候接口的重要性。Uml其实没看的时候就明白大半了，看就只是看了关于换乘的某一处比较重要的地方，后来针对那里课程组还进行了修改。真正难在时间复杂度的控制，要求要暂存各种可能暂存的中间结果，这就告诉我们接口用一个类实现即可，剩下大部分都是支撑的类，用来提升效率。
第四次作业主要熟练运用了instanceof，然后就是学习如何简单架构一个实际存在的软件。这次是在没有uml的情况下，让我们自己摸索接口是怎么样的，这种情况首先看类名并封装主要类。还有一点就是类很多，层次很广，感觉有些地方是应该存在一各类但是还并不会体现其作用，这和实际很接近。
四个单元中测试理解与实践的演进
测试的演进其实很难说，前三单元都可以自己构造随机样例进行测试，然而到了第四单元基本上是看着看着冒出一个想法然后测一下，或者写着写着想到了某个可能情况就画个测试。
然而无论是随机产生还是脑补测试，都是不能完备进行测试的，所以我还是不能完全主动地去发现深层次的bug。
第一次作业我用随机递归的方法产生测试。第二次作业我用随机产生合法req做性能估计。第三次作业我用随机点产生path然后尽量随机产生需要dijk的请求以进行压力测试。第四次就是画图玄学测试了。但是，我没法生成对拍用的标准输出，然后我就发现我写的许多bug没有找到。
我测试的方式一直都没变，c++和bat批处理产生测试文件，然后java更改输入流到文件，其实也够用了，比竟有些时候测一个测试点就要蛮久的。
课程收获
说实话我觉得最大的收获就是熟悉了java语言和其多线程，第二就是学会画uml图，展示起来高大上。
面向对象的方法能够让人更加清晰地组织数据，比如可以将一个图片和其边缘检测算法封装到一起，把一个三维几合体和其透视投影算法放到一起，但是算法是回避不了的。当算法解决了，那么搭建oo代码就如同搭积木一般，想方设法拼成一个个小的然后再把小的拼成大的。
三个建议
建议一：可以抽出一个单元作业做个游戏什么的，代替那个地铁寻路。卡牌游戏加上一定的对抗说不定会比较有趣。
建议二：最后一个单元uml就可以让我们做简单的逆向工程问题，那些查询操作太杂乱了。
建议三：中测和弱测就不要隐藏测试点了，毕竟每次作业的广度比较大，例子又少，有些需求理解错了，不看测试就不知道。