用例图
用例图是用来描述系统功能的技术，表示一个系统中用例与参与者及其关系的图，主要用于需求分析阶段。
用例图的基本组成元素：参与者、用例、元素之间的关系。
用例图使用范围：需求分析
1.捕获需求。描述功能需求、行为需求（系统要完成什么任务）
2.分析需求。明确类和对象，建立之间的关系
用例图的基本概念
1、用例图是表示一个系统中用例与参与者关系之间的图。它描述了系统中相关的用户和系统对不同用户提供的功能和服务。
2、用例图相当于从用户的视角来描述和建模整个系统，分析系统的功能与行为。
3、用例图中的主要元素包括参与者、用例以及元素之间的关系。此外，用例图还可以包括注解和约束，也可以使用包将图中的元素组合成模块。
如：
参与者的概念
1、参与者是与系统主体交互的外部实体的类元，描述了一个或一组与系统产生交互的外部用户或外部事物。
2、参与者位于系统边界之外，而不是系统的一部分。
3、参与者是从现实世界中抽象出来的一种形式，却不一定确切对应的现实中的某个特定对象。
符号：
如何确定参与者？
通过对参与者进行关注和分析，我们可以把重点放在如何与系统交互这一问题上，便于进一步确定系统的边界。另外，参与者也决定了系统需求的完整性。
确定参与者可以从以下几个角度来考虑：
1）为系统提供输入的人或事物
2）接收系统输出的人或事物
3）需要接入的第三方系统或设备
4）时间是否会触发某些事件
5）负责支持或维护系统中信息的人
系统中的参与者一般可以分为四类：
主要业务参与者：主要从用例的执行中获得好处的关联人员。
主要系统参与者：直接同系统交互以发起或触发业务或系统事件的关联人员。
外部服务参与者：响应来自用例的请求的关联人员。
外部接收参与者：从用例中接收某些价值或输出的非主要的关联人员。
参与者的泛化关系
当系统中的几个参与者既扮演自身的角色，同时也有更一般化的角色时，可以通过建立泛化关系来进行描述。
与类相似，父参与者可以是抽象的，即不能创建一个父参与者的直接实例，这就要求属于抽象父参与者的外部对象一定能够属于其子参与者之一。
用例的概念
用例是类元提供的一个内聚的的功能单元，表明系统与一个或多个参与者之间信息交换的顺序，也表明了系统执行的动作。
简单来说，用例就是某一个参与者在系统中做某件事从开始到结束的一系列活动的集合，以及结束时应该返回的可观测、有意义的结果，其中也包含可能的各种分支情况。
用例与用例图被广泛使用于系统的需求建模阶段，并在系统的整个生命周期中被不断细化。
符号：
用例与参与者的关系
一个用例可以隶属一个或多个参与者，一个参与者也可以参与一个或多个用例。用例与参与者之间存在关联关系。
主参与者与次参与者：通常来说主参与者是用例的重要服务对象，而次参与者处于一种协作地位。
用例的特征
用例的特征保证用例能够正确地捕捉功能性需求，同时也是判断用例是否准确的依据。
1）用例是动宾短语
2）用例是相对独立的
3）用例是由参与者启动的
4）用例要有可观测的执行结果
用例之间的关系
1．泛化关系
2.依赖关系（包含、扩展）
泛化关系：与参与者的泛化关系相似，用例的泛化关系将特化的用例与一般化的用例联系起来。子用例继承了父用例的属性、操作和行为序列，并且可以增加属于自己的附加属性和操作。父用例同样可以定义为抽象用例。
用例之间的泛化关系表示为一根实线三角箭头，箭头指向父用例一方。
依赖关系——包含
包含指的是一个用例（基用例）可以包含其他用例（包含用例）具有的行为，其中包含用例中定义的行为将被插入基用例定义的行为中。
包含的两个基本约束：
1）基用例可以看到包含用例，并需要依赖于包含用例的执行结果，但是它对包含用例的内部结构没有了解；
2）基用例一定会要求包含用例执行。
包含表示为一个虚线箭头附加上《include》的构造型，箭头从急用例指向包含用例。
依赖关系——扩展
扩展指的是一个用例（扩展用例）对另一个用例（基用例）行为的增强。
扩展使用一个附加了《enxtend》构造型的虚线箭头表示，箭头指向基用例。
注意：扩展与包含的箭头方向是相反的，这表明扩展取决于扩展用例而非基用例，扩展用例决定扩展的执行时机，基用例对此一无所知。
扩展用例的使用包括四个部分：
基用例：需要被扩展的用例，“注册”用例。
扩展用例：提供所添加的行为序列的用例，如图5-10中的“检查实名信息”用例。
扩展关系：使用虚线箭头表示，箭头指向基用例。
扩展点：基用例中的一个或多个位置，表示在该位置会根据某条件来决定是否要中断基用例的执行从而执行扩展用例中的片段。
包含、扩展的区别：
根本区别，包含是无条件执行，扩展是有条件执行。图的起点不同，终点也不同。
|
特性 |
include |
extend |
|
作用 |
增强基用例的行为 |
增强基用例的行为 |
|
执行过程 |
包含用例一定会执行 |
扩展用例可能被执行 |
|
对基用例的要求 |
在没有包含用例的情况下，基用例可以是也可以不是良构的 |
在没有扩展用例的情况下，基用例一定是良构的 |
|
表示法 |
箭头指向包含用例 |
箭头指向基用例 |
|
基用例对增强行为的可见性 |
基用例可以看到包含用例，并决定包含用例的执行 |
基用例对扩展用例一无所知 |
|
基用例每执行一次，增强行为的执行次数 |
只执行一次 |
取决于条件（0到多次） |
|
用例名称 |
提交订单 |
|
用例编号 |
UC002 |
|
参与者 |
会员 |
|
用例描述 |
该用例描述一个系统会员提交一份订单的行为 |
|
触发器 |
当订单被提交时，用例触发。 |
|
前置条件 |
提交订单的一方需要完成登录操作 |
|
后置条件 |
|
|
基本事件流 |
1 参与者将订单信息提交至系统。 2 系统验证用户信息及订单信息合法后作出响应。 3 对于订单中的每种产品，系统根据订单中的数量检查产品库存数量。 4 系统统计订单中产品的总价格。 5 系统从会员的系统账户余额中扣除相应金额。 6 系统生成并保存订单信息并将订单发送至分销中心。 |
|
扩展事件流 |
A-3 如果订单中产品数量超过产品库存量，则提示会员库存不足，暂无法购买，取消订单同时终止用例。 A-5 如果会员账户余额不足，系统给出相应提示，取消订单并终止用例。 |
|
结论 |
|
|
数据需求 |
|
|
业务规则 |
B-1 只有当订单中商品信息确认无误后才能要求会员进行支付。 |
