第一讲-软件构造的多维度视图和质量目标

1. 多维度软件视图 

1.1 多维度软件视图的概念

软件构造的多维度视图是指从不同的视角来观察和理解软件系统。这些视图有助于我们全面地把握软件的各个方面，从而在构造过程中做出更明智的决策。

1.2 按阶段划分的视图

• 构造时视图（Build-time views）：涉及软件从概念到可安装/可执行包的整个构造过程。包括源代码的逻辑组织、物理组织、特定时刻的软件形态以及软件形态随时间的变化。
• 运行时视图（Run-time views）：关注程序在目标机器上运行时的状态，包括内存中的程序单元如何交互以及软件包如何在物理环境中部署和交互。

1.3 按动态性划分的视图

• 时刻视图（Moment views）：在特定时间点上，源代码和组件的状态。
• 阶段视图（Period views）：随着时间的推移，源代码和组件如何发展和变化。

1.4 按构造对象的层次划分的视图

• 代码视图（Code-level views）：关注源代码的组织方式，包括基本程序块（如函数、类、方法、接口）的逻辑结构，以及它们之间的依赖关系。
• 构件视图（Component-level views）：关注源代码的物理组织，包括文件、目录、包、库以及它们之间的依赖关系。

1.5 各视图的元素、关系和模型

• 构造时视图的元素：源代码、抽象语法树（AST）、接口-类属性-方法（类图）、包、文件、静态链接、库、测试用例、构建脚本（组件图）。
• 运行时视图的元素：代码快照、内存转储、包、库、动态链接、配置、数据库、中间件、网络、硬件（部署图）、执行栈跟踪、并发多线程、事件日志、多进程、分布式进程、过程调用图、消息图（序列图）。

1.6 软件构造：视图之间的转换

• 编程/编码：涉及活动数据类型/面向对象编程（ADT/OOP）、代码审查、静态分析/检查。
• 代码到组件：涉及设计（ADT/OOP；可重用性；可维护性）、编译、静态链接、打包、安装等构建活动。
• 构造时到运行时：涉及安装/部署、调试、单元/集成测试（鲁棒性和正确性）。
• 时刻到阶段：涉及版本控制、加载、动态链接、执行（内存转储、性能分析、日志记录）、并发线程。

1.7 软件构造的不同视图的应用

• 在构建时，开发者关注源代码的编写、组织和初步测试。
• 在运行时，关注软件的实际执行、性能和稳定性。
• 时刻视图帮助开发者理解特定时间点的状态，而阶段视图则提供了随时间变化的演进视角。
• 代码视图侧重于单个文件和代码块的细节，而构件视图则从更宏观的角度审视整个系统的组件和架构。

2.阶段划分

软件构造通常被划分为两个主要阶段：

1. 构造时（Build-time）：涉及软件从概念到实现的过程，包括设计、编码、编译、链接和打包等活动。
2. 运行时（Run-time）：涉及软件在目标机器上执行时的状态和行为，包括程序的加载、执行、错误处理、性能表现等。 

2.1 构造时（Build-time）的构造活动

在构造时阶段，以下构造活动通常被执行：

• 需求分析：将业务需求转化为软件需求。
• 设计：创建软件架构和详细设计，包括数据结构、接口和算法的选择。
• 编码：根据设计编写源代码，涉及编程逻辑和数据结构的应用。
• 代码审查：通过同行评审来提高代码质量和可维护性。
• 静态分析：使用工具检查代码质量，发现潜在的错误和代码风格问题。
• 编译：将源代码转换为机器可读的代码。
• 静态链接：将编译后的代码与库文件链接，生成可执行文件。
• 打包：将所有必要的文件（如可执行文件、配置文件、资源文件等）打包成安装包或分发包。
• 安装：在目标机器上安装软件。
• 版本控制：管理软件的不同版本，跟踪变更历史。

2.2 运行时（Run-time）的构造活动

在运行时阶段，以下构造活动通常被执行：

• 加载：将软件的可执行文件和必要的库文件加载到内存中。
• 动态链接：在程序执行时动态地链接到所需的库文件。
• 执行：程序开始运行，执行其预定的功能。
• 错误处理：程序能够适当地响应异常和错误条件。
• 调试：如果程序运行出现问题，进行调试以查找和修复错误。
• 性能分析：评估程序的运行效率，识别性能瓶颈。
• 日志记录：记录程序运行时的事件和状态，用于问题诊断和监控。
• 内存转储：在发生严重错误时，保存程序的内存状态以供后续分析。
• 多线程和并发处理：确保程序能够正确地管理多线程和并发操作。
• 单元测试和集成测试：验证程序的各个部分是否按预期工作，以及它们是否能够协同工作。

