我懂了，原来这就是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），描述用力场景。

 
 

 
 

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。