最早的4+1视图由Philippe Kruchten于1995年提出，虽然历经26年的时间，中间使用过程中也被不断丰富，但是今天回头看最初的版本，还是有很多收获。

1 背景

很多人尝试使用一个视图来展示软件的方方面面，往往无法清晰地描述系统。作者提出应该用多个视图来描述一个软件系统，每个视图聚焦于说明软件的某个方面。

2 一种新的架构模型(4+1)

软件架构呈现的是软件设计和实现的高层结构，它将一定数量的架构元素经过良好的组织，来满足软件系统的主要的功能和性能需求，同时还要满足一些非功能性需求，例如可靠性、可扩展性、可移植性和可用性等。 Perry & Wolf用一个公式表达大概就是：软件架构 ＝ {元素，形式，关系/约束}(Software architecture = {Elements, Forms, Rationale/Constraints})。软件架构涉及抽象、分解和组合、风格和美学。为了描述一个软件架构，我们使用一组视图/表现形式来表达模型。为了能够应对具有挑战性的大型软件系统架构建模，作者推荐使用如下5(4+1)个视图来描述系统：

• 逻辑视图：对于面向对象设计来讲，就是对象模型。
• 运行视图：涉及并发和同步等方面。
• 物理视图：展现软件到硬件的映射，以及软件的分布式部署。
• 开发视图：描述软件在开发环境中的静态组织方式。

• +1 场景视图：是其它几个视图的补充，用于通过use case将其它几个视图串联起来。

  
  
  4+1 view model
  
  

  每个视图上独立应用 Perry & Wolf公式，即通过捕获建模元素和建立它们之间的关系，完成架构设计以满足需求。每种视图可以有不同的架构风格。4+1视图模型是一种通用的架构建模思想，可以使用不同的工具和标注方法来实现，也可以通过不同的建模方法来实现，只要能够表达每个对应的view即可。下面是使用的是 Booch 标记法，并未使用UML视图表示。

3 逻辑视图（The Logical Architecture View）

面向对象的分解。
架构视图描述系统的顶层设计，系统为了完成功能（要解决的问题），需要那些对象以及他们之间的关系是什么（即实现域），同时要完成一些支撑功能实现的通用机制的设计。此时还处于一个比较高的层次，不需要引入太多的细节，只考虑具有架构意义的元素，多用类图/对象图表示，采用抽象、继承、封装的原则，使用关联、依赖、继承、组合等表示其关系。（领域模型属于这个层次？）

逻辑视图标注

逻辑视图的风格
上述逻辑视图的风格采用的是面向对象的风格，逻辑视图设计的首要准则是在全系统中保持单一、一致的对象模型，避免在此引入不同场景和处理过程中产生各种类和机制的特例化。

逻辑视图

4 运行视图（The Process Architecture View）

运行视图需要考虑，如何让逻辑视图中的对象运行起来。此时需要考虑一些非功能性需求（例如性能，可靠性等），同时需要考虑并发、部署、系统集成、容错性等。
运行视图可以分为几层抽象：

• 1 最高层可以看做一组独立可执行的通信程序（processes）的逻辑网络（network）。这些逻辑网络结点分布在一组硬件资源上，通过wan/lan进行连接。设计过程中，多个逻辑网络可以并存，共享同一套物理资源。（例如同一套物理资源，要承载离线系统和在线系统两套运行视图）
• 2 第二层可以看做单个进程（process）。每个进程由一组可执行的任务（task）组成，在这个层次上，要能够表达进程的启动、停止、重配置、恢复、重启等控制策略（例如一些进程复位重启等自愈策略）。另外，进程要可以独立部署进行负荷分担，以提升系统的可用性。

• 3 第三层是任务级（task），任务包括主要任务和次要任务。主要任务是设计的重点，是描述系统的主要架构元素，要保证接口的标准和通用。次要任务是一些内部的辅助实现任务（例如一些周期触发、缓冲、暂停等），实现上可以更灵活一些。主要任务的通讯通过严格定义的通信机制：基于消息的同步或异步通信服务、远程过程调用、事件广播等。次要任务则以会见（rendezvous）或共享内存来通信。在同一过程或处理节点上，主要任务不应对它们的分配做出任何假定。

  
  
  运行视图标注

运行视图

5 开发视图（The Development Architecture View）

用于子系统分解。
开发视图聚焦于软件模块的组织和软件开发环境（语言、框架等）。康威定律在此处体现。软件需要分层，分块，然后定义良好的接口用于多团队并行开发。
系统的开发架构用模块和子系统图来表达，显示了"输出"和"输入"关系。完整的开发架构只有当所有软件元素被识别后才能加以描述。但是，在此之前可以列出控制开发架构的规则：分块、分组和可见性。
大部分情况下，开发架构考虑的内部需求与以下几项因素有关：开发难度、软件管理、重用性和通用性及由工具集、编程语言所带来的限制。
开发视图可用于需求分解、项目进度监控，可用于论证软件的重用性、可移植性和安全性，它是建立产品线的基础。
分解后的开发视图，N个子系统可以分布在M个层中，每个层可以包含多个模块。

