UML系统用例及用例关系.ppt

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