总体实现的类图如下
总体思路就是功能的分发，由一个总类把各个UmlElement视类型分发到类图处理类，顺序图处理类或状态图处理类。再由各处理类检查正确性，新建MyClass等结构，并进一步分发给各结构进一步处理。管理访问中由于需要从id到具体元素，故大量采用了Map结构。
为了省空间，各个MyClass等包装类没有继承UmlClass，而是选择了组合的方式，一个MyClass对应一个UmlClass（而且有的包装类并不需要原来的UmlElement，如MyParam中只用存各个参数的类型即可）。
各个包装类的设计思路也完全根据接口的方法需求来设计，比如需要接口中有查询消息数的方法，MyLifeline中便可以只用Map<MessageSort, Integer>来计数。
| 单元 | 架构设计 | 主要OO方法 |
|---|---|---|
| 一 | 输入解析部分用一个解析类处理构建。 具体化简求导部分采用接口抽象和组合结构，各个实现类分别实现相应方法。 |
用接口抽象每个项，充分利用多态性，建立抽象层次，工厂模式。 |
| 二 | 多线程采用生产者消费者模式。 总体结构采用组合的方式，分派器管理调度器，调度器管理电梯。 电梯采用简单的自动运行方法，指令顺序由调度器决定，指令由分派器决定。 |
层次化，状态模式。 |
| 三 | 总体结构采用组合的方式。 | 层次化 |
| 四 | 完全依赖需求的组合方式设计，逐步分解分发接口方法。 | 层次化 |
总的来看对OO方法的理解演进主要是在第一单元，而后的几个单元最多是对层次化的应用，并没有采用其他的一些模式。第二单元中简单了解了一个状态模式，但由于电梯状态不多，比较简单，也没有实际使用。多态性的应用也只有第一单元有所使用，之后的几个单元出于性能考虑都是按照需求来进行的架构设计，扩展性较差。
| 单元 | 测试理解 | 测试实践 |
|---|---|---|
| 一 | 知道了要构造边界数据测试，覆盖样例的所有情况，和随机生成器生成大量样例测试；增加新功能后需要保证原来的测试也能通过 | 边界测试，特殊数据测试；表达式随机生成器大量测试；回归测试 |
| 二 | 学习了多线程测试，测试中增加了各线程所占的CPU时间考察这一项，即需要测试有无轮询 | 手动构造样例测试；回归测试 |
| 三 | 认识到规格对单元测试的和样例覆盖情况的指导作用，知道了根据规格进行的形式推理验证正确性 | 分析规格中的null等条件手动推理验证；基于规格的覆盖性单元测试 |
| 四 | 无 | 手动构造样例测试；单元测试 |
总的来说最具有价值的还是规格指导的单元测试，因为程序规模大起来之后，有很多功能其实可以看成是独立出来的，而写的时候又容易不注意null等，而单元测试和规格可以很好的解决这一问题，快速排查有问题的方法等。生成器的覆盖由于时间并不充分，故只有第一单元有实践，后几单元的生成器都比较难写，而且验证起来也难，只能对拍或是找网上已经验证过的验证器。
原文：https://www.cnblogs.com/kylekirsten/p/14926419.html