在之前的文章《「后端」架构师是如何画架构图的》中，介绍了各种架构图的画法。其中提到了 4+1 视图，今天一起解读该内容。
最早的 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 标记法，并未使用 UM L视图表示。
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 用于架构设计完成后，对架构的的使用说明以及测试验证的参考。场景视图基本的建模元素跟逻辑视图类似，但是描述关系的方式使用了运行视图的表达方式。
场景视图
- Joe的电话控制器检测和校验摘机状态的变换,并发送消息唤醒相应的终端对象。
- 终端分配一些资源，并要求控制器发出拨号音。
- 控制器接受拨号并传递给终端。
- 终端使用拨号方案来分析数字流。
- 有效的数字序列被键入,终端开始会话。
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，则会发现并不存在逐一对应的类的不同种类到层的映射。而如果我们考虑类“‘Externalinterfaces-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"视图。
文章来源：https://www.jianshu.com/p/55778ec87ed8