BUAA-OO 第四单元做业 UML 总结与思考 & 结课学期总结

写在前面

OO结课散花~

蟹蟹这一个学期来并肩奋战的小伙伴们~

艺雯，毅飞，郑奕，xg，雨桐，小丁，花花，xsy，zyy，wsb，zwc，dyh，lmz，qzz学长等等等等~

蟹蟹你们给个人帮助~(｡･ω･｡)ﾉ♡

目录

1、第四单元做业需求分析

2、第四单元做业思路分析

一、基于度量的程序结构分析

二、BUG分析

三、架构分析

3、前四单元总结

一、架构设计及OO方法理解的演进

二、测试理解与实践的演进

4、收获与致谢

5、一点建议

1、需求分析

实现UML类图解析器，要求:

(1) 能够经过输入各类指令来进行UML类图有关信息的查询。

(2) 支持对UML顺序图和UML状态图的解析，并可以支持几个基本规则的验证。

2、思路分析

一、基于度量的程序结构分析

代码行数统计（利用Statistic插件）

第一次

第二次

 

代码设计复杂度（利用MetricsReloaded插件）

ev(G)基本复杂度，用来衡量程序非结构化程度

iv(G)模块设计复杂度，用来衡量模块断定结构

v(G)独立路径条数

第一次

第二次

 

二、BUG分析

这两次做业的弱中测和强测都顺利经过，但没少经历坎坷，第一次做业在南昌的火车上和宾馆里肝了三个夜晚，最后一天晚上9:50才提交了修改完致命bug的版本。而第二次做业用一天写完，却在马原考试前的晚上12:00发现了bug。

感谢%%少布和%%花花的对拍器，帮我de出了不少bug。

除对拍的方法外，此次做业用JUnit单元测试来进行正确性验证也十分合适。

第一次：

强测中得分 100

对拍中发现的问题：建图时要注意读入处理顺序。由于attribute隶属于class，parameter隶属于operation，因此必定要先把底层的指令预先读入。

第二次：

在强测中得分 100

对拍中发现的问题：

1. tarjan算法dfs时class与interface的属性数组用混了。

2. tarjan算法没有考虑自环状况（R002）。

3. R001没有考虑本身继承本身的状况。

4. 命令行参数的使用

 

三、架构分析

第一次：

第二次：

 

1. 第一次做业要读懂需求，主要是每一个元素的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创建了一个更为清晰的结构:

↓

 

2. 关于类与接口间的行为有必定的类似性，能够创建一个抽象基类来提取出相同的部分统一处理，避免重复编码。

   二者不一样之处在于对继承关系的处理方面，类只能单继承，而接口支持多继承：能够将继承关系和实现关系抽象成有向边，转化为树/图模型。而后无非就是建树（建图），递归找父节点（前驱结点）的工做。

3. 而图和树结构的建模和运用在第二次做业中体现得更加明显：

   状态图和顺序图的两个主要元素能够抽象成点和边，这样查询任务和合法性检查任务就迎刃而解。

   我用了最熟悉的Floyd处理连通性问题，tarjan算法求强连通份量（找环）。

 

3、四个单元的总结与反思

一、架构设计及OO方法理解的演进

第一单元 多项式求导 面向对象架构

让我深入地了解了面向对象来架构程序的思想，给了当时的我很大的冲击。再加上当时对java语言的运用还很吃力。如今还能想起来当时荣老师在课上对继承和接口的讲解给个人那种醍醐灌顶的感受。

经过了解编译原理中的递归降低算法，更好地分析出了多项式的结构层次。

也是我第一次了解了设计架构、测试优先的重要性。

在具体的实现过程当中运用了工厂模式。

第二单元 电梯调度 多线程

多线程做为一个”新世界“，编写代码的思路和debug的方法相较以往都有很大变化。

而多线程的设计模式是帮助我更好更快地上手编写多线程程序并保证逻辑正确性的必要工具。

同时我也对线程安全的容器有了必定的了解。

其次，决定此次做业得分的还有调度算法的取舍。怎么保证在广泛的状况下(≈数据随机)得到更好的执行效率，是很实际的问题。有趣的是，电梯调度算法的来源居然是操做系统的磁盘读取算法LOOK和SCAN（os乱入片场

第三单元 地铁线路 规格化与单元测试

第四单元 UML解析器 UML

这两个单元画风比较相近，对面向对象的架构要求不高，而重在帮助咱们熟练掌握JML规格和UML图这两大工具。

编写实际场景下运用的程序比单纯地写规格和画图，对我加深理解的帮助更大。

第三单元难点在于实际场景下的算法模型创建，而第四单元则延续了对图和树这两大重要结构的考察，弥补了大一程设和DS有始无终欠下的“图论债”。

同时，在为了知足性能要求须要大量使用、合理选择java容器。经过用java容器来高效实现c语言中的图论算法，我对java编程的熟练程度也增长了。

二、测试理解与实践的演进

