我懂了，原来这就是4+1架构视图模型

​我们讲架构描述的时候提到过，一个有效的架构描述需要做到以人为本，不同的利益相关方展示不同的视点及视图。​

软件架构文档过分强调软件开发的某一个方面。架构不能解决所有风险承担者所关注的问题。
每个软件系统都有多个风险承担者：最终用户、开发人员、系统工程师、项目经理等。

软件工程师欲使用单张视图来捕捉所有的系统架构要点，努力地在单一视图中表达超过其表达限度的蓝图。使用多个并发的视图来组织软件架构的描述，每个视图仅用来描述一个特定的所关注的方面的问题集合。

  

 

4+1视图最早由Philippe Kruchten提出。他在1995年的《IEEE Software》上发表了题为《The 4+1 View Model of Architecture》的论文，这一论文的发表引起了业界的极大关注，并最终被RUP（Rational Unified Process，统一软件开发过程）采纳，现在已经成为架构设计的结构标准。

“4+1视图” 从5个不同的侧面来描述架构，其中包括4个主视图和一个冗余的场景视图。4个主视图分别如下：

• 逻辑视图（Logical View）：主要是整个系统的抽象结构表述，关注系统提供终用户的功能。

• 进程视图（Process view）：处理视图关注系统动态运行时，主要是进程以及相关的并发、同步、通信等问题。

• 物理视图（Physical view ）：定义软件到硬件的映射，反映架构的分布式特性。

• 开发视图(Development View)：定义在开发环境中软件的静态组织结构。

在进行架构设计时，架构的各个关注点够归结于以上4个视图，同时使用一个场景视图对它们进行解释和说明，就形成了第5个视图，也就是4+1架构模型中的1

在设计架构时，会基于每个视图对系统进行独立分解，每种分解都是基于这个视图的关注点而进行的。基于每个视图的分解都会使用相同的方法和步骤，把系统分解成组件并维持组件间交互的关系。但是每个视图构成的组件类型各不相同，这些组件的类型源自视图分解的需求。

 

01 逻辑视图

相关方：客户，用户开发组织管理者。
视角：系统的功能元素，以及它们接口，职责，交互。
主要元素：系统，子系统，功能模块，子功能模块，接口。
用途：开发组织划分，成本/进度的评估。

用于描述系统的功能需求，即系统给用户提供哪些服务；以及描述系统软件功能拆解后的组件关系、组件约束和边界，反映系统整体组成与系统如何构建的过程。在UML中由类图来表示

下面springcloud微服务的逻辑视图示例（仅部分），就描述了springcloud中各个功能组件。从这个图中，基本可以对springcloud有一个大颗粒度的了解。

类图显示了一组类及其逻辑关系：关联 、泛化、组合、聚合、继承等等。相关的类可以分组为类别。

类模板专注于每个单独的类；它们强调主要的类操作，并识别关键的对象特征。如果定义对象的内部行为很重要，则可以通过状态转换图或状态图来完成。在类功能中定义了公共机制或服务。

 

02 物理视图

相关者：系统集成商，系统运维人员。
视角：系统逻辑组件到物理节点的物理部署和节点之间的物理网络配置。
主要元素：物理节点以及节点的通信。

开发出的软件系统，最终是要运行在物理或软件环境上。物理环境可能是服务器、PC机、移动终端等物理设备；软件环境可以是虚拟机、容器、进程或线程。部署视图就是对这个部署信息进行描述。在UML中通常由部署图表示

 

 

03 处理视图

相关者：性能优化，开发相关人员。
视角：系统运行时线程，进程的情况。
主要元素：系统进程，线程以及出来队列等。

处理视图，又称过程视图、运行视图。用于描述系统软件组件之间的通信时序，数据的输入输出。在UML中通常由时序图和流程图表示，如下图所示：

逻辑视图、开发视图和部署视图，描述的都是系统的静态信息，到现在为止我们还缺少对系统动态行为的描述，而运行视图就是用来描述系统中的动态信息的。运行视图最常见的设计工具就是UML的序列图。

 

4 开发视图

相关者：开发相关人员，测试人员
视角：系统如何开发实现
主要元素：描述系统的层，分区，包，框架，系统通用服务，业务通用服务，类和接口，系统平台和相关基础框架。
用途：指导开发组织设计和开发实现

开发视图关注软件开发环境下实际模块的组织，反映系统开发实施过程。开发视图关注的是架构如何指导开发流程，在这个视图中，软件系统会被分解成小的子程序或软件包，并为每个子程序或软件包定义接口。系统设计人员会根据这些分解的子程序和软件包分配工作内容。

一个设计良好的开发视图，应该能够满足以下要求：

通过逻辑架构元素，能够找到它所有代码和所有的二进制交付件 每一个代码源文件，都能够找到它所属的逻辑架构元素 每一个二进制交付件，都能够找到它集成了哪些逻辑架构元素，开发视图通常采用分层样式。每一层都有一个明确定义的责任。设计规则是，某个子系统只能依赖于同一层或下层的子系统，以尽量减少模块之间依赖关系，并允许简单的逐层发布策略。

 

05 场景视图（用例视图）

相关者：用户，设计和开发人员。
视角：概括了架构上最重要的场景（最典型或者最有风险）及其非功能性需求，通过这些场景的实现，阐明了架构的广度或众多架构元素运行的方式。

场景视图，即4+1中的1。从前面的图可以看到，4+1中的4个视图都是围绕着场景视图为核心的。它用于描述系统的参与者与功能用例间的关系，反映系统的最终需求和交互设计。在UML中通常由用例图表示

四个视图中的元素通过使业务场景视图或用例图无缝地协同工作。业务场景在某种意义上是对最重要需求的抽象。场景视图在传统IT架构设计中是多余的(因此是“+1”) 。场景视图就是描述现实中的一个系统运用场景的过程，把其中牵涉到的对象，服务和操作都展示出来。

场景视图有两个主要目的：

• 作为在架构设计流程中发现架构元素的驱动因素和需求；

• 作为在此架构设计完成之后的验证。

总结来说，以上5种架构视图，是从不同角度表示一个软件系统的不同特征，组合到一起作为架构蓝图描述系统架构。

逻辑视图（Logical View），设计的对象模型。
过程视图（Process View），捕捉设计的并发和同步特征。
物理视图（Physical View），描述了软件到硬件的映射，反应了部署特征。
开发视图（Development View），描述了在开发环境中软件的静态组织结构。
场景视图（Scenarios），描述用力场景。