系统用例与用例关系分析.ppt

* 事实上，基础用例没有扩展也是完整的，一个扩展用例反而改变了基础用例的事件流。扩展用例的行为是否被执行要取决于主事件流中的判定点。如果特定条件发生，扩展用例的行为才被执行。值得注意的是扩展用例的事件流往往也可以抽象为基础用例的备选流。 * 事实上，基础用例没有扩展也是完整的，一个扩展用例反而改变了基础用例的事件流。扩展用例的行为是否被执行要取决于主事件流中的判定点。如果特定条件发生，扩展用例的行为才被执行。值得注意的是扩展用例的事件流往往也可以抽象为基础用例的备选流。 * 在图书管理系统中，假设有一个基础用例“还书”，规定了一般情况下的还书流程。但是，如果读者所借书籍超期，在还书的时候是要交纳罚金的，这时基础用例“还书”不能描述超期情况下的还书流程。如果修改基础用例，可能会增加基础用例的复杂性，因此可以考虑在基础用例中添加扩展点，特定条件是超期，如果满足特定条件，将执行“交纳罚金”这个扩展用例。 * 时间 气温不是，仅是一个条件 * 用例粒度-4 如果确实是CRUD？ 如果CRUD不涉及复杂的交互，一个用例“管理××”即可 不管是C、R、U、D，都是为了完成“管理”目标 甚至很多种的基本数据管理都可以用一个用例表示 用例粒度-5 灵活处理CRUD 可以把包含复杂交互的路径独立出去形成用例 用例的命名 执行者视角： （状语）动词+（定语+ ）宾语 用例关系 Include 提取公共步骤，便于复用 Extend 分离扩展路径 Generalization 同一业务目的的不同技术实现 extend Extend include Include Generalization 包含关系1 包含关系2 包含关系 某些步骤在多个用例重复出现，且单独形成价值 用例步骤较多时，可用Include简化 当完全知道什么时间要调用用例时，基用例需要包含用例所封装的逻辑 可以简单认为源代码中的函数调用或操作调用 包含举例1 包含举例2 扩展关系1 扩展关系2 将扩展用例的事件流在一定的条件下按照相应的扩展点插入到基础用例中。 基础用例不必知道扩展用例的任何细节，它仅为其提供扩展点 扩展用例的行为是否被执行要取决于主事件流中的判定点。 扩展关系2 基用例路径本身是完整的 可能是一条扩展路径 扩展路径步骤多 扩展路径内部还可以有扩展点－扩展之扩展 扩展路径未定或容易变化－分离以“冻结”基用例 基础用例可以单独存在，但在一定条件下，他的行为可以被另一个用例作为扩展 扩展关系 扩展举例 泛化关系 同一业务目的不同技术实现： 一个用例可以泛化为另一个更普通用例（更普通用例特化为特殊用例） UML 1.5: 用例间的泛化关系表明子用例包含父用例中定义的所有属性、行为序列和扩展点，并且参与父用例中所有的关系 泛化 一个售货员可以终止任何交易，除了那些需要特殊的售货员（高级代理）终止的超过了一定限制的交易 包含用例与扩展用例的区别 ①相对于基础用例，扩展用例是可选的，而包含用例则不是。 ②如果缺少扩展用例，基础用例还是完整的，而缺少包含用例，则基础用例就不完整了。 ③扩展用例的执行需要满足某种条件，而包含用例不需要。 ④扩展用例的执行会改变基础用例的行为，而包含用例不会。 用例关系：扩展 VS. 泛化 采用不同关系，文档结构不同 小结 理解需求 以用例为中心组织需求 基于用例的需求分析过程 获取原始需求 开发一个可以理解的需求 识别参与者 识别用例 确定关系 思考 基于用例的需求分析过程可大致分几步？ 什么是系统边界 用例的概念 用例的关系 参与者的定义与关系 思考1：识别参与者？ 寻呼台系统：用户如果预定了天气预报，系统每天定时给他发天气消息；如果当天气温高于35度，还要提醒用户注意防暑； 在这个叙述里，谁是寻呼台系统的Actor？用户？气温？时间？ 思考2：获取需求-考勤卡应用程序 初次访谈记录开发者：谁将使用这个应用程序？客 户：所有用它来记录可记帐以及不可记帐的工时的雇员……开发者：现在考勤卡应用程序是什么样的？客 户：每半个月就用一个Excel表格来记录。每个雇员都将通过他的表格填好，然后用电子邮件发给我。这个表格相当标准：纵向是收费项目代码，横向是日期。雇员可以在每个条目上填写说明。开发者：这个收费项目代码可以从什么地方得到？……开发者：谁来管理收费项目代码？客 户：嗯，必要的时候由我来添加这个代码。而每个经理总会告诉他的下属应该填写什么。…… 思考3：识别用例 Email客户端（如：outlook express），A在北京发邮件给上海的B，系统提醒B你有“新邮件”，B收邮件 用例是一个完整的交互，用例之间没有顺序的关系 思考3：识别用例-正确 实验04 按照分组的任务设计用例 注意用例的粒度与关系 * *