2.3 视图之间的转换

软件构造还包括不同视图之间的转换，这些转换活动包括：

• 从需求到代码：将用户需求转化为实际的代码实现。
• 从代码到组件：将编写的代码组织成可重用的组件。
• 从构造时到运行时：确保软件在构造时的活动能够顺利转换到运行时的活动，例如通过适当的安装和部署策略。
• 从时刻到阶段：管理软件在不同开发阶段的状态，以及随时间的演变。 

 

 

外部质量指标（External Quality Factors）

外部质量指标是指那些软件产品的用户可以直接感知的质量属性：

1. 正确性（Correctness）：软件产品按照其规格说明书准确执行任务的能力。它是最重要的质量指标之一，可通过测试、调试、防御式编程和形式化方法来确保。

2. 健壮性（Robustness）：软件系统对异常情况的适当反应能力。它补充了正确性，确保系统在遇到未被规格说明书覆盖的情况时，不会引起灾难性事件，能够产生适当的错误消息，干净地终止执行，或进入所谓的“优雅降级”模式。

3. 可扩展性（Extendibility）：软件产品适应规格变化的容易程度。随着软件规模的增长，适应变化变得更加困难，因此需要设计简约和模块化来提高可扩展性。

4. 可复用性（Reusability）：软件元素用于构建许多不同应用程序的能力。可复用性来自软件系统通常遵循相似模式的观察，应该可能利用这种共性，避免重新发明已经解决的问题的解决方案。

5. 兼容性（Compatibility）：软件元素与其他元素结合的容易程度。兼容性的重要性在于，软件开发不是在真空中进行的，它们需要相互交互。

6. 效率（Efficiency）：软件系统对硬件资源（如处理器时间、内部和外部存储器占用空间、通信设备使用的带宽）的需求尽可能少的能力。

7. 可移植性（Portability）：软件产品转移到不同硬件和软件环境的容易程度。

8. 易用性（Ease of Use）：不同背景和资质的人学习使用软件产品并应用它们解决问题的容易程度。

9. 功能性（Functionality）：系统提供的可能性范围。功能主义可能导致程序变得极其复杂、不灵活、占用过多的磁盘空间。

10. 及时性（Timeliness）：软件系统在用户期望的时间或之前发布能力。

11. 可验证性（Verifiability）：准备验收程序、特别是测试数据以及在验证和操作阶段检测故障并追踪到错误的程序的容易程度。

12. 完整性（Integrity）：软件系统保护其各种组件（程序、数据）免受未经授权的访问和修改的能力。

13. 可修复性（Repairability）：方便修复缺陷的能力。

14. 经济性（Economy）：与及时性相伴，系统在分配的预算内或低于预算完成的能力。

内部质量指标（Internal Quality Factors）

内部质量指标是指那些只有开发者才能感知的软件产品的质量属性，通常作为外部质量指标的部分度量：

1. 源代码相关因素：如代码行数（LOC）、圈复杂度等。

2. 架构相关因素：如耦合度、内聚性等。

3. 可读性（Readability）：代码是否容易阅读和理解。

4. 可理解性（Understandability）：系统设计和实现是否容易理解。

5. 清晰度（Clearness）：代码和架构的清晰度。

6. 大小（Size）：组件或系统的规模。

内部质量因素通常用于作为外部质量因素的部分度量，因为它们直接影响软件的维护、扩展和复用等能力。复杂度通常被视为几乎所有外部质量因素的敌人，因此需要在设计和实现过程中予以控制。

质量指标之间的权衡（Tradeoff between Quality Properties）

开发者在追求一个质量指标时，往往需要在其他质量指标之间做出权衡。例如，为了完整性可能会引入各种保护措施，这可能会影响易用性；经济性与功能性之间可能存在冲突；最佳效率可能需要对特定硬件和软件环境的完美适应，这与可移植性和重用性相悖；及时性的压力可能会使我们倾向于使用“快速应用开发”技术，其结果可能在可扩展性方面表现不佳。

在软件开发过程中，正确性是一个不应为了其他关注点（如效率）而妥协的因素。如果软件不能执行其功能，其他一切都没有意义。开发者需要明确权衡的标准，并有意识地做出选择。