软件形式化方法历史
- 形式化方法的研究高潮始于20世纪60年代后期,针对当时所谓“软件危机”,人们提出种种解决方法,归纳起来有两类:一是采用工程方法来组织、管理软件的开发过程;二是深入探讨程 序和程序开发过程的规律,建立严密的理论,以其用来指导软件开发实践。前者导致“软件工程”的出现和发展,后者则推动了形式化方法的深入研究。经过30多 年的研究和应用,如今人们在形式化方法这一领域取得了大量、重要的成果,从早期最简单的形式化方法一阶谓词演算方法到现在的应用于不同领域、不同阶段的基于逻辑、状态机、网络、进程代数、代数等众多形式化方法。形式化方法的发展趋势逐渐融入软件开发过程的各个阶段,从需求分析、功能描述(规约)、(体系结构/算法)设计、编程、测试直至维护。
规格BUG分析
作业次数 |
规格bug |
名称 |
雷同bug数量 |
9 |
4 |
Modifies不完整/Effects逻辑错误/不符合JSF规范/Requires逻辑错误 |
0 |
10 |
1 |
repOK逻辑错误 |
0 |
11 |
0 |
\ |
0 |
规格BUG产生原因
- 规格bug各自都有各自的看法,对于规格自己反正也不太理解,所以出现错误也不知道是真的有问题还是这样也行,水平不够,继续提高
不好写法及其改进
public LinkedList<Integer> getDis(int startNode , int endNode){
/**
* @REQUIRES:(\all int startNode; 0<=startNode<=6399);(\all int endNode; 0<=endNode<=6399);
* @MODIFIES:None;
* @EFFECTS:\result == map.Bfs(arrays,endNode);
*
*/
引用了中间变量
public LinkedList<Integer> getDis(int startNode , int endNode){
/**
* @REQUIRES:(\all int startNode; 0<=startNode<=6399);(\all int endNode; 0<=endNode<=6399);
* @MODIFIES:None;
* @EFFECTS:return the shortest distance nodes between startNode and endNode;
*
*/
public synchronized void Set(int startnode, int endnode , int value){
/**
* @REQUIRES:(\all int startnode; 0 <= startnode <= 6399);(\all int endnode; 0 <= endnode <= 6399);(\all int value; 0 <= value <= 6399);
* @MODIFIES:None;
* @THREAD_EFFECTS:lock(this);
* @EFFECTS:set flow of the road between startnode and endnode to value;
*
*/
int roads = startnode*6400 + endnode;
int roads_copy = endnode*6400 + startnode;
roadMap.put(roads,value);
roadMap.put(roads_copy,value);
}
Modifies不完整
public synchronized void Set(int startnode, int endnode , int value){
/**
* @REQUIRES:(\all int startnode; 0 <= startnode <= 6399);(\all int endnode; 0 <= endnode <= 6399);(\all int value; 0 <= value <= 100);
* @MODIFIES:roadMap;
* @THREAD_EFFECTS:\lock(this);
* @EFFECTS:set flow of the road between startnode and endnode to value;
*
*/
int roads = startnode*6400 + endnode;
int roads_copy = endnode*6400 + startnode;
long times = System.currentTimeMillis();
for(int i = 0 ; i < value ; i++){
roadMap.get(roads).add(times);
roadMap.get(roads_copy).add(times);
}
}
public void set(int state , int credit , int PosNode){
/**
* @REQUIRES:(\all int state; 0<=state<=4);(\all int PosNode; 0<=PosNode<=6399);
* @MODIFIES:this.credit;this.posNode;this.state;
* @EFFECTS:this.credit==credit;this.posNode==PosNode;this.state==state+1;
*
*/
this.credit = credit;
this.posNode = PosNode;
this.state = state + 1;
}
逻辑错误
public void set(int state , int credit , int PosNode){
/**
* @REQUIRES:(\all int state; 0<=state<4);(\all int PosNode; 0<=PosNode<=6399);
* @MODIFIES:this.credit;this.posNode;this.state;
* @EFFECTS:this.credit==credit;this.posNode==PosNode;this.state==state+1;
*
*/
this.credit = credit;
this.posNode = PosNode;
this.state = state + 1;
}
功能bug与规格bug在方法上的聚集关系
- 个人感觉功能bug与规格bug可能并没有太大关系,测试者找bug之时,规格bug大部分不是因为功能bug导致的,而是后写规格容易遗漏规格的要点等内容,或者是写好规格之后修改了相应代码,总之感觉写规格更多考虑是怎么才不会被扣,感觉违背了教学初衷
基本思路与体会
- 基本都是先写好全部方法然后再动手开始写规格,写之前自己也确实是按照一定思路进行写代码的,但是没有按照规格的方式写下来。水平不够,仍需继续努力