【从 0 开始学架构】学习笔记 Day4 “4+1”视图模型

一、模型

（1）模型

模型，领域“特定”问题的解决方案，是一个系统的完整抽象。

现实世界领域问题繁多，针对功能直接进行开发，不建模，不设计，最后，系统将变得庞大无序，难以开发和维护

（2）软件开发的本质

为了解决某个领域特定问题，从领域问题到计算机系统的映射

模型的关键：抽象

领域模型：对业务（领域问题）中的关键点和关键关系梳理和抽象

设计模型：对系统进行抽象，关键点抽象出来

（3）架构设计

架构师输出架构设计文档，针对利益相关方，统筹协调各自的关注点，进而获得相关方的支持，实现开发、测试、运维等相关工作的落地，直至最终实现系统上线运行

架构设计文档包含架构视图，架构视图体现相关方的关注点

二、4+1视图模型

1）定义

单一视图无法完整表达整体的架构，需要通过完整的视图集进行表达

IBM 的 RUP 将软件架构视图分为“4+1 视图”

软件架构＝{元素，形式，关系/约束}

2）组成

• 场景视图（Scenarios），描述用例场景，场景与所有视图都是相关的
• 逻辑视图（LogicalView），设计的对象模型
• 过程视图（ProcessView），捕捉设计的并发和同步特征
• 物理视图（PhysicalView），描述了软件到硬件的映射，反映了部署特性
• 开发视图（DevelopmentView），描述了在开发环境中软件的静态组织结构

（1）场景视图

本质：执行者通过系统能做什么事情

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

应用：用例图

（2）逻辑视图

本质：系统有哪些功能，以及它们的接口、职责和交互是怎么样的

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

误解：逻辑视图不是业务流程，逻辑视图的相关方是用户，某种程度上用户不需要知道业务具体如何实现，具体如何流转，只是获取最终结果即可

关键：从用户的视角去理解系统

应用：功能模块图、子系统关系图

功能模块图示例

（3）开发视图

本质：描述系统如何开发实现

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

关键：从开发人员出发，系统如何落地实现，包含开发相关的元素，以及元素之间的关系

应用：类图

（4）物理视图

本质：逻辑组件与物理组件之间的部署关系和网络通讯关系，系统最终的物理呈现是什么样的

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

注意：不同的模块、组件和子系统，部署在不同的物理设备上，实际环境，由于物理设备资源紧张，会有一个物理设备部署多个模块、组件和子系统的情况

应用：部署图

（5）过程视图

描述用户请求产生的线程，如何流转，如何处理并发，如何处理异步，如何处理同步

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

（3）4+1视图模型的真正用途

4+1视图提供了软件架构设计的视角，为架构设计提供了思考角度，几乎涵盖了架构设计的所有方面

实际环境中，使用UML建模方法设计架构视图

三、UML

1）定义

UML（UnifiedModelingLanguage），统一建模语言，以图形方式描述软件概念

主要作用：

描述某个问题领域
构想中的软件设计
描述已经完成的软件实现

2）UML分类

（1）静态图

通过描述类、对象和数据结构以及它们之间存在的关系，来描述软件要素中不变的逻辑结构

用例图（UseCaseDiagrams）
对象图（ObjectDiagrams）
类图（ClassDiagrams）
组件图（ComponentDiagrams）
包图(PackageDiagrams)
部署图（DeploymentDiagrams）

（2）动态图

通过描绘执行流程或者实体状态变化的方式，来展示软件实体在执行过程中的变化过程

状态图（StateDiagrams），描述对象，子系统，系统的生命周期

活动图（ActivityDiagrams），着重描述操作实现中完成的工作以及用例实例或对象中的活动，活动图是状态图的一个变种

协作图（CollaborationDiagrams），用于描述相互合作的对象间的交互关系，它描述的交互关系是对象间的消息连接关系

序列图（SequenceDiagrams），一种交互图，主要描述对象之间的动态合作关系以及合作过程中的行为次序，常用来描述一个用例的行为

3）模型元素

模型元素，即软件架构中的基本概念，通过相应的试图元素（符号）表示，模型元素与模型元素之间的连接关系也是模型元素

模型元素：类、对象、结点、用例、组件、注释
模型元素之间的连接关系：泛化（generalization）、依赖（association）、关联（dependency）、继承、实现、聚合（aggregation）、组合

（1）模型元素

结点，指代服务器
注释，用以补充说明模型元素的信息

（2）模型元素之间的连接关系静态关系

泛化、依赖、关联、继承、实现、聚合、组合，用于表达静态关系。

依赖与关联

表达对象等模型元素之间的静态连接关系，关联关系紧密，依赖关系松散，关联相当于类中成员变量，依赖相当于类中成员方法里的参数或者局部变量

继承与实现

子类继承父类，具有父类中定义的变量和方法，子类实现接口，接口只有方法的定义，没有方法的实现

聚合与组合

