首页
学习
活动
专区
工具
TVP
发布
精选内容/技术社群/优惠产品,尽在小程序
立即前往

架构蓝图--软件架构的“4+1”视图模型

企业架构包含业务架构和 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”) 。

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

  • 作为在架构设计流程中发现架构元素的驱动因素和需求;
  • 作为在此架构设计完成之后的验证。

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

未完待续...


译者注:

注 1:第五个视图正是我们的业务架构中常用的业务场景视图,而业务场景视图可以用其他业务建模方式如用户故事地图、事件风暴、业务用例视图来替代。

注 2:此处的流程非业务流程,而是指 IT 架构中的信息流和数据流,对应 PCF 中 L3 以下的流程。

注 3:此处的开发架构对应 IT 架构中的应用架构。

注 4:export 用于对外输出本模块变量的接口(一个文件可以理解为一个模块)。import 用于在一个模块中加载另一个含有 export 接口的模块。

本文内文翻译自 Philippe Kruchten 在 1995 年在 IEEE  Software 上发表的一篇文章《Architectural Blueprints—The “4+1” View Model of Software Architecture》,为便于阅读,有删节。配图来自网络。


欢迎关注涛哥微信公众号“架构领导力”和视频号“涛哥-数字产品和商业架构”

  • 发表于:
  • 本文为 InfoQ 中文站特供稿件
  • 首发地址https://www.infoq.cn/article/f371c72ecc192407e5620f6e4
  • 如有侵权,请联系 cloudcommunity@tencent.com 删除。

扫码

添加站长 进交流群

领取专属 10元无门槛券

私享最新 技术干货

扫码加入开发者社群
领券