• OO_JAVA_JML系列作业_单元总结


    OO_JAVA_JML系列作业_单元总结

    (1)梳理JML语言的理论基础、应用工具链情况

    简单梳理

    以下三者是jml规格里的核心,对一个方法功能和属性的限制:

    1. requires子句:规定方法的前置条件(precondition);
    2. assignable子句:方法的副作用范围限定;
    3. ensures子句:规定方法的后置条件(post condition)。

    简单运用

    采用OpenJML工具check第一次JML官方开源库代码得到如下结果:

    命令行结果

    对比第一次和第二次JML规格官方源码:

    第一次:

        /*@ public normal_behavior
          @ requires path != null && path.isValid() && old(containsPath(path));
          @ assignable pList, pidList;
          @ ensures containsPath(path) == false;
          @ ensures (pidList.length == pList.length);
          @ ensures (exists int i; 0 <= i && i < old(pList.length); old(pList[i].equals(path)) &&
          @           
    esult == old(pidList[i]));
          @ also
          @ public exceptional_behavior
          @ assignable 
    othing;
          @ signals (PathNotFoundException e) path == null;
          @ signals (PathNotFoundException e) path.isValid()==false;
          @ signals (PathNotFoundException e) !containsPath(path);
          @*/
        public int removePath(Path path) throws PathNotFoundException;
    

    第二次:

        /*@ public normal_behavior
          @ requires path != null && path.isValid() && containsPath(path);
          @ assignable pList, pidList;
          @ ensures containsPath(path) == false;
          @ ensures (exists int i; 0 <= i && i < old(pList.length); old(pList[i].equals(path)) &&
          @           
    esult == old(pidList[i]));
          @ ensures (forall int i; 0 <= i && i < old(pList.length) && old(pList[i].equals(path) == false);
          @          containsPath(old(pList[i])) && containsPathId(old(pidList[i])));
          @ also
          @ public exceptional_behavior
          @ assignable 
    othing;
          @ signals (PathNotFoundException e) path == null;
          @ signals (PathNotFoundException e) path.isValid() == false;
          @ signals (PathNotFoundException e) !containsPath(path);
          @*/
        public int removePath(Path path) throws PathNotFoundException;
    

    发现问题根源在于requires判据本身就发生在该方法执行前,old条件无法在此应用,因为,requires执行时就已经是old的数据了。

    (2)部署SMT Solver,至少选择3个主要方法来尝试进行验证,报告结果,有可能要补充JML规格

    (3)部署JMLUnitNG/JMLUnit,针对Graph接口的实现自动生成测试用例, 并结合规格对生成的测试用例和数据进行简要分析

    对自己编写的graph接口的实现类MyGraph运行JMLUnitNG结果是这样:

    ➜  src git:(master) ✗ jmlunitng -cp ~/javalib/specs-homework-2-1.2-raw-jar-with-dependencies.jar container/MyGraph.java 
    JMLUnitNG exited because of an irrecoverable error: 
    org.jmlspecs.jmlunitng.JMLUnitNGError: Encountered 100 compilation errors: 
    /home/relia/Projects/Java/OO/graph_management/src/container/MyGraph.java:21: 错误: 非法的类型开始
        private HashMap<SymPair<Integer>, Integer> edges = new HashMap<>();
                                                                       ^
    /home/relia/Projects/Java/OO/graph_management/src/container/MyGraph.java:24: 错误: 非法的类型开始
                shortestRoutes = new HashMap<>();
                                             ^
    /home/relia/Projects/Java/OO/graph_management/src/container/MyGraph.java:37: 错误: 非法的类型开始
            return edges.containsKey(new SymPair<>(var1, var2));
                                                 ^
    /home/relia/Projects/Java/OO/graph_management/src/container/MyGraph.java:49: 错误: 非法的类型开始
            if (!shortestRoutes.containsKey(new SymPair<>(var1, var2))) {
                                                        ^
    /home/relia/Projects/Java/OO/graph_management/src/container/MyGraph.java:52: 错误: 非法的类型开始
            return shortestRoutes.containsKey(new SymPair<>(var1, var2));
                                                          ^
    /home/relia/Projects/Java/OO/graph_management/src/container/MyGraph.java:61: 错误: 非法的类型开始
            return shortestRoutes.get(new SymPair<>(var1, var2));
                                                  ^
    /home/relia/Projects/Java/OO/graph_management/src/container/MyGraph.java:68: 错误: 需要')'
            updateEdges(path, this::edgeAddingConsumer);
                                  ^
    /home/relia/Projects/Java/OO/graph_management/src/container/MyGraph.java:68: 错误: 非法的表达式开始
            updateEdges(path, this::edgeAddingConsumer);
                                   ^
    /home/relia/Projects/Java/OO/graph_management/src/container/MyGraph.java:68: 错误: 需要';'
            updateEdges(path, this::edgeAddingConsumer);
                                                      ^
    /home/relia/Projects/Java/OO/graph_management/src/container/MyGraph.java:76: 错误: 需要')'
            updateEdges(path, this::edgeRemovingConsumer);
                                  ^
    /home/relia/Projects/Java/OO/graph_management/src/container/MyGraph.java:76: 错误: 非法的表达式开始
            updateEdges(path, this::edgeRemovingConsumer);
                                   ^
    /home/relia/Projects/Java/OO/graph_management/src/container/MyGraph.java:76: 错误: 需要';'
            updateEdges(path, this::edgeRemovingConsumer);
    
    ...
    
    

    可见的是,JMLUnitNG至少不支持两种特性:

    1. 泛型的自动推断特性,在声明处已经声明的泛型,在new实例化时,不需要填充泛型类型,编译器可以自动推断,但是JMLUnitNG不支持;
    2. 函数式接口的两种形式都不支持,无论是方法引用的双冒号,还是lambda表达式。

    不支持上述特性,难以想象其广泛运用。

    (4)按照作业梳理自己的架构设计,并特别分析迭代中对架构的重构

    第一次作业

    说实话,跟大部分人相同,path container采用三个hash map莽到底,规格很简单,功能很简单,正确性容易达成。

    第二次作业

    这个也没有什么特色,就是BFS能用,便采用这个算法计算最短路径了,想必跟大部分人也是大同小异的设计。

    正确性方面还是较为容易达成的,强测和互测都没有发现bug。

    第三次作业

    联通集计算

    通过一个map来保留联通集的信息,其原理在于单个path内部的连通性是可以保障的,就可以在path ID的基础上建立联通集,我也是这么做的,一个pathID映射该path联通的pathID的集合,这样,就可以在线性时间内完成一次path的添加工作,其线性时间,主要依赖path本身的长度,由于我看见大家都是提到DFS能解决连通性的问题,就这么设计了,所以,我在这里大概说一下我的不一样的联通集的设计思路。

    作业架构感想

    说实话,没有算法,架构只是纸上谈兵,这是我第三次作业的感想,选择了最朴素的分离解耦的思维,但是在算法上,复杂度过高,没有充分考虑可缓存的,没有充分考虑遍历的控制,虽然降低了每个方法的复杂度,但这样的程序,是没有实际价值的,换言之,我大部分是做了无用功;

    到现在,我也没设计出自己的完成第三次作业的思路,虽然学习别人的思路是必要的,我还是想弄清楚,怎样的原因导致了我的遍历无法达到想要的效果,然后深刻理解怎样设计遍历算法,这是我想探究的事物。

    我对搜索本身有了更深刻的理解,所谓遍历,究其目的,就是寻找要寻找的目标,或者是在确定的线性集合里搜索,或者是在有更加特殊的结构的集合里搜索,为了完成这个任务,就要有无数优化加入其中,最朴素的,就是排序,排序可以极大的加快搜索的过程,放在单纯的线性集合里,排序可以将集合视为二分集,进行二叉树上的搜索,达到最高的静态集合的搜索效率,而在图结构里,搜索单源最短路径,也可以利用类似的方法,即dijkstra算法,每次根据基础集合从待选集合中搜索路径长度最小的一个,加入基础集合,变相地实现了排序的要求,排序的目的,就旨在滤除不需要的数据或数据集合,将其提前排除,加速搜索的过程。

    总的来说,对集合的遍历操作十分依赖集合本身的结构,没有排序这样的优化,计算就永远是暴力计算,是不可取的。

    (5)按照作业分析代码实现的bug和修复情况

    这个。。第一次有一个bug但是比较隐蔽,强测和互测均未发现,最后是我在第二次作业编写中发现的,并且就排除掉了,是两个path compare的函数的错误,第二次作业最后通过了强测和互测,没有发现bug;

    第三次作业,至今为止,我还是没有设计出遍历算法或者遍历同时计算的算法,保证计算的完全性的算法,没有这个,计算出的结果,就不能确定是最小值。

    目前还在思考修复中,也许如果不采用讨论区大佬提的拆点算法了话,可能暂时修复不出来。

    (6)阐述对规格撰写和理解上的心得体会

    规格是对方法结果的一种约束,可以作为需求的一种清晰表述,利于针对其进行规范详尽的测试,因为结果都用可证明的形式描述出来,所以针对jml规格,可以采用更加针对性的测试,测试单个函数的功能正确性,并进一步提高junit的测试手段。

    有了完善的规格,一定程度上,有利于我们写出更加正确的程序,当然,其作用主要还是测试方面,根据规格可以更加形式化地验证,乃至采用自动化地方法生成测试程序,甚至测试数据,这都是可能的。

  • 相关阅读:
    堆和栈的区别
    今天开通博客了!
    【转】Perl中的正则表达式
    【转】Windows server 2008远程桌面轻松搞定
    【转】彻底删除0KB顽固文件或文件夹的方法
    【转】Java URL Encoding and Decoding
    【转】一个女留学生在美国的七年
    【转】风雨20年:我所积累的20条编程经验
    【转】深入浅出REST
    【转】Python正则表达式指南
  • 原文地址:https://www.cnblogs.com/-atom/p/10904559.html
Copyright © 2020-2023  润新知