架构模型
软件架构涉及软件系统抽象的高级结构，通过使用分解和组合，具有架构风格和质量属性。软件架构设计必须符合系统的主要功能和性能要求，并满足可靠性、可扩展性、可移植性和可用性等非功能性要求。
软件架构必须描述其组件组、它们的连接、它们之间的交互以及所有组件的部署配置。
软件架构可以通过多种方式定义 −
UML（统一建模语言） − UML 是软件建模和设计中使用的面向对象解决方案之一。
架构视图模型（4+1 视图模型） −架构视图模型表示软件应用程序的功能性和非功能性需求。
ADL（架构描述语言） − ADL 正式且语义地定义软件架构。
UML
UML 代表统一建模语言。它是一种用于制作软件蓝图的图形语言。UML 由对象管理组织 (OMG) 创建。UML 1.0 规范草案于 1997 年 1 月提交给 OMG。它是软件需求分析和设计文档的标准，是开发软件的基础。
UML 可以描述为一种通用的可视化建模语言，用于可视化、指定、构建和记录软件系统。尽管 UML 通常用于对软件系统进行建模，但它并不局限于此范围。它还用于对非软件系统（例如制造单元中的工艺流程）进行建模。
元素就像组件一样，可以以不同的方式关联起来以形成完整的 UML 图片，这称为图表。因此，了解不同的图表对于在实际系统中实施知识非常重要。我们有两大类图表，它们进一步分为子类别，即结构图和行为图。
结构图
结构图表示系统的静态方面。这些静态方面表示图表中形成主要结构并因此稳定的部分。
这些静态部分由类、接口、对象、组件和节点表示。结构图可细分如下 −
- 类图
- 对象图
- 组件图
- 部署图
- 包图
- 复合结构
下表简要描述了这些图 −
| Sr.No. | 图表和说明 |
|---|---|
| 1 |
类 表示系统的对象导向。显示类如何静态关联。 |
| 2 |
对象 表示一组对象及其在运行时的关系，也表示系统的静态视图。 |
| 3 |
组件 描述系统的所有组件、它们的相互关系、交互和接口。 |
| 4 |
复合结构 描述组件的内部结构，包括组件的所有类、接口等。 |
| 5 |
包 描述包的结构和组织。涵盖包中的类和另一个包中的包。 |
| 6 |
部署 部署图是一组节点及其关系。这些节点是部署组件的物理实体。 |
行为图
行为图基本上捕捉系统的动态方面。动态方面基本上是系统的变化/移动部分。 UML 具有以下类型的行为图 −
- 用例图
- 序列图
- 通信图
- 状态图
- 活动图
- 交互概述
- 时间序列图
下表简要介绍了这些图 −
| Sr.No. | 图表和说明 |
|---|---|
| 1 |
用例 描述功能及其内部/外部控制器之间的关系。这些控制器称为参与者。 |
| 2 |
活动 描述系统中的控制流。它由活动和链接组成。流程可以是顺序的、并发的或分支的。 |
| 3 |
状态机/状态图 表示系统的事件驱动状态变化。它基本上描述了类、接口等的状态变化。用于可视化系统对内部/外部因素的反应。 |
| 4 |
序列 可视化系统中执行特定功能的调用序列。 |
| 5 |
交互概述 结合活动和序列图，提供系统和业务流程的控制流概述。 |
| 6 |
通信 与序列图相同，只是它关注对象的角色。每次通信都与一个序列顺序、编号和过去的消息相关联。 |
| 7 |
按时间顺序 通过消息描述状态、条件和事件的变化。 |
架构视图模型
模型是对软件架构的完整、基本和简化的描述，它由来自特定角度或观点的多个视图组成。
视图是从一组相关关注点的角度对整个系统的表示。它用于从不同利益相关者（如最终用户、开发人员、项目经理和测试人员）的角度描述系统。
4+1 视图模型
4+1 视图模型由 Philippe Kruchten 设计，用于描述基于使用多个并发视图的软件密集型系统的架构。它是一个 多视图 模型，可解决系统的不同功能和关注点。它标准化了软件设计文档，使所有利益相关者都能轻松理解设计。
它是一种用于研究和记录软件架构设计的架构验证方法，涵盖了所有利益相关者的软件架构的所有方面。它提供了四个基本视图 −
逻辑视图或概念视图 − 它描述了设计的对象模型。
过程视图 − 它描述了系统的活动，捕获了设计的并发和同步方面。
物理视图 −它描述了软件到硬件的映射，并反映了其分布式方面。
开发视图 − 它描述了软件在其开发环境中的静态组织或结构。
可以通过为软件系统的最终用户或客户添加一个称为场景视图或用例视图的视图来扩展此视图模型。它与其他四个视图一致，并用于说明作为"加一"视图（4+1）视图模型的架构。下图使用五个并发视图 (4+1) 模型描述了软件架构。
为什么叫 4+1 而不是 5？
用例视图 具有特殊意义，因为它详细说明了系统的高级要求，而其他视图详细说明了如何实现这些要求。当所有其他四个视图都完成后，它实际上是多余的。但是，如果没有它，所有其他视图都不可能实现。下图和表格详细显示了 4+1 视图 −
| 逻辑 | 流程 | 开发 | 物理 | 场景 | |
|---|---|---|---|---|---|
| 描述 | 显示系统的组件（对象）及其交互 | 显示系统的流程/工作流规则以及这些流程如何通信，重点关注系统的动态视图 | 提供系统的构建块视图并描述系统模块的静态组织 | 显示软件应用程序的安装、配置和部署 | 通过执行验证显示设计已完成并插图 |
| 查看者/利益相关者 | 最终用户、分析师和设计师 | 集成商和开发人员 | 程序员和软件项目经理 | 系统工程师、操作员、系统管理员和系统安装人员 | 他们的观点和评估者的所有观点 |
| 考虑 | 功能需求 | 非功能需求 | 软件模块组织（软件管理重用、工具约束） | 与底层硬件相关的非功能需求 | 系统一致性和有效性 |
| UML – 图表 | 类、状态、对象、序列、通信图 | 活动图 | 组件、包图 | 部署图 | 用例图 |
架构描述语言 (ADL)
ADL 是一种提供语法和语义来定义软件架构的语言。它是一种符号规范，提供用于建模软件系统概念架构的功能，与系统的实现不同。
ADL 必须支持架构组件、它们的连接、接口和配置，这些都是架构描述的构建块。它是用于架构描述的一种表达形式，提供分解组件、组合组件和定义组件接口的能力。
架构描述语言是一种形式化规范语言，它描述软件功能（例如进程、线程、数据和子程序）以及硬件组件（例如处理器、设备、总线和内存）。
很难对 ADL 和编程语言或建模语言进行分类或区分。但是，将一种语言归类为 ADL 需要满足以下要求 −
它应该适合向所有相关方传达架构。
它应该适合架构创建、改进和验证任务。
它应该为进一步实施提供基础，因此它必须能够向 ADL 规范添加信息，以便从 ADL 中得出最终系统规范。
它应该能够表示大多数常见的架构风格。
它应该支持分析功能或提供快速生成原型的实现。
