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

软件构造的多维视图

三个维度

（1）编程时&运行时
（2）时间&时刻
（3）微观和宏观
从这三个维度来看待软件构造，那么在这写维度的组合下，我们更关注一些什么呢？下图或许能解答你的疑惑！

如图中所展示的九个内容，在下面将一一做出说明。

编程时的视图下

对于微观上的视图（Code-level view），我们更加关注的是源代码：source code。在这个视图下，主要分析代码的逻辑组织，即源代码是怎样在基本的编程块，例如函数、类、方法、接口等，在这些的基础上的逻辑组织。
对于宏观的视图（Component-level view），我们更加关注的则是整个工程的结构：architecture。此时，像文件、路径、包、库以及他们之间的相关性，则更加值得我们注意，换句话来说，在这个视图下，主要跟分析代码的物理组织。
而在特定的时刻下，源代码和整体工程的特定形态也是我们分析代码的编程情况中必不可少的部分。
最后，在一段时间内，也可以说是一定周期内（软件的开发呈现一定的周期性，这个问题之后或许会再来探讨），我们更关注的是发展和变化，在这段时间内修改的内容，添加的方法等等，而这些变化，人为的记录未免强人所难，这时，一个好的软件管理工具的使用能大大提高软件开发的效率，暂且按下不提。

（1）Build-time，moment，code-level view

源代码在代码各部分的基础上是怎样逻辑组织的，例如函数、类、方法、接口等，以及它们之间的关系。
而这些又可以从三个层面来看待：词汇层面、语法层面（例如：Abstract Syntax Tree（AST））、以及语义层面（例如：Class Diagram）

词汇层面

即程序代码中使用的语句、字符串、以及变量以“近乎自然语言的风格+遵循特定的变成语法”的组织形式形成一种半结构化的源代码语言，这既方便了程序员的阅读，同时方便编译器的编译。

如图，相信即使不懂Java语言，也能轻松看懂图中的代码做了一些什么事，而这样的组织结构，让不同的程序员在阅读他人的代码时节约时间。

语法层面

对于语法的层面，更加注重的是软件执行的过程，或者说是软件执行的算法流程。

以图中左侧代码为例，构造出了AST（语法分析树），对应的就是程序执行的流程
同样对于数据或者文件的操作也同样可以构造除AST来描述整个操作的流程。而AST的目的就是将程序彻底结构化，把源代码变成一棵树，对树做各种操作就是对源代码的修改。这应该怎么理解呢？
以上图文件读取为例，在开发过程中，对读入文件的方式做出修改的话，只需要修改图中的①部分。这样结构分明的一棵树，便于修改的一种组织方式，对于我来说是没办法拒绝的。

语义层面

语义的含义是指源代码具体现实什么目标，例如：用UML来描述接口、类、属性、方法及它们之间的关系。而这些通常用图形化或者形式化的方法来表达“需求”和“设计”思想。如下图：

该图相信可以清晰的表示人和学生、教授之间的关系，以及人与地址之间的关系。

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

主要关注的是编码时，代码的改变情况，即Code churn 代码变化，包括添加的行、文件的改进或删除、从一个版本到另一的版本的变化。
而实现这些的管理，仅仅依靠自己是非常困难的，因此我们一般会使用一些版本控制工具。

例如图中红色区域，就是该次修改的项目。更加清晰直观的表现出了变化的发生位置，设想这样一个场景，昨天保存的代码已经通过测试没有问题，而今天出现了bug，通过这样的版本控制工具就能尽快的定位到代码可能出错的位置。

(3) Build-time, moment, and component-level view

在这三个视图下，我们所关注的是代码的组织情况，简单来说就是在开发程序的时候会有很多的类、很多的文件，当然我们可以任意的放在工程里，但这样就会出现一个问题，如果想要对程序进行更改，那什么应该更改，什么不该更改这个问题就会需要耗费大量的时间去思考以及记录。一种好的组织方式就是利用模块化的方式来组织文件。比如功能类似的、完成某个功能的文件放在一个包里，这样上面的问题就迎刃而解了。

如图中的ADT等。

Library

对于组织程序文件的时候，一种最简单的方法就是利用库函数（library）的形式来进行组织。在编程时，很多情况下，大部分的功能其实并不需要我们自己编写，大部分情况下我们可以调用第三方的库文件中的方法直接使用，就像使用编程指令一样使用库中的功能，例如：

System.out.println("Hello World");

除了编辑阶段，在构建阶段也可以使用库文件，例如我们可以用maven提供的资源；在测试阶段很多的第三方库也为我们提供了便利。

Linking with a library

