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视图中的全部视图、还是部分视图。比如：
只有一个处理器，则可以省略物理视图
仅有一个进程或程序，则可以省略过程视图
对于非常小型的系统，甚至可能逻辑视图与开发视图非常相似，而不需要分开的描述
场景对于所有的情况均适用
甚至可以决定是否要按照论文所述的方式来绘制架构视图。例如，上文所说的逻辑视图，论文中使用的是对象模型来描述，具体是否要使用对象模型可以自行决定。无论使用哪种表现形式，只要能使目标读者方便的从架构视图理解整个系统架构即可。
