北航面向对象OO第三单元——JML

简介

• 本单元借助JML(Java Modeling Language)，训练了我们关于的“规格（specification）”的意识和思想
• 本单元代码难度较低，简单来讲就是给你规定好明确要求来实现函数，因此自己不需要动脑子设计很多东西
• 在阅读本文时，我假设你已经了解了第三单元作业的内容

JML简介

• Java Modeling Language是一种对java程序的形式化描述。
• 形式化描述就是不借助自然语言，而是借助严谨的程序化语言，对方法的输入输出、对象的取值范围等等做出规定。相较于自然语言更加严谨，防止由于自然语言的模糊性造成团队合作的失误

设计

• MPerson

  • 第一次作业时，考虑到拓展性，额外创建了MRelationNet类，保存一个MPerson认识的人和关系，并创建了MRelation作为MRelationNet保存的基本单位，用来方便给“关系”拓展，比如“亲人”“同事”等等
  • 第一次作业之后，发现本次作业是扣你性能的，因此把这些冗余的设计全部删除，采用HashMap保存MPerson之间的关系。

• MNetwork

  • 由于有一个queryBlockSum()方法，要求返回图的连通分量个数。本单元还对性能要求较高，于是采用“并查集”的方式保存人与人之间的关系。但也基本上只针对于这一个方法提升了性能。

  • 关于“并查集”推荐一篇帖子，讲解的很好

  • https://zhuanlan.zhihu.com/p/93647900

  • 第三次作业中，又增加了求最短路的方法，我觉得这就不属于OO的范畴了，大家就当成一个算法题随便写写好了

    • 提一嘴：Java中对于排列顺序无要求的集合，完全可以用HashSet或者HashMap保存，比如Dijstra算法中需要查看子节点已经计算出的最短路需不需要更新
    • 在C中，我们可以用下标的方式访问，但是Java是一种更为高级的语言，再给节点们额外增加一个“下标”信息就十分协调
    • 可以直接使用HashMap<Person, Integer>记录每一个Person对应的最短路长度
    • 再比如保存MPerson的acquaintances时，直接用HashMap<Integer, Person>，将id与Person映射起来，查找就不需要遍历数组，大大提高了效率

• MGroup

  • 有一个比较恶心的方法queryValueSum()，求解Group内保存的人与人之间关系值形成的二维矩阵的所有元素加和。正常求的化复杂度为O(N^2)，如果不改就会被别人卡爆
  • 想要优化，一般都是采用定义一个成员变量保持实时更新，调用queryValueSum()的时候只需要返回他就行了。我们需要改三个地方：Group::addPerson, Group::delPerson, Network::addRelation，每一次调用这三个方法都更新该成员的值就可以了

• 异常类们：

  • 我还是用一个静态的HashMap<Intger, Integer>将id与id_count关联起来，每次调用构造函数时更新一下即可。总计数器就用一个静态的int count;。
  • 所有异常类模板相同，复制粘贴稍微改一下就好了

测试

• 本单元另一个很大的收获就是测评。主要学习了JUnit以及对拍机两种，下面介绍一下。

• JUnit

  • 贴一下安装和使用教程：

  • 安装：https://www.cnblogs.com/wangmingshun/p/6411885.html

    使用：https://blog.csdn.net/yitengtongweishi/article/details/80715569

  • 简单来讲，JUnit可以实现为你编写的每一个方法单独测试，这种测试一般是基于规格的。当然啦，测试代码也得你自己敲出来（啥时候能有自动编写测试代码的玩意嘞，可能这得等到JML这种形式化规格发展完善了才行）

  • 以JML为例，你应该保证你的测试样例覆盖所有requires可能的情况，一般我们取几组中间值，几组边界值和几组越界值即可

  • 检查输出的时候也应该根据ensures检查，尽可能保证全覆盖检查。我们在实际工作中，测试人员与编写人员试互相独立的，测试人员一丢丢都不能相信写代码的，尽量测全了。

  • 听上去很麻烦是吗哈哈哈哈，我也这么觉得。所以我们通常只对比较复杂的函数（比如求连通分量个数、最短路）进行测试，简单的小函数就不管了

  • 优点：

    • 是针对方法的单元测试，可能的情况相对较少，方便构造测试样例
    • 不需要改变源代码，解决了print调试的麻烦

  • 缺点：

    • 麻烦
    • 对于我们这种小项目来说，不值得为了一个方法设计复杂的评测算法保证覆盖，性价比不高
    • 仅能测试方法内实现是否正确，项目综合在一起是否正确无法保证

