OO第三单元总结

第三单元总结

一、JML

JML的语法课上讲的很清楚，我就谈谈自己阅读JML规格的体会。
requires和ensures成对出现，可以看作对应一个if块。requires就是if块的条件，ensures就是这个if块将要实现的功能。
单就阅读JML规格而言，体验不是很好，因为这个语言非常严谨，总是把自然语言一句话能说明白的事情搞得很复杂，给我们理解规格带来一定困难。不过我们可以先把JML转换成自然语言，便于理解，然后根据自己的理解写出实现代码，再将代码与JML语言进行对比来验证代码的正确性。这样的一个过程容易被初学者接受。
第一次作业的时候，自己错误地认为JML与代码实现一一对应，代码几乎直接照搬JML代码。虽然说正确性没出错，但是为第二次作业全部CTLE埋下了伏笔。JML只是表示逻辑，而不是最简单的实现方式，机械地根据JML编写代码时不明智的行为。其实JML只是一个辅助工具，不能被它过多局限自己的思维。
signals语句表示抛出异常，根据异常发生的条件，抛出异常即可，这个也很简单。
JML的表达式中在这单元的作业里出现最多的三个就是\forall全称量词、\exists存在量词、\sum求和。这就是检验离散数学基础是否牢固，快速准确地从这三个量词里捕获规格想要传达地意图很关键。
其实，读懂JML规格还是比较容易的，但自己写JML规格的话就不容易了。倒也不至于说根本写不出来，只是自己写出来的规格考虑不全面，容易遗漏一些东西，从而产生歧义。
总之，JML规格所蕴含的思想还是非常超前的，可以规范我们代码的具体实现。但是由于JML还不是非常完善，再加之我个人对JML的理解还不是很透彻。学习完这单元之后对规格还有一些模棱两可的地方，这就需要我之后的工作和学习当中慢慢领会了。

二、略

三、JUnit单元测试

利用实验六给出的使用JUnit的方法进行了简单测试。

四、架构设计

设计思路

第一次作业完全照搬JML规格，虽然通过了强测和互测，但由于复杂度过高，为第二次作业崩盘埋下伏笔。
第二次作业所有测试点全部CTLE。最重要的一个原因是容器选择有误，应该选用HashMap，但是自己用了Arraylist。HashMap快很多的原因，我认为是根据ID找Person和Group的时候会更快，这个容器用特殊的算法，可以根据键的内容在常量时间内找到所对应的值。在查找的这一个环节节约了大量的时间。另一个原因就是没有存下来临时值，比如说每一次求和的时候就从头开始重新加一边。正确的做法应该是每次进来新的人就更新Sum值，这样的话求和就可以直接读取，不用再求，节约了时间。
第三次作业的主要问题出在stronglink。自己从网上找的那个算法是错的，导致了错误。最后修改的时候采用了最笨的办法，把每个结点删除一次，每次判断是否iscircle。如果都iscircle，就说明双连通。

第三次作业类图

第三次作业类复杂度

五、BUG

1 方差如果递推计算，似乎会出现误差，因此还是每次计算都用方差的原始公式
2 delperson偷懒了，直接复制addperson的框架，错的一塌糊涂
3 dijkstra算法没有正常终止
4 iscircle方法在ID相同时应该返回true
5 第三次作业的BUG修复环节，第17个强测点CPU时间总是2.7秒，尝试修改无果，选择放弃。

六、体会

这个单元强测两次崩盘，并不是因为JML规格理解不到位。而是在图论、算法等基础知识上有较大漏洞。再加之编码习惯不好，喜欢复制粘贴，BUG百出也是对自己的警醒。相比前两个单元来说，这个单元难度有所降低，而且还给了JML规格，代码好写得多。但是成绩不是很好，周三晚上的实验还是一如既往地做不出来，都怪自己反应太慢，短时间内阅读、编写代码的能力还差很远。OO的确是一门让我受益的课程，前三单元做的不好，希望下个单元能够顺利。