软件构造的多维度视图及软件设计的质量指标
一、软件构造的多维度视图
1. Build-time Views
构造时遵循idea ->requirement ->design-> code ->installable / executable package的框架
具体地，从以下两个维度看待：
a)By levels: code and component views
Code-level view:源代码——代码的如何以程序基础的blocks(such as functions, classes, methods, interfaces,etc)来逻辑上把他们组合起来。
Component-level view:体系结构——代码是如何物理上( such as files, directories, packages, libraries)进行组织起来的
b) By dynamics: moment and period views
Moment view：what do source code and component look like in a specific time 特定时刻的软件形态
Period view: how do they evolve/change along with time 软件形态随时间的变化
这样，将衍生出下面四个视图 ：
（1）Build-time, moment, and code-level view
源代码如何通过基本程序块（如函数，类，方法，接口等）以及它们之间的依赖关系进行逻辑上的组织。
有三种形式：
词汇层面：基于词汇的半结构化源代码。半结构化，即近乎自然语言的风格+遵循特定的编程语法，既方便程序员，也方便编译器。
语法层面：面向语法的程序结构: e.g., 抽象语法树Abstract Syntax Tree(AST)。抽象语法树，彻底结构化，将源代码变为一棵树，对树做各种操作相当于对源代码的修改
语义层面：面向语义的程序结构: e.g., Class Diagram
通常是图形化或形式化的，在设计阶段进行建模，并转换为源代码。它是面向对象的分析和设计在用户需求方面的结果。例如：利用UML来描述接口，类，属性，方法和它们之间的关系。
(2) Build-time, period, and code-level view
表示了随着时间变化的观点。
Code churn代码变化：被定义为添加，修改或删除从一个版本到另一个版本的文件。
(3) Build-time, moment, and component-level view
源代码被物理地组织成文件，这些文件进一步组织成目录;
文件被封装成包，并在逻辑上封装成组件和子系统。
可复用模块采用库的形式。在build时需要执行静态链接，将库拷贝入代码形成整体，在执行时无需提供库文件。
(4) Build-time, period, and component-level view
关注各项软件实体随时间如何变化
从Software Configuration Item (SCI）软件配置项目和Version版本上进行观察
2. Runtime Views
程序在机器内运行时是什么样的，机器需要加载到内存中的所有磁盘文件是什么
运行时软件的高级概念：
Executable programs（可执行程序）:
The sequence of machine-readable instructions that the CPU executes, along with associated data values.CPU执行的机器可读指令序列以及相关的数据值。
这是完全编译的程序，可以加载到计算机的内存中并执行。
Libraries（库）:
常用代码的集合，可以被不同的程序复用。
大多数操作系统都包含一组标准的库，供开发人员重复使用，而不是要求每个程序都提供自己的库。库不能直接加载并在目标机器上执行; 它必须首先与一个可执行程序链接。动态链接的情况下，库文件不会在build 阶段被加入可执行软件，仅仅做出标记，程序运行时，根据标记装载库至内存，发布软件时，记得将程序所依赖的所有动态库都复制给用户。
Configuration and data files（配置和数据文件）：
这些不是可执行文件，它们提供程序从磁盘加载的有用数据和配置信息。
Distributed programs（分布式程序）：
这种类型的软件由多个可执行程序组成，这些程序可以通过网络相互通信，或者在同一台计算机上运行的多个进程。
这与具有单个单片程序映像的更传统的软件形成鲜明对比。
接下来从以下两个维度考察：
a)By levels: code and component views
Code-level view:源代码----可执行程序的内存状态是什么样的，程序单元（对象，函数等）如何相互交互
Component-level view:体系结构----软件包如何部署到物理环境（操作系统，网络，硬件等）以及它们如何进行交互
b) By dynamics: moment and periodviews
Moment view：how do programs behave in a specific time特定时刻的程序形态
Period view: how do they behave along with time 软件随时间的表现
（5） Run-time, moment, and code-level view 快照图（Snapshot diagram）：描述程序运行时内存里变量层面的状态
Memory dump (内存信息转储)：一个包含进程内存副本的硬盘上的文件，当进程被某种内部错误或信号中止时产生。
(6) Run-time, period and code-level view
程序执行时调用的关系次序。
UML中的顺序图：程序单元（对象）之间的交互
Execution tracing 执行跟踪
用日志方式记录程序执行的调用次序，这通常由程序员用于调试目的，并根据跟踪日志中包含的信息的类型和详细信息，由有经验的管理员或技术支持人员以及软件监控工具来诊断软件的常见问题。
(7) Run-time, moment, and component-level view
UML中的Deployment diagram（配置图）
(8) Run-time, period, and component-level view
事件记录为系统管理员提供了对诊断和审计有用的信息。
在开发周期中将考虑将要记录的不同类别事件以及事件消息中将显示的细节。每一类事件都被分配一个唯一的“码”来格式化和输出一个程序员可读的消息。这有利于本地化，并允许系统管理员更轻松地获得有关发生问题的信息。
总的来说，软件构造可以看做是不同视角之间的转换
二、软件构造的质量指标
(1) External quality factors
如速度或易用性，被用户体验的指标。
External 1: Correctness
正确性：至高无上的质量指标， 按照预先定义的“规约”执行
保证正确性的方法：
分层：每一层保证自己的正确性，同时假设其下层是正确的
测试和调试 ：发现不正确、消除不正确
防御式编程：在写程序的时候就确保正确性
形式化方法：通过形式化验证发现问题
External 2: Robustness
健壮性：针对异常情况的处理， 健壮性是对正确性的补充，出现规约定义之外的情形的时候，软件要做出恰当的反应。未被specification覆盖的情况即为“异常情况”，所谓的“异常”，取决于spec的范畴
External 3: Extendibility
可扩展性： 对软件的规约进行修改，是否足够容易，规模越大，扩展起来越不容易，分离主义设计，简约主义设计有利于可拓展性的维持。
External 4: Reusability
一 次开发，多次使用，重点在于发现共性。
External 5: Compatibility
不同的软件系统之间相互可容易的集成。保持设计的同构性，标准化文件格式，数据结构，用户界面，协议。
External 6: Efficiency
性能毫无意义，除非有足够的正确性，对性能的关注要与其他质量属性进行折中，过度的优化导致软件不再适应变化和复用。
External 7: Portability
软件可方便的在不同的技术环境之间移植
External 8: Ease of use
容易学、安装、操作、监控，给用户提供详细的指南。
External 9: Functionality
程序设计中一种不适宜的趋势，即软件开发者增加越来越多的功能，企图跟上竞争，其结果是程序极为复杂、不灵活、占用过多的磁盘空间。
External 10: Timeliness
Timeliness（及时性）是软件系统在用户需要时或之前发布的能力。
(2) Internal quality factors
内部质量因素影响软件本身和它的开发者
（1）代码的行数
（2）复杂度
（3）耦合度与聚合度
（4）易读易理解
（5）整洁
设计时要在不同的指标之间进行折中。