当前位置：首页 > ai >正文

【iSAQB软件架构】构建块、接口

ai 2025/6/26 22:40:29

构建块

现在我们可以探讨“构建模块”这个术语。“构建模块”这个术语经常被用作“组件”的同义词。然而，“构建模块”是一个通用术语，而“组件”是构建模块的一种特殊形式。在这方面，我们有意不使用“组件”这个术语，因为它常常被理解为其他含义。有些人认为组件主要是指 UML 组件，而另一些人则将组件与编程结构（如包或 JavaBeans）联系起来。

我们使用通俗的术语“构建模块”，从编程语言、建模方法和设计方法中使用的众多术语中抽象出软件架构的组件元素。在我们的上下文中，构建模块是特殊编程结构或描述元素的抽象。

构建模块是构建软件架构静态结构的核心基本元素。它包括最终代表源代码抽象的所有软件或实现工件。这从小型构建模块（如函数或类），到中型构建模块（如包或库），再到大型构建模块（如子系统、层或框架）都有。因此，构建模块可以以不同的方式表现出来。
这里需要注意的是，构建模块本身可以由其他构建模块组成。
在这里插入图片描述

构建块的三个基本特征：
⦁ 接口保证：构建模块按照合同意义提供并保证接口的有效性。就像一个支付模块，保证在特定配置下提供稳定的支付接口。

⦁ 封装与可替换：封装接口实现，能被具有相同接口的其他模块替换。比如，在更新数据库存储模块时，可以用新的模块替换旧的，只要接口一致。

⦁ 配置与分层：是系统分层的单位，可由其他子构建模块配置实现，并定义模块间关系。比如，订单处理模块可以包含订单生成、订单审核等子模块的组合。

接口

接口代表了系统或其构建模块的一个定义明确的访问点。在这种情况下，接口描述了这个访问点的特征（例如，属性、数据和功能）。目的是尽可能精确地定义这些特征，包括所有必要的方面，如语法、数据结构、功能行为、错误行为、非功能特征、接口使用日志、技术、协议、访问修饰符、文件格式、条件/约束和语义。

接口的这个定义清楚地表明，接口的全面规范可能极其费力。像 Java 或 C#这样的编程语言包含接口概念，通常可以用它们定义语法（接口的名称）、提供的方法及其参数和返回值。接口的其他方面，例如其功能行为，必须记录在额外的文档中。

我们经常在程序中发现不充分的接口描述。例如，如果您查看 Java 中的 Collection 接口，它似乎准备得非常好并且有详细的文档。另一方面，对于将元素插入 Collection 的 Insert 操作的性能（例如，上限和下限，或插入一个元素允许的平均时间）没有说明。

然而，对于此接口的使用，这个特性可能非常相关，特别是在处理大量元素的处理器密集型任务中。在决定是否应该使用 Java Collection ，还是必须找到替代解决方案时，这些特性至关重要。

在这种特殊情况下，程序员因此必须了解接口的具体实现并选择适当的一个。在这种情况下，他可以选择 ArrayList 或 LinkedList ，它们具有不同的性能特征。因此，尽管这是其定义的任务，但接口并未完全封装实现。

这个例子说明通常不可能创建完整的接口描述。更多时候是由架构师来决定在接口的哪些方面必须进行描述，哪些在有疑问的情况下可以忽略。然而，在可能的情况下，您仍应尝试创建完整的接口描述，并包含特定项目背景下的相关特征。

在软件架构中，无论构建模块是提供接口还是需要接口，两个构建模块都必须遵守接口协议。那么谁定义了接口和接口协议？：
在这里插入图片描述
由上图所示：
• 标准接口
此接口由外部第三方定义。提供和请求的构建模块都要遵循它。
• 提供接口
在这种情况下，接口由提供它的构建模块定义。除了标准接口，这是最常用的接口类型。
• 所需接口
在这种情况下，接口由需要它的构建模块定义。这种配置常在框架中发现。通过这些类型的接口，您可以将具有特定功能的构建模块合并到程序结构中。
• 独立的接口
在这种情况下，提供接口的构建模块和需要接口的构建模块都定义了自己的接口。这增加了构建模块的解耦性，它们可以独立开发和测试。然而，这意味着接口随着时间的推移可能不保持相同，因此必须在它们之间放置一个适配器。

以下是进一步解析：

1. 标准接口（Standard Interface）

定义主体：
由行业组织、标准化机构或企业架构委员会定义，确保跨系统互操作性和技术一致性。例如：

协议层面：如HTTP（RFC 7231）、HTTPS（RFC 2818）由IETF定义；ISAPI等专用协议由设备厂商联盟制定。
数据格式：如JSON、XML由W3C等机构标准化。

ISAQB视角：
架构师需选择符合业务场景的标准接口协议（如RESTful API基于HTTP），并确保实现遵从开放标准，避免技术锁定。

2. 提供接口（Provided Interface）

定义主体：
由组件或服务的开发者定义，明确模块对外暴露的能力。例如：

服务端接口：如WebService（SOAP协议）或HTTP API（JSON格式）由后端团队设计。
硬件接口：如摄像机ISAPI接口由设备厂商实现并公开。

关键属性：

包含输入/输出参数、协议（HTTP/TCP）、端口（如HTTPS默认443）、安全机制（如HTTPS加密）。
需通过接口描述（如OpenAPI规范）或契约（如WSDL）明确定义。

3. 所需接口（Required Interface）

定义主体：
由依赖外部资源的组件使用者定义，声明对其他模块的能力需求。例如：

客户端调用：前端基于后端提供的API文档定义所需接口格式（如请求头、URL路径）。
系统集成：平台需声明对安防设备ISAPI接口的调用规则（如认证方式、数据格式）。

ISAQB要求：

架构需明确依赖方向（如“前端→后端”），避免循环依赖。
通过接口桩（Stub）模拟所需接口，支持模块独立开发与测试。

4. 独立接口（Independent Interface）

定义主体：
由架构师主导设计，作为系统间解耦的核心设施：

中间件接口：如消息队列（MQ）的发布/订阅接口，由中间件平台定义并标准化。
适配器接口：用于异构系统集成（如数据库访问层抽象），隐藏底层实现差异。

设计原则：

技术中立性：如定义通用数据模型（如Protobuf Schema），不依赖特定传输协议。
演进兼容性：通过版本控制（如URL路径包含v1/v2）支持接口平滑升级。

5. ISAQB框架下的协作关系

接口类型	定义责任方	核心目标	案例参考
标准接口	行业组织/企业架构委员会	跨系统互操作性	HTTP、ISAPI3
提供接口	组件开发者	暴露模块能力	WebService API2
所需接口	组件使用者	声明外部依赖	前端调用后端API2
独立接口	架构师	解耦与扩展性	消息队列接口1