一、4+1视图是什么

在软件开发的两个范围维度：

（1）解决方案域：就是通过软件建模和软件设计，去实现一个软件系统；是去定义世界，改造世界的一个过程。帮助业务领域更好的运作。

（2）问题域：也就是业务领域，是基于解决方案域，认识世界，认识软件系统，实现系统中的业务并运作起来。

在系统层面，我们最需要关注的范围维度是解决方案域，如何去分析解决方案域的问题（业务领域的相关问题）？首先需要利用软件建模去清晰的描述认识这个系统；那么如何清晰的描述系统呢，那就需要从不同视角，分析出不同的视角来清晰表达这个系统视图。

系统视图可以从外部和内部两个维度来划分为：白盒视图（内部维度）和黑盒视图（外部维度），那么我们可以从那些视角去看这个系统呢？

总结有四种视角可以查看系统，并输出不同视图：

1）【黑盒视图】外部视角：对系统上下或环境进行建模（该系统具备那些对外呈现的功能）

2）【黑盒视图】交互视角：对系统及环境或者系统的构件之间的交互进行建模（该系统所具备的功能与那些其他外部组件有交互关系）

3）【白盒视图】结构化视角：对系统的组织或者系统所处理的数据结构进行建模（该系统内部所具备了那些组织结构，以达到实现对外功能）

4）【白盒视图】行为视角：对系统的动态行为以及系统如何响应事件进行建模（该系统内部是如何运行的，以满足对外功能需求）

通过四种不同视角，可以输出的不同视图，下面全面总结了五种视图（也就是我们所说的4+1视图）：

    （1）【白盒视图】逻辑视图（也叫结构视图）：从结构化视角，描述该系统对用户提供的所需功能服务所具备的组件结构和数据结构，以及一些边界约束条件，清晰的描述给用户提供的功能需求服务是如何构建的

    （2）【白盒视图】实现视图（也叫开发视图）：从结构化视角+行为视角，去描述实现系统功能的各个组件和模块是如何实现的

    （3）【白盒视图】行为视图（也叫过程视图、处理视图）：从行为视角，描述系统各个组件和模块是如何进行通信的

    （4）【黑盒视图】部署视图（也叫物理视图）：从交互视角，描述系统可以部署在那些物理环境上（服务器、PC端、移动端等）和软件环境（虚拟机、容器、进程等）

    （5）【黑盒视图】用例视图（也叫场景视图）：从外部视角，描述系统的参与者（用户）与系统功能用例的关系。反映的是系统的最终用户需求和交互设计。

其中+1就是场景视图，因为其他四种视图都是围绕场景去设计的，所以单独+1。

二、详解4+1视图

1. 场景视图（用例视图）

用例视图是一种需求分析技术，通常采用UML的用例图进行设计。通过用例视图的设计过程，可以正确的识别系统的用户和其它系统（Actor）、系统边界（Boundary）和用例（Use Case），并对系统的功能场景进行充分的分析，以确定系统提供的功能可以满足用户需求。

用例视图之所以是4+1视图的核心，是因为它确定了以下信息，而其它4个视图都是需要围绕着这些信息进行设计：

• 系统边界：有了边界，才能够确定系统的设计范围；同时，通过边界能够识别出系统需要与用户或其它系统进行交互；
• 系统用户：明确的用户定义是系统需求分析的先决条件；
• 功能和场景：通过识别出系统与用户或其它系统的交互，可以分析出系统需要提供哪些功能，以及这些功能存在哪些应用场景；

因此，用例视图并不限于使用UML的用例图进行设计，也可以使用其它方法，比如使用图表进行描述。只要能够清晰的定义出以上几点，就达到了目的。

2.逻辑视图（结构视图）

在系统设计中，如果系统的功能、场景等比较清晰（比如有明确协议定义的系统），可能会对用例视图进行简化，但却不可以没有逻辑视图。

逻辑视图是对系统职责的的逐级划分，咱们以java体系架构来说明逻辑视图，下图描述了java体系中各个功能组件，以及他们的层级关系，作用和依赖范围。

除了对系统职责进行划分，逻辑视图通常还要求对各逻辑架构元素（也就是上面图中的一个个功能组件）间的关系，也就是接口进行描述。增加逻辑元素的接口进行描述对系统的设计和实现非常重要。因为软件设计最重要的原则就是高内聚、低耦合，一个满足此原则的系统不应该存在不合理的依赖关系，比如下层与上层间的反向依赖，或是循环依赖等。

逻辑视图中的功能组件元素决定开发组织（每个功能模块由那个团队去开发），因此，功能组件的边界和接口也是后续多个开发组织之间进行接口控制的关系依据。设计合理的逻辑架构，可以提升团队的沟通效率，进而提升整个系统的交付效率和质量。

3.实现视图（开发视图）

主要包括两部分信息：

• 对逻辑视图中功能模块，描述其代码位置，可以是代码仓位置，或代码目录，或是开源软件的版本信息等
• 系统的构建，即如何将代码编译成二进制交付件（比如.so/.bin）。这个构建信息需要包括构建依赖、构建工具链、构建环境信息

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

• 通过逻辑视图的功能模块，能够找到它所有代码和所有的二进制交付件
• 每一个代码源文件，都能够找到它所属的逻辑功能模块
• 每一个二进制交付件，都能够找到它集成了哪些逻辑视图中的功能模块

4.行为视图（运行视图）

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

运行视图的设计，最常见的是逻辑架构元素之间的交互关系，比如消息交互、服务调用或API调用。如下图所示。

在运行视图中，除了要关注组件间的交互关系，通常还需要考虑并发、抢占、关键资源（比如锁）访问等。

5.部署视图（物理视图）

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

• 二进制交付件，与软件环境的部署关系
• 软件环境与物理环境的部署关系

通过逻辑视图、开发视图加部署视图，我们已经可以知道系统中每一个逻辑架构元素、每一份代码，最终会运行在什么位置上。反向也可以通过运行环境上，找到所有其上运行的逻辑架构元素和代码。