大型架构讲解（41架构视图）

大型架构讲解（41架构视图）软件架构图就像各个面上的投影图，架构图的目标读者则需要从这些投影图理解系统全貌（圆柱体）。一张投影图，显然无法做到这一点。同时，表意不清的架构图（倾斜后的投影）也很难帮助目标读者理解系统全貌。如果圆柱体的位置稍微有一点变化，三个投影就会出现变化。比如，将圆柱体稍微倾斜一点，那么：早期的架构设计人员，期望在一张架构图里将所有的设计都囊括在内，但是很明显，这基本不可能。「系统」是一个真实运行的实物，它是动态的；而「架构图」是静态图，很难用一张架构图就描绘出「系统」的全貌。这就像，你无法使用一张二维图片来描绘出一个三维物体。二维图像只是三维物体的一个投影而已。比如下面这幅图片：这是一个圆柱体：

4 1视图源自于1995年，Philippe Kruchten在《IEEE Software》上发表的一篇题为《The 4 1 View Model of Architecture》的论文。

本文是对论文核心内容的简介和分析。

为什么需要4 1视图？

在「什么是软件架构」一文中，我们给架构下了一个定义：「在特定约束下决策的结果」。在理想情况下，主要「结果」应该是运行良好、满足需求的系统。

不过，考虑到后续软件的维护、扩展等因素，需要提供对应的文档。文档包括但不限于：

• 用例图
• 决策过程文档（各个方案优缺点，选择该方案的原因）
• 架构图
• 备选方案
• ......

早期的架构设计人员，期望在一张架构图里将所有的设计都囊括在内，但是很明显，这基本不可能。「系统」是一个真实运行的实物，它是动态的；而「架构图」是静态图，很难用一张架构图就描绘出「系统」的全貌。这就像，你无法使用一张二维图片来描绘出一个三维物体。二维图像只是三维物体的一个投影而已。

比如下面这幅图片：

这是一个圆柱体：

• 它在V面和W面的投影是个矩形
• 在H面的投影是个圆形

如果圆柱体的位置稍微有一点变化，三个投影就会出现变化。比如，将圆柱体稍微倾斜一点，那么：

• V面的投影可能就变成了菱形
• W面的投影可能就变成了正方形
• 而H面的投影可能就变成了椭圆形

软件架构图就像各个面上的投影图，架构图的目标读者则需要从这些投影图理解系统全貌（圆柱体）。一张投影图，显然无法做到这一点。同时，表意不清的架构图（倾斜后的投影）也很难帮助目标读者理解系统全貌。

所以Philippe Kruchten提出了4 1视图，从5个方面来描述系统，每个方面都可以理解为是系统的一个投影，每个投影是关注系统的一个方面，结合五个视图，可以帮助目标读者理解系统全貌。

4 1视图

Philippe Kruchten提出的4 1视图包括了逻辑视图，过程视图，物理视图，开发视图和场景。其中「场景」就是那个1，用来整合其它四个视图。

• 逻辑视图：设计的对象模型（使用面向对象的设计方法时）。这是一个静态视图，描绘的是系统的静态逻辑结构。论文中使用的是对象模型，不过并不是强制的，只要能表达出意图即可。
• 过程视图：捕捉设计的并发和同步特征。这是一个流程图，通过对进程的描述，将系统中的各个组件串联到一起。和上面的逻辑视图结合，可以得到一个相对动态的系统结构。
• 物理视图：描述了软件到硬件的映射，反映了分布式特性。这是一个静态视图，表示系统的各个组件、子系统是如何部署的。
• 开发视图：描述了在开发环境中软件的静态组织结构。这也是一个静态视图，表示系统在代码层面的结构。
• 场景：整合上述四个视图。通过一个个的用例流程将系统组件串联到一起。既可用于完善上面的各个视图，也可以用于验证上面的视图意图。

4 1视图的设计过程

Philippe Kruchten在论文中给出了一个设计过程：「一种场景驱动方法」

首先，通过「场景用例」来捕获系统中大部分的关键功能：

• 最重要的功能
• 系统存在的理由
• 或使用频率最高的功能
• 或体现了必须减轻的一些重要的技术风险。

然后，基于这些「场景用例」开始迭代设计：

• 开始阶段：

• 基于风险和重要性为某次迭代选择一些场景
• 形成架构草图。然后对场景进行「描述」，以识别主要的抽象（类、机制、过程、子系统）
• 所发现的架构元素被分布到 4 个蓝图中：逻辑蓝图、进程蓝图、开发蓝图和物理蓝图
• 然后实施、测试、度量该架构，这项分析可能检测到一些缺点或潜在的增强要求
• 捕获经验教训
• 循环阶段：
• 下一个迭代过程开始进行：
• 重新评估风险
• 扩展考虑的场景选择
• 选择能减轻风险或提高结构覆盖的额外的少量场景
• 然后:
• 试着在原先的架构中描述这些场景
• 发现额外的架构元素，或有时还需要找出适应这些场景所需的重要架构变更
• 更新4个主要视图：逻辑视图、进程视图、开发视图和物理视图
• 根据变更修订现有的场景
• 升级实现工具（架构原型）来支持新的、扩展了的场景集合
• 测试。如果可能的话，在实际的目标环境和负载下进行测试
• 然后评审这五个视图来检测简洁性、可重用性和通用性的潜在问题
• 更新设计准则和基本原理
• 捕获经验教训
• 终止循环

初始的架构原型最终会演化为实际的系统 。较好的情况是在经过2到3次迭代之后，结构变得稳定：

• 主要的抽象都已被找到
• 子系统和过程都已经完成
• 以及所有的接口都已经实现

接下来则是软件设计的范畴，这个阶段可能也会用到相似的方法和过程。

这些迭代过程的持续时间参差不齐，原因在于：

• 所实施项目的规模
• 参与项目人员的数量
• 他们对本领域和方法的熟悉程度
• 以及该系统和开发组织的熟悉程度等等

整个流程和IBM的架构设计流程很类似：

4 1视图文档结构

论文中也给出了推荐的文档结构：

• Title Page（标题）
• Change History（变更历史记录）
• Table of Contents（目录）
• List of Figures（清单）
• Scope（范围）
• References（引用）
• Software Architecture（软件架构）
• Architectural Goals & Constraints（架构目标&约束）
• Logical Architecture（逻辑架构）
• Process Architecture（过程架构）
• Development Architecture（开发架构）
• Physical Architecture（物理架构）
• Scenarios（场景）
• Size and Performance（规模及性能）
• Quality（质量）
• Appendices（附录）
• Acronyms and Abbreviations（缩写词表）
• Definitions（定义）
• Design Principles（设计原则）

架构视图的应用

4 1视图实际是一种架构描述参考，并不是一个规范。现实中，可以根据架构复杂度和需求来自行决定是否使用4 1视图中的全部视图、还是部分视图。比如：

• 只有一个处理器，则可以省略物理视图
• 仅有一个进程或程序，则可以省略过程视图
• 对于非常小型的系统，甚至可能逻辑视图与开发视图非常相似，而不需要分开的描述
• 场景对于所有的情况均适用

甚至可以决定是否要按照论文所述的方式来绘制架构视图。例如，上文所说的逻辑视图，论文中使用的是对象模型来描述，具体是否要使用对象模型可以自行决定。无论使用哪种表现形式，只要能使目标读者方便的从架构视图理解整个系统架构即可。