- 商业分析教程
- 商业分析 - 首页
- 商业分析 - 简介
- 软件开发生命周期
- 商业分析 - 角色
- 工具和技术
- 商业分析 - JAD 会议
- 需求收集技术
- 功能需求文档
- 软件需求规格说明书
- 商业分析 - 用例
- 用例图
- 需求管理
- 规划良好的需求
- 商业分析 - 建模
- 商业分析有用资源
- 商业分析 - 快速指南
- 商业分析 - 有用资源
- 商业分析 - 讨论
用例图
统一建模语言 (UML) 的一个重要部分是绘制用例图的功能。用例在项目的分析阶段用于识别和划分系统功能。它们将系统划分为参与者和用例。参与者代表系统用户可以扮演的角色。
这些用户可以是人类、其他计算机、硬件部件,甚至是其他软件系统。唯一的标准是它们必须位于被划分为用例的系统部分之外。它们必须向系统的那一部分提供刺激,并且必须接收来自它的输出。
用例代表参与者在追求目标的过程中借助您的系统执行的活动。我们需要定义这些用户(参与者)需要系统提供什么。用例应反映用户需求和目标,并应由参与者启动。参与业务用例的业务、参与者、客户应通过关联连接到用例。
绘制用例图
下图显示了用例在 UML 图示形式中的外观。用例本身看起来像一个椭圆形。参与者被绘制成小小的简笔人物。参与者用线连接到用例。
用例 1 − 销售员结账
- 顾客将商品放在柜台上。
- «uses» 扫描 UPC 阅读器。
- 系统在数据库中查找 UPC 代码,获取商品描述和价格
- 系统发出蜂鸣声。
- 系统通过语音输出宣布商品描述和价格。
- 系统将价格和商品类型添加到当前发票。
- 系统将价格添加到正确的税款小计。
因此,「uses」关系非常类似于函数调用或子程序。
以这种方式使用的用例称为抽象用例,因为它不能独立存在,而必须由其他用例使用。
示例 ─ 取款用例
客户与我们的自动取款机 (ATM) 相关的目标是取款。因此,我们添加了取款用例。从自动取款机取款可能涉及银行进行交易。因此,我们还添加了另一个参与者 – 银行。参与用例的两个参与者都应通过关联连接到用例。
自动取款机为客户和银行参与者提供取款用例。
参与者和用例之间的关系
用例可以使用以下关系进行组织:
- 泛化
- 关联
- 扩展
- 包含
用例之间的泛化
在某些情况下,参与者可能与类似的用例相关联。在这种情况下,子用例继承父用例的属性和行为。因此,我们需要泛化参与者以显示函数的继承。它们由带有大型空心三角形箭头头的实线表示。
用例之间的关联
参与者和用例之间的关联在用例图中由实线表示。只要参与者参与用例描述的交互,就存在关联。
扩展
有些功能是可选触发的。在这种情况下,使用扩展关系,并将扩展规则附加到它。需要注意的是,即使未调用扩展用例,基本用例也应该能够自行执行功能。
扩展关系显示为一条虚线,带有从扩展用例指向扩展(基本)用例的开放箭头。箭头用关键字 «extend» 标记。
包含
它用于提取在多个用例中重复的用例片段。它还用于通过将大型用例拆分为多个用例以及提取两个或多个用例行为的公共部分来简化大型用例。
用例之间的包含关系,由一条从基本用例指向包含用例的带有开放箭头头的虚线表示。箭头用关键字 «include» 标记。
用例仅处理系统的功能需求。其他需求,例如业务规则、服务质量需求和实现约束,必须单独表示。
下图显示了一个带有所有标记元素的简单用例图示例。
用例成功应用的基本原则
- 通过讲述故事来简化它
- 无需完美即可高效
- 了解全局
- 识别用例的重用机会
- 关注价值
- 分片构建系统
- 增量交付系统
- 适应以满足团队的需求
用例模板
在这里,我们展示了一个用例的示例模板,业务分析师可以填写该模板,以便技术团队可以利用这些信息来确定项目信息。
| 用例 ID | |||
| 用例名称 | |||
| 创建者 | 最后更新者 | ||
| 创建日期 | 最后更新日期 | ||
| 参与者 | |||
| 描述 | |||
| 前提条件 | |||
| 后置条件 | |||
| 优先级 | |||
| 使用频率 | |||
| 正常流程 | |||
| 备选流程 | |||
| 异常 | |||
| 包含 | |||
| 特殊要求 | |||
| 假设 | |||
| 备注和问题 | |||