第三章 用例图
（1）参与者
是指系统以外的需要使用系统或与系统交互的外部实体，吧阔人、设备、外部系统等。
（2）参与者之间的关系
泛化关系的含义是参与者的共同行为提取出来表示成通用行为，并描述成超类。参与者之间的泛化关系表示一个一般性的参与者与另一个更为特殊的参与者之间的联系。
在UML规范中繁华关系用带空心的三角形箭头实现，箭头指向父类参与者
（3）参与者和用例之间的关系
参与者和用例之间存在着一定的关系，这种关系属于关联关系，又称为通信关联。这种关系表明了那个参与者与用例通信。
在UML规范中，用例图中的参与则和用例之间的关联关系用带箭头的实线表示如果不想强调对话中的主动者和被动者，或者参与者和用例互为主动者与被动者，则可以使用不带箭头的实线来表示他们之间的关联关系。箭头所指的对话就是被动接受者。
（4）用例的概念
用例是对一个活动者使用系统的一项功能时所进行的交互过程的一种文字描述序列;
用例是代表系统中各个项目相关人员之间就系统的行为所达成的契约；软件的开发过程分为需求分析、设计、实现、测试等阶段；
用例是系统、子系统、或类和外部的参与者交互的动作序列的说明，包括可选动作序列和会出现异常的动作序列；
在UML规范中，用例是使用椭圆形的图标来表示。
（5）用例的特征
1.用例从使用系统的角度描述系统中的信息，即站在系统外部查看系统的功能，而不考虑系统内部对该功能的具体实现方式。
2.用例描述了用户提出的一些可见的功能需求对应一个具体的用户目标。
3.用力总是被参与者启动，并向参与者提供可识别的信息。
4.用例可大可小，但他必须是一个完整的描述；
5.用例在以后的开发过程中，冰箱参与者提供可识别的信息；
6.用例是对系统行为的动态描述，属于UML的动态建模部分;
7.在用例视图中，用例设置代表了软件系统上网功能部分；
8.用例的实例是系统的一种实际使用方法，即系统的一次具体执行过程；
（6）用例之间的关系
泛化关系
代表一般与特殊的关系；在用例之间的泛化关系中，子用例继承父用例的行为和含义，子用例也可以增加新的行为和含义覆盖父用例中的行为和含义。当发现这个系统中有两个或两个用例在行为结构目的的方面存在共性时，就可以使用泛化关系。
包含关系
指的是两个用例之间的关系，其中一个用例（称为基本用例）的行为包含另一个用例（称为包含用例）的行为，包含关系是依赖关系的版型，也就是说包含关系是比较特殊的依赖关系，他们比一般的依赖关系多了一些语义。
当发现系统中在两个或多个用例中有某些相同的动作，则可以把这些相同的动作提取出来，单独构成一个用例（称为包含用例），基本用例在其内部的某一位置上显示的使用包含用例的行为的结果，包含用例作为包含他的基本用力的功能的一部分而不依赖包含用例的内部结构。
在UML规范中，包含关系用带箭头的虚线表示，箭头指向包含用例，同时，必须使用《include》标记附加在虚线旁边。
拓展关系
即一个用例的行为包含了另一个用例的行为，基本用例必须声明若干“扩展点” ，而扩展用例只能在这些扩展电商增加新的行为和含义
（7）用例之间的泛化、包含、扩展关系的比较
泛化关系和扩展关系表示的是 is a 关系，包含关系是用例之间的 has a 关系
依赖关系表示的是两个元素或元素集之间的一种关系，被依赖的元素称为目标元素，依赖的元素是源元素
用例的实现
用例与实现无关的，在uml 中用例之间不存在实现关系，但是可以用协作来说明用例的实现
用实线椭圆表示用例，虚线椭圆表示协作实现关系用的是带空心三角形箭头的虚线表示，箭头指向用例。
用例描述
用例之间的关系（泛化、包含、拓展），参与者之间的关系（泛化）、参与者和用例之间的关系（关联）
（8）用例建模
用例建模主要应用在需求分析阶段，在用例模型中，人们把系统看成是实现各种用例的黑盒子，只关心系统的功能有哪些。
用例建模的步骤
它是直接面向用户，主要是以需求陈述为基本依据，确定有关的系统边界。
1.找出系统的外部参与者和外部系统，确定系统的边界和范围
2.找出每一个参与者所期望上网系统行为，即参与者对系统的基本业务需求
3.把这些系统行为作为基本用例
4.区分用例的优先次序
5.细化每个用例的用例描述，使用泛化、包含拓展等关系处理系统行为的公共或变更部分
6.编写每个用例的用例描述
7.编写项目词汇词
系统的边界
是指系统与系统之间的界限。系统可以认为是有一系列的相互作用的元素形成的具有特定功能的有机整体。不属于这个有机整体的就是外部系统系统边界定义有谁或什么来使用系统，系统能够为参与者带来什么特定的系统边界就是要定义好系统的组成部分和什么是系统的外部边界。
确定参与者
1.参与者对于系统而言总是外部的
2.参与者直接同系统交互
3.参与者表示人或事物同系统发生的交互时所扮演的角色，而不是特定的人或事物。一个人或事物在与系统发生关系时，同时或不同时扮演多种角色。
4.一个人或事物在系统发生关系时，同时或不同时扮演多种角色
5.一个参与者可以包含多个不同的具体用户
确定用例
从参与者列表开始，然后考虑每个参与者如何使用系统，需要系统提供怎么样的服务。
参与者要向系统请求什么功能
每个参与者特定的任务是什么的某些信息吗
是否任何一个参与者都要向系统通知有关突发性的、外部的改变，或者必须通知参与者关于系统中发生的事件
参与者需要读取、创建、撤销、修改或存储系统
用例建模中常见的问题
用例的设计原则
1.需求和用例的关系
2.需求应有层次的组织起来
3.不要从用例直接推论出设计
用例模型的复杂度
用例包，包是最常用的刮玻璃模型复杂度的机制，也是uml语义中最简单的一种模型元素，他就是一种容器，在包中可以容纳其他任意的模型元素。