第3章3.2用例驱动的需求分析.ppt

面向对象的需求分析 1 结构化分析方法的不足 2面向对象的软件工程 3用例是什么？用例建模的基本过程 4 用例模型的提交物 1 用例模型 2 每个用例的详细描述 3 术语表：所用到的术语说明 4 补充规约：非功能性需求的说明 如，系统会监控执行者在系统里的操作，并在执行者删除数据之前备份。虽然它是系统的一个必需组成部分，但它在需求阶段却不应该作为用例出现。 因为这是一个后台进程，对执行者来说是不可观测的，它应该在系统用例分析阶段定义。 又比如，登录系统是一个有效的用例，但输入密码却不是。这是因为登录系统对执行者是有意义的，这样他可以获得身份认证和授权，但输入密码却是没有意义的，输入完了呢？有什么结果吗？ * * * 事实上，基础用例没有扩展也是完整的，一个扩展用例反而改变了基础用例的事件流。扩展用例的行为是否被执行要取决于主事件流中的判定点。如果特定条件发生，扩展用例的行为才被执行。值得注意的是扩展用例的事件流往往也可以抽象为基础用例的备选流。 * 在图书管理系统中，假设有一个基础用例“还书”，规定了一般情况下的还书流程。但是，如果读者所借书籍超期，在还书的时候是要交纳罚金的，这时基础用例“还书”不能描述超期情况下的还书流程。如果修改基础用例，可能会增加基础用例的复杂性，因此可以考虑在基础用例中添加扩展点，特定条件是超期，如果满足特定条件，将执行“交纳罚金”这个扩展用例。 判断下列操作，哪些是用例 支持跨行业务 插入卡片 输入密码 选择服务 取钱 存钱 修改密码 挂失卡片 交纳费用 警示骗子 三次错误吞没卡片 支持跨行业务 错，这是一个业务规则，限定业务的范围 插入卡片 错，这是一个过程步骤，不是完整目标 输入密码 错，这是一个过程步骤，不是完整目标 选择服务 错，这是一个过程步骤，不是完整目标 取钱 对，这是一个完整有效的目标 存钱 对，这是一个完整有效的目标 修改密码 对，这是一个完整有效的目标 挂失卡片 对，这是一个完整有效的目标 交纳费用 对，这是一个完整有效的目标 警示骗子 错，已超出了边界范围 三次错误吞没卡片错，这是一个业务规则，限定业务的范围 ATM的用例 “四轮马车” C(Create)R(Read)U(Update)D(Delete) 所有业务最终对会成为CRUD？ CRUD能为Actor提供价值？ CRUD掩盖业务，锐变成关系数据库的建模： “系统就是数据的增删改查” 关心数据的存储和维护，反而忽略了用户的目的 用例的粒度2 如果确实是CRUD？ 如果CRUD不涉及复杂的交互，一个用例“管理××”即可 不管是C、R、U、D，都是为了完成“管理”目标 甚至很多种的基本数据管理都可以用一个用例表示 讨论 电子邮件系统，有如下功能： 发件人A发送邮件给B，系统提醒B你有“新邮件”，收件人B接收邮件。 画出用例图 Step 5：给出用例的详细描述 单纯的用例图并不能描述完整的信息，需要用文字描述不能反映在图形上的信息。 用例名称 用例标识 涉及的参与者 描述 用例的规格说明 前置条件 PreConditions 后置条件 PostConditions 正常事件流 Flow of events 备选事件流 Alternate flow 其它 非功能需求、设计约束、尚存在的问题 前置、后置条件 前置条件约束在用例开始前系统的状态 把它们看做是看门人，它阻止参与者触发该用例直到满足所有条件 说明在用例触发之前什么必须为真 后置条件约束用例执行后系统的状态 用例执行后什么必须为真 对于有多个事件流的用例，则应该有多个后置条件 某些用例依赖于其他用例 一个用例在离开系统时，可能是另一个用例的前置条件（例如：“登录”和“管理系统”） 有助于识别漏掉的用例 如果一个用例的前置条件不能有执行其他用例满足，可能意味着丢失了用例（例如：“管理订单”却没有“登录”用例） 事件流 用例的事件流： 说明用例如何启动，即哪些执行者在何种情况下启动用例？ 说明执行者与用例之间的信息处理过程； 说明用例在不同条件下可以选择执行的多种方案； 说明用例在什么情况下才能被视作完成； 分为常规流和备选流两类： 常规流：描述该用例最正常的一种场景，系统执行一系列 活动步骤来响应执行者提出的服务请求； 备选流：负责描述用例执行过程中异常的或偶尔发生的一 些情况。 常规事件流 每一个步骤都需要用数字编号以清楚地 标明步骤的先后顺序。 用一句简短的标题来概括每一步骤的主要内容。 对每一步骤，从两个方面来描述： 执行者向系统提交了什么信息； 对此系统有什么样的响应。 备选事件流 备选流的描述格式可以与基本流的格式一致， 也需要编号并以标题概述其内容。 起点：该备选流从事件流的哪一步开始； 条件：在什么条件下会触发该备