268 lines
16 KiB
Markdown
268 lines
16 KiB
Markdown
---
|
||
title: "架构蓝图--软件架构的“4+1”视图模型"
|
||
source: "https://zhuanlan.zhihu.com/p/617082730"
|
||
author:
|
||
- "[[知乎专栏]]"
|
||
published:
|
||
created: 2024-12-16
|
||
description: "企业架构包含业务架构和IT架构两个部分。本文介绍了IT架构设计中的"4+1"视图模型。"4+1"视图模型诞生于上个世纪90年代，至今对我们进行业务架构到IT架构的映射仍然具有指导和借鉴意义。 “4+1”架…"
|
||
tags:
|
||
- "clippings"
|
||
---
|
||
企业架构包含业务架构和IT架构两个部分。本文介绍了IT架构设计中的"4+1"视图模型。"4+1"视图模型诞生于上个世纪90年代，至今对我们进行业务架构到IT架构的映射仍然具有指导和借鉴意义。
|
||
|
||
软件架构用来设计和实现软件的高级结构。它将一定数量的架构元素组装成一些精心选择的形式， 以满足系统的主要功能和性能需求，以及其他一些非功能需求，如可靠性、可伸缩性、可移植性和可用性。Perry and Wolfe 用以下模型表达软件架构：
|
||
|
||
**软件架构= {元素、关系矩阵、基本原理/约束}**
|
||
|
||
软件架构处理元素抽象、分解和组合、软件风格和UI美学。为了描述一个软件架构，我们使用了一个由多个视图组成的模型。为了最终解决大型和具有挑战性的架构，我们提出的模型包括五个主要视图：
|
||
|
||
- **逻辑视图**，即设计的对象模型 (当使用面向对象的设计方法时) ；
|
||
- **流程视图**，它捕获了设计的并发性和同步性方面；
|
||
- **物理视图**，它描述了软件到硬件上的映射，并反映了其分布式方面；
|
||
- **开发视图**，它描述了软件在其开发环境中的静态结构(系统和应用)。
|
||
|
||
![[a37bf19a83f2e5629ea57652a1e7eebd_MD5.jpg]]
|
||
|
||
对架构的描述——所做的决策——可以围绕这四个视图进行组织，然后通过一些选定的用例或成为第五个视图的场景(注1)进行说明。
|
||
|
||
### **逻辑架构**
|
||
|
||
**\---面向对象的分解**
|
||
|
||
逻辑架构主要支持功能需求，也就是系统应该为其用户提供的服务。系统被分解为一组关键抽象元素，这些抽象元素来自问题域，以对象或对象类的形式获取。对象利用了抽象、封装和继承的原则。这种分解不仅是为了进行功能分析，而且还可以用于识别在系统的各个部分之间的通用机制和设计元素。
|
||
|
||
**逻辑架构视图的样式：**逻辑架构视图使用Ratioon/Booch方法，通过类图和类模板来表示。
|
||
|
||
![[f26163d2a688f5dd905a1c7d4a8f305f_MD5.jpg]]
|
||
|
||
类图显示了一组类及其逻辑关系：关联 、泛化、组合、聚合、继承等等。相关的类可以分组为类别。
|
||
|
||
类模板专注于每个单独的类；它们强调主要的类操作，并识别关键的对象特征。如果定义对象的内部行为很重要，则可以通过状态转换图或状态图来完成。在类功能中定义了公共机制或服务。
|
||
|
||
![[3664d178531d5457c891cc46951ee436_MD5.jpg]]
|
||
|
||
图中设备信息是个类模板，电子设备和机床设备这两个类泛化（或抽象）为设备信息。
|
||
|
||
除了面向对象的方法(OO)方法，数据驱动的软件应用可以使用其他形式的逻辑视图，如著名的E-R图。
|
||
|
||
![[41e4ea597208e67082f94a303374efbf_MD5.jpg]]
|
||
|
||
### **流程架构**
|
||
|
||
**\----流程分解**
|
||
|
||
流程架构(注1)考虑了一些非功能的需求，如性能和可用性。它解决了并发性和分布、系统完整性、容错问题，以及逻辑视图的主要抽象元素如何适合流程架构---通过线程控制来执行对象的操作。
|
||
|
||
流程架构可以在几个抽象级别上进行描述，每个级别都处理不同的问题。在最高级别上，流程架构可以被看作是一组独立执行的通信程序的逻辑网络 (称为“流程”) ，分布在由局域网或广域网连接的一组硬件资源上。多个可同时的逻辑网络存在，共享相同的物理资源。例如，独立的逻辑网络可用于支持在线操作系统与离线系统的分离，以及支持软件的模拟或测试版本的共存。
|
||
|
||
流程是构成一个可执行单元的一组任务。任务是一个单独的控制线程，可以单独调度在一个处理节点上。
|
||
|
||
流程表示流程架构可以被战术控制的级别(例如, 已启动、已恢复、重新配置和关闭)。在此外，还可以复制流程，以增加处理负载的分布，或改进可用性。
|
||
|
||
任务可以分为：
|
||
|
||
- **主要任务：**是可以唯一处理的架构元素。
|
||
- **次要任务:** 是由于实现原因 (周期性活动、缓冲、超时等) 在本地引入的附加任务。例如，它们可以被实现为Ada任务，或轻量级的线程。
|
||
|
||
主要任务通过一组定义良好的任务间通信机制进行通信：同步和异步的基于消息的通信服务、远程流程调用、事件广播等。次要任务可以通过集合内存或共享内存进行通信。重大任务不得对其在同一流程或加工节点 中的配置进行假设。
|
||
|
||
**流程视图的样式：**流程可以通过一个具有判断、分支和合并的任务流程图进行绘制。
|
||
|
||
![[a692b621a4b5e4fbb40e9dfbb2acce3f_MD5.jpg]]
|
||
|
||
图中显示了一个蓝牙智能手表健康检测系统的任务流程图。
|
||
|
||
### **开发架构**
|
||
|
||
**\---子系统分解**
|
||
|
||
开发架构(注3)侧重于软件开发环境上的软件模块静态结构。软件被打包成应用程序库或子系统， 可以由一个或少数开发人员开发。
|
||
|
||
子系统被组织在一个层的层次结构中，每一层都为它上面的层提供了接口。系统的开发架构由模块和子系统图表示，显示了“export”和“import” 的关系(注4)。只有在确定了软件的所有元素时，才能描述完整的开发架构。开发架构的管理规则包括：分区、分组、可见性。
|
||
|
||
在大多数情况下，开发架构考虑了与开发的简易性、软件管理、重用或通用性相关的内部需求，以及工具集或编程语言所施加的约束。开发视图作为需求分配的基础，用于将工作分配给团队（甚至团队组织）、成本评估和规划、监控项目进度，以推理软件重用、可移植性和安全性。它是建立产品线的基础。
|
||
|
||
**开发视图的样式**
|
||
|
||
开发视图通常采用分层样式。每一层都有一个明确定义的责任。设计规则是，某个子系统只能依赖于同一层或下层的子系统，以尽量减少模块之间依赖关系，并允许简单的逐层发布策略。
|
||
|
||
![[6fbf7f074500217d780887fe980d73de_MD5.jpg]]
|
||
|
||
### **物理架构**
|
||
|
||
**\--将软件映射到硬件**
|
||
|
||
物理架构主要考虑了系统的非功能需求，如可用性、可靠性 (容错性) 、性能 (吞吐量) 和可伸缩性。软件在计算机网络或物理设施 (或简称节点) 上执行，确定的各种元素——网络、流程、任务和对象——需要映射到各个节点上。
|
||
|
||
节点使用不同的物理配置：一些用于开发和测试，另一些用于为不同的站点或不同的客户部署系统。因此，软件到节点的映射需要高度灵活，并对源代码本身的影响最小。
|
||
|
||
![[07a0c9ca571d89b92690208aea1ff81d_MD5.jpg]]
|
||
|
||
图中显示了一个大规模分布式集群的物理架构。
|
||
|
||
### 场景视图
|
||
|
||
四个视图中的元素通过使业务场景视图或用例图无缝地协同工作。业务场景在某种意义上是对最重要需求的抽象。场景视图在传统IT架构设计中是多余的(因此是“+1”) 。场景视图有两个主要目的：
|
||
|
||
- 作为在架构设计流程中发现架构元素的驱动因素和需求；
|
||
- 作为在此架构设计完成之后的验证。
|
||
|
||
![[ff9c702eadfa43c8fd45edc8a46511ae_MD5.jpg]]
|
||
|
||
图中显示了一个通过用例图绘制的场景视图。
|
||
|
||
## 视图之间的对应关系
|
||
|
||
不同的视图并不是完全正交的或独立的。一个视图中的元素与其他视图中的元素相连接，并遵循特定的设计规则和启发式方法。
|
||
|
||
### **从逻辑视图到流程视图**
|
||
|
||
我们确定了逻辑架构类的几个重要特征：
|
||
|
||
- **自主性：**对象是否主动、被动、受保护？
|
||
|
||
\-一个活动对象主动调用其他对象的操作或其自己的操作，并完全控制由其他对象调用其自己的操作
|
||
|
||
\-被动对象永远不会自发地调用任何操作，也无法控制其他对象调用自己的操作
|
||
|
||
\-受保护的对象永远不会自发地调用任何操作，而是对调用其操作执行一些仲裁。
|
||
|
||
- **持久性：**这些对象是短暂的，永久的吗？它们是流程或处理器的故障吗？
|
||
- **从属关系**：一个对象的存在或持久性是取决于另一个对象的吗？
|
||
- **分布：**一个对象的状态或操作是否可以从物理架构中的多个节点、从流程架构中的多个流程中访问？
|
||
|
||
在架构的逻辑视图中，我们认为每个对象都是活动的，并且可能是“并发的”。因此，逻辑架构只考虑了需求的功能方面。
|
||
|
||
然而，当我们开始定义流程架构时，实现每个对象都有自己的控制线程。此外，如果对象是并发的，必须有某种形式的仲裁来调用它们的操作。
|
||
|
||
另一方面，需要多个控制线程有几个原因：
|
||
|
||
- 对某些类型的外部刺激做出快速反应，包括与时间相关的事件；
|
||
- 来利用一个节点中的多个CPU，或利用一个分布式系统中的多个节点；
|
||
- 为了提高CPU的利用率，通过将CPU分配给其他活动，而一些控制线程被暂停，等待一些其他活动完成(例如, 访问某些外部设备，或访问某些其他活动对象)；
|
||
- 确定活动的优先级 (并有可能提高响应性)；
|
||
- 支持系统的可扩展性 (具有共享负载的其他流程)；
|
||
- 区分软件不同领域之间的问题；
|
||
- 实现更高的系统可用性 (具有备份流程)；
|
||
|
||
![[a28bee9d0c908ee097556ff5f0697228_MD5.jpg]]
|
||
|
||
我们同时使用两种策略来确定并发性的“正确”数量，并定义所需的流程集：
|
||
|
||
**由内而外：**
|
||
|
||
从逻辑架构开始：
|
||
|
||
a）定义代理任务，将单个控制线程复用到一个类的多个活动对象中；
|
||
|
||
b）持久性或生命周期从属于某个活动对象的对象也在同一代理上执行；
|
||
|
||
c）需要相互执行的几个类排除，或者只需要少量处理就可以共享一个代理。这种集群一直持续到我们将进程减少到一个相当小的数量，仍然允许物理资源的分配和使用。
|
||
|
||
**由外而内：**
|
||
|
||
从物理架构开始：
|
||
|
||
a)识别对系统的外部刺激 (请求) ，定义处理刺激的客户端流程，以及仅提供服务而不启动服务的服务器流程；
|
||
|
||
b)使用问题的数据完整性和序列化约束来定义正确的服务器集，并 将对象分配给客户端和服务器代理；
|
||
|
||
c)确定必须分配哪些对象。
|
||
|
||
其结果是将类 (及其对象) 映射到流程架构的一组任务和流程上。通常，一个活动类有一个代理任务，但有一些变化：给定类的多个代理以增加吞吐量，或者多个类映射到单个代理，因为它们的操 作很少被调用或保证顺序执行。
|
||
|
||
上述过程不是一个线性的、确定性的流程，而是一个迭代的过程，例如先从外到内再从内外。
|
||
|
||
![[a1dc66a560aaa37d35fc210542806a33_MD5.jpg]]
|
||
|
||
图中展示了一个假设的空中交通控制系统的类(逻辑视图)如何映射到流程上。
|
||
|
||
**逻辑视图包括:**
|
||
|
||
- **飞行类：**包括航班、飞行许可和飞行配置类；飞行配置类由位置类和空域类组成；
|
||
- **空域分区类：**空域分区类建立了一个空域分区(模板)， 以分配控制器对飞行的管辖权。空域类是空域分区类的一个实例。
|
||
|
||
![[dce52aa9dddb8af86c12a3358da2f9a2_MD5.jpg]]
|
||
|
||
**逻辑视图到流程(注1)的映射：**
|
||
|
||
a)空域分区类只能由单个代理处理，但可以与飞行类共享服务器流程：空域分区类很少更新;
|
||
|
||
b)位置、空域和其他静态航空信息是受保护的对象(飞行类)，在几个类之间共享，很少更新；它们被映射到自己的服务器上，并分发到其他流程；
|
||
|
||
c)飞行类被映射到一组飞行代理上。飞行代理上有许多飞行需要处理，高速率的外部刺激，响应时间至关重要 ，负荷必须分布在多个cpu上。此外，航班处理的持久性和分发方面受航班服务器影响，由于可用性原因，该服务器包括一个备用服务器。
|
||
|
||
d)飞行配置或空域总是从属于飞行，尽管有复杂的等级，但它们共享飞行等级的流程。航班被分配到其他几个流程，特别是为了显示和外部接口。
|
||
|
||
### **从逻辑视图到开发视图**
|
||
|
||
类通常作为模块实现。大型类被分解为多个包。密切相关的类/类别的集合被分组为子系统。对于子系统的定义，必须考虑额外的约束条件，如团队组织、预期的代码大小、预期的重用程度和通用性，以及严格的分层原则(可见性问题) 、 发布策略和配置管理。因此，我们通常以一个与逻辑视图没有一一对应的(开发)视图结束。
|
||
|
||
### **从流程视图到物理视图**
|
||
|
||
流程和流程组被映射到可用的物理硬件上，并以各种配置的方式进行测试或部署。
|
||
|
||
流程到物理的映射主要涉及逻辑视图，即使用的类，以及当对象之间的交互涉及多个控制线程时的流程视图。
|
||
|
||
不同的流程以不同的任务部署在服务器上，需要考虑的因素服务器的容量、安全和性能要求。
|
||
|
||
## 定制模型
|
||
|
||
并非所有的软件架构都需要完整的“4+1”视图。可以从架构描述中省略无用的视图，例如，如果只有一个处理器，则可以省略物理视图。对于非常小的系统，甚至有可能逻辑视图和开发视图非常相似，因此不需要单独的描述。
|
||
|
||
## 架构迭代
|
||
|
||
架构设计包括的4个阶段：绘制、组织、指定和优化。我们提倡一种更迭代的开发，即架构实际上是原型化、测试、度量、分析的，然后在随后的迭代中进行改进。
|
||
|
||
除了允许减轻与架构相关的风险外，这种方法对项目还有其他好处：团队建设、培训、熟悉架构、工具的获取、流程和工具的运行等等。 (我们在这里说的是一个进化原型，它慢慢成长成为系统，而不是被抛弃的探索性原型。) 这种迭代方法还允许细化、成熟、更好地理解需求。
|
||
|
||
## **场景驱动**
|
||
|
||
系统最关键的功能以场景 (或用例) 的形式被捕获。我们所说的关键是指：最重要的功能，系统存在的功能，或具有最高使用频率的功能，或存在一些必须减轻的重大技术风险的功能。
|
||
|
||
**开始：**
|
||
|
||
根据风险和临界性选择了少量的迭代场景。可以综合一些场景来抽象出一些用户需求；
|
||
|
||
- 一个架构草图已经到位。然后对这些场景进行“脚本化(注2)” ， 以识别主要抽象 ( 类、机制、流程、子系统) ，并分解成对的序列 (对象、操作) ；
|
||
- 将识别的架构元素布局在4个蓝图上：逻辑、流程、开发和物理；
|
||
- 然后实现、测试、验证该架构，这种分析可能会检测到一些缺陷或潜在的增强。
|
||
- 识别捕捉到的经验教训。
|
||
|
||
**迭代**
|
||
|
||
下一个迭代可以从：
|
||
|
||
- 重新评估风险；
|
||
- 扩展要考虑的场景要素
|
||
- 选择一些允许风险缓解或更大架构的额外场景覆盖；
|
||
|
||
然后：
|
||
|
||
- 尝试在初步架构中编写这些场景的脚本
|
||
- 发现其他架构元素，或者有时需要发生的重要架构更改
|
||
- 更新4个主要的蓝图：逻辑，流程，开发，物理；
|
||
- 根据这些更改修改现有的方案升级实现 (架构原型) ， 以支持新的扩展场景集。
|
||
|
||
**结束**
|
||
|
||
End
|
||
|
||
---
|
||
|
||
译者注：
|
||
|
||
注1：第五个视图正是我们的业务架构中常用的业务场景视图，而业务场景视图可以用其他业务建模方式如用户故事地图、事件风暴、业务用例视图来替代。
|
||
|
||
注2：此处的流程非业务流程，而是指IT架构中的信息流和数据流，对应PCF中L3以下的流程。
|
||
|
||
注3：此处的开发架构对应IT架构中的应用架构。
|
||
|
||
注4：export用于对外输出本模块变量的接口（一个文件可以理解为一个模块）。import用于在一个模块中加载另一个含有export接口的模块。
|
||
|
||
注 5：此处流程指 CPU 处理的任务顺序，和线程有关。
|
||
|
||
注 6：采用讲故事的方法对业务上下文进行描述。
|
||
|
||
*本文内文翻译自PhilippeKruchten在1995年在IEEE Software上发表的一篇文章《Architectural Blueprints—The “4+1” View Model of Software Architecture》，为便于阅读，有删节。配图来自网络。* |