在UML的世界里共有九种图，分为两类：静态图和动态图，用例图是静态图的一种。我们常听到的一句话：业务为王。可见了解业务是何等重要。映射到我们软件开发过程中，就是需求分析。也就是说，在软件开发过程中，需求分析是最重要的，只有需求做好了，你才可能设计出所谓的好软件。如果需求都没搞明白，那么做出来的软件，不管你的界面是多么的炫，使用的技术是多么的先进，那都是白扯。最终的结果就是，你的软件是个废物。而用例图，就是帮助我们了解业务，确定需求的，它是需求分析阶段使用的最重要的一种图。它的重要性不言而喻，我认为UML九种图中，用例图处于霸主地位。然而，就是如此重要的一个图，却似乎没有得到人们足够的重视。也许有人会认为，用例图随便画画，有那么个意思就完了。殊不知你每天抱怨加班，抱怨客户修改需求的原因，可能就是因为用例图没有画好。所以呢，认真对待用例图吧。

下面，就说一下用例图中那些被部分人忽视和个人认为比较重要的一些东西。

首先，画用例图的过程，就是确定需求的过程。在确定参与者和用例的时候，有一个比较重要的概念——边界，然而本人水平实在有限，难以给大家把这个比较抽象的概念解释清楚，这里只是跟大家提一下，具体的理解还得靠大家自己去悟。下面我说一下用例。

用例分为：业务用例、概念用例、系统用例。通常咱们说的用例指的是系统用例，而由于这三种用例其实差别不是很大，这就导致好多人忽视了业务用例和概念用例的存在，认为咱们常说的系统用例就是我们和客户沟通时用的图。其实不然，真正完成需求分析师与客户沟通的用例是业务用例，业务用例中使用的一些名词什么的，几乎全部来源与客户的业务，只有这样才不至于客户不理解我们的意思。概念用例则是需求分析师把业务用例精化、抽象成系统用例的过程中用到的一种用例。而我们大部分人看到的用例自然而然就是系统用例啦，换言之，系统用例就是给我们编程人员看的，是需求分析师辛辛苦苦得到的最终结果，它貌似与客户已经木有多大关系了（这里指客户不接触系统用例）。之所以好多人会让系统用例去做本属于业务用例的工作，就是因为这两个家伙真的是太像了。而好多人又奉行一个原则：王八排队——大概（盖）齐，所以这种误解也就比较容易理解啦，这里我就不啰嗦啦。

然后呢，说说用例图涉及到的几种关系。

参与者与用例之间的关系：关联关系，这个不必我多说，大家都懂。

用例与用例之间的关系：包含关系、扩展关系、实现关系。

包含关系：包含用例表示的是“必需”而不是“可选”，这意味着如果没有包含用例，基本用例是不完整的，同时如果没有基本用例，包含用例是不可能单独存在的。给大家看看包含关系的实例：

PS：用户要登录，就必须验证用户ID，如果不验证，用户登录用例就不完整。

这里再给大家介绍一下精化关系。先看图：

PS：其实在系统用例中，并没有精化关系或者说是有精化关系，但是精化关系完全等同于包含关系。那么为什么还要有精化这个概念呢？这就涉及到业务用例和概念用例了，需求分析是一个过程，精化关系就是在这个过程中使用的关系。可能在需求分析初期，客户告诉你我需要用户登录、用户下线等等业务，而随着需求分析的深入，进一步细化用户登录，得到了验证用户ID等几个用例。也就是说”用户登录“这个业务用例精化出”验证用户ID“等概念用例。等到所有的需求都明白了，需要定稿形成系统用例的时候，精化关系就被包含关系代替了。

扩展关系：扩展表示的”可选“，而不是”必需“，这意味着即使没有扩展用例，基本用例也是完整的。如果没有基本用例，扩展用例是不可能单独存在的。如果有多个扩展用例，同一时间用例实例也只能使用其中一个。看一个例子：

PS：查询消费信息时，可以导出Excel，可以打印消费信息，当然也可以只看消费信息。但是同一时间，你只能导出excel或者打印消费信息。

实现关系：这种关系比较简单，大家看个例子就懂了。

到此为止，关于用例图我就说完了，欢迎大家拍砖！