原文地址： http://blog.csdn.net/zhuojiajin/article/details/8657853
看过了UML视频，觉的UML里的内容其实看的挺明白的。在开始画图的时候才发现，纯粹是老师讲到好。听的明白或者说觉的自己明白了只是一种错觉。对于UML里的图还是理解上不够透彻，当然现在要求自己就透彻也是痴人说梦。虽然是一种错觉吧，好赖也让我看视频的时候感觉的痛快。再者这种错觉肯定还是以一定的“明白”为根据的。所以这种错觉我喜欢！这篇博客开始对UML中的9种图做个总结，这一篇先讲用例图。
那么用例图是UML用来描述一个软件系统中人和功能之间，即角色和用例之间的关系的一种图形化的表达。可以清晰的反应出角色的权限，角色的对应的功能之间的关系。它是从软件系统的外部用户的角度来描述系统、子系统或者类的行为的。用例模型是有开发者和用户共同达成的某种共识。用例模型用若干个用例图描述。用例图必须包含：功能的描述、角色、并且角色和功能对应关系。
角色（actor）：
软件系统中的角色，是与系统、子系统、或类交互的外部人员、进程或事物的理想化。一个活动这可以对应一个或多个用例。只要是和软件系统有互动的外部对象都可是角色，例如：人员、其他系统、外部服务器、数据库等。UML中用小人图形表示。在画图时，角色相对来说还是比较好找的。
--可以激活系统交互信息；
--可以对系统进行输入；
--可以从系统被动的接受信息。
角色：角色既可以是人也可以是物
寻找执行者的几个原则：
-谁使用系统的功能；
-谁需要系统支持日常工作；
-谁来维护关系系统；
-系统需要操纵那些硬件-需要与系统交互的其他系统；
-对系统产生的结果感兴趣的人或事物。
用例（usecase）：
用例是软件系统中一个个的功能单元，用例的目的是定义清晰的行为块而不是解释系统的结构。一个用例包括了它所具备的所有行为：主线（理想功能）、行为的不同变形、行为的异常条件、以及所需的响应。其实就是一个完整的功能，可以是一个大的功能模块，也可以是系统菜单上的每一个功能。
关系（assosciation）：
用于描述角色和功能之间的关系，有四种：关联、泛化、包含、扩展。
用例图中的主要属性：事件流、前置条件、后置条件、粒度、范围
事件流：简单的说就是一个用例要做什么的问题，描述的是用例在执行时执行者和系统之间交互的过程。包括基本流（用例中常规和预期的路径的描述：如登录）和备选流（用例出现特殊情况时执行的其他路径如错误处理）
--基本流--对用例中常规和预期路径的描述
--备选流--由于受到其他因素影响，用例执行了其他的路径。
前置、后置条件：即用例执行时需要满足的条件和结束时的处理结果。应该是类似于DO while循环的两种情况。
前置条件：该用例执行的前提条件，用来描述条件下可以开始执行一个事件流。
后置条件：说明用力结束时系统的状态。
粒度和范围：是评价一个用例图的优劣的属性。描述了用例图的宽度和离散程度吧。
UML用例图的粒度与范围：用例的多少、概述级、用户目标级、子功能级。设计时要重要考虑的方面，一开始粗略的设计用例图，然后慢慢细化。用例图的粒度不应太粗或太细。
用例注意点：
◆应该清晰的定义系统边界
◆防止用例过多
◆应该从执行者的角度来命名用例
◆用例描述的正规程度
◆避免执行者的名字不一致
◆避免执行者和用例之间的关系
◆注意用例的大小是否恰当（粒度）
◆避免用例描述混乱
◆区分用力分解和功能分解
◆避免客户不能理解用例的情况
◆有些场合，用用例来描述不适合
下面来一个例子吧：自动售货机销售货物功能，这里个过程中涉及的人员有：顾客 用例有：按钮，指示灯，投币槽，退币槽。用例图如下：
