在UML的整个学习过程中，9种图（用例图、活动图、状态图、顺序图、类图、对象图、协作图、组件图、部署图）的学习以及常用开发、建模工具的使用是最为重要的一个阶段，它是进行UML建模的基础。在本篇文章中首先介绍下用例图（Use Case Diagram）。
用例图概念
1、概念及作用：用例图描述的是开发人员与用户交流后完成的图，用来表达待系统的功能性需求和行为，它由参与者（Actor）、用例（Use Case）、子系统（Subsystem）以及构成它们之间的关系组成，主要用于对系统、子系统或类的功能行为进行可视化建模。用例模型是由多个用例图构成的。
2、使用用例图需要考虑：a.强调多少功能
b.各个功能的执行者是谁
c.系统为执行者完成哪些功能
用例图基本元素
-
角色
1、概念：是一种人员的角色，用来指明用例与角色的关系。角色可以是人，也可以是事，也可以是物。
2、寻找执行者的原则：a.谁使用系统的这些功能
b.谁需要系统支持日常的工作
c.谁来维护系统
d.系统操作需要哪些硬件
e.这个系统需要跟哪些系统进行交互
f.还有哪些人或事物对结果感兴趣
-
用例
功能的描述
-
关系
概念：执行者与用例之间的关系，包括关联（Association）、依赖（Dependency）、泛化（Inheritance）3种。用例与用例之间具有包含（Include）和扩展（Extend）关系。
注释（Note）
可以添加到任何地方，对用例图的不同部分加以说明
用例图的主要属性
- 事件流 ：描述一个用例在执行时执行者与系统之间的交互过程。
包 括：1、基本流：对用力中常规和预期路径的描述
2、备选流：由于受到其他因素影响，用例执行了其他的路径
- 前置条件 ：是该用例执行的前提条件，用来描述在什么条件下可以开始执行一个事件流
- 后置条件 ：说明用例结束时系统的状态
说明：前置条件和后置条件可以用于用例的验证
用例图的粒度与范围
用例的粒度必须适中，不能过多也不能太少，分为 以下三个级别：
-
概述级
-
用户目标级
-
子功能级
在设计用例图的时候必须仔细画出，并且把关系描述清楚，与后面的开发、维护等关系重大。
用例注意点
- 应该清晰的定义系统边界
- 防止用力过多
- 应该从执行者的角度来命名用例
- 用例描述正规程度
- 避免执行者的名字不一致
- 避免执行者与用例之间的关系太复杂
- 注意用例的大小是否恰当
- 避免用例描述混乱
- 区别用例分解和功能分解
- 避免客户不能理解用例的情况发生
- 有些场合，用用例来描述需求是不合适的
转载：
扩展和泛化的区别
表示类似于OO术语“继承”或“多态”。UML中的UseCase泛化过程是将不同Use Case之间的可合并部分抽象成独立的父Use Case，并将不可合并部分单独成各自的子UseCase；包含以及扩展过程与泛化过程类似，但三者对用例关系的优化侧重点是不同的。如下：
●泛化侧重表示子用例间的互斥性；
●包含侧重表示被包含用例对Actor提供服务的间接性；
●扩展侧重表示扩展用例的触发不定性；详述如下：
既然用例是系统提供服务的UML表述，那么服务这个过程在所有用例场景中是必然发生的，但发生按照发生条件可分为如下两种情况：
⒈无条件发生：肯定发生的；
⒉有条件发生：未必发生，发生与否取决于系统状态；
因此，针对用例的三种关系结合系统状态考虑，泛化与包含用例属于无条件发生的用例，而扩展属于有条件发生的用例。进一步，用例的存在是为Actor提供服务，但用例提供服务的方式可分为间接和直接两种，依据于此，泛化中的子用例提供的是直接服务，而包含中的被包含用例提供的是间接服务。同样，扩展用例提供的也是直接服务，但扩展用例的发生是有条件的。
另外一点需要提及的是：泛化中的子用例和扩展中的扩展用例均可以作为基本用例事件的备选择流而存在。
用例描述表
鉴于用例图有时并不能清楚地表达功能需求，开发中大家通常用描述来补充某些不易表达的用例，下图的表给大家提供一个参考：
