多维度视图
Build-time Views (构造阶段)
Build-time, moment, and code-level view
描述源代码如何按基本程序块进行逻辑组织,如函数、类、方法、接口等,以及它们之间的依赖关系。(代码的逻辑组织)
- 词汇层面:面向词汇的源代码
- 语法层面:面向语法的程序结构(AST, 抽象语法树)
- 语义层面:面向语义的程序结构(类图)
Build-time, period, and code-level view
- Code churn:描述一段时间内代码变化。
Build-time, moment, and component-level view
源代码如何按文件、目录、包、库以及它们之间的依赖关系进行物理组织。(代码的物理组织)
- 源代码被物理地组织成文件,这些文件进一步按目录组织
- 文件封装在包中,从逻辑上讲,封装到组件和子系统中
- 可重用模块采用库的形式组织
Build-time, period, and component-level view
描述各项软件实体随时间如何变化。
- 配置项(SI),版本(Version)等
Runtime Views (运行阶段)
Run-time, moment, and code-level view
-
代码快照图:描述程序运行时内存里变量层面的状态
-
内存信息转储:硬盘上的文件,其中包含进程内存内容的副本,当进程因某些类型的内部错误或信号而中止时生成
Run-time, period and code-level view
- UML中的流程图:描述在一段时间内不同程序单元的交互情况
- Execution tracing 执行跟踪:用日志方式记录程序执行的调用次序
Run-time, moment, and component-level view
- UML中的组件图
Run-time, period, and component-level view
- 系统层面的事件日志:事件日志记录为系统管理员提供了对诊断和审计有用的信息
视图间的转换
软件系统的质量指标
外部与内部的质量因素
- 外部质量因素:影响用户
- 内部质量因素:影响软件本身和它的开发者
- 外部质量取决于内部质量
外部质量因素
正确性
评价软件是否按照预先定义的“规约”执行,是最重要的质量指标。
- 测试以及调试来保证正确性
- 防御式编程:写程序时就确保正确性
- 形式化方法:通过形式化验证来发现问题
健壮性
描述软件能否正确处理异常情况,是对正确性的补充。
- 正确性:软件的行为要严格的符合规约中定义的行为
- 健壮性:出现规约定义之外的情形的时候,软件要做出恰当的反应
- “normal”和“abnormal”是主观而非客观:所谓的“异常”,取决于spec的范畴,未被spec覆盖的情况即为“异常情况”
可扩展性
评价对软件的规约进行修改是否足够容易。
问题规模越大扩展越不容易,扩展是为了应对变化。
两条原则:
- 简约主义设计(软件结构简单)
- 分离主义设计(解除模块耦合)
可复用性
即描述是否可以“一次开发,多次使用”
发现不同场景的共性
- 不要重复你自己(DRY)
- 不要重复造轮子
软件性能
描述软件系统对硬件资源提出尽可能少的需求的能力
- 性能毫无意义,除非有足够的正确性
- 对性能的关注 要与 其他质量属性进行折中
- 过度的优化导致软件不再适应变化和复用
及时性
描述软件是否能够按时发布,过晚地发布将不能达到软件原本的目标。
内部质量因素
- 与源代码相关的因素,如代码行(LOC)、循环复杂性等
- 与体系结构相关的因素,如耦合、内聚度等
- 可读性,易理解性,清晰/确切性,大小等
内部质量因素通常被用作外部质量因素的部分测量。
不同质量指标间折中
正确的软件开发过程中,开发者应该将不同质量因素之间如何做出折中的设计决策和标准明确的写下来。
虽然需要折中,但“正确性”绝不能与其他质量因素折中。
软件构造的五大关键质量目标
- 优雅的代码——易于理解
- 复用性设计——节约开发成本
- 低复杂度——易于改变,扩展
- 正确性和健壮性——没有漏洞,不易出错
- 性能和效率——高效运行