![cover](https://img-blog.csdnimg.cn/d708438f7a0c4b4eaa5336166378a262.jpeg)
架构蓝图--软件架构的“4+1”视图模型
企业架构包含业务架构和 IT 架构两个部分。本文介绍了 IT 架构设计中的"4+1"视图模型。"4+1"视图模型诞生于上个世纪 90 年代,至今对我们进行业务架构到 IT 架构的映射仍然具有指导和借鉴意义。
目录
目录
绍了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:采用讲故事的方法对业务上下文进行描述。
本文内文翻译自Philippe Kruchten在1995年在IEEE Software上发表的一篇文章《Architectural Blueprints—The “4+1” View Model of Software Architecture》,为便于阅读,有删节。配图来自网络。
![Logo](https://devpress.csdnimg.cn/79de2bf0b7994defa4242ef90d5513fa.jpg)
开放原子开发者工作坊旨在鼓励更多人参与开源活动,与志同道合的开发者们相互交流开发经验、分享开发心得、获取前沿技术趋势。工作坊有多种形式的开发者活动,如meetup、训练营等,主打技术交流,干货满满,真诚地邀请各位开发者共同参与!
更多推荐
所有评论(0)