💡 关键要点
- 标准化符号： 在所有图表中使用一致的形状和符号，以防止误解。
- 命名规范： 为元素采用严格的命名规则，以确保模型内的清晰性和可搜索性。
- 布局规范： 保持均匀的间距和对齐，以增强视觉流畅性并降低认知负担。
- 关系清晰性： 为线条和箭头定义精确规则，以准确表示系统连接。
在软件架构和系统设计领域，图表充当了通用语言。它们弥合了抽象概念与具体实现之间的鸿沟。然而，缺乏内在一致性的图表只会带来困惑而非清晰。一致性不仅仅是审美偏好；它是专业建模的基本要求。当利益相关者、开发人员和架构师审查模型时，他们依赖于既定的模式来快速提取含义。偏离这些模式会引入摩擦和潜在错误。
本指南概述了在统一建模语言（UML）图表中保持一致性的基本规则。这些原则适用于任何用于创建视觉效果的工具。目标是创建直观、可维护且精确的文档。
1. 符号标准 🎨
任何专业图表的基础在于遵循建模社区定义的标准符号。尽管不同工具之间存在细微差异，但类、接口、参与者和状态的核心符号始终保持一致。偏离这些符号会造成歧义。
类图符号
在构建类图时，必须严格遵守类使用矩形形状的规定。方框应分为三个不同部分：类名、属性和操作。名称应始终位于顶部部分。属性和操作应列在下方，由一条水平线分隔。
- 公共成员： 使用加号（+）前缀。
- 私有成员： 使用减号（-）前缀。
- 受保护成员： 使用井号（#）前缀。
- 包作用域： 使用波浪号（~）前缀。
不要在同一模型中混合使用这些约定。如果一个模型使用+符号表示公共属性，则每个类都必须遵循此规则。不一致的可见性修饰符会使一眼判断访问级别变得困难。
顺序图生命线
在顺序图中，对象和参与者的表示必须保持一致。生命线是从图表顶部延伸下来的垂直虚线。激活条应为窄矩形，放置在执行期间的生命线上。确保所有激活条的宽度相同，以保持视觉节奏。
状态机图
状态应表示为圆角矩形。转换用带空心箭头的实线表示。入口和出口点应使用特定符号明确标记（例如，用实心圆表示初始状态，用双圆表示最终状态）。对同一类型的状态使用不同形状会破坏视觉语言的一致性。
2. 命名规范 🏷️
命名是建模中不一致性的最常见来源。如果没有严格的规则，一位架构师可能会将一个类命名为User，而另一位则使用Person。有人可能会使用saveRecord()，而另一位则更倾向于使用persistData()这些差异迫使读者不断转换术语，从而减慢理解速度。
类与组件命名
类名应遵循 PascalCase 规范。这意味着每个单词的首字母都要大写（例如，CustomerOrder）。缩写应被视为一个整体单词（例如，HTTPConnection而不是HttpConnection）。这确保了类名与通常使用 camelCase 的变量名之间易于区分。
属性与方法命名
属性和方法应使用 camelCase。名称的首字母小写，后续单词首字母大写（例如，calculateTotal()）。这种区分有助于从文本上阅读图表。
| 元素类型 | 规范 | 示例 |
|---|---|---|
| 类 | PascalCase | PaymentGateway |
| 属性 | camelCase | 交易ID |
| 方法 | 驼峰命名法 | processRefund() |
| 接口 | 以 I 开头 | IPaymentProcessor |
命名空间和包结构
在将模型组织到包或命名空间时，层级结构应反映系统的逻辑领域。避免超过三层的深层嵌套。使用小写字母命名包，以区别于类。例如，com/company/project 是标准格式，而com.Company.Project可能会引起混淆，难以判断该文本是表示包还是类。
3. 布局与间距 📏
杂乱的图表就是失败的图表。布局的一致性确保观众能够高效地浏览信息。这包括对齐、间距和分组。
网格对齐
使用不可见的网格来对齐元素。表示类或组件的矩形应水平或垂直对齐。除非特别需要表示特定关系方向，否则不要将元素放置在任意角度。对于相关组件，通常推荐垂直堆叠。
间距规则
保持元素之间的间距一致。如果在一个区域中两个类之间的距离是50像素，那么在其他区域也应保持相似。这能创造出一种“视觉呼吸空间”，防止图表显得拥挤。一致的间距还有助于识别相关功能的集群。
分组与框架
使用框架来分组相关的图表或组件。框架应包含属于特定子系统的全部元素。框架的边框应为实线，标签应放置在左上角。确保框架不与指定范围外的元素重叠。
4. 关系线与箭头 ➡️
元素之间的连接与元素本身同样重要。错误地表示关系可能导致对系统行为的错误假设。
关联与聚合
明确区分关联与聚合。关联是一条简单的线。聚合（“拥有-一个”关系，其中部分可以独立存在）在源端使用空菱形。组合（“拥有-一个”关系，其中部分不能脱离整体而存在）使用实心菱形。不要将空菱形和实心菱形互换使用于不同类型的关系。
依赖线
依赖关系应使用带空心箭头的虚线表示。这表明一个元素依赖于另一个元素。避免使用实线表示依赖，因为这暗示了更强的结构连接。确保箭头指向被依赖的元素。
多重性
多重性值（例如，1，0..1，*）应放置在靠近其所描述类的连线末端。如果显示多个多重性，应确保格式一致。在需要时不要省略多重性，在隐含时也不要随意添加。
5. 颜色与层级 🎨
颜色应谨慎使用以传达意义，而非用于装饰。过度使用颜色会混淆层级关系。如果每个类都使用不同颜色，眼睛将无处聚焦。
标准颜色调色板
采用简约的调色板。例如：
- 黑色或深灰色： 标准元素。
- 蓝色： 接口或抽象类。
- 绿色： 活跃或运行中的进程。
- 红色： 错误状态或严重警告。
不要随意应用颜色。如果一个类是蓝色的，它在整个模型中必须代表接口或抽象概念。如果一个状态是红色的，必须始终表示错误状态。
字体一致性
在整个模型中使用单一的无衬线字体。常见选择包括 Arial、Helvetica 或 Roboto。字体大小应清晰可读且保持一致。类名应使用粗体，而属性和方法应使用常规字重。这种视觉区分有助于快速浏览图示内容。
6. 文档一致性 📝
一张图的价值取决于其配套文档的质量。视觉模型与文字描述之间的不一致是技术债务的主要来源。
版本控制
确保图示中的版本号与系统文档的版本一致。如果代码发生变化，图示必须随之更新。展示已被移除功能的图示具有误导性。建立规则，将图示更新纳入代码审查流程。
上下文注释
使用注释解释无法用标准符号表示的复杂逻辑。这些注释应通过虚线连接到特定元素。确保注释文字简洁明了。图示框内包含长段落会降低可读性。如果注释超过三行，应考虑创建单独的规格文档并加以引用。
7. 审查与维护 🔄
一致性不是一次性的设置，而是一个持续的过程。随着系统的发展，必须定期审查以确保标准得以维持。
自动化检查
在可能的情况下，使用能够验证模型一致性的工具。自动化检查可验证所有类是否遵循命名规范，或所有关系是否具有明确的多重性。这能减少维护质量所需的手动工作量。
同行评审
将图示评审纳入开发工作流程。同行应检查是否遵守既定规则。这有助于团队成员对模型形成共同理解。如果某条规则不明确，应更新样式指南，而非允许例外。
结论 🏁
保持UML图的一致性需要纪律和明确的规则。通过标准化符号、命名、布局、关系和颜色，团队可以创建作为可靠文档的模型。这些图示成为团队共享的资产，能够加速开发并减少错误。在一致性上投入的努力，将带来沟通开销的降低和系统设计质量的提升。
从最初的草图到最终交付，都应严格遵守这些规则。一张专业的图示，正是专业工程流程的证明。