Question

当负责一个新软件系统的设计工作时，一些人首先会提出的问题之一就跟他们应该使用的工具有关。这样的讨论通常会重点围绕着统一建模语言（UML），以及他们的组织是否有任何比较知名的UML工具的许可证。

有很多类型的UML工具

不幸的是，这个问题并不容易回答，因为有很多商业和开源的工具可以帮助你进行软件架构和设计，这些工具往往会从不同的角度来处理这个问题。它们可以从较高层次归纳如下。

1.只有图：有很多独立的UML工具和针对主流IDE1的插件，可以让你画简单的UML图。它们对控制你的图和图描述的内容真的很有用，但这样的图也很容易随着时间推移而落后于现实。如果你有使用权，那么安装了UML模板的微软Visio或OmniGraffle都是很好的起点。

1集成开发环境，Integrated Development Environment。——译者注

2.逆向工程：有独立的UML工具和IDE插件可以从代码创建UML图。这非常好，因为你可以快速同步代码和图表，但这些图表往往也会很快变得杂乱，因为它们通常默认包含了所有细节（比如，每一个属性、方法和关系）。

3.往返工程：许多逆向工程工具还允许你做往返工程，对模型所做的改变会反映在代码中，反之亦然。这有助于保持代码和图同步。

4.模型驱动：有几个模型驱动架构（MDA）的工具，可以让你从模型自身驱动软件系统的实现，通常是通过在图上用可执行UML（xUML）或对象约束语言（OCL）之类的语言标注出所需特性和行为。这些工具可以提供一个完整的端到端的解决方案，但为了从中受益，你需要遵循一个不一样并且往往是刚性的开发过程。

既有效又简单

即使对可用工具分类的简短总结，也会带来数量巨大的选择。Rational软件架构师？Visio？PowerPoint？OmniGraffle？WebSequenceDiagrams.com？你选择哪一个?!

然而关键在于，架构和设计软件并不需要UML工具。在过去几年的大会演讲中，我做了一些非正式的调查，只有10%~20%的听众说他们在日常工作中经常使用UML。一张白纸、挂图或白板，以及一套便利贴或索引卡，你需要的通常就是这些，特别是当你有一组人想要以协作的方式承担设计过程。你有没有试过三四个人挤在笔记本电脑屏幕前协作？

敏捷方法将这种技术含量不高的方法用于捕捉用户故事、故事墙和看板已经有一阵子了。在许多情况下，这是能够奏效的最简单的方法，但什么都抵不过办公室中间人人都能看到的、贴满了东西的白板。跟微软项目计划不同，没人能忍住不走过去瞧瞧那些仍在“待办”一栏的便利贴。

从软件设计的角度来看，使用技术含量不高的方法，可以把你从对使用工具的复杂性的担忧和对正式标记法的屈从中解放出来，从而能集中精力在软件设计的创造性工作上。就以勾画出大局为起点，加工必要的底层细节。记住，如果你不使用工具，就需要明确地思考各个抽象层次之间的可追溯性、规约和一致性。比如，UML的箭头是有意义的，缺了线索，你随手画的箭头到底是指向依赖还是指示数据的流向，可能就不明显。如果过后需要的话，你总是可以用UML工具以更加正式的方式记录你的设计。

UML的用途

在我看来，使用非正式的框线图而不是UML来可视化软件架构的主要原因是，对于我想传达的东西，UML往往不是一个合适的选择。我的语境图、容器图和组件图呈现的信息可以通过用例、组件和部署图的混合使用获得，但我个人不觉得得到的图很容易用标记法解释。UML对我的可视化软件架构的C4方法可能就没用，但我仍然将其用在我工作的软件项目上。

UML周边的工具使它可以被用在许多方面，包括带有关联仓库的全面综合模型，到从现有代码反向工程得到的图表。UML也可以用作简单的图表标记法，要么在白板上画草图，要么在微软Visio或OmniGraffle之类具有可安装的UML模板的工具中。这里是我对UML用途的总结。

流程和工作流：如果要构建一个流程自动化或是基于工作流的软件，我往往绘画一张简单的UML活动图来表示。很多人似乎忽略了UML活动图，但是我发现简单的流程图式的标记法适用范围非常广。

运行时行为：我的C4方法真的只关注可视化软件系统的静态结构，但从运行时的角度来呈现系统往往是有用的。UML序列和协作图通常用于展示多个类在运行时协作实现一个特定的用户故事、用例、特性等。即使你的设计没有做到类这个级别，这些图表仍然非常有用。你可以展示协作容器或组件，而不是展示一系列协作类。

域模型：如果想可视化一个域模型，我会使用UML类图，得到的图通常只展示最重要的属性和关系。通常在这种图上我会隐藏所有类的方法分隔。

模式和原则：我经常需要解释如何在代码库中实现模式或原则（比如一本软件指南的代码部分），UML类图显然是做这件事的方法。我的建议是让图保持简单，不要因感到有压力而展示每一个微小细节。

状态图表：UML状态图是可视化状态机的好方法，标记法也相当直接。我发现人们总是忘记UML状态图的存在。

部署：要展示你的容器或组件是如何部署的，UML部署图是一个很有用的方法。通常这种图呈现为非正式的框线图比较好，但决定权在你。

没有银弹

忘了昂贵的工具吧。很多时候，你需要的只是一张白纸、挂图或白板，特别是当你有一组人想要以协作的方式承担设计过程。然而不幸的是，当谈到设计工具时，并没有银弹，因为每个人、每个组织的工作方式都不同。一旦你确信自己明白了如何进行软件的架构和设计，才是时候开始研究软件工具来帮助改进设计流程。

是否使用UML并不是一个黑白分明的选择。几张到位的UML图真的可以帮助你呈现一个软件系统中复杂和详细的元素。如果你不熟悉UML，也许现在就是让你意识到有很多可用图表的好机会。你不需要UML工具来做架构和设计，但它们确有自己的用途。你不需要把每种类型的图表全都用上！