UML-用例图(1)
组成
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相反是小扩大【小的用例扩展了大的用例，小的流程则是可有可无的，比如查询酒店数据的时候不一定要看酒店介绍影片】
总结到这里清晰多了，，要考试了。。