软件构造系列学习笔记（1.1）——— 软件构造的多维视图

软件构建的多维视图

1. 前记
2. 构成软件系统的三个维度
3. 软件构造的八个多维视图
4. 视图之间的转变
5. 总结

---

前记

这篇博客是软件构造系列学习笔记的第一篇，也是我博客的第一篇。开通博客主要也是因为教授软件构造课程（使用语言为Java）老师的要求，用来记录学习MIT的这门课我觉得也是很不错的方法。由于笔者不太善于表达同时能力水平有限，故博客难免有错误之处，敬请指正，但我会尽我所能地记录下学习这门课的点滴感悟。

构成软件系统的三个维度

构成软件系统主要有三个维度：

1. By phases: build- and run-time views
2. By dynamics: moment and period views
3. By levels: code and component views

以上是英文的定义。在三个维度中每个维度都包含两个views（视图）。下面对这些视图进行介绍。

build- and run-time views

Build-time views 简单翻译为构造阶段视图，从想法到用户需求到产品设计到代码编写再到可安装/可执行的程序包，其实都属于构造阶段。

idea => requirement => design => code => installable / executable package

从code-level来看，build-time views意味着代码的逻辑组织，源代码是如何通过例如functions, classes, methods, interfaces等基本的代码块有逻辑的组织起来，以及相互之间的依赖关系。

从component-level来看，build-time views意味着代码的物理组织，源代码是如何通过 files, directories, packages, libraries组织起来，以及相互之间的依赖关系。

从moment-view来看，build-time views意味着特定时刻的软件形态。

从period-view来看，build-time views意味着软件形态随时间的变化。

---

Run-time views 简单翻译为运行阶段视图，当你的程序在目标机器中运行时表现如何，以及在运行时目标机器要将哪些磁盘文件存入内存等等，这些问题都是run-time views所关注的。

从code-level来看，run-time views意味着一个可执行程序在内存中的状态以及程序内部各个单元间（例如Objects和functions等）如何相互调用。

从component-level来看，run-time views意味着软件包是如何部署到具体的物理环境中（例如操作系统，网络，硬件等），以及他们之间如何相互作用。

从moment-view来看，run-time views意味着一个程序在特定时刻的表现。

从period-view来看，run-time views意味着程序随时间变化的一系列表现，包括过程调用图（Procedure Call Graph），消息图（序列图）（ Message Graph (Sequence Diagram)），并行和多线程/进程（Parallel and multithreads/processes），分布式进程（Distributed processes）等。

---

Moment and Period views

Moment views简单翻译为特定时刻视图，Period views简单翻译为阶段视图，从moment和period这两个英文单词就可看出这两个视图之间的差异，前一个着眼于软件在某一特定时刻的表现或者组织结构，后一个着眼于软件在某个阶段一系列的表现变化或者组织结构的变化。

---

Code and Component views

Code views简单翻译为代码视图，Component简单翻译为组件视图。这两个视图的差异主要在于前一个着眼于程序本身，包括程序自身的逻辑组织以及程序在内存中的状态。后一个着眼于程序的外部物理环境，包括程序的物理组织以及程序是如何部署到不同的物理环境中的。

---

软件构造的八个多维视图

在前面软件构造的三个维度中介绍了六个视图，其实在这六个视图中相互之间是有联系的，在介绍build-time view 和 run-time view的时候也已经涉及到了，在这一节中，我会详细介绍不同维度的不同视图三个三个组成的多维视图，共有八个多维视图。

（1）Build-time, moment, and code-level view

在这个多维视图中，有三个相互关联的形式：

• 词汇层面
• 语法层面
• 语义层面

词汇层面指的是基于词汇的半结构化源代码（Lexical-based semi-structured source code），半结构化是指近乎自然语言的风格+遵循特定的编程语法，前者方便程序员，后者方便编译器。

语法层面指的是面向语法的程序结构（Syntax-oriented program structure），具体例子有抽象语法树（AST）。

AST：彻底结构化，将源代码变为一棵树，对树做各种操作等于对源代码的修改。

在Java中有专门的类可将源代码转换为AST，并对AST做各种操作，具体过程可参考下图。

语义层面指的是面向语义的程序结构（Semantics-oriented program structure），语义是指源代码具体想实现什么目标。具体例子有使用类图Class Diagram（UML）来描述 interfaces, classes, attributes, methods以及它们之间的关系。下图既是一张Class Diagram。

（2）Build-time, period, and code-level view

这个多维视图描述了代码随时间的变化（Code churn），包括代码行的增加，删除和修改。

Code churn is defined as lines added, modified or deleted to a file from one version to another.

用过github的人应该很熟悉这张图，这张图就体现了Code churn，图中绿色部分代表新增加的代码，红色部分代表删除的代码。

（3）Build-time, moment, and component-level view

这个多维视图着眼于源代码被物理地组织成文件（file），这些文件进一步由目录组织。文件被封装成包（package），并在逻辑上封装组件和子系统。可重用模块以库（library）的形式存在，具体例子见下图。

在编程时和build时，需告诉IDE和JVM在哪里寻找某些库 ，将库整合到可执行程序中有两种不同方法，静态链接和动态链接，静态链接发生在build-time阶段。

（4）Build-time, moment, and component-level view

这个多维视图着眼于各项软件实体（例如files/packages/components/libraries）随时间如何变化，Software Configuration Item (SCI，软件配置项) 以及版本（Version）的演变。

Software versioning is the process of assigning either unique version names or unique version numbers to unique states of computer software.

对于每个软件，都会有一个初始版本，并在此版本的基础上逐步发展，在发展的过程中，不断发布新的版本，直到Final Version。在此过程中，我们通常使用Version Control System (VCS)即版本控制系统来对软件的版本进行管理，现在流行的VCS主要是git，下图展示了软件版本的不断发展。

(5) Run-time, moment, and code-level view

这个多维视图着眼于程序运行时在某个特定时刻的代码层面的状态，主要工具有快照图（Snapshot diagram）和内存信息转储（Memory dump ）。

快照图描述了程序运行时内存里变量层面的状态，内存信息转储是指硬盘上的一个文件，它是当进程因特定类型的内部错误或信号而中止时产生的，其中包含进程内存的副本。

(6) Run-time, period and code-level view

这个多维视图着眼于程序运行阶段在某一段时间内在代码层面的视图，以下面UML中的Sequence diagram为例，图中体现了程序各个单元间的交互。

在这一视图中主要涉及到执行跟踪（Execution tracing），即用日志方式记录程序执行的调用次序，这通常由程序员用于调试目的，并根据跟踪日志中包含的信息的类型和详细信息，由有经验的管理员或技术支持人员以及软件监视工具来诊断软件的常见问题 。

(7) Run-time, moment, and component-level view

这一多维视图着眼于程序运行阶段在某一特定时刻在组件层面的视图，以下面UML中的部署图为例，图中展示了各个组件的相互联系。

(8) Run-time, period, and component-level view

这一多维视图着眼于程序在运行阶段在某一阶段的组件层面视图，这一视图主要涉及到事件日志（Event logging），事件日志为系统管理员提供了对诊断和审计有用的信息。每一类事件都被赋予一个唯一的“代码”来格式化并输出一条人类可读的消息。这有利于本地化，并允许系统管理员更轻松地获得有关发生问题的信息。

下图展示了事件日志和执行追踪的区别

视图之间的转变

以下图来总结各个视图之间的转变。

总结