目录

目录

“4+1”架构模型概述

逻辑架构

流程架构

开发架构

物理架构

场景视图

视图之间的对应关系

从逻辑视图到流程视图

从逻辑视图到开发视图

从流程视图到物理视图

定制模型

架构迭代

场景驱动

绍了IT架构设计中的”4+1″视图模型。”4+1″视图模型诞生于上个世纪90年代，至今对我们进行业务架构到IT架构的映射仍然具有指导和借鉴意义。

“4+1”架构模型概述

软件架构用来设计和实现软件的高级结构。它将一定数量的架构元素组装成一些精心选择的形式， 以满足系统的主要功能和性能需求，以及其他一些非功能需求，如可靠性、可伸缩性、可移植性和可用性。

Perry and Wolfe 用以下模型表达软件架构：

软件架构= {元素、关系矩阵、基本原理/约束}

软件架构处理元素抽象、分解和组合、软件风格和UI美学。为了描述一个软件架构，我们使用了一个由多个视图组成的模型。为了最终解决大型和具有挑战性的架构，我们提出的模型包括五个主要视图：

  • 逻辑视图，即设计的对象模型 (当使用面向对象的设计方法时) ；

  • 流程视图，它捕获了设计的并发性和同步性方面；

  • 物理视图，它描述了软件到硬件上的映射，并反映了其分布式方面；

  • 开发视图，它描述了软件在其开发环境中的静态结构(系统和应用)。

对架构的描述——所做的决策——可以围绕这四个视图进行组织，然后通过一些选定的用例或成为第五个视图的场景(注1)进行说明。

逻辑架构

—面向对象的分解

逻辑架构主要支持功能需求，也就是系统应该为其用户提供的服务。系统被分解为一组关键抽象元素，这些抽象元素来自问题域，以对象或对象类的形式获取。对象利用了抽象、封装和继承的原则。这种分解不仅是为了进行功能分析，而且还可以用于识别在系统的各个部分之间的通用机制和设计元素。

逻辑架构视图的样式：

逻辑架构视图使用Ratioon/Booch方法，通过类图和类模板来表示。

类图显示了一组类及其逻辑关系：关联 、泛化、组合、聚合、继承等等。相关的类可以分组为类别。

类模板专注于每个单独的类；它们强调主要的类操作，并识别关键的对象特征。如果定义对象的内部行为很重要，则可以通过状态转换图或状态图来完成。在类功能中定义了公共机制或服务。

图中设备信息是个类模板，电子设备和机床设备这两个类泛化（或抽象）为设备信息。

除了面向对象的方法(OO)方法，数据驱动的软件应用可以使用其他形式的逻辑视图，如著名的E-R图。

流程架构

—-流程分解

流程架构(注1)考虑了一些非功能的需求，如性能和可用性。它解决了并发性和分布、系统完整性、容错问题，以及逻辑视图的主要抽象元素如何适合流程架构—通过线程控制来执行对象的操作。

流程架构可以在几个抽象级别上进行描述，每个级别都处理不同的问题。在最高级别上，流程架构可以被看作是一组独立执行的通信程序的逻辑网络 (称为“流程”) ，分布在由局域网或广域网连接的一组硬件资源上。多个可同时的逻辑网络存在，共享相同的物理资源。例如，独立的逻辑网络可用于支持在线操作系统与离线系统的分离，以及支持软件的模拟或测试版本的共存。

流程是构成一个可执行单元的一组任务。任务是一个单独的控制线程，可以单独调度在一个处理节点上。

流程表示流程架构可以被战术控制的级别(例如, 已启动、已恢复、重新配置和关闭)。在此外，还可以复制流程，以增加处理负载的分布，或改进可用性。

任务可以分为：

  • 主要任务：是可以唯一处理的架构元素。

  • 次要任务: 是由于实现原因 (周期性活动、缓冲、超时等) 在本地引入的附加任务。例如，它们可以被实现为Ada任务，或轻量级的线程。

主要任务通过一组定义良好的任务间通信机制进行通信：同步和异步的基于消息的通信服务、远程流程调用、事件广播等。次要任务可以通过集合内存或共享内存进行通信。重大任务不得对其在同一流程或加工节点 中的配置进行假设。

流程视图的样式：

流程可以通过一个具有判断、分支和合并的任务流程图进行绘制。

图中显示了一个蓝牙智能手表健康检测系统的任务流程图。

开发架构

—子系统分解

开发架构(注3)侧重于软件开发环境上的软件模块静态结构。软件被打包成应用程序库或子系统， 可以由一个或少数开发人员开发。

子系统被组织在一个层的层次结构中，每一层都为它上面的层提供了接口。系统的开发架构由模块和子系统图表示，显示了“export”和“import” 的关系(注4)。只有在确定了软件的所有元素时，才能描述完整的开发架构。开发架构的管理规则包括：分区、分组、可见性。

