组件图表示系统的物理或逻辑组件。它提供了软件各部分如何交互的高层次视图。本指南详细介绍了创建清晰、有效图表所需的符号、规则和实用技巧。
组件建模入门 🏗️
组件图关注的是系统结构，其层次高于类图。它们展示了不同模块或子系统是如何组织的。这种视图有助于开发人员理解软件架构的物理部署和逻辑依赖关系。
主要优势包括：
- 可视化系统结构
- 定义接口契约
- 跟踪模块之间的依赖关系
- 支持高层设计文档
在创建这些图表时，目标是清晰。避免展示每一个类。应聚焦于构成应用程序的主要构建模块。
核心符号与表示法 🔣
理解标准符号是第一步。这些元素定义了图表的视觉语言。
1. 组件图标
主要符号是一个左侧有两个凸起的矩形。该形状代表系统的一个模块化部分。在矩形内部，放置组件的名称。
- 形状：左侧有两个凸起的矩形。
- 标签：加粗的组件名称。
- 构造型： 可以在名称上方添加类似 <
> 的标签。
2. 接口
接口定义了组件提供的行为或所需的行为。它们对于将实现与使用解耦至关重要。
- 提供的接口： 一个连接到组件的“棒棒糖”形状。它表示该组件提供的功能。
- 所需的接口： 一个连接到组件的“插座”形状。它表示该组件需要从其他组件获取的功能。
3. 端口
端口是组件之间的交互点。当一个组件需要与多个不同系统连接时，通常会使用端口。
- 符号： 位于组件边框上的小矩形。
- 使用： 表示外部连接进入或离开的位置。
4. 节点
虽然组件图侧重于软件，但它们通常与部署相关。节点表示物理硬件或执行环境。
- 符号： 3D立方体形状。
- 标签： 服务器、设备或环境的名称。
| 符号 | 名称 | 含义 |
|---|---|---|
| 带标签的矩形 | 组件 | 系统的一个模块化部分 |
| 棒棒糖 | 提供的接口 | 组件提供的功能 |
| 插座 | 所需的接口 | 组件所需的功能 |
| 3D立方体 | 节点 | 物理硬件或环境 |
| 开放矩形 | 包 | 元素的分组 |
接口与端口概念 🔌
接口是组件之间的桥梁。它们确保组件之间能够通信，而无需了解彼此的内部细节。
提供的接口
当一个组件实现特定功能时，它就提供了接口。其他组件可以使用此接口与系统进行交互。
- 使用一个圆圈（棒棒糖）来表示接口。
- 将接口连接到组件线。
- 用可用的具体操作来标记接口。
所需的接口
当一个组件依赖外部功能时，它就需要一个接口。这会形成依赖关系。
- 使用一个半圆（插座）来表示接口。
- 将插座连接到组件线。
- 用所需的操作来标记接口。
使用端口
端口细化了接口的概念。它们允许您将多个接口组合在一个单一的访问点下。
- 将端口放置在组件的边缘。
- 将连线连接到端口，而不是组件主体。
- 当存在大量连接时，这可以使图表更整洁。
关系与依赖关系 🔄
正确连接组件对于理解系统流程至关重要。不同的线条代表不同类型的交互。
依赖
依赖表示一个组件依赖于另一个组件。如果供应商发生变化，客户端可能会失效。
- 样式： 虚线配开放箭头。
- 方向： 从客户端指向供应商。
- 用途： 用于接口使用或简单引用。
关联
关联表示一种结构关系。它暗示两个组件之间存在直接连接。
- 样式： 实线。
- 用途： 当组件是更大整体的一部分或直接共享数据时使用。
实现
当组件实现接口或规范时，就会发生实现。
- 样式： 虚线，带有实心箭头头。
- 方向： 从实现者指向接口。
泛化
泛化表示继承。一个组件是另一个组件的特化版本。
- 样式： 实线，带有空心三角形箭头。
- 方向： 从子类指向父类。
| 关系 | 线型 | 箭头类型 | 用途 |
|---|---|---|---|
| 依赖 | 虚线 | 开口箭头 | 使用或依赖 |
| 关联 | 实线 | 无 | 直接连接 |
| 实现 | 虚线 | 实心三角形 | 实现 |
| 泛化 | 实线 | 空心三角形 | 继承 |
结构规则与规范 📏
一致性使图表更易读。遵循这些规范以保持质量。
命名规范
- 组件名称使用帕斯卡命名法（例如，PaymentService).
- 接口名称使用驼峰命名法（例如，paymentInterface).
- 保持名称具有描述性。除非是行业标准，否则避免使用缩写。
分组与包
- 使用包来分组相关的组件。
- 清晰地标记包（例如，Core, UI, Data).
- 通过将组件嵌套到包中，避免图表过于拥挤。
分层
按层逻辑组织组件。这有助于理解数据的流动。
- 将表示层组件放在顶部。
- 将业务逻辑放在中间。
- 将数据访问放在底部。
应避免的常见错误 ⚠️
即使是经验丰富的建筑师也会犯错。请注意这些常见的陷阱。
- 过度复杂化： 不要画出每一个类。组件图是高层次的。如果你看到类，很可能你正在使用类图。
- 缺少接口： 不要没有接口就直接连接组件。这会使它们耦合得太紧密。
- 命名不一致： 确保所有名称与代码库或文档一致。名称不匹配会造成混淆。
- 循环依赖： 避免出现组件A依赖B，而B又依赖A的循环。这表明设计存在缺陷。
- 忽略端口： 如果一个组件连接到很多东西，使用端口来保持布局整洁。
文档和维护 📝
只有当图表保持最新时，它才有用。将其视为动态文档。
版本控制
- 将图表文件存储在你的版本控制系统中。
- 当架构发生变化时，更新图表。
- 在提交信息中记录变更。
交叉引用
- 将组件图链接到类图以获得详细视图。
- 链接到部署图以获得物理上下文。
- 确保所有图表中的组件名称完全一致。
审查流程
- 让同事审查图表以确保清晰。
- 检查接口是否与实际的API契约一致。
- 确保依赖关系反映实际的构建顺序。
高级考虑 🧠
对于复杂系统，标准符号可能需要调整。
复合组件
有时一个组件包含其他组件。这被称为复合结构。
- 绘制一个更大的组件框。
- 将较小的组件放入其中。
- 表示内部连接，但不与外部连接。
包中的接口
你可以将接口分组到包中，以组织大型系统。
- 为所有服务接口创建一个包。
- 为所有数据接口创建一个包。
- 在你的组件图中引用这些包。
文档编制的最佳实践 📋
遵循这些建议可确保你的图表有效实现其目的。
- 从整体视角开始： 首先定义主要组件。稍后再添加细节。
- 使用空白空间： 不要使元素过于拥挤。使用间距来分组相关项目。
- 限制连接： 如果一个组件的连线过多，考虑将其拆分为子组件。
- 保持一致的方向： 将组件按行或列对齐，以引导视线。
- 图例： 如果你使用非标准符号，请包含图例。
关键要点总结 🎯
- 为组件、接口和端口使用标准符号。
- 定义清晰的接口以减少耦合。
- 使用虚线表示依赖关系，实线表示关联关系。
- 保持图表的高层次性；避免展示单个类。
- 保持命名和结构的一致性。
- 定期更新图表以匹配代码库。
遵循这些指南，你可以创建出清晰传达架构的图表。这有助于更好的协作，并减少开发过程中的错误。
