OO_JAVA_JML系列作业_单元总结
(1)梳理JML语言的理论基础、应用工具链情况
简单梳理
以下三者是jml规格里的核心，对一个方法功能和属性的限制：
- requires子句：规定方法的前置条件(precondition)；
- assignable子句：方法的副作用范围限定；
- 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)) &&
@ \result == \old(pidList[i]));
@ also
@ public exceptional_behavior
@ assignable \nothing;
@ 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)) &&
@ \result == \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 \nothing;
@ 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至少不支持两种特性：
- 泛型的自动推断特性，在声明处已经声明的泛型，在new实例化时，不需要填充泛型类型，编译器可以自动推断，但是JMLUnitNG不支持；
- 函数式接口的两种形式都不支持，无论是方法引用的双冒号，还是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的测试手段。
有了完善的规格，一定程度上，有利于我们写出更加正确的程序，当然，其作用主要还是测试方面，根据规格可以更加形式化地验证，乃至采用自动化地方法生成测试程序，甚至测试数据，这都是可能的。