1. 本单元作业架构设计
这个单位的主题的UML，相应的，作业内容是实现相应的UML解析器，个人认为，这两次作业的难点有如下：
- 对于每个概念的理解，特别是概念和UML元素之间的对应
- 数据的组织方式
- 搜索算法
1.1 第一次作业设计
第一次完成的是类图的解析器，拆开来看，其实就是一个十分复杂网络，类、接口、属性、方法之间连成的网络
同时，有继承网和关联网，这两个网络的组成元素不同，所以也要分开建模
再有一个十分重要的点，就是名字，是的，名字，我们需要一个方便的转换中心，专门处理好名字、ID、Element之间的转换问题，这个是十分重要的
基于分析每种元素和其他元素之间的关系，我给出了下面的几个类
├── app
│ ├── ElementFactory.java
│ ├── Main.java
│ └── MyUmlInteraction.java
├── graph
│ ├── AssGraph.java
│ └── GenGraph.java
└── info
├── CastInfoCenter.java
├── ClassInfoCenter.java
└── OpInfoCenter.java其中，数据和逻辑分开，管理起来十分方便
info中的ClassInfoCenter和OpInfoCenter，记录了相应元素相关的数据信息
而CastInfoCenter则记录了一些转换信息，具体包括id2Element, name2Elements等
而graph中包含了两个图，也就是上面说到的继承图和关系图，通过这两个图，可以获知整个继承关系和关联关系
app中即为逻辑层，里面通过利用上面说到的数据来实现相应的逻辑
特别值得一提的是ElementFactory，因为我们的元素类型很多，一个元素影响的数据也很多，所以有一个单独的工厂用于建模
下面是生成的UML类图
1.2 第二次作业设计
第二次相比于第一次，加了对状态图和时序图的解析支持以及UML规则合法性的检查
不难看出，这几个功能都是分立的，我们可以分别实现几个解析器，然后用组合关系将他们组建成最终的产品
下面是我的工程结构
├── app
│ ├── FactoryDispatcher.java
│ ├── Main.java
│ └── MyUmlGeneralInteraction.java
├── module
│ ├── classmodule
│ │ ├── ClassElementFactory.java
│ │ ├── MyClassInteraction.java
│ │ ├── graph
│ │ │ ├── AssGraph.java
│ │ │ └── GenGraph.java
│ │ └── info
│ │ ├── CastInfoCenter.java
│ │ ├── ClassInfoCenter.java
│ │ └── OpInfoCenter.java
│ ├── statemodule
│ │ ├── MyStateInteraction.java
│ │ ├── StateElementFactory.java
│ │ ├── graph
│ │ │ └── StateGraph.java
│ │ └── info
│ │ ├── CastInfoCenter.java
│ │ └── StateInfoCenter.java
│ └── timemodule
│ ├── MyTimeInteraction.java
│ ├── TimeElementFactory.java
│ ├── graph
│ │ └── TimeGraph.java
│ └── info
│ ├── CastInfoCenter.java
│ └── TimeInfoCenter.java
└── precheck
└── StandardChecker.java可以看到，我还是延续了之前的架构，在module（好像拼错了，将错就错吧）包下面，是三个解析器的模型，因为本次作业，三个解析器之间的交集很少(没有涉及到检查类是否定义等一致性问题)，所以这里是分开建模的，如果考虑检查一致性等问题的话，我可能会将数据层单独分包
可以看到，每个解析器包的结构基本一致，都是数据模型、数据存储器、逻辑层这三个部分组成
这里没太多可说的，重点还是想讲一下我的Factory
这回的Factory有了进一步的升级，不同于之前的一层结构，这次有了两层的结构
其中FactoryDispatcher实现了将任务分发给三个解析器的工厂，从而实现一个解耦的建模
至于其他的逻辑就很简单，下面给出生成的UML
2. 四个单元中架构设计及OO方法理解的演进
首先，最明显的一点就是对于一些惯用技巧的使用比较娴熟了，比如工厂模式等，用的比较自然
其实说架构设计的演进或者说OO方法的理解，我觉得这几个单元倒是没有必然的先后顺序，就好像我现在看第一单元的作业感觉还是很复杂
要我说，我更觉得不同单元上我学到的OO设计的不同纬度，第一单元的检查和优化，我对于单一职责原则，解耦，以及继承多态、接口用法等有了全新的认识
到第二单元，面对多线程，又是另外一套OO方法，就好像我们在学习多线程编程，不可能一直在思考怎么继承，显然更多思考的是线程安全和调度的问题
到第三单元，我最喜欢第三单元，我觉得第三单元带来的高度代码复用设计给人一种赏心悦目的感觉，从中也可以感觉到，自己两个单元下来，积累的OO经验已经有所体现
到现在这次作业完成，我觉得，最大的变化就是，给一个任务，现在可以有条不紊地分析数据应该怎么组织，逻辑应该怎么分配，哪里谁做什么，能够有一个宏观的把握，而不是东一榔头西一棒槌地瞎写
3. 在四个单元中测试理解与实践的演进
实话说，从第一单元我就开始用Junit了，但是用的方式一直不是很对，对于极限编程中提倡的先写测试后写代码的理解也不是很深，现在多多少少是有些理解了
说起个人对测试的理解，我觉得一个优秀的测试工程师绝不比一个有效的架构师身份要低，测试和架构一样，都是很吃经验的工作，我们用Junit等测试框架做单元测试，然后跑一下覆盖了，我相信很多人的单元测试的覆盖率都达到了99+，但是我也相信，这些人并不都是次次测试满分，为什么，这就说道了覆盖率的骗局，并非全覆盖就是没问题，因为一个软件的分支实在太多，所以不可能实现全覆盖，所谓的全覆盖就只是都跑了一下而已
这就回到软件测试工程师的话题上了，一个优秀的测试人员，能够把握哪里容易出错，哪里是重灾区，优先测哪里，重点测哪里，这不仅仅需要技巧，更需要经验。
对于我个人做测试，有的时候是测试驱动，但是测试驱动不写代码就写测试带来的编辑器一片红橙有时候实在让人受不了，所以总体来说还是补测试的情况多，一般写测试的时候，往往针对逻辑分支，边界条件，临界情况做测试
重点是要直面内心的障碍，举个例子，常常会有，一个工厂里面很多函数，总有那么几个你是觉得很难写、不愿写、不想写、不敢写、写了不敢跑、不忍直视的，之所以有这种情况，一般两个原因，需求没有烂熟于心、对自己的设计或算法没把握。对于这部分代码，一定要大力测，一方面是增强信心，另一方面这些代码可能是问题重灾区。
4. 课程收获
课程收获嘛，我觉得最大的收获就是编码量不错。
不得不说，作为软件行业，编码量是很重要的，我们提倡方法学，但是不动手一切都是纸上谈兵，就我所看到的和了解到的，咱们OO课程的编码量还算是足够的。只有一直写，实践学到的东西，才能保持进步，这点感受很深，因为最后一次作业和倒数第二次之间隔得时间比较久，中间也没咋写大型代码，结果最后一次作业放出来的时候，有一种强烈的恐惧和抗拒感，就感觉有点陌生了，所以一定要保持状态。
说完作业说理论课和讨论课，通过课程，比较整体的认识了OO的全貌，通过老师的引导，也是极大地有利于课下的深入学习，其实我觉得，课上的重点不在于学会多少，而在于通过课上的时间，有知道了多少新东西，我个人认为0到1要比1到100更难，课上就是给了0到1的机会，给了深入学习的方向和建议，讨论课同理，大家相互分享，实话说，真的学到了很多，尤其后期分享的内容越来越广，包括并行计算、机器人等，极大拓宽了视野，视野是最重要的。
5. 改进建议
这里随便说说，不分条了，也不弄得那么正式，一点拙见
首先，个人觉得编码量可以再大一些，实话说，现在的作业规格还不足以把C玩家逼上绝路(我亲爱的舍友用500行C莽掉了第三次作业)，也让很多架构型玩家觉得发挥空间有限
其次就是作业形式，个人觉得不必死在OI上，诚然，助教们都很辛苦，软工很忙，不用评测机让助教大大目力给分也不现实，但是我觉得也是可以有一些可以让大家自由发挥，神仙打架的机会的，类似中期大作业或者期末大作业的形式，让同学们组队或者个人完成，充分检验和实践一个学期的学习成果，这个我觉得还是很有意义的
最后，个人觉得设计模式这个学期说要讲，但是好像还是有点半途而废的感觉，好像到后期又不怎么提了，倒是不必为讲设计模式而说设计模式，但是个人觉得可以将设计模式的相关内容穿插在作业布置中和总结课中会不会更好，给大家一些设计建议，然后让大家在做作业的时候去切身感受，这样的效果会不会比让大家全部都摸着石头过河要好一些
以上是个人的一点拙见，也是仅供参考，望有所帮助
一个学期的OO结束了，实话说，有点不很过瘾，学到了很多，经历了很多挑战，也付出很多心血，但是至少有了收获的饱腹感，也是蛮值得的了
艺术，值得为之痛哭