uml04.Use-CaseModeling概要.ppt

* * * * * * * * -*- 事件流描述-用例交互四部曲 1. 动 作 4. 响 应 2.验证 3.处理 系 统 重点写：1和4（可观测的、体现客户利益的文字） -*- 事件流描述要点 事件流描述要使用户和开发人员互相理解用例的功能，要注意以下几点： 使用业务语言：使用用户平时所使用的语言进行描述 要明确参与者与系统所交互的信息 不使用[例如]、[等]这样的不清晰的表达 不要细化GUI 不要描述计算机内部的处理，要描述从系统外部所看到的活动 要明确描述用例的开始和结束 -*- 例1：使用业务语言 技术语言：无法与用户沟通 系统通过JDBC建立数据库连接，传送SQL查询语句，从“商品表”查询商品的详细信息… 业务语言(用户语言) 系统按照查询条件搜索商品的详细信息 -*- 例2：描述参与者与系统交互过程 以参与者或系统作为主语描述 参与者…… 系统…… 示例 出纳员接收顾客的付款—顾客的付款数可能高于商品总额 出纳员录入顾客所付的现金总额 系统显示出应找还给顾客的余额，打印付款收据 -*- 例3：不细化GUI 过细的GUI描述 会员从下拉框中选择类别 会员在相应文本框中输入查询条件 会员点击“确定”按钮 -*- 例4：分支和循环的描述 分支：放到备选路径中 参与者的选择 另一条成功线路 系统进行验证 …… 循环：直接描述 -*- 用例文档中的补充约束 用例重点在于描述功能需求，而其它方面的补充约束： 与特定用例相关的补充约束，作为该用例文档中一部分来描述 一些全局性的补充约束，单独形成一份独立的文档，如“补充需求规约”文档 补充约束 字段列表 业务规则 非功能需求 设计约束 -*- 实例分析：撰写用例文档 用例文档参考模板(教材P90) 旅店预订系统用例文档 “UC01-预订房间”用例文档 “UC02-取消预订”用例文档 旅行申请系统用例文档 “ UC01-申请旅游团”用例文档 -*- 内容安排 从业务模型获取需求 建立用例模型 编写用例文档 重构用例模型 其它问题 重构用例模型 利用用例建模高级技术重构用例模型 用例关系 通过用例关系将复杂的用例进行适当的分解，以便于提高需求的复用性和可扩展性等，从而使用例模型的结构更合理 用例分级 可以根据用例的重要程度进行分级，以便后续迭代计划的制定，高级别的用例优先考虑 用例分包 将相关的用例打包，通过分包的方式可以将用例图分层表示，以用于大规模系统的用例建模 -*- -*- 用例关系 include extend 扩展 包含 泛化 -*- 通过关系整理文档 Extend(扩展) 通过扩展用例对基用例增加附加的行为 Include(包含) 基用例中复用被包含用例的行为 提取公共步骤，便于复用 Generalization(泛化) 派生用例继承泛化用例的行为并添加新行为 -*- 用例关系：扩展 扩展：某个用例在特定情况下，包含其他用例(扩展用例)的行为，表示功能被扩展 扩展使用带有extend的虚线表示。此时，箭头由扩展的用例指向原用例，通过扩展点指明在原用例中的扩展位置 -*- 用例关系：包含 包含：表示某个用例中包含了其他用例的行为 包含用带有include的虚线来表示。此时，箭头由原有的用例指向被包含部分的用例 -*- 扩展 VS. 包含-1 包含：由用例A连向用例B，表示用例A中使用了用例B中的行为或功能 包含关系的提出一般是基于用例行为复用的考虑，这也意味着被包含的用例往往被多个基用例引用 扩展：由用例B连向用例A，表示用例A描述了一项基本需求，而用例B则描述了该基本需求的特殊情况，即一种扩展 扩展用例的提出是为了将基用例的一些特殊情况分离出来，在保持基用例本身相对完整的情况下（即一般情况都能处理）来处理这些特殊行为 -*- 用例关系：泛化 泛化：表示子用例继承了父用例 用例间的泛化关系表明子用例继承父用例中定义的所有属性、行为序列和扩展点，并且参与父用例中所有的关系 -*- 旅游申请系统重构后的用例模型 -*- 用例分包 对用例进行分包 让用例图能够更为清晰地表现出系统的业务逻辑关系和层次 对系统进行模块的分割，这将影响到今后的开发和系统的最终表现形式 常见的分包方式 按参与者分包 按主题分包 按开发团队分包 按发布情况分包 先按主题分包，主题内再按开发团队和发布情况分包 -*- 利用分包机制组织用例模型 -*- 用例分级 用例和迭代开发 迭代开发中开发周期的定义是围绕用例来组织的 一个迭代周期要被指派一个到多个用例，如果完全版本的用例在一个迭代周期中处理起来太复杂的话，那就采用简化版本的用例 迭代周期 迭代周期 迭代周期 用例A -简化版本 用例A -完整版本 用例B 用例C -*- 用例分级实施策略-1 可以使用一个简单的但是有些不精确的分类方法，如将用例划