HIT 软件构造期末复习一软件构造的多维视图和质量目标

本课程为：HIT软件构造 大二下学起开设，在高级语言程序设计的基础上，认识软件构造的质量标准与目标，学习软件构造的基本过程，从而具备面向质量目标的复杂软件构造方法与能力 – 深入学习抽象数据类型 ADT 与面向对象编程 OOP– 初步掌握面向关键质量目标（可理解性、可维护性、可复用性、健壮性、时空性能）的软件构造基本技术 – 了解软件代码重构和面向更复杂软件系统的高级构造技术

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

1.多维软件视图

软件的分类方法有多种，可以分为系统软件和应用软件，个人软件和商业软件，开源软件和专利软件等；
软件是介于用户和硬件之间的媒介：

软件系统构造的基本步骤：计划->分析->设计->实现->测试->维护：

软件系统的构成有三个维度，可按照：阶段（构造时/运行时）、动态性（时刻/一个极阶段）、构造层次划分（代码层/组织层）进行划分，三者组合构成一个三维空间，由八个模块组合而成：

不同视图之间的转换：从无到有写出代码，相同功能的代码模块构成部件，不同逻辑功能的部件组合构成软件，先经历构造阶段，然后到达执行阶段，由某一时刻构成了一段阶段：

分别来看八个视图：

2.Build-time view

构造阶段步骤：想法>需求分析>设计>code>可执行文件
在构造阶段，需要软件的代码视图和架构视图，瞬间视图和阶段视图
代码视图code-level重点在代码的逻辑组织，即源代码源代码是如何逻辑组织的，通过基本的程序块，如函数，类，方法，接口，等等，以及它们之间的依赖性，。
架构视图component-level重点在代码的物理组织，即源代码的物理结构根据文件、目录、包、库和依赖关系进行组织
瞬间视图 moment:源代码和组件在一个特定的时间的形态
阶段试图period:软件是如何随着时间而演变/变化的，如版本迭代

2.1 build-time & code-level & moment

逻辑组织方式包括：
词汇层面 ：半结构化，近乎自然语言的风格+特定编程语言的语法规则
语法层面（AST） ：AST：彻底结构化，将源代码变为一棵树，对树做各种操作==对源代码的修改

语义层面（类图）：使用类图(UML)来 描述接口、类、属性、 方法以及它们之间的关系。 常是图形化或形式化的。在设计阶段建模，并转换为源代码。 它是面向对象分析和设计的结果 用户需求。

2.2 build-time & code-level & period

描述随时间的变化性
code生产代码变化:行添加、修改或删除一个文件 从一个版本到另一个版本。

code churn：被定义为添加、修改或 从一个版本删除到另一个文件。

2.3 build-time & moment & component-level

源代码被物理地组织到文件中 组织的目录;
文件被封装成包，逻辑上是组件 和子系统。
可重用模块以库的形式存在。

库存储在它们自己的磁盘文件中，收集一组代码 可以在各种程序中重用的函数。 开发者并不总是构建一个单一的可执行程序文件，而是join 定制开发的软件和预建的库到一个单一的程序。
在构建时，一个库函数可以被视为一个扩展 标准语言，与编写函数的方式相同 由开发人员。

库的来源：操作系统提供 第三方库 编程语言库 自己写的库

库的链接：当程序被编辑、构建和安装时，要创建的库列表 必须提供搜索。 如果一个函数在源代码中被引用，但是开发人员 没有明确写它，库列表被搜索定位 所需的功能。找到函数后，复制适当的目标文件 进入可执行程序。 包括 Static linking (静态链接)– Dynamic linking (动态链接)

2.4 build-time & period & component-level

软件实体随时间的变化 迭代

3 Runtime view

运行时：程序被载入目标机器，开始执行
代码层面：逻辑实体在内存中如何呈现？
构件层面：物理实体在物理硬件环境中如何呈现？
Moment view: how do programs behave in a specific time 逻辑/物理实体在内存/硬件环境中特定时刻的形态如何？
Period view: how do they behave along with time 逻辑/物理实体在内存/硬件环境中的形态随时间如何变化？

可执行程序:机器可读的程序序列 CPU执行的指令，以及相关数据 值。 这是一个完全编译的程序，可以加载到 计算机的内存和执行。
▪库:常用目标代码的集合 被不同的程序重用。 大多数操作系统都包含一组标准的库供开发者使用 可以重用，而不是要求每个程序自己提供。 一个库不能直接在目标机器上加载和执行 它 必须首先与可执行程序链接
配置和数据文件:它们不是可执行文件; 他们 提供有用的数据和配置信息说明程序 可以从磁盘加载。
分布式程序:这种类型的软件由多个组成 一种可执行程序，它可以在内存中相互通信 网络或简单地说，多个进程运行在同一上机器。 -这与更传统的软件，有一个单一的单片项目形象。 分布式程序的运行态：需要多个运行程序，分别部署于多个计算机物理环境
动态链接：库文件不会在build阶段被加入可执行软件，仅仅做出标记，程序运行时，根据标记装载库至内存，发布软件时，记得将程序所依赖的所有动态库都复制给用户

3.1 Run-time & moment & code-level

