OO第三次博客作业

(1)调研，然后总结介绍规格化设计的大致发展历史和为什么得到了人们 的重视

1.大致发展历史：

　　（百度百科）软件形式化方法最早可追溯到20世纪50年代后期对于程序设计语言编译技术的研究，即J.Backus提出BNF描述Algol60语言的语法，出现了各种语法分析程序自动生成器以及语法制导的编译方法，使得编译系统的开发从“手工艺制作方式”发展成具有牢固理论基础的系统方法。

形式化方法的研究高潮始于20世纪60年代后期，针对当时所谓“软件危机”,人们提出种种解决方法,归纳起来有两类：一是采用工程方法来组织、管理软件的开发过程；二是深入探讨程 序和程序开发过程的规律，建立严密的理论，以其用来指导软件开发实践。前者导致“软件工程”的出现和发展，后者则推动了形式化方法的深入研究。经过30多 年的研究和应用，如今人们在形式化方法这一领域取得了大量、重要的成果，从早期最简单的形式化方法一阶谓词演算方法到现在的应用于不同领域、不同阶段的基于逻辑、状态机、网络、进程代数、代数等众多形式化方法。形式化方法的发展趋势逐渐融入软件开发过程的各个阶段,从需求分析、功能描述(规约)、(体系结构/算法)设计、编程、测试直至维护。

2.得到重视的原因：

　　重视场合：工程项目等代码规模大的场景

　　原因分析：（1）规格可以明确编写者的写程序的思路、便于调试：使用规格后，可以快速让自己想起来之前写了什么，快速整理思路，不会发生写着写着不知道在干什么的情况。调试时也能更快地定位和分析bug。

　　　　　　　（2）规格可以方便他人更快地看懂或使用代码。

 

(2)按照作业，针对自己所被报告的规格bug以及雷同的规格bug（限于 bug树的限制，对手无法上报），列一个表格分析

       JSF写的比较认真和严谨，并且花了很长时间检查，所以基本没有被报过JSF。

 (3)分析自己规格bug的产生原因

　　在改原来方法的内容时，会忘记改JSF。所以应该先改JSF，这也是写JSF的初衷：事前规划，而不是事后总结。

(4)分别列举5个前置条件和5个后置条件的不好写法，并给出改进写法

　　1.前置条件

1.前置条件必须是布尔表达式
void change(Object a){
//@REQUIRES:a is available 改：a!=null;
　　this.a=a;
}

2.前置条件需要具体，因为可能传入的指针非空，但是是非法的对象
void change(int a){
//@REQUIRES:a!=null 改：intMin<=a&&a<=intMax;
this.a=a;
}

3.前置条件可以再具体，进一步明确编译上合法对象的是否在逻辑上合法
void change(int a){
//@REQUIRES:a!=null 改：0<=a&&a<100;
this.a=a;
}

4.前置条件最好不要省略，因为不确定别人怎么调用（在多人合作场景下），所以尽量写全
void change(int a){
//@REQUIRES:None 改：0<=a&&a<100;
this.a=a;
}

5.前置条件需要考虑方法执行过程，并不一定是参数本身的限制
void change(int a,int b){
//@REQUIRES:none 改：0<=a+b&&a+b<100;
this.a=a+b;
}

2.后置条件

1.后置条件不写局部变量
void change(Object a){
//@EFFECTS:b==a 改：None;
　　int b=a;
}

2.后置条件使用符号语言的话，必须是布尔表达式
void change(Object a){
//@EFFECTS:	his.a=a 改：	his.a==a;
　　this.a=a;
}

3.后置条件需要写多线程的内容
void sycronized change(Object a){
//@THREAD_EFFECTS:Nobe 改：@THREAD_EFFECTS:lock=();
　　this.a=a;
}

4.后置条件不能直接表述算法
void sycronized change(Object a){
//@EFFECT: b==a;	his.a==a; 改：@EFFECT:	his.a==a;
　　int b=a;
　　this.a=b;
}

5.后置条件可以使用java方法
void sycronized change(){
//@EFFECT: a is random int 改：@EFFECT:	his.a==Math.random();
　　this.a=Math.random();
}

  (5)按照作业分析被报的功能bug与规格bug在方法上的聚集关系

　　被报bug为程序性能延迟或者指导书没读仔细等（如过滤空格），与规格没有明显关系。

(6)归纳自己在设计规格和撰写规格的基本思路和体会

 　　虽然应该是写程序之前完成规格的书写，但是由于ddl太赶只能先写程序，省去后期调整规格的时间。主要思路就是前置条件看参数，改变和后置条件看全局变量。最难的就是复杂方法的后置条件，用自然语言没法说清细节，用符号语言又像在写具体算法。考虑到评测，最后选择了说不清细节的自然语言描述一个方法的后置条件。

　　切实体会到的是规格对于调试的遍历。以前调试的时候总会忘记某个方法是干什么的，写了规格后能快速回忆起一个方法的功能。感觉以后多人合作程序会很需要规格，而不是每个人都随性地写注释。