如何审查软件架构图

我每年都会看到数百张软件架构图，主要是通过我的软件架构研讨会。有些图比其他图更好，但我注意到很多人很难评判一张图，因为他们不确定该看什么。这就是这篇博文的目的。让我们从我某个研讨会上一个相当典型的白板图示例开始。

乍一看，这张图还不错。它层次丰富、干净、简洁、色彩鲜艳，你甚至可能猜得出它的意思。但我们需要更仔细地观察一下。

一般方面

我们先来看一下这张图的整体结构。首先，我们需要思考以下几点：

• 该图表有标题吗？
• 您了解图表类型是什么吗？
• 您了解图表范围是什么吗？
• 该图有图例吗？

我估计，在我的研讨会上看到的初始图表中，超过90%都没有标题！这个图表虽然有一个“上下文”标题，但它并没有明确说明它所展示的上下文是什么，以及图表的范围是什么。我假设标有“风险系统”的大框是图表的范围，但更好的标题应该能更清楚地说明这一点。

关于符号。嗯，这看起来像是一堆临时拼凑的“方框和线条”，而不是 UML 或 ArchiMate 符号。虽然这未必是坏事，但图表图例/图例可以帮助读者理解所使用的符号。我建议也为 UML 和 ArchiMate 图表添加图表图例/图例，因为并非每个人都了解这些可视化语言。

元素（框）

让我们继续更详细地了解这些元素。同样，以下是一些需要考虑的事项：

• 每个元素都有名字吗？
• 您是否了解每个元素的类型？（即抽象级别；例如软件系统，容器等）
• 您了解每个元素的作用吗？
• 在适用的情况下，您是否了解与每个元素相关的技术选择？
• 您是否了解所有使用的首字母缩略词和缩写的含义？
• 您了解所有使用的颜色的含义吗？
• 您了解所有使用的形状的含义吗？
• 您了解所有使用图标的含义吗？
• 您是否了解所有使用的边框样式的含义？（例如实线、虚线等）
• 您是否了解所用所有元素尺寸的含义？（例如小盒子与大盒子）

这里每个元素都有一个名称，这很好，但有些名称是首字母缩略词/缩写。我知道“RDS”在这里是什么意思，但你可能不知道，所以这个问题确实应该修复。“IAM”也是一个相当通用的术语，所以也许最好添加更多细节。我们这里使用了一些形状，我不确定矩形和椭圆形之间有什么区别。颜色也是一样。为什么有些元素是蓝色的，而有些是黑色的？

抛开视觉层面不谈，这些元素在抽象层面上究竟代表什么，实际上并不清楚。它们都是同一个东西吗（例如“软件系统”）？还是其中一些（例如“审计日志”）实际上只是“风险系统”的实现细节？

关系（线）

最后，我们来看一下这些关系：

• 每一行是否都有一个标签来描述该关系的意图？
• 在适用的情况下，您是否了解与每种关系相关的技术选择？（例如，进程间通信协议）
• 您是否了解所有使用的首字母缩略词和缩写的含义？
• 您了解所有使用的颜色的含义吗？
• 您了解所有使用的箭头的含义吗？
• 您是否了解所用所有线条样式的含义？（例如实线、虚线等）

只有大约一半的行带有标签，这种情况很常见。我猜想“审计日志”会被发送到“审计日志”框，但如果能知道其中包含哪些内容就更好了。“输入”（从“RDS”到“风险系统”）这个词相当笼统且含糊不清，尤其是在你不知道“RDS”是什么意思的情况下。

虽然大多数箭头都是单向的，但在“风险系统”和“IAM”框之间有一个双向箭头。我不太喜欢双向箭头，因为它们往往更难正确标记。

更好的图表

我以前看过很多关于“图表反模式”的博客文章，它们会展示劣质图表带来的问题，却没有展示“好”的例子。所以，让我们来谈谈这个问题。

这是上面图表的改进版本。我使用了一个工具（图表来源），但你也可以使用白板或纸张。

我对审计日志、数据保留和记录器元素做了一些假设，认为它们只是实现细节，因此在此系统上下文图中省略了它们。每个元素都有名称和描述，此外，我还在元素内部添加了一些文本，以明确说明该元素代表的事物类型（例如“人员”或“软件系统”）。所有线条也都带有标签。最后，还有一个图例，显示了所使用的不同形状和颜色。

概括

学习如何审查软件架构图是一项相对容易掌握的技能，我建议您在下次需要审查时使用我的图表审查清单。

从工具的角度来看，白板上的便签效果很好，但如果你需要在线工具，可以看看Structurizr 图表审阅工具，它可以免费使用。其他选择包括 Miro 和 Mural 等协作工具。

创建良好的软件架构图是一个很大的话题，但如果您有兴趣了解更多，我建议从C4 模型开始。