开发视图

上面面的开发视图对应于逻辑视图3b。第一层 和第二层组成了独立于域的覆盖整个产品线的分布式基础设施，并保护其免受不同硬件平台、操作系统或市售产品（如数据库管理系统）的影响。第三层为该基础设施增加了 ATC 框架，形成一个特定领域的软件架构（domain-specific software architecture）。使用该框架,可以在第四层上构建一个功能选择板。层次 五 则非常依赖于客户和产品,包含了大多数用户接口和外部系统接口。72 个子系统分布于 5 个层次上，每层包含了 10 至 50 个模块。

6 物理视图（The Physical Architecture View）

把软件映射到硬件。
物理视图聚焦于软件的非功能性需求，例如可用性、可靠性（容错）、性能（吞吐量）和可伸缩性。物理视图展示软件网络结点、进程、任务、对象到硬件结点的部署关系。软件的部署应尽可能灵活，减少对原代码的影响/依赖。可以根据对不同硬件资源的性能/容量的诉求，设计出不同物理视图的部署方式，如下两图：

小容量部署

大容量部署

7 场景视图（Scenarios View）

也称用例视图
场景视图在某种意义上讲是对最重要需求的一种抽象，将上述4视图连接在一起的纽带。因此场景视图看似多余（因此归为+1）。但是它至少有两个重要功能：

• 1 驱动我们去发现架构元素（领域对象等），用于架构设计过程中的其它视图。

• 2 用于架构设计完成后，对架构的的使用说明以及测试验证的参考。
  场景视图基本的建模元素跟逻辑视图类似，但是描述关系的方式使用了运行视图的表达方式。

  
  
  场景视图

1. Joe的电话控制器检测和校验摘机状态的变换,并发送消息唤醒相应的终端对象。
2. 终端分配一些资源，并要求控制器发出拨号音。
3. 控制器接受拨号并传递给终端。
4. 终端使用拨号方案来分析数字流。
5. 有效的数字序列被键入,终端开始会话。

8 视图之间的关系

各种视图并不是完全是正交的或独立的，视图的元素根据某种设计规则和启发式方法（heuristics）与其他视图中的元素相关联。

8.1 从逻辑视图到运行视图

逻辑视图的对象的几个重要特征：

• 1 对象的自主性（主动、被动、受保护）
• 2 对象的持久性
• 3 对象的从属关系
• 4 对象的分布
  从逻辑视图上看，认为每个对象都是主动的，并且可能存在并发（虽然我们不需要知道确切的并发量）。因此，逻辑架构更多关注功能性需求。
  但是我们定义运行视图时，每个对象一个进程/线程是不现实的，硬件资源往往受限。另外，如果存在并发，还需要考虑互斥性。但有些情况下不得不使用多线程：
• 1 对外部事件需要做出快速反应
• 2 充分发挥多核处理器的性能
• 3 最大化处理器的利用率，当由于一些等待导致任务挂起时，可以使用多线程来提升处理器的使用率
  ...
  在软件并发度的设计上，一般有两种方式：

由内而外

从逻辑架构出发，定义代理任务，一个类的多个主动对象可以复用单个控制线程，同时，该代理任务还执行生命周期和持久化依赖于主动对象的那些对象。需要考虑互斥的类和一些处理较少的类，可以共享同一个代理任务。这种聚合方式持续进行下去，直到进程数达到一个合理的范围。

由外而内

从物理架构出发，识别系统的外部触发，设计出客户端进程和服务端进程，根据数据的完整性和时序的约束，设计出一系列的服务进程，然后为客户机与服务器代理分配对象；
不管用那种方法，最终都是将类（和它们的对象）映射到任务和进程上。通常，一个主动对象对应一个代理任务。但也不尽然：例如为了提升吞吐量，需要为同一个类提供多个代理任务；或者反之，对于一些调用不频繁的类或者需要保证执行顺序的类，这些类可以放在同一个任务上。
上述过程并不是一蹴而就的，可能需要多个迭代反复进行，才能得出一个合理的设计。

图 12 显示了空中管制系统的实例，展示如何将一些类映射至进程。
1 flight 类映射至一个 flight 代理集合：有许多航班等待处理，外部触发的频率很高，响应时间很关键，负载必须分布于多个 CPU。并且，航班处理的持久化和分布性方面都取决于 flight server，为了满足可用性，为 flight server 设计了一台备份服务器。
2 航班的 profile 和 clearance 总是从属于某个航班,尽管它们是复杂的类,但它们共享 flight 类的进程。航班分布于若干其他进程，用于显示和外部接口。
3 sectorization 类，为 controller 的权限分配建立了空域划分。由于完整性约束，仅能被一个代理处理，但可以与 flight 类共享服务器过程：更新得并不频繁。
4 location 和 arispace 及其他的静态航空信息是受到保护的对象，在几个类中共享，很少被更新；它们被映射至各自的服务器，分布于其他进程。

空中交通管制图

8.2 从逻辑视图到开发视图

