规格设计的发展历史
规格设计用于对程序设提供分解,抽象等的手段. 在撰写代码规格的时候, 需要对组成部件进行抽象.
在1960s, 软件设计出现危机, 例如 Dijkstra 提出了 goto 语句的种种危害, 引发了软件开发领域长期的论战, 并且在这时候产生了结构化程序设计方法, 例如Pascal语言在1970s占据有统治地位.
之后, 随着计算机软件规模日渐庞大, 结构化程序设计方法开始无法满足用户的需求, 面向对象程序设计(OOP)应运而生. 面向对象程序设计是一场重大的革命, 提高了开发人员的效率, 有效的控制了软件开发的复杂度, 提高了软件的可维护性和可拓展性.
规格化设计是随着面向对象程序设计的火热而发展起来的, 可以有效提高程序的规范性以及程序的模块化划分. 这样使得程序设计的数据更加安全, 软件的可维护性得到有效的提高.
发展到现在, 出现了以 JSF 为代表(实际上也只有 JSF not JSF but JSF)的教学用的规格设计要求. 很有创造力和想象力.
规格 bug
我的规格一开始是用自然语言(助教同意)书写的, 没有被爆太多的错误.
后来似乎禁止了自然语言, 因为全部修改的工作量太大, 于是放弃了.
不在这里一一赘述.
规格 bug 产生的原因
没有深入到 JSF 设计者的内心灵魂深处, 对 JSF 文档设计不够充分了解, 没有仔细阅读 JSF 工具的源代码(如果有). 导致书写 REQUIRES, MODIFIES, EFFECTS 的时候完全懵x.
分别列举 5 个前置条件和 5 个后置条件的不好写法, 并给出改进
前置条件
不好的写法当然是自然语言了啊对吧是的呢. 我列举 5 个进行修改.
- @REQUIRES: 传入的出租车对象不为空 改为 @REQUIRES: taxi != null
- 对于对象数组, 应判断数组中每个对象也不为空 @REQUIRES: (arr != null) && (\all i in arr; i != null)
- 构造方法, 对传入的参数进行约束 @REQUIRES: * != null
- 传入参数有范围限制时 @REQUIRES: 0 <= x < 80
- get 类方法, 对返回值约束 @REQUIRES: * != null
后置条件
- 涉及算法的, 不应该书写细节 @EFFECTS: (road.open) ==> (\result == true); (road.close) ==> (\result == false)
- 注意区分传入参数和成员变量名字 @EFFECTS: this.name == name
- 强行对返回值进行约束没有意义, 应该写 @EFFECTS: None
- 对常量单独定义, 否则失去意义 @EFFECTS: (0 <= x < max_limit) ==> (\result == true)
- 自然语言书写的, 应改为 JSF 标准格式
功能 bug 与规格 bug 在方法上的聚类关系
功能 bug 与规格 bug 在我的程序中没有同时出现, 或者暂时没有看出联系(规格 bug 多是因为自然语言被爆), 故没有参考价值.
设计规格和撰写规格的基本思路和体会
我从头到尾都认为撰写设计规格是一个很重要的东西, 但是在我们的课程设计中, 它的重要性并没有得到很好的体现, 反而引发了同学们不少的抱怨甚至是抵触. 我相信这其中一定是有问题的, 我们的课程一方面没有系统的培养我们撰写规格的能力, 一方面又以胡(互)测的形式对规格进行格式上的不加任何区分的检查.
我们作为计算机学院的学生, 应当正视我们与软件学院的区别.
我们还应该当作无事发生, 不要因为课程的原因, 导致以后对正常的规格撰写产生抵触心理. 共勉.