HIT 软件构造笔记 第五章 规约Designing Specification

第五章 规约Designing Specification

图片来自HIT 软件构造 lm老师ppt 2022

规约是什么

规约不仅仅是注释，还包括方法名（对方法的声明）；规约是脱离实现方法的！

规约的用途–”防火墙“

交流；用来做什么；怎么做；把对程序做出的假设或者要求写清楚。

规约的设计决策

1. 代码中的”设计决策“：给编译器读（所以规约可以被编译器检查）
2. 注释形式的”设计决策“：给自己和别人读

行为等价性（Behavioral equivalence)

​ 站在客户端视角看行为等价性：如果都能满足用户的需求，那么就是行为等价的；

​ 比如两个方法，一个返回val值的第一次出现；一个返回最后一次，而用户只关心val是否出现过，所以这两个方法是等价的。

信息隐藏：

不要对用户公开具体的实现，只需要提供接口

方法前的注释

也是一种规约，但是需要人工判定条件是否满足：

@param:参数含义

@return :return what

@thows :exception

（规约不能带有程序的实现部分：比如不能说@return boolean，@param String word—输入一个字符串（无论实际的数据结构是字符串或者是字符数组）；输出一个布尔值（具体代表什么））

（不要用@requires ,@effects）

（告诉用户这是做什么的，而不是怎么实现的）

对于会对输入数据发生改变的方法，一定要在声明中告诉用户输入参数已经发生了改变 （这种方法–mutable是不安全的）

（建议一般都使用immutable类型的参数，这样就能保证程序的安全性，除非spec必须如此）

对于mutable类型的声明：

1、将压力给到客户，要求他们执行严格的规约

2、靠开发者的”良心“，如：不能再用这个数组

黑盒测试：

完全依靠给定规约来进行测试用例的编写

哪个规约更好？

规约的确定性、陈述性、强度（前置条件尽量弱，后置条件尽可能强）

强度低的规约可以被强度高的规约替代

规约的比较考试必考！！！

（ppt 50-52页还有三个例子）

前、后置条件同时变强或变弱：不可比较的两个规约（如上图）

当然，越强的规约对于程序员的要求增高，对用户的要求降低。

程序员可以在规约范围之内自由选择实现方式：

（规约构成⚪，程序员在圆内自由选择实现）-更强的规约表现为更小的区域–弱的规约表现为更大的⚪

（再来一个规约的例子–橙色的圈是ExactlyOne）

什么是好的规约？

1. 规约应该是内聚的（coherent）–一个规约对应一个方法，做一件事
2. 规约要足够强–要考虑到各种情况，不要出现遇到一些意外情况时没有规约说明的情况
3. 规约也要足够弱（weak enough)–太强的规约，给开发者提供实现的难度（给用户带来了程序总是会出很多错的信息）
4. 规约使用”抽象“类型(types)–用接口（顶层的类）不要用实现
5. 前置条件需要写吗？前置条件给用户提要求，若是不用前置条件，就需要在代码内部check；所以衡量check与否的代价来决定”责任人“是谁。

（第五章不会考很大的题，就是考考规约怎么写，写得对不对）