一、度量分析程序结构
1. UML类图分析
1.1 第一次作业UML类图
1.2 第二次作业UML类图
1.3 第三次作业UML类图
1.4 分析结构
在面向对象的第一单元里，我三次作业的代码结构在不断进步。从一开始的Main+多项式+项，再到之后加入InputHandler类，加入三角函数类。我觉得我对面向对象的理解在不断增强。就和荣文戈老师所述一样，将输入类独立出来可以很方便的对输入进行控制，如果需求有变，之后的格式判断条件增多，在InputHandler类中进行修改即可，不需影响其余模块的工作。将这些类独立出来之后，单独测试这些类也变的更加容易。我更加理解了面向对象是对象之间信息的传递。
2. MetricsLoaded代码分析
2.1 第一次作业
2.2 第二次作业
2.3 第三次作业
2.4 代码圈复杂度分析
我查阅了所谓的圈复杂度（cyclomatic complexity）是个什么东西，大概是用来衡量代码复杂度的一种标准，即合理地预防错误所需要测试的最小路径条数。
从我的三次作业来看，第一次作业中v(G)较高的方法是多项式类中的toString()函数，在这个函数的实现过程中，我使用了大量的分支语句来对输出进行优化，所以这里的覆盖测试可能需要更多的情况，会带来更高的维护复杂度和调试复杂度。
第二次作业中，v(G)较高的方法是项的构造方法，项是我在第二次作业中采用的最小模块，在这里我会对当前字符串进行分类，用正则识别后进行构造，分支较多。
第三次作业中，查找最外层配对括号、检查多项式是否为合理多项式、项的构造、项的toString()圈复杂度都较高，原因是我在括号配对中采用了c语言的写法，扫描配对，检查多项式中的方法也较为复杂，项的构造采用了递归构造，导致了较高的圈复杂度。
更高的圈复杂度意味着更高的调试复杂度和维护难度，确实，在第二次作业到第三次作业的改写中，对于圈复杂度较高的方法，都比较难以维护。
3. Statistics代码分析
3.1 第一次作业
3.2 第二次作业
3.3 第三次作业
3.4 代码量分析
三次作业的代码量在逐渐增长，在第一单元的三次作业中，我几乎没有编写注释，这给日后的维护带来了很大的麻烦，我会在以后的作业中注意这个问题。
二、漏洞分析
1 第一次作业
在这次作业中，bug出现在我想使用java内建的排序函数而编写的比较类中，在返回值的时候，并未考虑两数相等的情况，在Java5到Java6的版本更迭中，排序算法有了一些变化，导致有相同的数时，我这样的写法可能会导致RE。问题还是出在测试太少上了。
2 第二次作业
第二次作业的bug出现在我试图用加号分割多项式成项的过程中，我替换加号时考虑不完全，忘记考虑乘号或者指数后面跟着的数可以带有一个加号，导致程序出现错误。还是没有测试的问题。
3 第三次作业
第三次作业的bug出现在对题目理解的方面，诸如sin(x^2)之类三角函数中嵌套因子的情况，我忘记考虑其可带有指数，不过在这次的课下环节，进行了比前两次作业更加严谨的测试，所以强测成绩有小幅提高。
三、互测方法
我的互测方法比较简陋，把一个屋子同学的代码下载之后，放在一起，写一个脚本从一个in文件里一起读入相同数据，检查运行结果。
出数据就全靠手玩。
四、总结
通过第一单元OO的学习，我大致完成了对Java语言基本的了解，作为我接触的第一个用来编写面向对象的语言，我觉得Java还是较为易用的。通过阅读同学的代码，也让自己的代码水平有了一定提高。希望在接下来的OO中，我能进行更严密的测试，多多考虑代码构架。