代码快照图：专注于 中的变量级执行状态 目标计算机的内存。 描述程序运行时内存里变量层面的状态；

Memory dump内存转储:硬盘上的一个文件，其中包含内容的副本 进程的内存，当某个进程被终止时产生 各种内部错误或信号。

3.2 Run-time & period & code-level view

UML中的序列图: 程序之间的交互 单位(对象 ）

3.3 Run-time & moment & component-level view

UML中的部署图

3.4 Run-time & period & component-level view

事件日志为系统管理员提供信息 对诊断和审计有用。
-将被记录的事件的不同类别，以及什么细节 将出现在事件消息中，都在开发周期中考虑。
-每一类事件被分配一个唯一的“代码”来格式化和输出一个 人类可读的信息。

总结

4.Software construction: Transformation between views

从设计者和使用者来考虑：
构建时：某一瞬间 设计者从无到有编程，使用ADT/OOP技术，写出代码，有代码设计架构·，这样的多个瞬间构成的一个时刻（时期），在一段时间内添加修改文件 模块 一段时间内有软件版本的迭代；
运行时：代码快照 物理结构图，

5.Types of Transformations in Software Construction

包括外部和内部质量因素：
外部质量因素:速度或易用性等品质， 在软件产品中可以由其用户检测到谁的存在或不存在。
内部质量因素：适用于软件产品的其他品质，例如 模块化或可读性是内部因素，只能被感知到
能够访问实际软件文本的开发人员。 内部质量因素 影响 软件本身和它的开发者。
外部质量取决于内部质量

5.1 External quality factors外部质量因素

软件需要按照实现定义的规约（spec）执行：正确性是软件产品执行其精确任务的能力 ，如其规范所定义的。 正确性是最重要的质量目标。

正确性：软件的行为要严格的符合规约中定义的行为
测试和调试：发现不正确、消除不正确 Robustness；
防御式编程：在写程序的时候就确保正确性
形式化方法：通过形式化验证发现问题

**健壮性：**针对异常情况的处理
健壮性是对正确性的补充
出现规约定义之外的情形的时候，软件要做出恰当的反应
健壮性：出现异常时不要“崩溃”
健壮性与“异常情况”有关，这意味着 正常和异常情况的概念总是相对于 特定的规范 ，未被specification覆盖的情况即为“异常情况”，所谓的“异常”，取决于spec的范畴。

可扩展性：可扩展性(可扩展性)是软件产品适应规范变化的能力，即对软件的规约进行修改，是否足够容易。
对于小程序来说，更改通常不是一个困难的问题; 但随着软件 规模越大，适应就越难。
-一个大型软件系统经常把它的维护者看作是一个巨大的房子 代码中的任何一个元素都可能导致整个大厦的倒塌崩溃；
设计简单:一个简单的架构将 总是比一个复杂的更容易适应变化 。
去中心化:自主性越强模块中，简单的改变只会影响一个模块，或者是少量的模块，而不是 引发一系列的变化 。 分离主义设计

可复用性：.一次开发，多次使用，不需要重复写相同的模块，不需要重复造轮子。关键在于找到共性。

兼容性：不同的软件系统之间相互可容易的集成，
兼容性的关键在于同质性 设计(保持设计的同构性),并达成一致 程序间通信的标准化约定。

高效性：效率是指软件系统满足最少需求的能力 尽可能少占用硬件资源，如处理器时间、空间
内存占用在内部和外部，带宽使用在通信设备。
高效性建立在正确性的基础之上，，没有足够的正确性，性能毫无意义
对性能的关注 要与 其他质量属性进行折中，过度的优化导致软件不再适应变化和复用。

可移植性：软件可方便的在不同的技术环境（操作系统，硬件）之间移植。

易用性：容易学、安装、操作、监控，给用户提供详细的指南。一个精心设计的系统，建立在一个清晰，深思熟虑的 结构基础上，会比凌乱的结构更容易学习和使用 。
这里的论点是，优秀的设计师必须努力去理解 系统的预期用户，即使用对。

5.2 Internal quality factors 内部质量因素

与源代码相关的因素，如：行 代码(LOC)、圈复杂度等
与架构相关的因素，例如 耦合、凝聚力等
可读性
可理解性
清洁度
大小
内部质量因素通常用作 外部质量因素的部分测量。

5.3 各质量之间的权衡

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

最重要的几个质量因素：
•软件构建的系统方法
•正式规范
•开发过程自动检查 更好的语言机制
•一致性检查工具
可扩展性和可重用性:模块化
OOP如何提高质量：
▪正确性:封装、去中心化
▪健壮性:封装、错误处理
▪可扩展性:封装、信息隐藏
▪可重用性:模块化、组件、模型、模式
▪兼容性:标准化模块和接口
▪可移植性:信息隐藏、抽象
▪易用性:GUI组件，框架
▪效率:可重用组件
▪时效性:建模、重用
▪经济:重用
▪功能:可扩展性

5.4 五个关键质量目标

优雅和美丽的代码： 容易理解,可理解性
重用设计便宜 为开发
低复杂性：准备 更改，易于扩展
健壮性和正确性： 安全远离bug，不容易出错
性能和效率： 高效的运行