4+1视图

2025年9月17日

视图类型	描述
逻辑视图	逻辑视图面向系统逻辑分析和设计，是描述系统逻辑结构的视图，主要解决系统分析和设计的问题，它描述系统的业务上下文、系统的逻辑分解，以及分解出的逻辑元素间的关系。
开发视图（实现视图）	开发视图面向系统开发及软件管理，是描述系统代码结构，构建结构的视图，主要解决系统技术实现和开发的问题，它依托逻辑视图，描述代码、构建结构。
运行视图（处理视图、行为视图）	运行视图面向系统运行，是描述系统启动过程、运行期交互的视图，主要解决系统运行期交互，描述各可执行交付件在运行期的交互关系。
部署视图（物理视图）	部署视图面向系统部署，是描述系统的交付、安装、部署的视图，主要解决系统安装部署的问题，描述系统的交付、安装、部署关系。
用例视图（场景视图）	用例视图以用例作为驱动元素，驱动和验证其他四个视图的设计，用例视图不增加设计元素，仅增加用例作为输入，因此作为“+1”视图。

[!note]
白盒视图：逻辑视图、开发视图、运行视图都属于
黑盒视图：部署视图、用例视图

1. 用例视图

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

从文章开头的图中我们也能看到其他视图都是围绕用例视图展开的。用例视图之所以是4+1视图的核心，是因为它确定了以下信息，而其它4个视图都是需要围绕着这些信息进行设计：

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

[!note]
结合DDD思想，我们可以通过事件风暴输出我们的领域事件（功能和场景），从而形成用例视图

1.1. 用例模型画法

组成元素	说明	备注
参与者（actor）	参与者（actor）在建模过程中处于核心地位，actor是在系统之外与系统交互的人或事物。用一个小人表示。	1. 找出参与者：参与者一定是直接并主动地向系统发出动作并反馈，否则就不是参与者。 2. 谁对系统有着明确的目标和要求并主动发出动作？ 3. 系统为谁服务？业务工人（business worker）：被动参与业务处于系统边界内部。
用例 (User Case)	用例定义了一组用例实例，每个实例都是系统所执行的一系列动作。用一个椭圆代表。	用例特征：1. 用例是相对独立的 2. 用例的执行结果对参与者来说是可观测和有意义的 3. 这件事必须由一个参与者发起 4.用例必然由动宾短语形式出现的 5.一个用例就是一个需求单元、设计单元、开发单元、测试单元，甚至部署单元用例的粒度：1. 概念建模阶段：每个用例描述一个完整的事件流。2. 系统建模阶段：每个用例能够描述操作者与计算机的一次完整交互用例粒度的划分依据最标准的方法以该用例是否完成了参与者的某个完整目的为依据。用例的来源：1. 一个明确有效的目标 2. 一个真实的目标应当完备的表达主角的期望 3. 一个有效的目标应当在系统边界内，由主角发动并具有明确的后果
关联关系 (Association)	表示参与者与用例之间的关系。用一个直线箭头表示
包含关系 (Include)	表示一个大的功能分解成多个小模块的动作。用一个带包含文字的虚线箭头表示
扩展关系 (Extend)	表示用例功能的延伸，相当于是为用例提供附加功能。用一个带扩展文字的虚线箭头表示
边界	用来表示正在建模系统的边界。边界内表示系统的组成部分，边界外表示系统外部。系统边界在画图中用方框来表示，同时附上系统的名称，参与者画在边界的外面，用例画在边界里面。	边界是可大可小的，由建模者主观确定。边界的确定是一个动态的过程，没有明确的方法。需求过程是一个动态的过程，不可能一蹴而就，我们只能把这些不同的结果进行对比、思考、讨论，最终希望得到一个更恰当的结果，就像盲人摸象—样，多方结果的相互印证得出的结论总是会更接近真相。所以在建模过程中，如果对建模结果感到疑惑，就可以试着改变边界设定，得到不同的参与者和用例，再通过相互印证的方式得到更好的结果。系统边界的作用有时候不是很明显，在画图时可省略。

1.2. 示例

2. 逻辑视图

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

软件设计最重要的原则就是高内聚、低耦合，一个满足此原则的系统不应该存在不合理的依赖关系，比如下层与上层间的反向依赖，或是循环依赖等。

一般，逻辑架构元素决定了开发组织（根据康威定律，反之亦然）。因此，逻辑元素的边界和接口也是后续多个开发组织之间进行接口控制的关系依据。设计合理的逻辑架构，可以提升团队的沟通效率，进而提升整个系统的交付效率和质量。

2.1. 逻辑视图画法

步骤分解顺序为：System > Susbsystem > Component > Module，对应着0层逻辑模型 -> 1层逻辑模型 -> 2层逻辑模型。

2.1.1. 0层模型

0层模型描述了System之间的关系，System与Subsystem包含关系。

2.1.2. 1层模型

1层模型描述Subsystem之间的关系，Subsystem和Component包含关系。

2.1.3. 2层模型

2层模型描述Component之间的关系，Component和module包含关系。

2.2. 示例

javaj体系中各个功能组件，以及他们的层级关系，作用和依赖范围。

springcloud微服务的逻辑视图示例，描述了springcloud中各个功能组件。该逻辑视图描述了springcloud的关键组件、作用及相互依赖关系

3. 开发视图

主要包括两部分信息：

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

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

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

4. 运行视图

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

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

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

4.1. 组成元素

元素	描述
进行角色（`Actor`）	在交互中扮演特定角色的实体，可以是人、系统、外部组件等。
对象(`Object`)	在交互中参与通信的实体，表示在系统中存在的具体对象，可以是类的实例、组件等。
生命线(`LifeLine`)	表示对象在整个交互中的存在时间，是对象的生命周期，通常与对象的生存期一致。
控制焦点(`Activation`)	表示对象活跃时的时间段，用于标识对象的操作或消息发送的时间段，用虚线框表示。
消息(`Message`)	表示对象之间的通信或交互，可以是同步消息、异步消息、返回消息等。
自关联消息	表示对象发送消息给自身的情况，用于描述对象的自我调用或自身处理。
组合片段	用于表示在一段时间内特定的控制流程或行为，可以嵌套在时序图中，用来划分不同的交互片段。

时序图元素通过各种连接和注释，共同描述了对象之间的交互过程，以及它们的执行顺序和时序关系。这有助于开发人员更好地理解系统中的消息传递和协作情况。

4.2. 示例

5. 物理视图

物理视图是软件架构中的一部分，用于描述系统的物理部署和运行环境。它关注于如何将软件系统部署在硬件设备上，并展示了不同组件、模块、服务在物理设备上的布局和交互关系。物理视图帮助开发人员和架构师理解系统的部署情况，以及硬件资源的利用情况。在UML中通常由部署图表示。

5.1. 元素组成

元素类型	描述	示例
节点（Node）	物理或虚拟的计算资源，代表部署目标的硬件或软件环境	Web 服务器、数据库服务器，既可以是物理机器也可以是容器
构件（Component）	系统中可部署和替换的模块单元	数据库组件、应用服务器组件
节点关系（Node Relationship）	表示节点之间的连接或依赖关系	连接、依赖
部署关系（Deployment Relationship）	节点与构件之间的部署关系	部署、关联
网络（Network）	物理或逻辑的网络基础设施	局域网、互联网
存储（Artifact）	被部署的物件（如文件、数据库表）	配置文件、数据文件
线条（Connector）	构件之间的通信路径	连接器、通信路径