Question

统一建模语言（UML）是正规且标准化的交流软件系统设计的标记法，尽管很多人更推崇框线式草图。这样当然没有错，但你为了图表的灵活性而牺牲一致性，结果就是这些非正规的草图大多使用的图表元素都不一致，往往需要伴以叙述。

当你在白板上画草图时，如果要使用“无UML”的图并决定以后用微软Visio之类的东西对其正规化，这里有几件事情要考虑。

标题

首先，真正能帮助人们理解一张图的事是包含一个标题。如果你使用UML，根据图表的语境，图表元素会提供一些信息，但如果你的图表里都是框和线，这就不见得有帮助。让标题尽量短而有意义。如果一张图应该按特定的顺序来阅读，就用编号来确保顺序。

标签

你的图可能有多个标签，包括软件系统的名称、组件等。如果可能，避免使用缩略词，如果为了简洁确实需要使用缩略词，确保把它们记录在项目词汇表中或在图上某处留下图例。项目团队正式成员对常见的项目缩略词可能有共同的理解，而团队外的人或项目的新人则很可能不明白。

用来描述技术选择的缩略词在这里是例外，特别是如果它们在行业内被广泛使用。例子包括JMS（Java消息服务）、POJO（普通Java对象）和WCF（Windows通信基础）。让特定的语境来决定是否需要解释这些缩略词，如果有疑问，安全起见可以使用全称或包含一条图例。

形状

我见过的大多数框线式草图都不仅仅是框和线，这些团队使用各种形状来表达它们软件架构中的元素。比如，你经常会在一张图中看到圆柱，很多人会把它们理解为某种类型的数据库。确保给出解释来确认是否是这种情况。

职责

向架构图增加一个额外的信息层有一个很简单的方法，就是对系统和组件之类的东西，通过短小的声明标注其职责。项目符号列表（7±2项1）或短句很管用。提供这个信息时保持简短（这个信息使用更小的字体也很有帮助），在图上增加职责有助于对软件系统做什么以及如何结构化提供真正有用的“一目了然”的视角。

1http://en.wikipedia.org/wiki/The_Magical_Number_Seven,_Plus_or_Minus_Two

线条

线条是大多数架构草图的重要组成部分，扮演着将所有框（系统、容器、组件等）连接起来的粘合剂。而这正是线条的大问题，它们往往被认为是用来连接图上其他更重要的元素，自己并不会得到太多关注。每当在草图上画线时，确保你的用法一致，并且目的明确，比如下面这些。

线条样式（实线、点线、虚线等）：线条的样式有意义吗？如果有，意义是什么？

箭头：箭头是否指向依赖（比如：像UML的“用途”关系）或者表明数据正常的流向？

通常线条上的标注（比如“用途”、“发送数据”、“下载报告”等）有助于说明箭头所指的方向，但要注意两端都有箭头的线条！

颜色

软件架构图不一定是黑白的。颜色可以用来区分图中的元素或者确保它们是否被强调。如果要使用颜色，我建议你，特别是画草图时，通过包含一个颜色索引参考来确保你用的颜色编码是明显的。颜色能让世界变得不一样。你所需的只是一些不同颜色的白板、记号笔和一点点想象力。

边框

在图表元素周围添加边框（比如双行线、彩色线、虚线等）是强调或把相关元素归类到一起的好方法。如果要这样做，确保边框有明显的意义，要么给边框添加标签，要么在图例中包含一个解释。

布局

使用微软Visio或OmniGraffle等电子绘图工具，让布局图表元素变得更容易，因为你可以随意移动它们。很多人更喜欢站在白板或活动挂图前设计软件，主要是因为它提供了更好的协作环境。你要多想想图表元素的布局，因为如果空间不够，你就得不断地画了擦，擦了画，这会很痛苦。

用便签和索引卡替代画框图的例子

用便利贴和索引卡替代绘制框图可以带来一定的灵活性。如果你使用一种类-职责-协作2式技术来识别候选的类/组件/服务，可以把所得的卡片作为开始创建你的图表的一种方式。

2http://en.wikipedia.org/wiki/Class-Responsibility-Collaboration_card

需要移动一些元素？没问题，移动它们。需要移除一些元素？没问题，把它们从图上拿掉，扔到一边。便利贴和索引卡是开始软件架构草图的好方法，但是我往往看到所得的图都很杂乱。哦，对了，便利贴往往没法好好粘在白板上，因此还是随手备一些蓝丁胶3吧！

3http://en.wikipedia.org/wiki/Blu-Tack

方向

想象你在设计一个由Web层、中间层和数据库构成的三层的Web应用程序。如果要画一个容器图，你会怎么画？用户和Web层在上方，数据库在下方？别的方式？或者从左到右排列元素？

我看到的大多数架构图都把用户和Web层放在上方，但并非总是如此。有时候这些图会上下或前后颠倒，这也许说明了作者（潜在的潜意识）认为数据库是宇宙的中心。尽管没有“正确”的方向，然而从我们常规的思维来考虑，绘制“颠倒”的图要么令人困惑，要么具有非凡的效果。选择在你。

要点

使用UML的一个优势是它为各种类型的图表提供了一个标准化的元素集。理论上，如果有人熟悉这些元素，就应该能理解你的图。在现实中情况并非总是如此，但对框线草图来说肯定不是如此，是画图的人逐渐发明了标记法。再次，这并没有什么错，但要通过在图中或旁边包含一个小图例来确保你给每个人平等的机会去了解你的创作。这里是几类你可能想要包含其解释的事情：

形状；

线条；

颜色；

边框；

缩略语。

有时候没有图例（比如“灰框似乎是已有系统，红框是新东西”）你也能理解图表元素的用途，但我建议安全起见加上一条图例。即使看似明显，也会被不同背景和经验的人误解。

图表的评审清单

软件架构流程就是为软件项目引入结构和愿景，因此评审架构图时，有一些事情可能是你想要坚持以确保情况就是如此的。这个清单适用于在架构流程开始阶段产生的图表，也适用于那些为一个已有软件系统回顾性编写文档而产生的图表。

1.我能从多个抽象层次看到并理解解决方案。

2.我理解大局，包括谁将使用系统（比如，角色、人物等）以及现有的IT环境（比如现有的系统）有什么依赖。

3.我理解逻辑容器和已作出的高层次技术选择（比如，Web服务器、数据库，等等）。

4.我理解哪些是主要组件，以及如何使用它们来满足重要的用户故事、用例、功能，等等。

5.我理解所有这些组件是什么，它们的职责是什么，还能看到所有的组件都有一个归属。

6.我理解图表使用的表示法、约定、颜色编码，等等。

7.我能看到图表之间的可追踪性和一直在使用的图表元素。

8.我理解业务领域是什么，也能从较高层次看到软件系统提供的功能。

9.我理解实现策略（框架、类库、API等），对于系统如何被实现也差不多能可视化。

倾听问题

最后一点，在图表绘制中要注意倾听任何出现的问题或作出的说明。如果你发现自己说这样的话，“说明一下，这些箭头表示数据流”，确保该信息体现在某处的图例中。