架构模型


软件架构涉及软件系统抽象的高层结构,通过分解和组合,具有架构风格和质量属性。软件架构设计必须符合系统的主要功能和性能需求,同时满足可靠性、可扩展性、可移植性、可用性等非功能性需求。

软件架构必须描述其组件组、它们的连接、它们之间的交互以及所有组件的部署配置。

软件架构可以通过多种方式定义 -

  • UML(统一建模语言) - UML 是软件建模和设计中使用的面向对象的解决方案之一。

  • 架构视图模型(4+1视图模型) - 架构视图模型代表软件应用程序的功能和非功能需求。

  • ADL(架构描述语言) - ADL 在形式上和语义上定义了软件架构。

统一建模语言

UML 代表统一建模语言。它是一种用于制作软件蓝图的图形语言。UML 由对象管理组 (OMG) 创建。UML 1.0 规范草案于 1997 年 1 月向 OMG 提出。它作为软件需求分析和设计文档的标准,是开发软件的基础。

UML 可以被描述为一种通用的可视化建模语言,用于可视化、指定、构造和记录软件系统。尽管UML通常用于对软件系统进行建模,但它并不限于此范围。它还用于对非软件系统进行建模,例如制造单元中的流程。

这些元素就像组件一样,可以通过不同的方式关联起来形成完整的 UML 图片,即所谓的图表。因此,理解不同的图表以在现实系统中实现知识非常重要。我们有两大类图表,它们进一步分为子类别,即结构图Behave图

结构图

结构图表示系统的静态方面。这些静态方面代表了图表中形成主要结构的部分,因此是稳定的。

这些静态部分由类、接口、对象、组件和节点表示。结构图可以细分如下 -

  • 类图
  • 对象图
  • 元件图
  • 部署图
  • 封装图
  • 复合结构

下表提供了这些图的简要说明 -

先生。 图表及说明
1

班级

代表系统的面向对象。显示类如何静态相关。

2

目的

表示运行时的一组对象及其关系,也表示系统的静态视图。

3

成分

描述系统的所有组件、它们的相互关系、交互和接口。

4

复合结构

描述组件的内部结构,包括组件的所有类、接口等。

5

包裹

描述包结构和组织。涵盖包中的类以及另一个包中的包。

6

部署

部署图是一组节点及其关系。这些节点是部署组件的物理实体。

Behave图

Behave图基本上捕获了系统的动态方面。动态方面基本上是系统的变化/移动部分。UML 有以下类型的Behave图 -

  • 用例图
  • 时序图
  • 通讯图
  • 状态图图
  • 活动图
  • 交互概览
  • 时序图

下表提供了这些图的简要说明 -

先生。 图表及说明
1

使用案例

描述功能及其内部/外部控制器之间的关系。这些控制器称为参与者。

2

活动

描述系统中的控制流程。它由活动和链接组成。该流程可以是顺序的、并发的或分支的。

3

状态机/状态图

表示系统的事件驱动状态变化。它基本上描述了类、接口等的状态变化。用于可视化系统通过内部/外部因素的反应。

4

顺序

可视化系统中执行特定功能的调用序列。

5

交互概述

结合活动图和序列图来提供系统和业务流程的控制流概述。

6

沟通

与序列图相同,只是它侧重于对象的角色。每个通信都与序列顺序、编号加上过去的消息相关联。

7

时间顺序

通过消息描述状态、条件和事件的变化。

架构视图模型

模型是对软件架构的完整、基本和简化的描述,它由特定角度或观点的多个视图组成。

视图是从一组相关关注点的角度对整个系统的表示。它用于从不同利益相关者(例如最终用户、开发人员、项目经理和测试人员)的角度来描述系统。

4+1视图模型

4+1 视图模型由 Philippe Kruchten 设计,用于描述基于使用多个并发视图的软件密集型系统的体系结构。它是一个多视图模型,可以解决系统的不同功能和问题。它标准化了软件设计文档,并使所有利益相关者易于理解设计。

它是一种用于研究和记录软件架构设计的架构验证方法,涵盖了所有利益相关者的软件架构的所有方面。它提供了四个基本观点 -

  • 逻辑视图或概念视图- 它描述了设计的对象模型。

  • 流程视图- 它描述系统的活动,捕获设计的并发和同步方面。

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

  • 开发视图- 它描述了软件在其开发环境中的静态组织或结构。

可以通过为软件系统的最终用户或客户添加一个称为场景视图用例视图的视图来扩展此视图模型。它与其他四个视图一致,用于说明充当“加一”视图(4+1)视图模型的架构。下图描述了采用五并发视图(4+1)模型的软件架构。

4+1视图模型

为什么叫4+1而不是5呢?

例视图具有特殊的意义,因为它详细说明了系统的高级需求,而其他视图则详细说明了如何实现这些需求。当所有其他四个视图都完成后,它实际上是多余的。然而,没有它,所有其他观点都是不可能的。下图和表格详细显示了 4+1 视图 -

逻辑性 过程 发展 身体的 设想
描述 显示系统的组件(对象)以及它们的交互 显示系统的进程/工作流规则以及这些进程如何通信,重点关注系统的动态视图 给出系统的构建块视图并描述系统模块的静态组织 显示软件应用程序的安装、配置和部署 通过执行验证和插图显示设计已完成
观众/利益相关者 最终用户、分析师和设计师 集成商和开发商 程序员和软件项目经理 系统工程师、操作员、系统管理员和系统安装人员 他们的观点和评估者的所有观点
考虑 功能要求 非功能性需求 软件模块组织(软件管理重用、工具约束) 有关底层硬件的非功能性需求 系统一致性和有效性
UML – 图表 类、状态、对象、序列、通信图 活动图 元件、封装图 部署图 用例图

架构描述语言 (ADL)

ADL 是一种提供用于定义软件架构的语法和语义的语言。它是一种符号规范,提供了对软件系统概念架构进行建模的功能,与系统的实现不同。

ADL 必须支持架构组件、它们的连接、接口和配置,它们是架构描述的构建块。它是一种用于架构描述的表达形式,提供分解组件、组合组件和定义组件接口的能力。

架构描述语言是一种形式化的规范语言,它描述了进程、线程、数据、子程序等软件特征以及处理器、设备、总线、内存等硬件组件。

很难对 ADL 和编程语言或建模语言进行分类或区分。但是,将语言归类为 ADL 需要满足以下要求 -

  • 它应该适合于将架构传达给所有相关方。

  • 它应该适合架构创建、细化和验证的任务。

  • 它应该为进一步的实现提供基础,因此它必须能够向ADL规范添加信息,使得最终的系统规范能够从ADL导出。

  • 它应该能够代表大多数常见的架构风格。

  • 它应该支持分析功能或提供快速生成原型实现。