软构阶段性考点总结（一）

1.软件构造的多维度视图和质量目标

1. 多维视图表

2. 软件测试与测试优先的编程

1. 黑白盒测试，例如能发现哪些错误（白盒通常选择题，黑盒可能大题）
2. 等价类划分（要有标准，可以多分不要少分，无效等价类最好加上）
3. 测试用例考的不多

3.软件开发过程与软件版本控制工具

3.1 软件开发

1. 选择题，通常考原型模型【适用于需求不明确】和螺旋模型【涉及风险分析】;
2. 传统开发过程与敏捷开发过程区别【四点特征】

3.2 版本控制

1. 需要了解基本git指令；
2. 【选择题】一个版本的父版本可能有0、1、2个，子版本可以有任意多个
3. git在进行merge时会涉及三个版本，需要merge的两个版本以及其公共父版本
4. git在merge时若出现版本冲突，需要人工解决
5. git远程协作时为了保护，服务器强制用户在更新版本前需要把服务器上的版本下载到本地，与本地的进行merge之后才能提交，避免与其它用户更新的版本冲突

4. 数据类型与类型检验

1. 重点是可变类型与不可变类型：把不安全程序改为安全程序；信息隐藏，用户不能通过方法以外的手段改变属性值

1. 全局final变量只限制变量不能改变指向，但不限制改变具体值，所以final修饰的基本数据类型和不可变类型就不能改变，但可变类型仍然可以改变
2. 可通过new一个对象形成值的拷贝，避免原属性暴露
3. 对象及属性存储在堆里，但变量名存在栈里，如string s，s内容在堆里，名字s存在栈里。iterator迭代器在迭代时，如果想删除集合内容，需要用it的remove，不能用集合的remove

5.规约【会考大题，写规约】

5.1 注意事项

1. 规约不止包含代码注释，还有对方法的声明，后者可以被编译器静态检测。
2. 对于require前置条件和effect后置条件，前置条件不满足则方法可做任何事，或用@param、@return等，正规的规约中不出现require和effect，也不需要给出具体代码实现，只需告诉调用方怎么用，包括数据类型，但是输出必须明确。
3. 尽可能使用不可变类型，假使需要使用mutating（可变类型）的方法，如果程序会改变输入的参数，必须要在规约中声名，这种情况下可以带上数据类型等信息；黑盒测试完全是根据规约进行的。

   

5.2 规约的强度

强度大的规约可以直接替代强度小的规约【当然强度相等也能替换】，强度大的规约，前置条件弱，后置条件强【可以相等】。图示表示下，强的规约被弱的规约包含。但在比较后置条件时，要以两者中较强的前置条件作为基础，此时原本更过多用户使用，更少结果被接受。程序员可在规约范围内任意选择实现方式。

5.3 好的规约

1. 内聚的——功能单一
2. 输出足够强——输出必须明确
3. 规约足够弱
4. 规约里用抽象类型（接口等）——比如不写arraylist，写list（最顶层接口）
5. 是否使用前置条件——不用就要在代码内check，如果这么做代价太大最好使用，另外private方法不给用户使用，不需要使用前置条件

5.4 行为等价性

从用户的角度考虑，抛开需求讨论两个程序的行为等价性是没有意义的