软件构造第一章复习

软件构造第一章总结

临近考试，开始复习软件构造，发现对于一些总的概念记忆与理解不是很深刻，所以写下相关内容的博客便于自己记忆，以及自己的一些思考。

软件构造多维度视图

1.1 从三个维度看软件系统的构成

1. 按阶段划分：build-time（构造阶段）和run-time（运行阶段）视图
2. 按动态划分：moment（时刻）和period（时期）视图
3. 按层次划分：code（代码层面）和 component（构件，文件层面）视图

1.2 不同视图块的分析

Build-time, moment, code-level

这个视图块主要表现在，代码如何在逻辑上被组织为基本的程序块，例如函数、类、方法、接口等，以及其之间的依赖关系。

其有三种相关联的形态：

• 词汇层面：面向词汇的源代码
• 语法层面：面向语法的程序结构，如抽象语法树AST
• 语义层面：面向语义的程序结构，如类图
  

Build-time, period, code-level

代码在时间尺度上的变化，例如代码行的增删改。

Build-time, moment, component-level

源代码被组织为文件，文件被组织进目录；文件被包含在包中，在逻辑上也被包含在容器和子系统中；可复用的模块被组织为库。

链接技术（动态 / 静态） Library

• 操作系统提供的库

• 编程语言提供的库

• 第三方公司提供的库

• 自己编写的库

链接：编程时和build时，需告诉IDE和JVM在哪里寻找某些库。

静态链接，库被拷贝进入代码形成整体，执行的时候无需提供库文件。 静态链接发生在构造阶段。

Build-time, period, component-level

软件系统中的文件、包、容器、库随时间如何变化，或称版本如何变化。SCI 配置项的更改 VCS 版本控制系统 各项软件实体随时间如何变化 软件随时间变化的版本 版本控制（通过Git，SVN等等）

Run-time, moment, code-level

快照图(snapshot diagram)、内存转储(memory dump)。即软件在运行时保有的数据及其在内存中的结构。Memory dump（内存信息转储） 常发生在异常退出时，把内存中信息写到文件中（常用来调试）。

Run-time, period. code-level

顺序图(sequence diagram)、运行时栈跟踪(execution stack trace)，描述程序运行时间各个种类间的依赖关系，并用日志方式记录程序执行的调用次序。

Run-time, moment, component-level

部署图（各个组件被部署在了哪些机器上），根据跟踪日志里的信息进行调试或诊断软件问题

Run-time, period, component-level

事件日志（系统层面）

Event logging	Event logging
Consumed primarily by system administrators	Consumed primarily by developers
Consumed primarily by developers	Logs "low level" information (e.g. a thrown exception)
Must not be too "noisy" (contain many duplicate events or information not helpful to its intended audience)	Can be noisy
A standards-based output format is often desirable, sometimes even required	Few limitations on output format
Addition of new types of events, as well as new event messages, need not be agile	Addition of new tracing messages must be agile

各视图直接的相互联系

二、内部/外部的质量指标

外部质量因素影响用户

内部质量因素影响软件本身和它的开发者

外部质量取决于内部质量

2.1 External quality factors（外部质量因素）

1. Correctness（正确性） 按照预先定义的“规约”执行 正确性是至高无上的质量指标 每一层保证自己的正确性，同时假设其下层是正确的 测试和调试：发现不正确、消除不正确 防御式编程：在写程序的时候就确保正确性 形式化方法：通过形式化验证发现问题

2. Robustness（健壮性） 针对异常情况的处理 – 健壮性是对正确性的补充 – 正确性：软件的行为要严格的符合规约中定义的行为 – 出现规约定义之外的情形的时候，软件要做出恰当的反应 出现异常时不要“崩溃” 健壮性是主观而非客观 – 未被specification覆盖的情况即为“异常情况” – 所谓的“异常”，取决于spec的范畴

3. Extendibility（可扩展性） 定义：对软件的规约进行修改，是否足够容易的程度。 规模越大，扩展起来越不容易。 目的是为了变化。 两个准则（为了可扩展性）：简约主义设计，分离主义设计

4. Reusability（可复用性） 一次开发，多次使用 找到不同问题之间的共性

5. Compatibility（兼容性） 不同的软件系统之间相互可容易的集成 兼容性很重要因为开发设计不在真空中，所以需要相互联系 方法：保持设计的同构性并标准化

6. Efficiency（性能） 性能包括很多内容，最常见的就是时间复杂度和空间复杂度。 性能毫无意义，除非有足够的正确性。 – 对性能的关注要与其他质量属性进行折中 – 过度的优化导致软件不再适应变化和复用 过早优化是万恶之源

7. Portability（可移植性） 软件可方便的在不同的技术环境之间移植 硬件、操作系统中的移植

8. Ease of use（易用性） 容易学、安装、操作、监控 给用户提供详细的指南

9. Functionality（功能性） 每增加一小点功能，都确保其他质量属性不受到损失。 程序设计中一种不适宜的趋势，即软件开发者增加越来越多的功能，企图跟上竞争，其结果是程序极为复杂、不灵活、占用过多的磁盘空间。

10. Timeliness（及时性） 当用户需要的时候，要能及时地设计出来。

11. Other qualities： Verifiability（可验证性） Integrity（完整性） Repair ability（可修复性） Economy（经济性）

2.2 Internal quality factors（内部质量因素）

代码相关：Lines of Code (LOC代码行数), Cyclomatic Complexity（圈复杂度）,

结构相关：coupling（耦合度）, cohesion（内聚度）

可读性、可理解性、清晰、大小。

2.3 Trade-off between quality properties（质量折中）

正确的软件开发过程中，开发者应该将不同质量因素之间如何做出折中的设计决策和标准明确的写下来。 虽然需要折中，但“正确性”绝不能与其他质量因素折中，也就是说正确性是其他质量因素的前提。