在UML的9种图中，用例图是比较重要的一种图，它是在系统的分析阶段产生的图，从功能上对系统进行了分析得出的一种模型，对后续的系统开发起到了高屋建瓴的作用，用例图画好了，那么系统也就离成功不远了。

由参与者、用例和他们之间的关系构成的用于描述系统功能的动态视图称为用例图。用例图是需求分析的产物，从软件需求分析道最后实现的第一步，描述系统的功能性需求，显示了系统的用户和用户希望实现的功能，也是开发人员和用户之间对系统需求进行沟通的一个有效手段。下面来分别进行详细的说明：

       参与者代表的是一个集合，是指存在于系统外部并直接与系统进行交互的人、系统、子系统或类的外部实体的抽象，在寻找参与者的时候不要集中在人上面，全面分析与系统有关联的部分。另外，在分析系统的用例的时候还要确定系统的边界，将目标系统与系统外部进行清晰分割，营造良好的系统开发和运行环境。

       用例是参与者可以感受到的系统服务或功能单元，定义了系统是如何被参与者使用的，它也是一个类，描述了系统功能的主要特点。用例的最大优点是站在用户的角度上从外部来描述目标系统的功能，表达了整个系统对外部用户的可见行为。这对于目标系统的功能分析和实践非常重要，所以分析出用例也是这里的重点，从分析系统参与者开始，根据参与者来确定系统的用例；还可以通过一些与参与者无关的问题来发现用例，保证用例的完整性和合理性。在分析用例时也要考虑用例的粒度，用例的粒度过大或过小都会造成系统的复杂性增加，不利于目标系统的实现。应在充分分析后，适当的系统功能组成合适的用例粒度，对目标系统进行有效的划分，有利于系统的进一步分析。

       用例图中的关系分为：参与者与参与者之间的关系，参与者与用例之间的关系，用例与用例之间的关系。这三种关系是用例图中的主要关系，其中参与者与参与者之间主要是泛化关系，或称为继承关系。泛化关系表示的是参与者之间的一般/特殊关系；比如在销售系统中的职员和经理之间的关系，职员进行销售的常规操作，而经理可以进行销售的常规操作和销售的管理工作，这其中，职员所具有的功能是两者共有的部分，所以职员是一般类（超类），经理是特殊类，实现了从职员到经理的泛化关系。

用例和参与者之间的关系属于关联关系，又叫通讯关联。是双向的一对一关系，表明了哪个参与者与哪一个用例通信，在Rational Rose中关联关系的箭头指向用例，

用例与用例之间可以抽象出包含、扩展和泛化关系。包含关系是指用例可以简单的包含其他用例的行为，并且把它所包含的用例行为作为自身行为的一部分。扩展关系是在一定条件下把新的行为加入到已有的用例中，获得的新用例成为扩展用例。两者之间对比可以轻松理解：包含的用例是在基础用例执行后必然执行的；而扩展用例是在基础用例执行后不一定要执行的，是可以选择执行与否的。比如下图：在数据库中的信息被修改后，保存信息这个用例是必然要被执行的；而在登陆这个用例中，找回密码这个用例是扩展的：用户的密码忘不了自然也就不需要找回密码了。两者对比就可以明白了。用例之间也有泛化关系，一个父用例被特化形成多个子用例。比如购物，可以泛化为上街购物和网上购物。 用例之间的关系有利于复用多个用例中的公共行为。 

       在这部分中，用例图的分析是重点掌握的。面对一个陌生的系统，如何才能做到脉络清晰呢？从用例分析起，有目的的去划分系统，这样层层分析下来，理清了系统的思路，陌生的系统也就不是很生疏的了。尤其是在功能的分析上，对于后期的系统实现，这部分的分析也是非常重要的。

UML中的9种图之用例图