22用例关系.pptVIP

* 用包组织用例 使用包组织相似的建模元素，以简化复杂的用例图,也可做为分配任务的依据 为同一子目标的用例，可以组织到一个包中 包中的用例相互间的逻辑关系密切，用 引入包，用例图变得更加简单和易于理解。 包可以简单理解为子系统。 * 用例图中的用例个数控制在7+2 大量用例时的组织方式 按执行者分包 按主题分包 按开发团队分包 按发布情况分包 也可以先按主题分包，主题内再按开发团队和发布情况分包 * 大学信息管理系统示例 * 用包组织 * 对用例进行排序 用例的排序原则 对类图有重要影响 包含丰富的业务过程信息和线索 有开发风险、时间紧迫或功能复杂 涉及到重要核心技术或新技术 能直接产生经济效益或降低成本 代表本系统的核心流程 对排在前面的用例应应详细描述 例：POS用例，包含关系 * 例：扩展关系 * * * 面向对象分析与设计 用例关系 叶文来 * 用例关系 进一步细化用例 从用例文本中捕获的消息、基本业务活动图、用户界面原型和补充规约等反映的内容，应用包含(include)、扩展(extend)和泛化(generalization)概念重新编写用例反映复用 对原有的用例模型进行检视，看是否可以进一步简化用例模型、提高重用程度、增加模型的可维护性 有利于代码的简化，功能块的复用 用例关系有一定价值，但最重要还是文本 * 改写用例图示例 饮料销售机 * 对用例的重构 主要着眼点 用例之间是否相互独立？如果两个用例总是以同样的顺序被激活，可能需要将它们合并为一个用例。 例： 多个用例之间是否有非常相似的行为或事件流？如果有，可以考虑将它们合并为一个用例。 例：餐馆系统中，顾客点菜和顾客修改菜单最终都需要通知厨房。可以考虑合并为一个通知厨房的用例 * 用例事件流的一部分是否已被构建为另一个用例？如果是，可以让该用例包含(include)另一用例 例：POS系统中，处理销售中的付款 是否应该将一个用例的事件流插入另一个用例的事件流中？如果是，利用与另一个用例的扩展关系(extend)来建立此模型。 例：自动饮料售货机，供货员巡查与供货 * 用例关系 扩展：分离扩展路径； 包含：提取公共步骤，利于复用； 泛化：用例业务不同实现方式；少用 * 识别用例的关系——扩展 扩展用例的事件流往往也可以抽象为基础用例的备选流 将基用例中一段相对独立并且可选的动作，用扩展（Extension）用例加以封装，再让它从基用例中声明的扩展点（Extension Point）上进行扩展，从而使基用例行为更简练和目标更集中。 对于一个扩展用例，可以在基用例上有几个扩展点。 * 识别用例的关系——扩展 * 示例：查询 例如，系统中允许用户对查询的结果进行导出、打印。对于查询而言，能不能导出、打印查询都是一样的，导出、打印是不可见的。导入、打印和查询相对独立，而且为查询添加了新行为。因此可以采用扩展关系来描述： * 执行查询 基本流： 1.员工选择查询功能 员工期望查询业务数据时，选择查询链接，从而启动本用例的执行。 2. 系统转入查询页面，并显示备选的查询选项 3.员工填写查询条件并提交 4.系统验证查询条件的合法性 验证条件的格式以及简单逻辑，如大小、前后、范围 5.系统将符合条件的信息返回 [扩展点：导出、打印] 系统将查询结果以分页列表的形式显示在页面上 6.员工退出查询功能 员工点击退出链接，返回到上一级页面 扩展点：导出、打印扩展点定义在步骤5 导出 该用例是在“导出、打印”扩展点上扩展了执行查询用例 基本流： 1．如果员工要求导出，选择导出按钮 。。。。。。 * 扩展举例 * 识别用例的关系——包含 使用包含（Inclusion）用例来封装一组跨越多个用例的相似动作（行为片断），以便多个基（Base）用例复用。基用例控制与包含用例的关系，以及被包含用例的事件流是否会插入到基用例的事件流中。基用例可以依赖包含用例执行的结果，但是双方都不能访问对方的属性。 * 识别用例的关系——包含 * 包含举例 何时使用包含 某些步骤在多个用例重复出现，且单独形成价值 用例的步骤较多时，可以用Include简化（慎用） * 包含关系的误用 * 餐馆系统中，顾客点菜和顾客修改菜单最终都需要通知厨房。 UC1:顾客点菜 基本流： 1.服务员创建一个新点菜单 2.系统为新的点菜做好准备 3.服务逐项输入顾客所点的菜，并确定 4.系统记录顾客所点的菜 5.系统发送消息至厨房[包含点：UC2通知厨房] UC2:通知厨房 基本流： 1.服务员端