在大多数情况下，开发架构考虑了与开发的简易性、软件管理、重用或通用性相关的内部需求，以及工具集或编程语言所施加的约束。开发视图作为需求分配的基础，用于将工作分配给团队（甚至团队组织）、成本评估和规划、监控项目进度，以推理软件重用、可移植性和安全性。它是建立产品线的基础。

开发视图的样式

开发视图通常采用分层样式。每一层都有一个明确定义的责任。设计规则是，某个子系统只能依赖于同一层或下层的子系统，以尽量减少模块之间依赖关系，并允许简单的逐层发布策略。

物理架构

–将软件映射到硬件

物理架构主要考虑了系统的非功能需求，如可用性、可靠性 (容错性) 、性能 (吞吐量) 和可伸缩性。软件在计算机网络或物理设施 (或简称节点) 上执行，确定的各种元素——网络、流程、任务和对象——需要映射到各个节点上。

节点使用不同的物理配置：一些用于开发和测试，另一些用于为不同的站点或不同的客户部署系统。因此，软件到节点的映射需要高度灵活，并对源代码本身的影响最小。

图中显示了一个大规模分布式集群的物理架构。

场景视图

四个视图中的元素通过使业务场景视图或用例图无缝地协同工作。业务场景在某种意义上是对最重要需求的抽象。场景视图在传统IT架构设计中是多余的(因此是“+1”) 。

场景视图有两个主要目的：

  • 作为在架构设计流程中发现架构元素的驱动因素和需求；

  • 作为在此架构设计完成之后的验证。

图中显示了一个通过用例图绘制的场景视图。

视图之间的对应关系

不同的视图并不是完全正交的或独立的。一个视图中的元素与其他视图中的元素相连接，并遵循特定的设计规则和启发式方法。

从逻辑视图到流程视图

我们确定了逻辑架构类的几个重要特征：

  • 自主性：对象是否主动、被动、受保护？

-一个活动对象主动调用其他对象的操作或其自己的操作，并完全控制由其他对象调用其自己的操作

-被动对象永远不会自发地调用任何操作，也无法控制其他对象调用自己的操作

-受保护的对象永远不会自发地调用任何操作，而是对调用其操作执行一些仲裁。

  • 持久性：这些对象是短暂的，永久的吗？它们是流程或处理器的故障吗？

  • 从属关系：一个对象的存在或持久性是取决于另一个对象的吗？

  • 分布：一个对象的状态或操作是否可以从物理架构中的多个节点、从流程架构中的多个流程中访问？

在架构的逻辑视图中，我们认为每个对象都是活动的，并且可能是“并发的”。因此，逻辑架构只考虑了需求的功能方面。

然而，当我们开始定义流程架构时，实现每个对象都有自己的控制线程。此外，如果对象是并发的，必须有某种形式的仲裁来调用它们的操作。

另一方面，需要多个控制线程有几个原因：

  • 对某些类型的外部刺激做出快速反应，包括与时间相关的事件；

  • 来利用一个节点中的多个CPU，或利用一个分布式系统中的多个节点；

  • 为了提高CPU的利用率，通过将CPU分配给其他活动，而一些控制线程被暂停，等待一些其他活动完成(例如, 访问某些外部设备，或访问某些其他活动对象)；

  • 确定活动的优先级 (并有可能提高响应性)；

  • 支持系统的可扩展性 (具有共享负载的其他流程)；

  • 区分软件不同领域之间的问题；

  • 实现更高的系统可用性 (具有备份流程)；

我们同时使用两种策略来确定并发性的“正确”数量，并定义所需的流程集：

由内而外：

从逻辑架构开始：

a）定义代理任务，将单个控制线程复用到一个类的多个活动对象中；

b）持久性或生命周期从属于某个活动对象的对象也在同一代理上执行；

c）需要相互执行的几个类排除，或者只需要少量处理就可以共享一个代理。这种集群一直持续到我们将进程减少到一个相当小的数量，仍然允许物理资源的分配和使用。

由外而内：

从物理架构开始：

a)识别对系统的外部刺激 (请求) ，定义处理刺激的客户端流程，以及仅提供服务而不启动服务的服务器流程；

b)使用问题的数据完整性和序列化约束来定义正确的服务器集，并 将对象分配给客户端和服务器代理；

c)确定必须分配哪些对象。

其结果是将类 (及其对象) 映射到流程架构的一组任务和流程上。通常，一个活动类有一个代理任务，但有一些变化：给定类的多个代理以增加吞吐量，或者多个类映射到单个代理，因为它们的操 作很少被调用或保证顺序执行。

上述过程不是一个线性的、确定性的流程，而是一个迭代的过程，例如先从外到内再从内外。

图中展示了一个假设的空中交通控制系统的类(逻辑视图)如何映射到流程上。

逻辑视图包括:

  • 飞行类：包括航班、飞行许可和飞行配置类；飞行配置类由位置类和空域类组成；

  • 空域分区类：空域分区类建立了一个空域分区(模板)， 以分配控制器对飞行的管辖权。空域类是空域分区类的一个实例。

逻辑视图到流程(注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》，为便于阅读，有删节。配图来自网络。