第2章 用例建模.ppt

第二章 用例建模 想从生活中得到什么，必不可少的第一步就是：决定想要什么。 本章内容 用例的概念 用例格式及编写规范 定义用例的方法 用例图的UML表示 本章内容 用例的概念 用例格式及编写规范 定义用例的方法 用例图的UML表示 2.1 需求分析与用例 问题： ①用例是什么？ ②怎样使用用例描述需求？ ③如何识别是正确的用例？ 2.1 需求分析与用例 需求：就是系统（或者说项目）必须提供的能力和必须遵从的条件。 需求分析的一种重要手段是：确定和编写用例。 用例的定义 用例是文本形式的情节描述，用于需求的发现和记录。 简单示例 登录系统：管理员向系统提交用户名和密码。系统进行认证。系统向管理员显示成功登录信息。 用例的理解 用例是参与者想要系统做的事情。它是特定参与者对于系统的“使用情况”。 用例总是由参与者开始。 用例总是从参与者的角度来编写的。 2.1 用例的概念 用例的概念？ 需要弄清三个概念 参与者： 场景： 系统边界： 场景 场景：是参与者和系统之间的一系列特定的活动和交互。 例如，使用现金成功购买商品的场景，或者由于付款被拒收造成的购买失败的场景。 所以，场景包括主成功场景和交替场景（或主路径和扩展路径） 用例：就是一组相关的成功和失败场景的集合。 例如，下面是包含交替场景的非正式的用例： 处理退货 主成功场景： 顾客携带商品到收银台退货。 收银员使用pos系统记录并处理每件退货…… 交替场景： 如果客户之前用信用卡付款，信用卡退款交易失败，则告知顾客使用现金退款。 如果在系统中未查找到该商品的标识码，则提示收银员并建议手工输入标识码。 如果系统检测到与外部记账系统通信失败，则…… 本章内容 用例的概念 用例格式及编写规范 定义用例的方法 用例图的UML表示 本章内容 用例的概念 用例格式及编写规范 定义用例的方法 用例图的UML表示 2.2用例格式和编写规范 用例，强调用户的目标和观点。 形式化形式： 简洁用例—需求分析早期使用，通常用于主成功场景 非正式用例—需求分析早期使用，可覆盖不同的场景 详述用例—详细编写所有步骤及各种变化 用例的名称应使用动词开头 编写用例的时候应尽量使用行业的专业名称，而不是计算机专业术语 准则： 编写简洁的用例 编写黑盒用例 采用参与者和参与者目标的视点 掌握发现用例的方法 下章讲 本章内容 用例的概念 用例格式及编写规范 定义用例的方法 用例图的UML表示 本章内容 用例的概念 用例格式及编写规范 定义用例的方法 用例图的UML表示 真实项目中如何发现用例？ 遵循如下的思维习惯： 调研需求时，最先清楚有多少部门，多少岗位（参与者），然后找到每一个岗位的业务代表，问他们类似的问题：你平时都做什么？（参与者目标）这件事是谁交办的？做完后你需要通知或传达给谁吗？做这件事你需要填写些表格吗？（用例） 识别用例最好的方法就是从分析系统的参与者开始，考虑每个参与者是如何使用系统的。 步骤1：选择系统边界 考虑构造系统时，你所需要做的第一件事情是确定系统的边界在哪里，需要定义什么是系统的组成部分（系统的边界内）和什么是系统的外部（系统边界外） 确定边界，可以通过确定参与者，一旦定义了外部参与者，系统边界将变得清晰。 步骤2：寻找主要参与者和目标 谁是参与者？ 例如这样一个场景：小王到银行去开户，向大厅经理询问了办理手续，填写了表单，交给柜台职员，拿到了银行存折。在这个场景中，谁是参与者。 可以通过回答下列问题，确定谁是参与者 谁对系统有明确的目标和要求并且主动发出动作？ 系统为谁服务？ ATM机系统的用例示例： 客户代表说：我希望这台ATM机能支持取款和存款，当需取款时，首先我插入卡片，系统读卡，提示我输入密码，我输入密码并登陆，选择取款，输入取款金额，它从指定的出口吐钞，并打印出回执单；另外，我还可以修改密码，也可以挂失；还有我希望可以交纳电话费、税费、电费等费用；为了安全起见，ATM上应当有警示小心骗子的提示条，还有摄像头。 下面哪些是有效用例，哪些不是？ 插入卡片？ 输入密码？ 选择服务？ 取钱？ 存钱？ 挂失卡片？ 交纳费用？ 警示骗子？ 识别用例 应该怎样发现用例？通常很难判断某个用例是否合理。任务可以在不同粒度级别上组合，可能是一个或几个简单步骤，也可能是一个企业级的复杂活动。 对于ATM取款机系统，下面哪些是有效的用例？ 取款 读卡 登陆 打印回执单 可以认为这些都是用例，但它们处于不同的级别，依赖于系统的边界、参与者和目标。 系统中， “什么是合理的用例？”或者说“对应用的需求来说，在什么级别上描述用例最有帮助？” 答：应专注于“基本业务过程”(EBP)级别的用例。 EBP定义：由一个人在某个时间某个地点执行的一项