• 对拍机

  • 前几单元我就写过一次评测机，原因是觉得自己写评测机无法保证我的“标准输出”就是正确的。第一单元可以有现成的Python库，第二第三单元都不好搞。所以对测评机一直比较消极
  • 后来我“意识到”（早就知道了但是没有”意识到“），我可以写对拍机而不是评测机。
  • 对拍机就是把好几个人的程序放在一起跑，比较大家的输出结果是否相同。这就基本解决了正确性的问题。3个人以上一起跑就很难会出错了
  • 相信看到这里，你已经明白要怎么写了对吗( •̀ ω •́ )✧
  • 思路(Python)：
    • 用随机数随机生成测试数据
    • 用subprocess.Popen跑一下每个人的程序，获得输出
    • 比较输出，如果都一样就ACCPTED!，如果不一样就WONG ANSWER!，输出一下不一样的内容
  • 航天工程中会做“正交化设计”，也就是同样的功能用不同的设计实现，这样一个出了bug另一个能顶上。在测试的时候也可以用对拍机这种思路测评两个设计，测试人员就不需要再费尽心思造数据了

心得

• 关于“规格”与设计

  • 编写本单元代码时，最大的体验就是“爽”，因为编写者不需要考虑额外的事情，不用考虑类之间的关系，不需要考虑如何组织整个项目（要求就是在完成了这些设计的情况下才能提出来的），只需要保证实现要求就行了，大大提高了代码效率
  • bug减少了。编写代码时只需要关注当前方法是否符合要求，每一个方法都不复杂，bug率大大下降
  • 最难的“设计”部分其实课程组都给我们做了，这也是我们未来最重要的难题。我一个软院的室友这学期做软工项目，他们小组设计项目、制定规则花费了大量的时间，一切准备就绪再开始写代码，工程进度就会变得飞快无比。
  • 代码能力不会是未来道路上的主要阻碍，只要有要求总能干得出来，最为关键的就是“如何规划整个项目”。老师说“项目设计阶段犯的错误，在代码实现阶段要用10倍的代价弥补”，我深以为然。

• 一些吐槽：

  • 本单元十分强调性能，我认为这与“面向对象”毫无关系，给同学们增加了很多压力，却没有增长“面向对象设计”的能力。
  • 我非常不愿意在这样一门课上为了性能额外编写一些东西，我认为这“不面向对象”
  • 另外课程组还要求在博客里“总结分析容器选择和使用的经验”，这是Java语言使用技巧，更与面向对象毫无关系
  • MPerson, MNetwork,MGroup这三个类应当是完全独立的，MNetwork中应该只需要用到Person接口即可。
    • 然而Person接口却没有提供更改acquaintances的对外方法，导致MNetwork::addRelation时，必须提前在MPerson定义相应的方法，然后再MNetwork中将Person强行转为MPerson使用该方法，这也非常不”面向对象“
    • 诚然，在Person中规定用怎样的方法更改acquaintances会给实现该接口的人增加许多限制，也不是很”面向对象“。但我认为不规定的话有些弊大于利了

• 关于Python

  • 当你想干个什么事，先去搜搜有没有现成的库
  • 比如想要随机选取列表中的一个元素，我们有list.choice()方法，不要自己roll一个随机数，然后再取这个下标下的值啦