组成
1.用例（use case） 2.活动者（角色，actor） 3.关系（relationship） 还可以有包、注解等
Use Case
系统、子系统或类与外部参与者（actor）交互的动作序列的说明，包括各种序列及出错序列。
简单理解为用例就是系统的功能。【我能干啥】
用例分析可以认为是对系统功能的分解。
怎样确定用例的粒度？（用例规模的大小）
用例的粒度可大可小，一般一个系统控制在20个左右，但没有严格规定
用例是系统级的、抽象的描述，不是细化的（考虑的是“做什么what”，而不是“怎样做how”）
对复杂的系统可以划分为若干子系统处理
怎样识别用例
活动者希望系统执行什么任务？
活动者在系统中访问哪些信息？（创建、存储、修改、删除等）
需要将外界的哪些信息提供给系统？
需要将系统的哪个事件告诉活动者？
一、执行者(Actor)
执行者是指用户在系统中所扮演的角色。执行者在用例图中是用类似人的图形来表示, 但执行者可以是人，也可以是一个外界系统
如何维护系统？
二、用例(use case)
从本质上讲,一个用例是用户与计算机之间的一次典型交互作用。在UML中,用例被定义成系统执行的一系列动作（功能）。
用例有以下特点:
用例捕获某些用户可见的需求,实现一个具体的用户目标。
用例由执行者激活,并将结果值反馈给执行者。
用例必须具有功能上的完整描述。
用例图描述了系统的功能需求，它是从执行者的角度来理解系统，由“执行者”、“用例”和“用例之间的关系”3类模型元素构成。
《Use》表示一个用例使用另一个用例。(《include》)
《Extend》通过向被扩展的用例添加动作来扩展用例。
关联（accociation）
包含（include）
扩展（extend）
泛化（generalization）
关联（accociation）
每个用例都有活动者启动（每个用例必须和一个活动者关联，有一个活动者来参与），除包含和扩展用例
无论用例和活动者是否存在双向数据交流（无论是参与者提供信息给系统，还是从系统获取信息），关联总是由活动者指向用例，只用单向箭头。
包含（include） （是一种依赖关系，加了版型<<include>>）
两个以上用例有共同功能，可分解到单独用例，形成包含依赖；【共同的一块抽离出来吧】
箭头方向由基本用例指向被包含用例；
执行基本用例时，每次都必须调用被包含的用例（吃饭前洗手）；
被包含用例也可以单独执行；
扩展（extend） （是一种依赖关系，加了版型<<extend>>）
一个用例（在某些扩展点extension point上）扩展另一个用例的功能，构成新用例；箭头方向由扩展用例指向被扩展用例（即基本用例）；
【比如一开始一个系统只有查询功能后来再次基础上增加了语言查询】
扩展用例依赖于被扩展用例（基本用例），只是部分片段组成，不是完整的独立用例，无法单独执行；
扩展用例不一定每次都被执行和调用。（吃饭前也可以不洗手），而被包含用例每次必修执行。
肯定没有活动者指向扩展用例，因为扩展用例依赖基本用例。
泛化太过简单，就不去介绍了
总结：区分一下extend 和 include ,其实很容易理解，include是大包小【大的用例流程包含小的比如订房包含短信提醒--必不可少的】
etends相反是小扩大【小的用例扩展了大的用例，小的流程则是可有可无的，比如查询酒店数据的时候不一定要看酒店介绍影片】
总结到这里清晰多了，，要考试了。。
UML-用例图(1),布布扣,bubuko.com
UML-用例图(1)
原文：http://blog.csdn.net/mariofei/article/details/23123537
