OO--第三单元规格化设计 博客作业

时间:2024-01-06 22:54:14

OO--第三单元规格化设计 博客作业

前言

第三单元,我们以JML为基础,先后完成了

PathContainer -> Graph -> RailwaySystem

这是一个递进的过程,代码实现基于课程组给出的JML语言,JML是一个只关心前提与结果的建模语言,可以描述清楚对于该方法的需求,但具体实现由个人完成,实现方法不限,只需要满足需求。一定意义上,算是工程方面客户的需求,而我们依据其完成代码。

JML理论基础及应用

注释结构

一般使用块注释,即/*@ annotation @*/,注释放在被注释成分的上方,一般类似于下方例子的构架。

/*@ public normal_behavior
 @ requires 定义该方法的前置条件
 @ assingable 列出该方法可能修改的成员属性
 @ ensures \result = 定义后置条件
 @ also
 @ exceptional_behavior
 @ signals (Exception e) 抛出异常的类型以及何种情况下
 @*/

同时也可以使用行注释,如下

//@ ensures \result = 

规格中的每一个句子都必须以分号结尾,否则会导致JML工具无法解析,且规格中描述的model int[] elements只是规格层次的描述,并不一定要实现该声明,变量类型也无需相同。

JML表达式

1. 原子表达式

\result:表示一个非 void 类型的方法执行所获得的结果,即方法执行后的返回值。

\old( expr ):用来表示一个表达式 expr 在相应方法执行前的取值。

\not_assigned(x,y,...):用来表示括号中的变量是否在方法执行过程中被赋值。

\not_modified(x,y,...):该表达式限制括号中的变量在方法执行期间的取值未发生变化。

\nonnullelements( container ):表示 container 对象中存储的对象不会有 null。

2. 量化表达式

\forall表达式:全称量词修饰的表达式,表示对于给定范围内的元素,每个元素都满足相应的约束。

\exists表达式:存在量词修饰的表达式,表示对于给定范围内的元素,存在某个元素满足相应的约束。

\sum表达式:返回给定范围内的表达式的和。

\product表达式:返回给定范围内的表达式的连乘结果。

\max表达式:返回给定范围内的表达式的最大值。

\min表达式:返回给定范围内的表达式的最小值。

\num_of表达式:返回指定变量中满足相应条件的取值个数。

3. 操作符

(1) 子类型关系操作符:E1<:E2 ,如果类型E1是类型E2的子类型(sub type),则该表达式的结果为真,否则为假。如果E1和E2是相同的类型,该表达式的结果也为真。

(2) 等价关系操作符:b_expr1<==>b_expr2或者b_expr1<=!=>b_expr2,其中b_expr1b_expr2都是布尔表达式,这两个表达式的意思是b_expr1==b_expr2或者b_expr1!=b_expr2

(3) 推理操作符:b_expr1==>b_expr2或者b_expr2<==b_expr1

(4) 变量引用操作符:除了可以直接引用Java代码或者JML规格中定义的变量外,JML还提供了几个概括性的关键词来引用相关的变量。\nothing指示一个空集;\everything指示一个全集,即包括当前作用域下能够访问到的所有变量。

部署JMLUnitNG/JMLUnit

测试代码

package demo;
public class Demo {
   private int[] Nodes = new int[100000];

   public Demo(int[] list) {
       for (int i = 0; i < list.length; i++) {
           Nodes[i] = list[i];
      }
  }

   //@ public instance model non_null int[] nodes;

   //@ ensures \result == nodes.length;
   public /*@pure@*/int size() {
       return Nodes.length;
  }

   /*@ requires index >= 0 && index < size();
     @ assignable \nothing;
     @ ensures \result == nodes[index];
     @*/
   public /*@pure@*/ int getNode(int index) {
       return Nodes[index];
  }

   /*@
     @ public normal_behaviour
     @ ensures \result == a + b;
   */
   public /*@pure@*/ int add(int a, int b) {
       return a + b;
  }

   //@ ensures \result == (nodes.length >= 2);
   public /*@pure@*/ boolean isValid() {
       return Nodes.length >= 2;
  }

   public static void main(String[] args) {
       int[] list1 = {1, 2, 3, 4, 5};
       int[] list2 = {5,12354, 2345342, 12312345, 425};
       Demo demo1 = new Demo(list1);
       Demo demo2 = new Demo(list2);
       System.out.println(demo1.size());
       System.out.println(demo1.size() + demo2.size());
  }

}

测试结果

OO--第三单元规格化设计 博客作业

显然有多个地方failed,例如add方法,没有考虑溢出,导致多次被爆破,且当构造函数接收到Null时也会出错。我试图修改代码,我考虑了传入数组为null的情况,抛出了异常,同时也考虑了add溢出的可能性,但依然skip或是fail。。。就很绝望,个人感觉JML体系还不是很完善,或是OpenJml以及TestNG不够完善,还有很大上升的空间。

作业情况分析

第一次作业(Path+PathContainer)

架构设计

第一次作业较为简单,只需实现一个路径管理系统,实现通过输入指令来进行数据增减查改。在MyPath中,我是用ArrayList存储路径节点,Path中的方法都较为容易实现,而在MyPathContainer中,我使用了两个HashMap来存储<Id, Path>,<Path, Id>,使用HashSet来存所有Path中的不同节点,同时还将PathId和Path在ArrayList中也存储一次,当使用contains功能时,我选择使用ArrayList.contains方法,速度较HashMap更快,但在get方法中,我使用HashMap效率更高,当路径发生更改,入add或remove时,会对于以上存储进行维护。强侧并没有出现问题。