聚合是多个对象聚合在一起，整体对象生命周期结束消失后，聚合的对象依然存在
组合是多个对象组合在一起，组合起来的整体对象消失了，各个对象也会消失

泛化

表示一般与特殊的关系，即“一般”元素是“特殊”关系的泛化

4）静态图（静态建模）

1、用例图

描述系统的功能需求，描述的是外部执行者（Actor）所理解的系统功能，描述了待开发系统的功能需求

系统的业务功能有哪些，如何对外提供服务，强调的是执行者与系统功能之间的关系，执行者可能是人，也可能是系统，用例图中的方框表示用例边界（即系统边界）

2、部署图

描述系统硬件的物理拓扑结构以及在此结构上执行的软件，部署图的元素有结点和连接，部署图中的结点代表硬件，还包括在其上运行的软件组件，软件组件代表可执行的物理代码模块

描述系统部署的情况，软件如何部署，部署在哪些服务器上，服务器之间如何访问调用

3、组件图

组件（Component），系统中遵从一组接口且提供其实现的物理的、可替换的部分，可以看作是包与类的物理代码模块，逻辑上与包、类对应，实际上是一个文件，有以下几种类型的构件：

源代码构件
二进制构件
可执行构件

组件，一种是物理组件，可复用和替换的部分，通常软件开发打包出来的，window开发，打包出来dll，Java开发打包出来时jar包，一种是逻辑组件，系统在逻辑上分解为不同的模块

组件图，描述业务组件之间，模块之间关系的图，要表达组件之间的调用关系，可以使用组件图的时序图

架构师理清组件以及组件之间的关系，进而可以更有效率进行程序开发，不同人负责不同的组件，在清晰的依赖关系下组合在一起即可，进而形成系统

4、类图与对象图

类图与对象图表达类与对象模型的静态结构

类图（ClassDiagrams），描述类之间和类与对象之间的关系

对象图（ObjectDiagrams），描述对象之间的关系，与类图相似，不常用

5、包图

解决问题就是如何将大系统拆分为小系统，表达系统与子系统之间的关系，类似于包，形成高内聚、低耦合，主要是为了降低系统的复杂性，不常用

5）动态图（动态建模）

动态模型，主要描述系统的动态关系和控制结构，即运行期间模型元素之间调用依赖的关系如何变化

动态模型中，对象间的交互是通过对象间的消息传递完成的

1、消息（Message）

简单消息（simple）

表示控制流，描述控制如何从一个对象传递到另一个对象，但不描述通信的细节，不区分同步或者异步

同步消息（synchronous）

一种嵌套的控制流，用操作调用实现，操作的执行者要到消息相应操作执行完并回送一个简单消息后，再继续执行

相互之间需要明确信息，一旦其中一方未得到响应，就会被阻塞等待

异步消息（asynchronous）

一种异步的控制流，消息的发送者在消息发送后就继续执行，不等待消息的处理

子系统与组件之间的调用关系，不需要实时获取处理结果，采用异步消息方式

2、序列图/时序图

描述对象之间动态的交互行为，着重体现对象间消息传递的时间顺序

时序图存在两个轴

水平轴表示对象
垂直轴表示时间，即对象的生命周期

方块表示广义的对象，可以是类的对象，也可以是组件，也可以是子系统或者服务器，对象下方的长条，表示对象处于执行状态

3、活动图

活动图描述了系统中各种活动的执行的顺序，刻化一个方法中所要进行的各项活动的执行流程，也即描述处理流程和处理逻辑

既可用来描述操作（类的方法）的行为，也可以描述用例和对象内部的工作过程，并可用于表示并行过程

UML中没有流程图，流程图描述开始到结束的整个处理过程，包含哪些操作、哪些分支判断、如何进行跳转，UML中使用活动图描述流程的整个过程，用于表达各个环节的选择判断，描述处理的逻辑和流程，常用

4、状态图

描述一个特定对象的所有可能的状态及其引起状态转移的事件，一个状态图包括一系列的状态以及状态之间的转移

状态图中定义的状态：

初态-状态图的起始点，一个状态图只能有一个初态
终态-是状态图的终点，而终态则可以有多个
中间状态-可包括三个区域:名字域、状态变量与活动域。
复合状态-可以进一步细化的状态称作复合状态

5、协作图/合作图

描述对象之间如何协作，可由时序图转化得出合作图，合作图就是一种没有“时序”的时序图，不常用

顺序图着重体现交互的时间顺序，合作图则着重体现交互对象间的静态链接关系

6）实现模型

实现模型描述了系统实现时的特性，又称为物理体系结构建模，包括源代码的静态结构和运行时刻的实现结构

实现模型：

（1）组件图

代码本身的逻辑结构，描述系统中存在的软件及其之间的连接关系

（2）部署图

描述系统中硬件与软件的配置情况和系统体系结构

---

参考

《从 0 开始学架构》01 | 架构到底是指什么？