JML 是一种行为接口规格语言，提供了对方法和类型的规格定义手段。通过 JML 和其支持工具，不仅可以基于规格自动构造测试用例，并整合了 SMT Solver 等工具以静态方式来检查代码实现对规格的满足情况。
1.1 方法规格
-
JML 中的前置条件指的是在调用方法之前必须要满足的条件；
-
-
副作用范围限定指的是在执行过程中可能（允许）被修改的对象的属性数据或者类的静态成员变量。
1.2 类型规格
-
JML 中不变式 (invariant) 是要求在所以可见状态下都必须满足的特性，语法上定义
invariant P，其中invariant为关键词，P为谓词； -
状态变化约束 (constraint) 是指对象的状态在变化时也需要满足的一些约束，这些约束在本质上也是一种不变式。
1.3 应用工具链
-
openJML
-
JMLUnitNG
二、 JMLUnitNG
我使用 JMLUnitNG 组件的流程如下：
-
下载并安装 JMLUnitNG 组件
-
使用 JMLUnitNG 生成测试类
-
在 IDEA 中运行测试类
我首先对一个简单的方法 Demo.java 进行了测试：
通过命令行输入 java -jar jmlunitng.jar Demo.java 生成测试类，然后在测试类目录下建立 project，直接在 IDEA 中运行 Demo_JML_Test 即可。
我生成的测试数据如下：
三、梳理架构设计，分析迭代中对架构的重构
第一次作业
完全按照官方接口建立。
其中 union 记录的是整个 container 中的不同的节点，每次 container 中的路径变化，更新一次 union。
第二次作业
第二次作业将第一次中的 MyPathContainer 部分方法复制到 MyGraph 中，然后根据接口添加了新的方法，其他大致都没变。
第三次作业
第三次作业将第二次作业中的 MyGraph 中部分方法复制过去，然后根据接口添加了新的方法。
这一次作业比上一次添加了很多要求，且复杂度更高了，并且涉及到一些算法上的问题。
我使用的是讨论区大佬的不拆点的算法，用四个数组分别记录、完成四种功能，但其实都是基于最短路径的，只是每种功能中路径的权不同而已。每次更新 Path 时需要更新四个数组，且做四次floyd 。但因为常数较小，所以时间相对较短。
四、分析代码实现的bug和修复情况
第一次作业中，在 MyPath 中实现的 compare 方法中出现了一个小 bug，是我在遇到不相同的节点时，返回的是两值相减的值，这时没有考虑到可能会溢出。修复改为返回两值比较的布尔值。
第二次作业中吸取了第一次作业的教训，认真阅读规格，没有出现Bug。
第三次作业由于比前两次多了很多复杂的逻辑，而我的架构并不适于拓展，慌忙之下写出了一个较为严重的bug。在 containsEdge() 方法中，由于没有认真看规格，将两个同节点算作存在这条边，但实际不应该算作边；另外，在计算 least unpleasant value 时，我的方法需要在每个 path 内部另外计算 path 内节点的 least unpleasant value ，本来可以直接套用计算整个地铁系统的方法，我却另外想了一个更复杂的方法，既添了麻烦又出了错。已经修复为更简单的方法，即将路径权设为 unpleasant value ，然后跑 floyd。
五、对规格撰写和理解上的心得体会
-
对于一些较为复杂的方法，其规格的逻辑表达式很长，需要认真仔细地阅读，搞清楚前置条件和后置条件。
-