第三单元博客总结
这一单元，主要是进行的JML的使用，以及考察了对于容器，对于算法选择时候的时间复杂度的控制。
JML的理论基础和相关工具
JML的核心就是规格和规范，当我们作为设计者想要向开发表达出让他们做什么的时候，我们往往需要用注释的方式来进行表述，比如某个类应该有什么变量，干什么，再比如某个方法应该做什么，什么可以变，什么不可以变化，以及对于数据有着特殊的要求等等一系列的要求。我最开始的时候认为如果用自然语言模仿规格进行表述的话，可以有着更好的效果。同样，最开始作为一个开发者，我或许更加希望能有类似于规格的自然语言描述。
那么问题来了，我们为什么要用一种规范的类似于伪代码的方式去写注释呢？因为只要有了规范，就代表可以自动化验证，自动化验证可以避免人思维的死角，能够从一个更加完整的系统的方法进行规格的验证，检测正确性，除此之外，为了进行大规模，批量复杂的验证，光靠人力去一点一点看注释解答注释，或者说，让测试人员去先读明白注释，再去读明白代码，检测是否正确，需要大量的人力和时间。如果机器可以代替我们的工作，当然是最好的。但是机器是死的，只能按照模板按照规矩来解读，所以我们不得不创造一个约定，让机器可以识别，但是对于书写者来说便于书写，对于开发者来说便于看，最终就诞生了我们的JML。除此之外，自然语言会有各种各样的歧义，也会导致很大的问题。
JML的核心是用表达式，对于方法规格，类型规格进行控制的一种语言。
这里面就涉及到了三个要素，什么是JML表达式，什么式方法规格，什么是类型规格
（1）表达式
有关于表达式的内容，说白了就是JML的语法的核心内容，这部分在JML手册里面规定的很详细了，我这里不再赘述，包括原子表达式，量化表达式，集合表达式，操作符等一系列表达式。这些就是JML语言的基本语法，用这些语句表达出具体的意思。
补充一下，表达式内容特别接近离散数学一里面的谓词逻辑系列的内容，在有大一离散数学的基础之上，我们可以不太困难的理解JML的表达式语言
（2）方法规格
方法规格的核心就是，满足什么条件达成什么样的结果。特别强调的是，方法规格只规定了满足什么条件，和产生什么结果。不关心产生结果的过程
在这句核心的基础之上，生发出来各种各样的约束，
前置条件：就是需要满足什么要的条件才能进行方法，
后置条件：你这个方法做完了要满足什么结果。
在这里特别提出一下，后置条件只规定了方法开始和结束应该满足什么，不规定方法怎么执行。
副作用：允许你的方法对什么进行成员修改，不允许你修改的不可以动
异常：满足什么条件，需要你去抛出什么样的异常
由此可见，方法规格，或者叫JML的核心，就是调用方法如果满足A条件，必须得到B结果，怎么得到结果？我不关心，那是开发者的事情。
（3）类型规格
类型规格的核心是变于不变，不变式就是告诉你，在方法执行前，完成等可见状态下某种数据变量的要求。
与之相对的约束就是状态变化约束，如果要变化，怎么变，给出了变化的具体要求。
有关JML的工具有很多
如， 使用OpenJml检查JML规范性
如， 使用SMT Solver检查等价性
如， 使用JMLUnitNG自动化生成数据测试
JML相关工具的使用
说到JML相关工具使用，可以说一把心酸，工具的不成熟，JDK版本的不对劲，还有各种各样的神奇bug的出现，导致了一些工具可以使用，而有一些的工具在我的电脑之上完全无法运行。
在查阅了各种各样的资料之后，无论是同学的帮助，还是网上教程，还是学长往届博客，我的工具问题还是没有解决，我就只能简单的说一说我使用过的工具。
（1） openjml
openjml我完全按网上和同学的方法使用，但是在分析代码的时候还是在中间报了异常。
除此之外，我最想验证的几个方法，如同最短路径，强连通，连通之类的方法，由于openJML似乎不支持对于 （forall int [] path）之类对于数组的判断，加上我本身使用的各种hashmap，hashset，以及为了满足算法规定增加的若干变量，都没法进行有效的进行openJML的判断 。
到这一步我觉得，如果我为了穿鞋，把脚砍去一半的话，完全体现不出这个博客的意义，所以我在这一步选择了放弃
至少我觉得，如果让程序员抛弃程序效率，抛弃程序简洁度，甚至说是抛弃程序能否满足课程组要求（算法时间之类的），去满足一个比较低下的工具，我真的觉得本末倒置。
（2）JMLUNIT相关测试
在用这个工具之前，我是满心期待的，这也太爽了吧，我不用对拍了，不用自己写测试代码了
但是我看到一片夹杂的FAILED和PASSED之后，我整个人是完全无语的，
这个测试真的就是，划水
我不但测试了MyGroup类，还测试了其他的东西，并且本地写了几个demo
发现一个神奇的规律：
你要是参数为int，就给你int上下界放进去，或者塞个0
你要是参数为对象，给你扔个null进去。
如果没爆出异常，就是falied
然后排列组合，进行测试。。。。。
说实话，课程组以及规定了各种异常处理方式，各种数据的限制
很多测试做的无用功，求年龄在-2147483648到0之间的人。。。
总而言之，这个方法只能判断极端条件下的异常！！！
这个方法只能提醒你一些疏漏，但是这些疏漏90%以上由于课程组数据限定不会出现，还有9%已经丢入了异常判断里面
（3）JUNIT系列
这个系列是典型的测试，有着完备的工具，规范简单的使用方法，也是我进行测试的主力，但是这个和JML有啥关系呢？
由于上述工具基本对我都是没有帮助的收益，我只能利用JUnit和自己写其他函数的方式，来模仿一个我希望的“JMLUNIT”“openjml”的功能
我希望有一个测试方法，完全按照规格，只判断满足条件之后的结果
所以我就相当于在测试代码翻译了JML语言后置条件，进行比对操作等等。
总而言之，JML本意是节省人力和时间，但是使用出来之后，却造成了没太大意义的结果
说实话，这不是JML的问题，这是不成熟工具链的问题，我们要给JML工具链发展的时间
我只能说，在现在这个时间段，JML的这几个工具没法高效率投入工作生产甚至课后作业里面发挥很大的良性作用，
这一系列的工具，目前顶多是跑一跑demo，给一点小的提示防止遗漏判断，完全不能满足JML希望的“用规格保证正确”的这种目的。
三次作业架构设计
第一次作业
第一次作业架构很简单
总体来说，没什么好的架构，在当时的时间内，我还处于认为JML规格就是方法执行步骤的阶段
JML用的数组，我就用arraylist
JML用循环遍历，我也循环遍历
第一次作业唯一一个难度，就是判断两个点是不是直接可达的，这里用到了一个dfs函数，没有更多复杂的东西了
第一次作业由于测试很弱，我这种无脑循环的方式可以没有任何bug的通过中测，强测，拿到满分
当时我还以为照着规格翻译就好了，然后第二次作业酿成了大祸
Myperson复杂度
Mynetwork复杂度
总的来说，不复杂，就是有几个循环而已
第二次作业
第二次作业和第三次类图是一样的
总体结构很简单，因为架构是课程组规定好的，不需要我大幅度更改
我前面说过了，第二次实验，我最开始是无脑的按照规格进行的双循环遍历，
在10w条指令的轰炸之下，出现了巨大的问题，所以我使用了缓存机制
缓存机制也很简单，观察所有算法里面，只有两个函数是O（n*n）的，那就是group里面的getRelationSum()和getValueSum()两个函数
使用双循环直接超时
但是仔细观察这个函数，发现有窍门，可以在每一次加入group的时候更新一次，在每一次加关系时，可能更新一次
所以我进行了更改，先是加人的时候和组里面所有人比对，如果有link的人，就更新relationsum和valuesum
除此之外，还要加上relationsum的自圈数。
但是，有个巨大的问题，那就是当两个人先加入group再加关系的时候，难以直接通过已经有的函数进行更新
那怎么办呢？我选择了牺牲封闭性的方法，额外加了个方法，允许外界更新relationsum，valuesum，那就是加关系的时候判断两个人都在组里面的话，就更新这个组的有关数据
总的来说，这次在JML不代表方法运行方式上面这一点吃了大亏，因为超时出了问题。
除此之外，我这次最大的改动还有一点：使用hashmap和arraylist结合的方法，因为hashmap方便取，方便判断存在，但是不方便遍历，而arraylist刚好可以补充遍历困难的弱点，所以我通过两种方法一起使用，相互补充，最大限度减少时间开销，也让代码更加简洁。
这一次，MyPerson没有变化
MyGroup复杂度
MyNetwork复杂度
所有复杂度在于添加关系上面。和预想的一样，但是这样子会减少超时的错误，所以是合理的复杂。
第三次作业
第三次作业是这一单元灵魂所在，虽然我的方法最终还是超时了，但是我个人认为，我的一些方法有着很好的借鉴意义。
这次的增加了从组里面删除一个人，就是增加一个的镜像操作，把加改成减，利用缓存更新就可以了，问题不大
至于增加的年龄范围的人数，借钱，判断一个人钱多少这种操作，就不提了，因为是很简单的一次遍历或者不用遍历的操作。
这次主要三个大难点
第一，最短路径
最短路径我使用了一个矩阵记录任意两个点之间最短距离，再添加一次关系的时候，更新所有点的最短距离
当调用函数计算最短距离的时候，就是一次二维矩阵的读取操作，是O（1）
但是问题来了，更新最短距离的时候，是一次O（n*n）的操作，特别浪费时间，也是我超时+被hack的直接原因
这一部分内容会在bug里面详细展开
思路就是，最开始所有人之间距离无限大，每次添加关系，如果两个人之间最短距离大于加入的关系，就更新最短距离
如果更新了最短距离，就会进行二重循环遍历，遍历任意两个点的最短距离会不会因为这条边距离的变化而变化，
由于终点和起点都需要包括所有点，所以复杂度数O（n*n）
第二，强连通
强连通我使用了课程组给的方法，如果两个人不是直接连接，就采取每次删除一个人，遍历删除所有人的每一个，之后判断起点终点是否可达的方法
如果两个人因为删除一个人无法连通，就不是强连通。
但是有一个问题，那就是两个人直接link的时候，这种做法是无效的
所以这种情况需要特殊判断，就是遍历起点所有的相邻结点，如果起点的相邻结点（除去终点）有一条不经过起点可以到达终点的路径，那就是强连通的
所以做法分两个分支，直接相连和不直接相连，复杂度都接近O（n*n）
第三，连通块数
使用双循环一定暴毙，所以我用了缓存技术，每次加入一个人，就blocksum加一，每次加入一个关系，如果加关系的两个人之前不是可达的，
那就blocksum-1，代表两个块变成了一个块
这个方法是我觉得的最简单也是最省时间的方法
由于我的最短距离矩阵存在，所以我的isCircle是O（1），所以这个方法也不复杂
总的来说，这一次我把所有复杂度丢给了addrelation上面，导致了方法臃肿，时间缓慢。
这是network的复杂度，所有复杂度堆在了stronglink和addrelation上面，和预料一致
现在反思，应该降低单个方法复杂度，使用堆优化方法的迪杰斯特拉算法，计算最短路径。
MyGroup的复杂度也没大的变化
这一次作业呕心沥血，担心自己会强测0分，但是结果比想的好了不少，虽然错了几个点，也被hack一次，但是可以接受了
毕竟当时只能想到O（n*n）的方法了，是自己能力不足导致的。
bug实现和修复
第一次，没有bug，
课下进行了大量测试检查正确性
同时我还使用了大量伪JUnit代码进行了测试
都没有发现特别大的问题，也顺利拿下了第一次满分
互测阶段，大家写得基本是一个模子刻出来的，所以没什么测试必要性，
拍了一些没发现大的问题，就没继续管
但是在课下阶段，我最大的问题是isLink函数的实现，想当然认为自己和自己之间不是link的，没有管规格语句，还好及时在课下阶段发现
好几个人，因为这个函数的问题，强测0分
同样的，还有dfs，bfs不标记循环到死的，也在强测拿了0分
这些我在课下都遇到了，也解决了，出现这个问题就是课下不到位，没看规格
第二次，超时bug
这次就是方法完全按照规格后置条件造成的错误
没记忆化，没缓存，无脑循环，不去考虑时间问题
是我这次最大的失误
解决方案就是前文描述的那样，增加缓存机制
组里加人的时候更新，加关系的时候如果在同一组就给这个组更新
很成功的两次解决两个bug。
hack别人也是hack这两个函数，失败了
第三次，超时bug
如同前文所言，所有复杂度堆在了addrelation上面，被人使用addrelation多次给hack了
强测也因为这个问题挂掉了四个测试点
解决bug的方法要完全重构代码，从isCircle，minpath，stronglink到之前若干函数
都要进行大大小小改动调整，截止到写博客这一天，bug还没修理
预计使用堆优化迪杰斯特拉方法修理bug
心得体会
经过这一单元，我对于规范化有了更加深刻的认知，虽然因为openjml工具出了问题，导致我的一些验证失败了，但是这个小插曲并不能阻挡我对JML的赞赏。
同样是注释，如果别的课也可以用这种注释给大家进行方法规格的注释，开发者的任务量就会少很多，而且更容易传达相应的信息，防止各种各样的歧义，防止自然语言的一些死角。
自然语言往往为了消除歧义追加内容
然后为了消除追加内容的歧义追加新的内容
再之后每次修订很可能是在改正上一次歧义导致的错误，而不是本身的问题
但是JML语言消除这种歧义，让注释简单易懂，直接了当。
除此之外，对于理解JML语言而言，我也有了很高的进步
第一次作业我是忽视JML，按照自己的性子写，觉得差不多就没管
第二次作业我是误以为后置条件是方法执行过程，导致出现了tle
第三次作业是我个人算法设计问题导致了超时，但是完美对接了JML规格，有着很大的进步
多次作业下来，我对规格有了更加深刻的认识，虽然自身代码功底有一些不足，一些算法没实现成功，但是我深刻感受到了读懂规格，遵守规格是一种什么感受，感觉有了规格的帮助，写起代码心里就有了保底，有了底气，只要我满足规格，我就是对的。
规格核心就是，允许你改什么数据，怎么改数据，满足条件达成什么结果
但是规格不关心你取得结果的方法，只关心更改之后的结果是什么样子，以及更改之后的结果和之前应该有什么关系
这种看似锁定但是很自由的规格，真的让我收获很多。
最后，再次强调，虽然openjml没法实现生活中大部分工作和作业要求，但是这不代表JML是有问题的，这种想法，一定会随着工具链逐渐成熟，一步一步深入到软件设计和开发之中。