oo第三次博客

一.

　　在1960年代末至1970年代初期，出现了一次软件危机：一方面需要大量的软件系统，如操作系统、数据库管理系统；另一方面，软件研制周期长，可靠性差，维护困难。人们希望编写出的程序结构清晰、易阅读、易修改、易验证，即得到良好结构的程序。1968年，北大西洋公约组织（NATO）在西德召开了第一次软件工程会议，分析了危机的局面，研究了问题的根源，第一次提出了用工程学的办法解决软件研制和生产的问题。1968年，Dijkstra提出了“GOTO是有害的”，希望通过程序的静态结构的良好性保证程序的动态运行的正确性。1969年，Wirth提出采用“自顶向下逐步求精、分而治之”的原则进行大型程序的设计。其基本思想是：从欲求解的原问题出发，运用科学抽象的方法，把它分解成若干相对独立的小问题，依次细化，直至各个小问题获得解决为止。

　　在1970年代到1980年代，规格说明（Spec）和体（body）的分离说明是类型定义和操作描述，体是操作的具体实现。（具体的例子就是Java等面向对象语言的类说明与类实现的分离。）解决方案设计只关注说明，实现时引用或者设计体。体的更改、置换不影响规格说明，保证了可移植性。支持多机系统，但要同样环境。此时产生了划时代的面向对象技术。

　　一方面，规格化设计可以帮助开发者理清思路，构建一个写程序的框架，这样一来开发者可以按照既定的套路来完成自己的任务，从而能够摒弃杂念，提高效率。另一方面，一个程序中很多代码会以一块一块的形式被反复使用，这些重复的代码块有可能被封装为函数反复使用，也有可能被放入库中供他人使用。如果能按照一定的规格去完成他们，那么调用者不必大费周折的去理解代码，可以通过已有的对于格式的学习以及清晰明了的格式来快速完成对代码的理解，从而提高学习工作的效率。还有一点，增强可读性。

二.

　　1.关于文件格式识别的bug，Mian函数第61、64、68,71等行，bug类型：第十个公测点。

　　2.未写jsf的bug，Taxi类的第418行。

三.

　　bug产生的原因：有时候发现了bug，但是由于结构比较复杂，改动起来比较麻烦，所以就没有修改。

四.

　　1.

　　　　*@REQUIRES: true;

　　这是Taxi方法的前置条件，由于觉得调动这个方法应该不需要满足什么条件，所以这么写的，还是这么写比较好

　　　　*@REQUIRES:map ！= null  && gui ！= null

　　2.

　　　　*@REQUIRES: true;

　　这是input的前置条件

　　　　*@REQUIRES: map ！= null；

剩下的和这些雷同，就不一一赘述了

五.

　　撰写规格的思路：关于思路这个事情，我是这样写的，先把自己所有的代码写完，然后再按照调用关系以及函数作用来撰写规格

　　体会：规格真的比代码还恶心，要好好加油