但库文件毕竟是第三方提供的，那么我们如何去使用这些库文件呢？
回想一下刚开始使用java的时候，我们需要配置java环境以及资源目录，而这些工作就是为了在之后的代码编写过程中告诉程序库文件的位置。但仅仅找到是不够的，我们要做的第二步就是告诉程序怎么把库文件链接到程序中，链接的方式有两种，一种是静态链接，一种是动态链接。关于链接的内容可以参考学习《深入理解计算机系统》，在这里只作简单介绍。
静态链接是将库被拷贝进入代码形成整体，执行的时候无需提供库文件，这种链接发生在构造阶段，当然这样做的坏处就是当库文件更新升级的升级后，程序中的库文件相关资源是不会发生改变的；
而动态链接则是在程序运行时，通过地址动态的使用库文件中的资源，因此，在将程序打包发送时，不要忘记将用到的库文件一并打包发送给客户！

如图是一个模块化的UML图，与代码级别不同的是，这个图不在将视线聚集在方法和类等之间的关系，而是例如图中shopping cart 和 orders之间。

(4) Build-time, period, and component-level view

在这些维度下，其实我们所关注的也是代码的改变情况，简单来说，也就是希望我们能够知道在这个阶段中，我们对这个代码做了什么改变。没错！还是版本控制工具！software configuration item ！比如说window在不同的阶段会有不同的版本，我们就希望能把它记录下来。

例如图中，我们希望记录每个文件的不同的开发版本，而最后我们所发布的final version 实际上就是file1 的1.3 ，file 2 的1.2 ，以及file 3 的1.4 的版本。
而版本控制工具除了记录的功能外，它还提供了另一个非常重要的功能，支持协同开发。通常一个大的工程，不可能由一个人甚至是几个人来完成，他有可能是由一个大的几十甚至几百人的团队来负责开发的，那么这个时候就需要协同工作，在工程的不同分支上开发完成部分功能以及对这些功能的集成。

如上图，可能每个分支就是不同的模块的功能的开发，这样能够在一定程度上不影响别人的工作状况下独立的完成自己的工作。

运行时的视图下

运行时，程序被载入目标机器，开始执行
在code-level view 的维度，我们关心的是逻辑实体，例如：对象、函数等，在内存中如何呈现？其实很简单，我们使用的java是一种面向对象的编程语言，在程序进行运行的时候，我们所关注的就是程序在某一个时间点到底有多少个对象，以及对象里面的值是什么样的。
而在模块化的角度，我们更关注的是多个模块在运行时的配置是什么样的，即在软件层面，物理实体（OS 、network 、 hardware 等等）在物理硬件环境中如何呈现？目前很多的程序都是采用分布式的情况来进行配置的，什么的是分布式呢，简单来说，就是一个程序并不是就安装在一个机器上，而可能是被分割成了几部分，安装在了不同的机器上来进行运行的。
在时刻视角下，我们可能更关注的是程序在内存中的情况，程序占用内存的空间有多大，程序在某个时间点生成了多少个对象。
在时间或者周期的角度，我们关注的是这个程序在执行时到底需要多大的内存等问题。

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

在当前视图下，我们关注的就是程序在某一个时间点到底有多少个对象，以及对象里面的值是什么样的。这时候我们引入一个snapshot diagram（代码快照图）来描述当前我们所关注的信息。


如上两图，我们所关注的信息就一目了然了。而该图的含义与结构我们暂且按下不提。
同样另外一个我们所使用的方法是memory dump（内存信息转储），这种工具科技方便的查看内存的使用情况。

最常见的memory dump 工具相信我们都并不陌生

任务管理器！它就能告诉我们在运行过程中，程序的一些内存占用信息。

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

这个角度我们所看重的是代码的执行情况，这也可以通过一个UML图来表示，这时的UML图我们称之为运行视图，或者也可以称之为时序图，这个时序图就描述了在和层序运行的时候，多个类、多个方法之间是怎么进行调用的。

当然我们还可以利用一些工具，例如一些列的tracing也就是追踪的工具，来了解到程序在执行的时候的一些信息，即用日志记录程序执行的调用次数。如下图：

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

在这个维度下，我们从模块的角度来看待代码的组织情况，即程序在不同的机器或者单元上的配置情况，如下图：

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

在这最后一个维度下，我们关注的是整个系统的调用情况或系统的使用情况，我们可以通过日志文件从系统的层面上看待程序的使用情况，例如程序被调用、被挂起、程序结束等信息。如下图：

总结

将以上八个维度下的关注重点放在同一张表格中，我们就得到了本文讨论的内容：软件构造的多维度视图。表格中被红色框矿主的部分就是软件构造这门课会涉及的部分，而其他的知识点也推荐大家去了解知识点对应的内容。
从不同的维度下看待软件构造，梳理了一遍之后，相信我们对如何构造使用工具来对软件进行监视和了解有了进一步的认识，当然还有如何构造一个好的软件也有了初步的判断，但更多的内容还需要之后慢慢探索。

引用

以上博文中的资料均引用自2021年春季学期软件构造课程（任课教师：王忠杰 感谢老师的倾囊相授！）中的内容，加上个人对其的稍许理解。

欢迎各位相约探讨！