第三次博客做业

一． 规格设计的发展历程：

在1960年代末至1970年代初期，出现了一次软件危机：一方面须要大量的软件系统，如操做系统、数据库管理系统；另外一方面，软件研制周期长，可靠性差，维护困难。人们但愿编写出的程序结构清晰、易阅读、易修改、易验证，即产生良好结构的程序。60年代中期，大容量、高速度的计算机出现，随之出现的是代码量急剧提高，复杂度急剧增加、程序可靠性的重要性突出的问题。结果化程序设计随之提出，它要求程序设计时以模块为单位，每一个模块专职本身的工做，而要在模块间交流，在开发者和用户，开发者和开发者之间交流，就只须要相应接口便可。到了80年代，“软件工程”的概念第一次被提出，计算机的速度和容量大大提升，程序的复杂度也急剧增加，人们开始在程序设计时以模块为单位，各部分有了本身各自独立的工做，开始出现规格化抽象。好比说C++和JAVA的类说明和类实现出现了分离。以后，随着计算机软件规模日渐庞大，结构化程序设计方法开始没法知足用户的需求，面向对象程序设计（OOP）应运而生。面向对象程序设计是一场重大的革命，提升了开发人员的效率，有效地控制了软件开发的复杂度，提升了软件的可维护性和可拓展性。（本部分来自于互联网和适当修订）

规格化的设计大大提升了程序的规范性和规模化，提升了程序可读性，并下降了维护难度，因此获得了普遍的重视。

二． 做业中出现的规格bug：

第九次做业无bug。

第十次做业中由于是对第九次的补充。。。致使一些地方忘了补充repok方法和其余规格而被报了bug。。。

第十一次仍是落下了一个类没写repok。。。

这种bug。。。不分析也罢。。。

三． 分析BUG产生的缘由：

不想写规格，全部的规格都是最后往上加，因此东丢西落。（胡乱分析）

四． 写法改进：

1. 前置条件：

第一类（无限制）：

/**

         * 增删流量

         * @REQUIRES: None;

         * @MODIFIES: guigv.flowmap;

         * @EFFECTS:

         * increase and reduce the flow by time interval;

         */

改成* @REQUIRES: 0<=xbegin, ybegin, xend, yend<80;

 

第二类（未检查repok）:

/**

  * 获取乘客请求

  * @REQUIRES: r1!=null;

  * @MODIFIES: this.request,this.sign,this.state;

  * @EFFECTS:

  * request == r1;

  * sign == 1;

  * state == 3;

  * r1.tapoint ="("+Integer.toString(this.x)+","+Integer.toString(this.y)+")";

         */

                     改成：* @REQUIRES: r1!=null && r1.repok()!=false;

 

　　2.影响：

/**

       * 读地图

       * @REQUIRES: None;

       * @EFFECTS:

       * initialize map

*/

加上* @MODIFIES: this.map;

　　3.后置：

基本都上的天然语言，没得改。

五． 心得体会：

好人有好报。善恶终有报。人在作，天在看。我就不信抓着一个crash换花样报三个点，没检查map格式扣四个bug，测试文件名里面加空格的人，能是什么好人。

就这些，没了。