类图

OO--第三单元规格化设计 博客作业OO--第三单元规格化设计 博客作业

方法复杂度

OO--第三单元规格化设计 博客作业

OO--第三单元规格化设计 博客作业

可以看出CompareTo方法,复杂度最高,因为根据要求使用字典序,我使用了较为笨拙的方法,即循环判大小,复杂度较高。

类复杂度

OO--第三单元规格化设计 博客作业OO--第三单元规格化设计 博客作业

第二次作业(Path+Graph)

架构设计

第二次作业新增了实现无向图系统功能,Graph除了继承PathContainer中的功能以外,还多出了节点是否连通,是否包含边,以及求两点之间的最短路径。我选择使用邻接矩阵,鉴于该无向图边的权重都为1,使用二维数组来维护点之间的最短路径,同时维护了一个change变量,当执行add或remove命令时,change++,在查询之前,判断change是否大于0,若是则使用update方法,更新二维数组,这样可以减少更新数组的次数。距离矩阵初始化为INF,即无限大,同时根据指导书描述,节点不可超过250个,于是建立映射数组,将节点与0-250建立起联系,以便使用数组。矩阵的建立采用Floyd算法,一次更新将所有最短距离都算出,查询时直接返回int即可。强侧并没有出现问题。

类图

OO--第三单元规格化设计 博客作业

OO--第三单元规格化设计 博客作业

方法复杂度

OO--第三单元规格化设计 博客作业

可以看出延续第一次作业中的CompareTo方法较高复杂度,而getShortestPathLength方法复杂度较高,是因为要分别判断抛出三个异常,if语句使用较多,问题不大。

类复杂度

OO--第三单元规格化设计 博客作业

OO--第三单元规格化设计 博客作业

第三次作业(Path+RailwaySystem)

架构设计

第三次作业较为复杂,不再是不加权无向图,更新为计算权值型无向图,需要我们维护价格,满意度,最少换乘次数,最短距离四个权重图。首先延续第二次作业中的映射,维护了映射HashMap,每当进行增加或删除路径操作时,都重新根据不同节点数组,更新映射。由于本次作业新增要求,只在RAilwaySystem类中维护矩阵,远远不足以满足需求,于是我在每一个Path类中维护了一个该路径下的最短距离举证,但现在想来,当时应该重新写一个类,如PathHelper类,来完成这些工作,而不是自己篡改接口,接口也就失去了意义。每新建一条path时,该path内部会自信跑一边floyd,算出最短路径矩阵,同时提供返回值。在RailwaySystem中,即总图需要更新时,首先根据每一条path的最短距离矩阵配合权重计算方法,初始化总图,此时的总图的权重代表了一个path内部的最小值,以最少换成次数为例,初始化时会更新每一个path内部,相连的点之间的权重,而不仅仅时相邻点的权重,同时给权值加1,代表一次换乘,初始化完成后,用总图跑一边Floyd,此时计算出的最小矩阵的权值,是多加一次换乘的权值,因此在计算最后返回值时,需要考虑到这一点。并没有使用拆点做法,下面时更新的过程,同时,连通块采取染色算法,可以轻易算出。

    private void update() {
       updateMap();
       init();
       int num = idList.size();
       for (Path path : paList) {
           for (int i = 0; i < path.size(); i++) {
               for (int j = 0; j <= i; j++) {
                   if (i != j) {
                       // 计算新的权值,同时加上一次换乘
                  } else {
                       int a = path.getNode(i);
                       a = map.get(a);
                       priceMap[a][a] = 0;
                       transMap[a][a] = 0;
                       pleaseMap[a][a] = 0;
                  }
              }
          }
      }
       floyd(priceMap, num);
       floyd(transMap, num);
       floyd(disMap, num);
       floyd(pleaseMap, num);
       int[] color = new int[num];
       int count = 0;
       numOfConn = 0;
       while (count < num) {
           int t = 0;
           numOfConn++;
           while (color[t] != 0) { t++; }
           for (int n = 0; n < num; n++) {
               if (0 <= disMap[t][n] && disMap[t][n] < INF) {
                   color[n] = numOfConn;
                   count++;
              }
          }
      }
  }

类图

OO--第三单元规格化设计 博客作业

方法复杂度

OO--第三单元规格化设计 博客作业OO--第三单元规格化设计 博客作业

类复杂度

OO--第三单元规格化设计 博客作业

OO--第三单元规格化设计 博客作业

OO--第三单元规格化设计 博客作业

Bug修复

总体并没有遇到太多的bug,前两次作业都是满封,但第三次作业,强测通过,但在互测阶段,被找到了一个bug,同时我自己写的评测机本来用来hack别人的,结果报的都是我的错,是一个极其粗心的错误,在同一点的距离矩阵中,我直接初始化为0,后续在containsEgde中,我根据距离矩阵的值大于0,判断存在边,于是忽视了自环的情况,导致了这个极其弱智的bug。(其实我运气也比较好,强测数据点竟然没有测自环,毕竟我的评测机几乎10个点就有1个是我的bug,可能是我造的数据太弱了。

心得体会

个人感觉规格在本次单元作业中体现并不是那么明显,大家都把大量的时间投入到了算法优化,复杂度的计算中,导致我们忽视了本单元最初的目的,且在后期感觉复杂方法的JML描述,不是很清晰,经常会出现一些特殊情况无法判断。个人感觉自然语言描述或许会更加通俗易懂,理论课上老师也反复强调只要你自然语言能够描述清楚全面,就可以代替JML。或许在日后的工作中,会逐渐体会到JML的意义所在。