用例图简介
用例图
- 用例图应用在软件开发的需求分析阶段，他描述了系统的功能以及如何使用一个系统
- 用例图显示谁将是相关的用户、用户希望系统提供什么服务以及用户需要为系统提供的服务
- 用例图最常用来描述系统以及子系统
- 用例图分为业务用例图和系统用例图
用例图的组成
用例图主要包含以下 6 个元素
- 参与者（Actor）
- 用例（Use Case）
- 关联关系（Association）
- 包含关系（Include）
- 扩展关系（Extend）
- 泛化关系（Generalization）
1.参与者
参与者的概念:
- 外部的一个实体
- 参与用例的执行过程
- 参与者由参与用例时所担当的角色来表示
- 每个参与者可以参与一个或多个用例
参与者的种类
- 系统用户
真实的人，即用户，是最常用的参与者，几乎存在于每一个系统中,命名这类参与者时，应当按照角色命名 - 与所建造的系统交互的其他系统
外部程序 - 时间代理人
例如在汽车租凭系统中，到了还车时间客户还没有归还汽车，系统会提醒客户服务代表致电客户，这时时间就成了该系统的一个参与者 - 其他如：硬件设备、外部服务和外部数据库等
如何寻找系统的参与者？
- 谁将使用该系统的主要功能
- 谁将需要该系统的支持以完成其工作
- 谁将需要维护、管理该系统
- 系统需要处理哪些硬件设备
- 与该系统交互的是什么系统
- 谁或什么系统对本系统产生的结果感兴趣
启动者和支持者
启动者是用例的主要服务对象
另一类是扮演支持者角色的参与者
参与者间的关系
参与者之间可以具有泛化关系
在用例图中，使用泛化关系来描述多个参与者之间的公共行为
2.用例
什么是用例
外部可见的系统功能单元，在不揭示系统内部构造的前提下定义连贯的行为，不是需求或功能的规格说明
用例的表示
- 简单名（Simple Name）
- 路径名（Path Name）
如何识别用例
- 特定参与者希望系统提供什么功能
- 系统是否存储和检索信息
- 当系统改变状态时，是否通知参与者
- 是否存在影响系统的外部事件
- 哪个参与者通知系统这些事件
用例与事件流
用例分析处于系统的需求分析阶段，这个阶段应该尽量避免考虑系统的细节问题，但是要实际建立系统，则需要更加具体的细节，这些细节写在用例对应的事件流文件中
事件流的描述是独立于实现方法的，事件流描述系统“做什么”，而不是“怎么做”
事件流文件的组成
- 简要说明
与用例相关的说明，描述该用例的作用
应包括执行用例的参与者和通过这个用例要达到的结果 - 前提条件
用例执行前必须满足的条件，如另一用例必须要先执行 - 后置条件
用例执行完后必须要做的事情，如必须执行另一个用例 - 事件流程（主事件流、其他事件流、错误流 ）
从用户角度描述执行用例的具体步骤
包括用例的开始和结束、用例如何与参与者交互、用例的正常流程、主事件流的变体以及错误流
用例间的关系
关联关系（Association）
- 表示参与者与用例之间的关系
- 不同的参与者可以访问相同的用例
包含关系（include）
- 一个用例可以简单地包含其他用例具有的行为，并把它所包含的行为作为自身行为的一部分，这称作用例间的包含关系
- 包含关系把几个用例的公共部分分离成一个单独的被包含用例，被包含用例称为提供者用例，包含用例称为客户用例
- 客户用例可以简单地包含提供者用例具有的行为，并把它所包含的用例行为作为自身行为的一部分
包含关系的特点：
- 包含用例（客户用例）执行，则被包含用例（提供者用例）必须执行
什么时候使用包含关系？
- 如果两个以上的用例有大量一致的功能，则可以将这个功能分解到另一个用例中，其他用例可以和这个用例建立包含关系
- 一个用例的功能太多时，可以用包含关系建模成两个以上的用例，降低用例的复杂度
扩展关系（extend）
- 扩展用例被定义为基础用例的增量扩展
- 扩展关系是把新的行为加入到已有的用例中去
- 基础用例提供扩展点以添加新的行为
- 扩展用例插入到基础用例的扩展点上
扩展关系的特点
- 没有基础用例，扩展用例也是完整的用例
- 基础用例被执行时，一般不会涉及扩展用例，只有特定的条件发生，扩展用例才可能被执行，这是与包含关系的差别
泛化关系（Generalization）
- 泛化关系是一般和特殊的关系
- 一个用例（父用例）可以被特别地列举为一个或多个子用例
- 子用例表示父用例的特殊形式
- 子用例从父用例处继承行为和属性，还可以添加行为或覆盖、改变继承的行为
如果系统中一个或多个用例是某一个一般用例的特殊化用例时，就应该使用用例的泛化关系，例如：
用例图示例：
图书馆管理员处理借书、还书的用例图
系统管理员进行系统维护的用例图
扫一扫
2万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
