用例图
统一建模语言(UML)的一个重要部分是绘制用例图的工具。在项目的分析阶段使用用例来识别和划分系统功能。他们将系统分为参与者和用例。参与者代表系统用户可以扮演的角色。
这些用户可以是人类、其他计算机、硬件,甚至其他软件系统。唯一的标准是它们必须位于被划分为用例的系统部分的外部。他们必须向系统的该部分提供刺激,并且必须从该部分接收输出。
用例代表参与者在系统的帮助下为追求目标而执行的活动。我们需要定义这些用户(参与者)需要从系统中获得什么。用例应该反映用户的需求和目标,并且应该由参与者发起。参与业务用例的业务、参与者、客户应通过关联连接到用例。
绘制用例图
下图显示了用例的 UML 示意图形式。用例本身看起来像一个椭圆形。演员被画成小人物。参与者通过线条连接到用例。
用例 1 - 销售员检查商品
- 顾客将物品放在柜台上。
- «使用» 刷卡 UPC 阅读器。
- 系统在数据库中查找UPC代码采购物品描述和价格
- 系统发出蜂鸣声。
- 系统通过语音输出宣布商品描述和价格。
- 系统将价格和项目类型添加到当前发票。
- 系统将价格添加到正确的税收小计中
因此,“uses”关系非常类似于函数调用或子例程。
以这种方式使用的用例称为抽象用例,因为它不能单独存在,而是必须由其他用例使用。
示例 ─ 提款用例
客户使用我们的自动售货机 (ATM) 的目标是取款。因此,我们正在添加提款用例。从自动售货机取款可能需要银行来进行交易。所以,我们还添加了另一个演员——Bank。参与用例的两个参与者应该通过关联连接到用例。
自动售货机为客户和银行参与者提供取款用例。
参与者和用例之间的关系
可以使用以下关系来组织用例 -
- 概括
- 协会
- 延长
- 包括
用例之间的泛化
在某些情况下,参与者可能与类似的用例相关联。在这种情况下,子用例继承父用例的属性和Behave。因此,我们需要概括参与者以显示函数的继承性。它们由带有大空心三角形箭头的实线表示。
用例之间的关联
参与者和用例之间的关联在用例图中用实线表示。每当参与者参与用例描述的交互时,关联就存在。
延长
有一些功能是可选触发的。在这种情况下,将使用扩展关系并将扩展规则附加到其上。要记住的是,即使未调用扩展用例,基本用例也应该能够自行执行功能。
扩展关系显示为带有空心箭头的虚线,从扩展用例指向扩展(基本)用例。箭头标有关键字“extend”。
包括
它用于提取在多个用例中重复的用例片段。它还用于通过将大型用例分成几个用例来简化大型用例,并提取两个或多个用例的Behave的公共部分。
包括用例之间的关系,用带空心箭头的虚线箭头表示,从基本用例到包含的用例。箭头标有关键字“include”。
用例仅涉及系统的功能需求。其他要求(例如业务规则、服务质量要求和实施约束)必须单独表示。
下图是一个简单用例图的示例,其中标记了所有元素。
成功应用用例的基本原则
- 通过讲故事保持简单
- 高效但不完美
- 了解大局
- 确定用例的重用机会
- 关注价值
- 分片构建系统
- 增量交付系统
- 适应团队的需求
用例模板
在这里,我们展示了一个用例模板,业务分析师可以填写该模板,以便技术团队确定有关项目的信息。
用例 ID: | |||
用例名称: | |||
由...制作: | 最后更新者 | ||
创建日期: | 上次更新日期 | ||
演员: | |||
描述: | |||
前提条件: | |||
岗位条件: | |||
优先事项: | |||
使用频率: | |||
事件的正常过程: | |||
替代课程: | |||
例外情况: | |||
包括: | |||
特殊要求: | |||
假设: | |||
注意事项和问题: |