在软件开发中，从需求工程到代码工程，都离不开 UML 图的绘制。今天简要总结一下我以往使用 UML 图的一些体会。
很多图，都是由原始需求到代码的一种转换，只是转换的程度不一样。在软件开发过程中，不同的阶段需要不同的 UML 图，在选择使用哪些图时，我们必须理解该图能表达一些什么，即它的主要用途，以及它表达的优势在哪里：
用例图
用于需求描述、范围确定。
所含内容：参与角色集合、功能项集合、角色可用功能集合。
如果需要更详细地说明需求，则应该在每一个用例中添加相应的用例规约说明。
鲁棒图
则是系统的初步设计。此图虽然是行为视图，但是比较偏静态。
所含内容：角色、界面对象、控制器、事件、实体（数据存储）。
我认为此图的关注点在于表达控制器，它能让我们更好地理解控制器所涉及到的实体以及设计控制器之前的调用关系。
控制器在 OEA 中可以理解为 Service，而在 DDD 中则可以理解为 DomainService。这些控件器承载了系统中最多的流程性业务逻辑，非常重要。但是在此图中，只能看到 Service 及其涉及到的 Entity，却不能非常详细地表达它们之间的交互规则。
类图
在需求分析阶段，在 DDD 方法论中用于描述领域模型。
在设计阶段，则是代码静态结构的设计图。
在反向工程阶段，用于精确描述当前软件的静态结构。
序列图（或协作图）
这两个表等价，一般使用序列图。强调对象间的交互关系，时间顺序关系。
我一般把它用于反向工程，表达、理解当前的代码。非常易用。
有时也用在需求分析阶段，主要是为了表达时序。
活动图（或流程图）
具体描述一个控制流，体现控制流的细节。
状态图
关注某一事物状态的变化。
以下换一个角度，当在做一个全新的系统时，各阶段绘制不同的图：
需求分析阶段：
用用例图描述整个系统的功能范围。
鲁棒图初步描述某个需求/业务流涉及到的多种对象：界面、控制器、实体。（主要是实体）
如果某一个需求的流程比较复杂，则使用活动图描述。
设计阶段：
使用类图说明类之间的静态结构关系。
使用序列图说明类之间的动态调用时序。
使用活动图描述某种算法。
反向工程：
一般则使用类图、序列图来帮助理解现有系统。
一篇说 UML 图的文章，里面居然没有一个 UML 图，罪过。（主要是这些图网上一搜一大把，而且贴进来太长了，总是影响整体把握这些图的意义。）