#软件构造 软件构造过程中的多维度视图

这个地方涉及的知识点多且杂，需要系统性的整理一下

首先提几个概念：

• Build-time Views，即为构造阶段，具体流程就是程序涉及和具体的编程的过程
• Runtime Views，运行时，意思是程序被载入目标机器，开始执行的阶段
• Moment view 实体在特定时刻的形态如何？
• Period view 实体在随时间如何变化？
• Code-level view源代码层面：
• Component-level view: 组件级层面
  因此，我们可以对上面那张表中的内容进行理解
  （因为OneNote到2020年了都不支持合并表格就不画了）

---

Build-time Views

Moment— Code-level view

主要指代码的逻辑组织，比如源代码本身，可以分为三个层面，下面介绍这三个层面和描述他们的方式

• 词汇层面： 本身的词汇，近乎自然语言的风格+遵循特定的编程语法
• 语法层面：抽象语法树 (AST)
• 语义层面：源代码具体想实现什么目标？ UML类图(Class Diagram)

Moment — Component-level view

包，文件，静态链接，库，测试案例，构建脚本这种东西
同样可以使用 UML图来描述这些关系

Period — Code-level view

主要来描述代码随时间的变化
Code churn ：代码改动量 定义为从一个版本另一个版本的文件添加，修改或删除文件的而产生的变化
举个例子：

Period — Component-level view

描述的是各项软件实体随时间如何变化

Software Configuration Item (SCI，配置项)

Version(版本) 可以用版本控制工具（VCS）来描述

---

Runtime Views

Moment— Code-level view

源代码层面：逻辑实体在内存(类，方法)中的瞬时呈现
可以用
代码快照图(Code Snapshot )：描述程序运行时内存里变量层面的状态
如

与
内存信息转储(Memory dump )：将内存中的数据转储保存的转储文件

Moment — Component-level view

物理实体在物理硬件环境（操作系统，网络，硬件…）中的瞬时呈现
可以使用部署图(Deployment Diagram）进行分析

Period — Code-level view

源代码层面：逻辑实体(如类，方法)在内存中随时间而变化
可以：

• 执行跟踪（Execution tracing ）——用日志方式记录程序执行的调用次序
• 堆栈轨迹（stack trace）——打印出某个时间的调用堆栈状态

Period — Component-level view

物理实体在物理硬件环境（操作系统，网络，硬件…）中随时间而变化
可以用事件记录日志（Event log）进行分析

---

一些QA

Q：Memory dump属于软件三维度视图的什么层次？
A：由表中所示,属于Moment和component-level view层次

Q：Execution stack trace和code snapshot在软件三维度视图中的共性特征是：
A：都是run-time view

Q：Code Churn和AST分别是属于什么阶段的视图？
A：都是在Build阶段，前者属于随时间变化的描述，而后者是瞬时的描述

Q：Static linking和Dynamic linking的区别在于：
A：前者发生在构造阶段，后者发生在运行阶段

一些观点

Code static analysis是发生的在build-time

Deployment是把build-time的软件转换为run-time的软件的手段之一

Files随时间发生变化，产生各个不同版本，按时间连起来形成period view

对软件的profiling和tracing均发生在run-time