哈工大软件构造笔记1

1.1Multi-dimensional software views

1、软件构造中的多维视图

 

·Moment维度关注于程序在某一时刻的表现，而Period关注的是程序在一段时间内的表现。

·Build-time维度关注程序还未被投入运行，编码阶段的表现，而Run-time维度更关注于程序运行时的表现；

·

1.build time views

code-level view: functions \classes\methods\interfaces(代码逻辑组织）

component-level view: file \directories\packages\libraries (代码物理组织）

Static linking :库被拷贝进代码形成整体，执行的时候无需提供库文件（build time）

4）build time ，period， component-level view

versioning

版本控制是给计算机软件的不同的状态分配唯一的名字或者编号的过程。

2. runtime views

（runtime就是运行，程序被载入目标机器，开始执行。）

以下是在各种视图（views）中的含义

code-level ：逻辑实体在内存中如何呈现？（in-memory states）

component-level ：物理实体在物理硬件环境中如何呈现？（physical environment）

moment：逻辑/物理实体在内存/硬件中特定时刻的形态。

period ：逻辑/物理实体在内存和/硬件中随时间如何变化。

dynamic linking :动态链接

2、视图之间的联系

 

①从无到有，写出了代码，就进入了Build-time维度，开始只是单个的没有任何联系的代码文件，所以是在moment+Code-level维度；

②此时随着时间的推移，代码删删改改，就属于Period+Code-level了，而代码越写越多成为了一个包，甚至形成了一个库，于是就属于moment+Component-level维度了；

③但是随着时间的推移，库文件由于需求的变化发生了变化，所以就属于Period+Component-level；

④代码写好了，投入运行，进入Run-time维度，观察的如果是某一句代码的执行后结果，那就是moment+Code-level维度，但如果看的是代码执行的轨迹，那就是Period+Code-level维度，而如果看的是一个库文件的连接情况等，那就是moment+Component-level维度了；

⑤如果看的是线程或进程的执行过程，也就是通过日志等手段查看一段时间内系统都做了什么事情，那么就是Period+Component-level了。

1.2 Quality Objectives of Software Construction

1、外部质量与内部质量

外部质量因素影响用户，内部质量因素影响软件本身和它的开发者，外部质量取决于内部质量。

2、外部质量的具体方面

（1）正确性（Correctness）：至高无上的质量指标，按照预先定义的“规约”执行。一个可用的软件一定是正确的，所以首要保证软件的正确性，其他的都可以做妥协、让步，但只有这一项不可妥协。

（2）健壮性（Robustness）:是对正确性的补充，即在出现“规约”定义之外的情形的时候，软件要做出恰当的反应，通俗地说就是出现异常时不要“崩溃”。

但软件的“正常”与“异常”是主观而非客观的，所谓的“异常”，取决于spec的范畴，那些未被“规约”覆盖的情况即为“异常情况”。

（3）可扩展性（Extendibility）

（4）可复用性（Reusability）

（5）兼容性（Compatibility）

（6）效率（Efficiency）

（7）可移植性（Portability）

（8）易用性（Easy of use）

（9）功能性（Functionality）

3、折中处理

①正确的软件开发过程中，开发者应该将不同质量因素之间如何做出折中的设计决策和标准明确的写下来；

②当某一项满足的足够好的时候有可能其他项的表现极差，此时需要做权衡，使得各部分的表现都较好，在某些特定要求下也可以放弃优化其他项而做到某一项的极致；

③虽然需要折中，但“正确性”绝不能与其他质量因素折中。

5、五个关键的质量指标

·Elegant and beautiful code：代码要容易理解，通过统一变量/方法的命名标准、代码的风格、注释、包组织结构、必要时重构代码等方式让代码尽可能的容易理解。

·Design for/with reuse：ADT/OOP、接口、继承(Overload、Override)、多态、泛型、框架等技术可用于提高代码的可复用性。

·Low complexity：当复杂度较低的时候，代码就容易被扩展新的功能，所以要高内聚低耦合，遵从SOLID原则、OO设计模式、使用VCS控制代码版本

·Robustness and correctness：使用测试驱动的开发、异常处理、Assertion机制、防御式编程等技术保证程序的健壮性和正确性。

·Performance and efficiency：使用设计模式、并行/多线程等技术提升性能。

二、软件测试与测试优先编程

认可“测试”的价值，搞清楚“测试优先”的哲理

1.测试的特点

测试：

–> 在规定的条件下对程序进行操作，以发现程序错误，衡量软件品质，并对其是否能满足设计要求进行评估的过程。

①测试跟其他活动的目标相反：破坏、证错、“负能量”，即我们希望发现“错误”，要转变心态，用“让其出错”和“尽快出错”作为写高质量代码的日常法宝；

②要认识到即使是再好的测试也不能保证程序里不存在错误

2.测试用例

测试用例 = 输入+执行条件+结果

最主要的方法——单元测试：针对软件的最小单元模型开展测试，隔离各个模块，容易定位错误和调试。

基于等价类划分的测试：将被测函数的输入域划分为等价类，从等价类中导出测试用例。

此外还要注意边界值分析方法的补充，即在进行等价类划分的时候，需要把边界也作为等价类之一加入考虑。

3.代码覆盖度

覆盖度：

1.代码覆盖度

–> 基于代码的测试覆盖评测测试过程中已经执行的代码的多少，与之相对的是要执行的剩余代码的多少。

2.输入空间覆盖度

–> 参照模块的规格说明，测试用例占总输入空间的比例。

效率：

–> 成果（测试结果）/资源（测试时间空间）

代码覆盖度越低，测试越不充分，但要做到很高的代码覆盖度，需要更多的测试用例，测试代价高。

测试效果：路径覆盖 > 分支覆盖 > 语句覆盖

测试难度：路径覆盖 > 分支覆盖 > 语句覆盖

4.两类测试

黑盒测试：黑盒测试：用于检查代码的功能，不关心内部实现细节。检查程序是否符合规约

白盒测试：要考虑内部实现细节，根据程序执行路径设计测试用例。一般比较早执行