第三次博客作业
一、 规格化设计的发展历史
规格化设计伴随OOP而生，为了提高程序的规范性，对类、方法等进行规范化设计，有利于程序的模块化划分。这样设计程序的数据更加安全可控，测试也变得容易，软件的维护性得到提高，因而受到程序设计人员的重视。
随着计算机技术的发展，结构化设计语言和结构化分析无法满足用户的需求，OOP由此应运而生，即面向对象的程序设计。OOP的诞生是程序设计方法学的一场革命，大大提高了开发效率，减少了软件开发的复杂性，提高了软件的可维护性，可拓展性。1990年以来，面向对象分析、测试、度量和管理研究都得到长足发展。
二、 规格bug表格及原因分析
| 类别 |
方法 |
对应代 码行数 |
Bug原因 |
| JSF不符合规范 |
RepOK |
… |
未写，觉得无关紧要，后来被爆了bug，觉得写写也行 |
三、 前置条件后置条件写法改进
前置条件不好的写法1
对前置条件不做要求，自己在程序其他部分进行限制来保证一些隐含的前置条件会被满足。其实这样不是很好，降低了方法的通用性。
前置条件不好的写法2
a既然作为int类型，最好设定好上界2^32-1。即使不是int类型，一些参数最好也设定合理的界限。
前置条件不好的写法3
隐含了(x1,y1），（x2,y2）这两个点必须相邻的要求。这样会导致不处理错误的数据，作为规格并不全面。需要补全相应的约束。不完全的前置条件，给设计者和方法使用者都会带来困扰
前置条件不好的写法4
也应该对t进行约束
前置条件不好的写法5
对于方法外的的变量进行约束是不行的，规格与实现无关。应该去掉
后置条件不好的写法1
单纯的通过自然语言来描述后置条件，这样并不如逻辑语言清晰。
后置条件不好的写法2
代码中存在IO操作在后置条件中却没有写明。IO操作本身也应该是属于后置条件的范畴，应该在后置条件中加入
后置条件不好的写法3
该方法使用了锁机制来保证方法的线程安全性，后置条件应该说明要锁住哪些对象。
四、 功能bug与规格bug关系分析
功能bug
| 方法名 |
功能bug数量 |
规格bug数 |
| Taxigui |
1 |
0 |
| Queue |
1 |
0 |
| analyze |
1 |
0 |
总体来说，我个人的功能bug和规格bug聚合度不高。功能bug有两个是没有注意在issue中的补充要求。还有是自己对流量计算方法的错误.
五、 设计规格撰写规格时的体会
在第九次作业中，临时要加上JSF。添加JSF时，我发现
（1）自己某些方法功能过多，导致JSF不好描述
（2）JSF的规格不好控制
后面的作业中，在实现新的功能需要添加新类、方法时，我会先完成Overview和规格的设计，再去进行实现。这样的设计流程，虽然在功能上差别不大，但是程序的安全性（可控制）与可拓展性有了显著的提升。撰写规格时，我主要的考虑顺序是：
（1）方法的线程安全性
（2）需要实现什么功能
（3）在实现过程中改变的什么数据
（4）实现功能需要提供哪些参数