OO第四单元作业分析——UML的存在本质真的是图吗？

一、UML单元总结

本单元的两次任务都是解析UML图文件，区别仅仅在于第一次只处理类图，而第二次则是捎上了流程图与状态图。第一次作业，居然时隔半年又一次只用了一个类（上一次应该是寒假作业的A+B......），但是个人认为架构上并没有偷懒。实际上仔细想来，第一次任务需要统计的量其实都需要若干个数据结构来为之服务，当然不同的量可能会公用某个数据结构（比如一个HashMap classid2name，key是类的名字，value是类的id，很多都会用到！），换言之，第一次任务不同的量之间的关系不大。所以，最终经过权衡，我采取的就是最直接暴力的方式：用一个类（作为方法类），在构造器里面进行解析，完成各个数据结构，查询的时候直接查询即可（复杂度都是O(1)）。

第一次作业的架构：

所以换言之，我们绝大多数工作都是在构造器里面完成的。具体而言，我们要先通过两次遍历所有UMLElement，类似流水线的工作模式。随后再走一遍dfs算法，来完善那些需要考虑父类的结构：

第二次作业我们一共有五个类：分别是总类以及处理pre-check，类图，状态图，流程图的四个分类。其中每一个类的工作模式都是和第一次作业类似的（相当于这次是四个“第一次作业”由一个总类统领起来）。具体来讲，就是总类先对传入的所有UMLElement进行分类筛选，将某类图的元素用一个HashSet<UMLElement>来存储（比如UmlAssociation，UmlAssociationEnd等等属于类图元素，Lifeline，Endpoint就属于顺序图元素），然后再把各自的HashSet传送给负责相应图处理的类即可。值得一提的是，类图和pre-check是有重复元素的，其实pre-check完全可以在类图中实现（只是我第一次因为全部集中到类图，导致那个类已经游走在500行的边缘实在不堪重负了......）。

总结一下本单元作业。个人认为本单元作业难度不大，但是对于一些关键必须要小心，仔细地对待，否则可能会写出自己都不想看的代码以及一堆堆的bug。其中至关重要的一点是，要对于层次逻辑具备清晰，准确的认识。比如如何找一个类相关联的类？就必须先找到AssociationEnd，它的parentid透露了它是属于哪个类，我们要找到该类所有的AssociationEnd。其次，就要找Association，这样才能知道AssociationEnd对应的对端是谁。第一次作业，我就是因为过于莽撞而屡次修改，耽误了许多功夫；所以第二次作业吸取教训，先画几个UML文件用工具包导出观察一下，对于每个性质都进行一番了解，这样接下来就能省去很多不必要的麻烦。除此之外，还有就是关于规则必须要理解正确，切勿主观臆断。UML作为一个成熟的体系是具备其基本的性质的。

 

二、作业总回顾上篇：架构设计与方法的演进

在求导单元，重点在于一个由面向过程到面向对象的转型。求导任务本身是可以拿C完成的，毫无疑问（只不过正则匹配可能会处理地麻烦一点），但是既然要学习面向对象模式，就应该想到面向对象有怎样的不同。我前两次的架构都是类似于流水线的模式，按照判断输入是否满足要求，简化合并项，计算结果并化简的流程，一个类负责一项任务。第三次作业的类稍多，还涉及递归，但是如果抛去细节，抽象来看的话，其实也是类似的思想。

电梯单元引入了多线程。因此我遵照的就是多线程最为经典的生产者-消费者模式，由Button，Scheduler，Elevatort三个类构成（名字起得有些与众不同，不要在意......好像管调度器叫做Dispatcher的人占大多数）。Button类是“生产者”负责接收输入请求，并将其交由Scheduler来存储，处理；Scheduler收到各种请求后，会维护一个队列（或多个，取决于调度需要），然后电梯是“消费者”，从Scheduler不断地取指令完成。对于多线程而言，并发可能引发的问题是一个非诚令人头疼的隐患，因为它们往往无法复现，难以使用常规断点进行调试，此外逻辑关系也比顺序执行的程序复杂很多，分析起来往往感到力不从心。因此在架构上尽量精简，使用自己有把握的锁或方法是个人比较倾向于的方法。

在JML单元，重点是在于理解，运用JML，因此本单元似乎在架构上并没有什么新颖之处。一定要说的话，就是在处理复杂图的问题时，可以运用对于不同的问题进行归纳统一，比如最短路径，最低票价，最小不满意度等等，看似不同实际上有类似的特点，都可以使用类似于Floyd算法的方式进行解决，只是权重计算略有不同。

UML单元上面已经说过，这里不再赘述。

三、作业总回顾下篇：测试理解与实践的演进

一，二单元采取白盒测试。其中第一次很是偷懒，基本上是自己脑补几个复杂的，空格较多的，人脑觉得比较恶心的走一遍没事就完事了。其实也不完全是草率行事，因为从客观需要的角度，第一次作业的确是基本上大体没有问题就问题不大，尽管如此，这显然不是一个非常推荐的态度。第二次电梯，经过第二次捎带电梯因为一个小bug而翻车的血的教训，我终于下定决心要正视测试了。

四、课程收获

五、课程改进建议

1，实验课时间：建议相关内容的实验至少放在理论课之后几天再进行。上午讲完全新的知识，下午就立即上机实在是太考验人的心理素质了......况且个人认为在缺乏复习过程的前提下，上机也是抓瞎胡做一气，不如踏踏实实地，等消化之后在进行巩固，效果肯定会更好！

2，理论课内容：理论课的讲授内容本身很棒！本学期收益也是颇丰。但是现在理论课上只讲设计层面甚至是哲学层面的概念，不仅和作业基本脱节，而且缺乏了实践的支持导致理解起来也存在一定的难度。因此希望理论课也能够增加一些更加基础，更加接地气的内容，比如Java语言相关的知识，多贴出一些代码样例来供大家学习，这样也方便上手，更快地掌握。基础内容比例不需要太多（5%就可以，不会占用太多时间）。

3，作业难度。本学期作业难度其实把握得很好！每个单元都是递增，每次作业都是既有一定挑战性，需要投入相当多的精力，同时又没有到难以企及的地步。但是，美中不足的是第一次作业，一上来就这样子实在是太难了！强烈建议可以有个缓冲（事实上，个人感觉求导第一次作业比电梯，UML等单元的第一次作业难得多）。

转载于:https://www.cnblogs.com/ZHONG-YU-1999/p/11073391.html