类通常作为一个模块来实现。密切相关的类（类的种类）的集合组合到子系统中。子系统的划分必须考虑一些约束，例如如团队组织、期望的代码规模、可重用性和通用性的程度以及严格的分层依据（可视性问题），发布策略和配置管理。所以，通常最后得到的不是与逻辑视图逐一对应的视图。
逻辑视图和开发视图非常接近，但关注点却大不相同。我们发现项目规模越大，视图间的差距也越大。例如，如果比较图 3 b 和图 6，则会发现并不存在逐一对应的类的不同种类到层的映射。而如果我们考虑类“‘External
interfaces-Gateway”时，它的实现遍布若干层：通讯协议在第 1 层或以下的层，通用网关机制在第 2 层，而特定的网关在第 5 层子系统。

8.3 从运行视图到物理视图

进程和进程组映射到不同的物理硬件上，通过不同的配置来满足测试和部署需要。
当需要关注场景中使用了那些类是，场景视图更多与逻辑视图关联；但当关注多线程之间的对象交互时，则场景视图更多与运行视图打交道。

9 模型的剪裁

并不是所有的软件架构都需要"4＋1"视图。无用的视图可以从架构描述中省略，比如： 只有一个处理器，则可以省略物理视图；而如果仅有一个进程或程序，则可以省略运行视图。 对于非常小型的系统，甚至可能逻辑视图与开发视图非常相似，而不需要分开的描述。场景视图一般是必须的。

10 迭代过程

Witt 等人为设计和架构指出了 4 个阶段：勾画草图、组织、具体化和优化，分成了 12 个 步骤。他们还指出需要某种程度的反向工程。而作者认为对于大型的项目，该方法太"线性化"了。在 4 个阶段的末尾，可用于验证架构的内容太少。作者提倡一种更具有迭代性质的方法，即架构先被原形化、测试、估量、分析，然后在一系列的迭代过程中被细化。该方法除了减少与架构相关的风险之外，对于项目而言还有其他优点：团队合作、培训，加深对架构的理解，深入程序和工具等等。（此处提及的是演进的原型，逐渐发展成为系统，而不是一次性的试验性的原型）这种迭代方法还能够使需求被细化、成熟化并能够被更好地理解。

一种场景驱动的设计方法

系统大多数关键的功能以场景（或 use cases）的形式被捕获。主要指的是：最重要的功能，系统存在的理由，或使用频率最高的功能，或体现了需要提前识别的关键的技术风险。
Start:

• 基于风险和重要性为某次迭代选择一些场景。场景可能被归纳为对若干用户需求的抽象。
• 形成"稻草人式的架构"。然后对场景进行"描述"，以识别主要的抽象（类、机制、过程、子系统），如 Rubin 与 Goldberg 所指出的 ―― 分解成为序列对（对象、操作）。
• 所发现的架构元素被分布到 4 个视图中：逻辑视图、运行视图、开发视图和物理视图。
• 然后实施、测试、度量该架构，这项分析可能检测到一些缺点或潜在的增强要求。
• 捕获经验教训。
  Loop:
  下一个迭代过程开始进行：
• 重新评估风险。
• 扩展考虑的场景。
• 选择能降低架构风险或提高架构覆盖范围的额外的少量场景。
  然后：
• 试着在原先的架构中描述这些场景。
• 发现额外的架构元素，或有时还需要找出适应这些场景所需的重要架构变更。
• 更新4个主要视图：逻辑视图、运行视图、开发视图和物理视图。
• 根据变更修订现有的场景。
• 升级实现工具（架构原型）来支持新的、扩展了的场景集合。
• 测试。如果可能的话，在实际的目标环境和负载下进行测试。
• 然后评审这五个视图来检测简洁性、可重用性和通用性的潜在问题。
• 更新设计准则和基本原理。
• 捕获经验教训。
  End loop
  为了实际的系统，初始的架构原型需要进行演进 。较好的情况是在经过 2 次或 3 次迭代之后，结构变得稳定：主要的抽象都已被找到。子系统和过程都已经完成，以及所有的接口都已经实现。接下来则是软件设计的范畴，这个阶段可能也会用到相似的方法和过程。
  这些迭代过程的持续时间参差不齐，原因在于：所实施项目的规模，参与项目人员的数量、他们对本领域和方法的熟悉程度，以及该系统和开发组织的熟悉程度等等。因而较小的项目迭代过程可能持续数周，而大型的项目可能为数月。

11 架构的文档化

架构设计中产生的文档可以归结为两种：

• 1 软件架构文档，其结构遵循"4+1"视图（请对照图 13，一个典型的提纲）

• 2 软件设计准则，捕获了最重要的设计决策。这些决策必须被遵守，以保持系统架构的完整性。

  
  
  一个典型的架构文档目录结构

12 总结

4+1视图对软件开发过程中的不同利益相关人分离了关注点，例如，系统工程师首先接触物理视图，然后转向进程视图；最终用户、顾客、数据分析专家从逻辑视图入手；项目经理、软件配置人员则从开发视图来看待"4＋1"视图。

4+1模型一览表

参考

架构蓝图--软件架构 "4+1" 视图模型
Architectural Blueprints—The “4+1” View Model of Software Architecture