在强测中wa了两次，分别是第一单元第3次做业和第二单元第3次做业，内心有点难受，本身本能够作得再好一点的。

第一单元 多项式求导

此次的对拍任务很容易借助python的算术功能来完成，我经过构造易错数据、编写对拍程序来进行了简单的对拍，但没有进行细粒度和大批量的测试。

第二单元 电梯调度 多线程

开始完善本身的评测机。但架构和编码时间有点长，直到最后一天晚上才进行性能测试，致使时间不够优化算法。并且最终仍是在处理换乘问题上出现了纰漏，反映出本身的数据生成器仍是不够强，粒度也不够细。而且缺乏静态差错的环节。

第三单元 地铁线路

直到我在第三单元中学习了单元测试的方法，前两次对于测试的困惑终于获得了一个解决方案！

尝试编写了单元测试程序，同时也利用本身的评测机进行了对拍。

第四单元 UML解析器

通过一个学期与bug抗争的过程，我认为一个完整的测试过程应该是这样的：

①coding前构造通常数据与极端数据，力图全部状况后再选择算法和架构

②coding时，一个功能模块编写完成后进行单元测试，经过后再进行下一个模块的coding

③coding后进行静态差错，确保代码实现与思路一致，结合小黄鸭调试法食用味道更佳（

④用coding前构造的数据进行简单的正确性验证

⑤编写数据生成器，进行对拍验证，本地测试程序的运行效率与在“大“数据下的执行效果（能够按照功能分批进行测试）

 

4、课程收获/致谢

一、oo这门课让我了解了面向对象的思想，以及初步感觉到工程项目与以往所编写的程序的不一样。

从最开始的每次重构、看到代码量大的项目根本无从下手、谈”虫“色变不知从何处de起，到掌握了必定的java语言基础、设计模式、测试方法，懂得算法如何运用到实际场景中，也学会了简单的脚本的编写。

课程组对checkstyle的重视，也让我养成了良好的代码风格习惯。

你们在讨论区中的发言，不管是解决问题的思路，仍是一些黑科技，也都给了我很大的启发。

二、同时也更深入地意识到了本身还有很长的路要走。zsa说”穷则思变，而不是穷则思易”。这句话我发自心底地赞同。对于每一次做业，强测只是规定了能力达标的“下限”，而想要写好代码，其“上限”是无止境的。

三、感谢老师和助教的辛苦付出。指导书等有纰漏在所不免，课程组对待问题的态度让同窗们很信任和安心。同窗们对课程的重视和认真也来源于课程组的重视和负责。

四、一些碎碎念：

如今耳机里播放着哥哥的《怪你过度美丽》《追》，忽然有点想流泪。oo填充了我这个学期一半以上的生活，开学时看到每周时间线望而生畏的我，如今忽然以为很感激，如果没有这样的课程压力逼着小伙伴们写代码debug极限互测，就算会逃避掉不少的痛苦，快乐亦会不复存在吧。

cmx说，coding大概和写文字有些类似，都是须要“工巧心”的事情。

想明白了这点，不管面前的代码再如何的支离破碎与混乱不堪，也不会以受难者的心态对待了。

"一想起你如此精细 其余的一切 没一种矜贵 "

反倒会以为，任何本身没有打磨好的代码，都会愧对了这份情愫吧。

 

5、一点改进建议

1. 四个单元的做业难度最好有层次梯度，按部就班，而且可以迭代式上升。好比第一单元对面向对象架构的要求能够稍微弱化，后两单元在特定的单元主题要求以外，还要强化对面向对象架构的考察。

2. 实验课内容很好，能够帮咱们巩固课堂上老师教授的理论知识。可是实验课结束以后得不到结果反馈，考察的题目依旧不懂，甚至实验结束后没法看到题面和知识点总结，没法有效地学习巩固。

3. 我认为每一个人完成的做业代码能够开源，这样可以扩大同窗间交流学习的范围，同时这种自发性的交流分享可以让助教筛选优秀做业的工做轻松不少。多阅读别人代码，可以提高本身的代码能力；而在网络上又很难找到和oo做业所需内容契合的代码，致使同窗们在没有面向对象基础的状况下只能YY，结果就是交上去的代码写得很丑而不自知。至因而在什么时间读、以何种方式读（是大脑空白借鉴别人的思路，仍是在完成本身的代码后学习别人的实现方法，抑或是给别人找bug），由同窗们本身来决定，只要恪守不抄袭的原则便可。

   若是出现抄袭行为，对于类似代码是谁抄袭的评判，能够经过上传的时间前后来判断。

   这个回答或许能够成为一个解决方案

4. 老师们能够了解一下每次做业的内容。课件应该是老师作的，而指导书应该是助教们写的。课件中的内容和做业内容虽然大致类似，但没法真正衔接上。同窗们在完成做业时没法运用课堂上收获的知识，老师解答同窗的问题时也只能给出大致思路。若是能针对同窗在本次过程当中遇到的具体问题给出具体的解决方案，或许能够达到“窥一斑而见全豹”的效果。