实现UML类图解析器，要求:
(1) 可以通过输入各种指令来进行UML类图有关信息的查询。
(2) 支持对UML顺序图和UML状态图的解析，并能够支持几个基本规则的验证。
二、思路分析
1、基于度量的程序结构分析
代码行数统计（利用Statistic插件）
第一次
第二次
代码设计复杂度（利用MetricsReloaded插件）
ev(G)基本复杂度，用来衡量程序非结构化程度
iv(G)模块设计复杂度，用来衡量模块判定结构
v(G)独立路径条数
第一次
第二次
2、BUG分析
这两次作业的弱中测和强测都顺利通过，但没少经历坎坷，第一次作业在南昌的火车上和宾馆里肝了三个夜晚，最后一天晚上9:50才提交了修改完致命bug的版本。而第二次作业用一天写完，却在马原考试前的晚上12:00发现了bug。
除对拍的方法外，这次作业用JUnit单元测试来进行正确性验证也十分合适。
第一次：
强测中得分 100
对拍中发现的问题：建图时要注意读入处理顺序。因为attribute隶属于class，parameter隶属于operation，所以一定要先把底层的指令预先读入。
第二次：
在强测中得分 100
对拍中发现的问题：
-
tarjan算法dfs时class与interface的属性数组用混了。
-
tarjan算法没有考虑自环情况（R002）。
-
R001没有考虑自己继承自己的情况。
-
命令行参数的使用
3、架构分析
第一次：
第二次：
-
第一次作业要读懂需求，主要是每个元素的id唯一，而name可重复，故用两个hashmap来维护类：
private HashMap<String, MyClass> clist;//id-->class private HashMap<String, MyClass> cnList;//name-->class
所以在处理异常的代码段如下：
private MyClass checkClassException(String className) throws ClassNotFoundException, ClassDuplicatedException { if (!cnList.containsKey(className)) { throw new ClassNotFoundException(className); } if (cnList.get(className) == null) { throw new ClassDuplicatedException(className); } MyClass cls = cnList.get(className); return cls; } /* MyClass cls = new MyClass(e.getName(), e.getId()); clist.put(e.getId(), cls); //在dup时加入null: if (cnList.containsKey(e.getName())) { cnList.put(e.getName(), null); } else { cnList.put(e.getName(), cls); } */
第二次作业同理。我复用了第一次作业的代码，并且用package建立了一个更为清晰的结构:
↓
-
关于类与接口间的行为有一定的相似性，可以建立一个抽象基类来提取出相同的部分统一处理，避免重复编码。
两者不同之处在于对继承关系的处理方面，类只能单继承，而接口支持多继承：可以将继承关系和实现关系抽象成有向边，转化为树/图模型。然后无非就是建树（建图），递归找父节点（前驱结点）的工作。
-
状态图和顺序图的两个主要元素可以抽象成点和边，这样查询任务和合法性检查任务就迎刃而解。
我用了最熟悉的Floyd处理连通性问题，tarjan算法求强连通分量（找环）。
三、四个单元的总结与反思
1、架构设计及OO方法理解的演进
第一单元 多项式求导 面向对象架构
让我深刻地了解了面向对象来架构程序的思想，给了当时的我很大的冲击。再加上当时对java语言的运用还很吃力。现在还能想起来当时荣老师在课上对继承和接口的讲解给我的那种醍醐灌顶的感觉。
通过了解编译原理中的递归下降算法，更好地分析出了多项式的结构层次。
也是我第一次了解了设计架构、测试优先的重要性。
在具体的实现过程中运用了工厂模式。
第二单元 电梯调度 多线程
多线程作为一个”新世界“，编写代码的思路和debug的方法相较以往都有很大变化。
而多线程的设计模式是帮助我更好更快地上手编写多线程程序并保证逻辑正确性的必要工具。
同时我也对线程安全的容器有了一定的了解。
其次，决定这次作业得分的还有调度算法的取舍。怎么保证在普遍的情况下(≈数据随机)获得更好的执行效率，是很实际的问题。有趣的是，电梯调度算法的来源竟然是操作系统的磁盘读取算法LOOK和SCAN（os乱入片场
第三单元 地铁线路 规格化与单元测试
第四单元 UML解析器 UML
这两个单元画风比较相近，对面向对象的架构要求不高，而重在帮助我们熟练掌握JML规格和UML图这两大工具。
编写实际场景下运用的程序比单纯地写规格和画图，对我加深理解的帮助更大。
第三单元难点在于实际场景下的算法模型建立，而第四单元则延续了对图和树这两大重要结构的考察，弥补了大一程设和DS虎头蛇尾欠下的“图论债”。
同时，在为了满足性能要求需要大量使用、合理选择java容器。通过用java容器来高效实现c语言中的图论算法，我对java编程的熟练程度也增加了。
2、测试理解与实践的演进
在强测中wa了两次，分别是第一单元第3次作业和第二单元第3次作业，心里有点难受，自己本可以做得再好一点的。
这次的对拍任务很容易借助python的算术功能来完成，我通过构造易错数据、编写对拍程序来进行了简单的对拍，但没有进行细粒度和大批量的测试。
第二单元 电梯调度 多线程
开始完善自己的评测机。但架构和编码时间有点长，直到最后一天晚上才进行性能测试，导致时间不够优化算法。而且最终还是在处理换乘问题上出现了纰漏，反映出自己的数据生成器还是不够强，粒度也不够细。并且缺少静态差错的环节。
第三单元 地铁线路
直到我在第三单元中学习了单元测试的方法，前两次对于测试的困惑终于得到了一个解决方案！
尝试编写了单元测试程序，同时也利用自己的评测机进行了对拍。
第四单元 UML解析器
经过一个学期与bug抗争的过程，我认为一个完整的测试过程应该是这样的：
①coding前构造一般数据与极端数据，力图所有情况后再选择算法和架构
②coding时，一个功能模块编写完成后进行单元测试，通过后再进行下一个模块的coding
③coding后进行静态差错，确保代码实现与思路一致，结合小黄鸭调试法食用味道更佳（
④用coding前构造的数据进行简单的正确性验证
⑤编写数据生成器，进行对拍验证，本地测试程序的运行效率与在“大“数据下的执行效果（可以按照功能分批进行测试）
四、课程收获/致谢
1、oo这门课让我了解了面向对象的思想，以及初步感受到工程项目与以往所编写的程序的不同。
从最开始的每次重构、看到代码量大的项目根本无从下手、谈”虫“色变不知从何处de起，到掌握了一定的java语言基础、设计模式、测试方法，懂得算法如何运用到实际场景中，也学会了简单的脚本的编写。
课程组对checkstyle的重视，也让我养成了良好的代码风格习惯。
大家在讨论区中的发言，无论是解决问题的思路，还是一些黑科技，也都给了我很大的启发。
2、同时也更深刻地意识到了自己还有很长的路要走。zsa说”穷则思变，而不是穷则思易”。这句话我发自心底地赞同。对于每一次作业，强测只是规定了能力达标的“下限”，而想要写好代码，其“上限”是无止境的。
3、感谢老师和助教的辛苦付出。指导书等有纰漏在所难免，课程组对待问题的态度让同学们很信任和安心。同学们对课程的重视和认真也来源于课程组的重视和负责。
4、一些碎碎念：
现在耳机里播放着哥哥的《怪你过分美丽》《追》，突然有点想流泪。oo填充了我这个学期一半以上的生活，开学时看到每周时间线望而生畏的我，现在突然觉得很感激，若是没有这样的课程压力逼着小伙伴们写代码debug极限互测，就算会逃避掉很多的痛苦，快乐亦会不复存在吧。
cmx说，coding大概和写文字有些相似，都是需要“工巧心”的事情。
想明白了这点，无论面前的代码再如何的支离破碎与混乱不堪，也不会以受难者的心态对待了。
"一想起你如此精细 其他的一切 没一种矜贵 "
反倒会觉得，任何自己没有打磨好的代码，都会愧对了这份情愫吧。
-
-
实验课内容很好，可以帮我们巩固课堂上老师教授的理论知识。但是实验课结束之后得不到结果反馈，考察的题目依旧不懂，甚至实验结束后无法看到题面和知识点总结，无法有效地学习巩固。
-
我认为每个人完成的作业代码可以开源，这样能够扩大同学间交流学习的范围，同时这种自发性的交流分享能够让助教筛选优秀作业的工作轻松很多。多阅读别人代码，能够提升自己的代码能力；而在网络上又很难找到和oo作业所需内容契合的代码，导致同学们在没有面向对象基础的情况下只能YY，结果就是交上去的代码写得很丑而不自知。至于是在什么时间读、以何种方式读（是大脑空白借鉴别人的思路，还是在完成自己的代码后学习别人的实现方法，抑或是给别人找bug），由同学们自己来决定，只要恪守不抄袭的原则即可。
如果出现抄袭行为，对于相似代码是谁抄袭的评判，可以通过上传的时间先后来判断。
-
老师们可以了解一下每次作业的内容。课件应该是老师做的，而指导书应该是助教们写的。课件中的内容和作业内容虽然大体相似，但无法真正衔接上。同学们在完成作业时无法运用课堂上收获的知识，老师解答同学的问题时也只能给出大体思路。如果能针对同学在本次过程中遇到的具体问题给出具体的解决方案，或许可以达到“窥一斑而见全豹”的效果。