JML语言梳理
理论基础
面向对象编程思想中有一个重要原则就是尽量推迟过程性的思考。所以我们在设计面向对象程序时首先要考虑的要干什么而不是怎么干什么。而Java本身并没有提供一种描述程序要干什么的方法，于是我们引入Java建模语言JML(Java Modeling Language)来实现这一目的。
JML是一种行为接口的规范语言，可以用来指定Java模块的行为，其最基本的用途是作为Java的合同设计(DBC)语言。
JML在实际设计中主要有两种用途：
在实现前对设计的规格进行精确传达
JML语言通过对规格进行精确表述，使架构人员和代码实现人员达成一致，可以认为是程序猿之间进行交流的猿语。
对已实现的代码进行总结梳理
这方面的作用主要体现在提高代码的可维护性。
实际上，如果我是维护人员，可能我只会在第一次通读规格，然后用自然语言进行注释（毕竟还是要说人话的）。这种感觉有点像把精妙但晦涩文言文翻译成粗糙易懂白话文，白话文有什么地方解释得模糊了，再去查原文。
应用工具链
首先通过开源的JML编译器，比如OpenJml，编译含有JML标记的代码。
对于Openjml来说 -check 选项可以对生成的类文件进行JML规范检查。
Openjml中还包含z3等SMT Solver，可以对代码等价性进行验证。通过Openjml -esc 选项对代码的静态验证是不依赖JML的，SMT Solver会自动整理JML(当然存在整理不出来的情况，这时就只能手动添加一波，强烈建议统一源码和jar包)。
JUnit可以对写出来的规格进行单元测试，并且可以检查覆盖性，可以进行保证质量上的测试。
SML solver：
SML solver简单来说就是利用openJML对程序进行静态检查，查找可能出现的错误。建立shell文件：
#!/bin/bash
java -jar C:/Users/lzhs/Desktop/oo/openjml/openjml.jar "$@"
然后就可以利用openjml命令进行检查。
非常抱歉本人对于这种功能没有十分清楚，所以不过多赘述。
分析架构：
第一次
对于第一次的代码，主要目的是让我们初次认识到JML的语法以及使用。代码相对上实现比较简单。唯一需要考虑的地方是需要把查询平均计算到每一个修改指令上去，否则会导致时间复杂度过高的问题。
Bug分析：
其实没有啥bug，唯一需要注意的是hashmap或者hashset的使用正确性，以及保持各种列表信息的一致性。
第二次
第二次其实就是一次对于最短路径操作的实现：
简单来说需要考虑的地方在于如何在计算的时候读取信息：简单来说就是，在增加的时候建立邻接表（单独建立图）。如何删除信息，利用hashmap记录信息，用于实现删除边的操作。为了方便记录建立了邻接表的类，以及节点类。
第二个问题在于如何降低时间复杂度，从算法的角度来讲，其实不是影响时间复杂度的根本因素。降低时间复杂度的主要位置在于记忆性搜索（因为只有50条修改指令），我们只需要在修改更新后进行查询时更新距离矩阵的信息，就可以做到50*n*n*n的复杂的，就是秒杀。具体算法上推荐floyd以及堆优化dij，bfs由于时间复杂度不可控不推荐使用。
Junite测试：
测试代码分为两部分：第一部分做了一下简单路径的时间复杂度测试，在1秒之内就说明，时间复杂度上不存在问题。第二部分对于具体算法以及增删操作进行了查询（事实上算法上很难出错，主要作物在于增删操作上）。
bug分析：
Bug主要就出在删除操作导致的信息不一致，从而出现错误。
第三次
第三次作业在第二次的基础上增加了更贴近于现实系统的功能：连通块，换乘，票价，不满意度。
我们来逐一分析：
总体思想就是继承上一次的思想，即记忆性搜索，剩下的就都是算法问题了。
连通块，其实个人感觉连通块利用bfs就可以，染色搞定一切问题。
换乘，票价，不满意度经过分析其核心问题都在于换乘如何处理上。
这样一来，我们就可以将问题这样分析，在同一条路径上的点与点之间换乘为零，那我们就可以将连通（将在同一条路上下车再上车视为换乘，允许换向直达）。另外，还有票价，不满意度如何解决的问题，事实上我们只需要对同一条路径进行一次floyd处理，处理完的数据用来建立邻接表就可以完美解决信息记录的问题。
这样一来我们可以发现换乘，票价，不满意度可以使用同一个模型进行处理。
在上述规格之中，邻接采用了一种新的邻接表以及结点方便记录信息。
分析bug
Bug主要存在与两个地方，第一是在算法上，如果使用了拆点的算法，容易出现信息记录上的疏漏，使用了邻接表，容易在remove上出现删除不全的错误。
心得体会：
其实jml交给我们的是一种设计上的思想，以及测试提前的思想，只要满足规格的程序就是正确的程序。