JML是用于对Java程序进行规格化设计的一种表示语言。与自然语言会带来的歧义性不同,JML语言通常都具有独一的意义,因此,常被用来实现逻辑严密的规格。
JML的注释方法一般有两种:
JML对于方法的规格主要有三个部分
类型规格值对Java程序中定义的数据类型所设计的限制规则,一般而言,就是指针对类或接口所涉及的约束规则。
我们主要会涉及两类,不变式限制(invariant)和约束限制(constraints)
[TestNG] Running: Command line suite Failed: racEnabled() Passed: constructor MyGroup(-2147483648) Passed: constructor MyGroup(0) Passed: constructor MyGroup(2147483647) Passed: <<MyGroup@1ab7767>>.addPerson(null) Passed: <<MyGroup@722c82d8>>.addPerson(null) Failed: <<MyGroup@98ba811c>>.addRelation(-2147483648) Failed: <<MyGroup@4ee0c29a>>.addRelation(2147483647) Passed: <<MyGroup@6124fbb2>>.addRelation(0) Failed: <<MyGroup@77db4eae>>.addRelation(2147483647) Passed: <<MyGroup@d0a988d5>>.delPerson(null) Passed: <<MyGroup@13399d24>>.delPerson(null) Passed: <<MyGroup@1510e06>>.equals(null) Passed: <<MyGroup@e3414c71>>.equals(null) =============================================== Command line suite Total tests run: 14, Failures: 5, Skips: 0 =============================================== Process finished with exit code 0
可以看出,测试主要是针对于传入参数为null和INT_MAX、INT_MIN这类比较边界的条件,错误的情况也主要是对于边界条件的处理上。这个也是我在考虑代码时所没有考虑到溢出的情况而导致的。
本次架构设计主要针对于最后一次拓展情况进行分析,最后一次设计类图如下
本次架构基本上是按照MyPerson、MyNetwork、MyGroup实现的,只是引入了一个Tuple类用于实现类似python语言中元组的功能。从整体架构上来讲MyNetwork类相对显得有些许臃肿。在作业结束后反思我认为还是应该以迭代的设计方法来实现这三次作业。比如第二次作业就可以在第一次的基础上实现继承,并对MyNetwork类实现Group相关方法的实现。第三次作业可以在第二次作业的基础上实现继承,并添加相应的图算法。
对于本单元而言,因为过于信赖中测的原因,BUG存在相对还是较多的。
第一次作业:强测未能通过,主要BUG点在于isCircle方法中一个判断语句的错误,这个错误相对不是很起眼,但是如果进行了一定程度上的测试还是可以发现问题所在的。这也是我的问题所在。
第二次作业:强测仍然未能通过。由于上一次作业的惨痛教训,我对我的各类方法都进行了正确性的测试,然而万万没想到,我的莽夫实现方法(如每次在query相关属性的时候对集合进行遍历)导致了运行时间上的超时。
第三次作业:本次作业基本上是完全的重构,在容器选择上也采用了性能相对较高的HashSet和HashMap。同时对于一些经常访问的属性值也是进行了动态维护。同时也使用了较多的数据对本次各类方法进行测试。本次通过了强测测试,但本次因为对于集合初始化的原因,导致了部分测试点存在TLE的问题。
本单元主要是基于JML规格开展的一系列代码实现。在头两次实现过程中,由于过度相信中测,导致了自己对代码测试不全,考虑不周的情况,同时也存在照着规格写代码的问题。其实本单元三次作业相对于前面两个单元的实现难度还是有一定程度上的降低的,但这一单元也用惨痛的教训来警示了我测试的重要性,任何时间都不能盲目地相信自己实现的代码。培养良好的代码测试习惯也是非常重要的一个能力。在后续的任务中我也会更为注重这一方面的问题。
原文:https://www.cnblogs.com/1806lay/p/12941790.html