uml04.Use-Case Modeling要点解析.ppt

* * * * * * * * * 时间 气温不是，仅是一个条件 * * * * * -*- 补充约束：设计约束 本质上不是需求，只是从商业、行政、技术上的约束 用Oracle数据库平台，用.Net开发… 软件必须符合ISO×××标准 …… -*- 实例分析：撰写用例文档 用例文档参考模板 旅店预订系统用例文档 “ UC01-预订房间”用例文档 “UC02-取消预订”用例文档 旅行申请系统用例文档 “ UC01-申请旅游团”用例文档 -*- 用例建模流程 1. 获取原始需求 2. 开发一个可以理解的需求 2.1 识别参与者 2.2 识别用例 2.3 构建用例图 3 详细、完整地描述需求 撰写用例文档 4 重构用例模型 4.1 识别用例间的关系 4.2 对用例进行分级和分包 重构用例模型 利用用例建模高级技术重构用例模型 用例关系 通过用例关系将复杂的用例进行适当的分解，以便于提高需求的复用性和可扩展性等，从而使用例模型的结构更合理 用例分级 可以根据用例的重要程度进行分级，以便后续迭代计划的制定，高级别的用例优先考虑 用例分包 将相关的用例打包，通过分包的方式可以将用例图分层表示，以用于大规模系统的用例建模 -*- -*- 4.1 用例关系 include extend Extend Include Generalization -*- 通过关系整理文档 Extend(扩展) 通过扩展用例对基用例增加附加的行为 Include(包含) 基用例中复用被包含用例的行为 提取公共步骤，便于复用 Generalization(泛化) 派生用例继承泛化用例的行为并添加新行为 -*- 用例关系：扩展 扩展：某个用例在特定情况下，包含其他用例(扩展用例)的行为，表示功能被扩展 扩展使用带有extend的虚线表示。此时，箭头由扩展的用例指向原用例，通过扩展点指明在原用例中的扩展位置 -*- 用例关系：包含 包含：表示某个用例中包含了其他用例的行为 包含用带有include的虚线来表示。此时，箭头由原有的用例指向被包含部分的用例 -*- 扩展 VS. 包含 老大知道老二 老二知道老大 什么时候该我上场呢？不知道！ 出现这种情况，就该我上场了！ -*- 扩展 VS. 包含-1 包含：由用例A连向用例B，表示用例A中使用了用例B中的行为或功能 包含关系的提出一般是基于用例行为复用的考虑，这也意味着被包含的用例往往被多个基用例引用 扩展：由用例B连向用例A，表示用例A描述了一项基本需求，而用例B则描述了该基本需求的特殊情况，即一种扩展 扩展用例的提出是为了将基用例的一些特殊情况分离出来，在保持基用例本身相对完整的情况下（即一般情况都能处理）来处理这些特殊行为 -*- 用例关系：泛化 泛化：表示子用例继承了父用例 用例间的泛化关系表明子用例继承父用例中定义的所有属性、行为序列和扩展点，并且参与父用例中所有的关系 -*- 用例关系：扩展 VS. 泛化 -*- uses关系 关于uses关系 uml1.1中有两种用例关系 uses关系和extends关系 它们都是泛化（generalization）关系的构造型（stereotype） uml1.3之后，提供了三种用例关系 include关系、extend关系都是依赖（dependency）关系的构造型（stereotype） 泛化关系（generalization） -*- 旅游申请系统重构后的用例模型 -*- 4.2为什么要对用例进行分级 用例和迭代开发 迭代开发中开发周期的定义是围绕用例来组织的 一个迭代周期要被指派一个到多个用例，如果完全版本的用例在一个迭代周期中处理起来太复杂的话，那就采用简化版本的用例 迭代周期 迭代周期 迭代周期 用例A -简化版本 用例A -完整版本 用例B 用例C -*- 用例分级实施策略-1 可以使用一个简单的但是有些不精确的分类方法，如将用例划分成高、中、低三个等级 -*- 用例分级原则 用例分级的一个基本原则 高级别用例是那些对系统核心架构影响最大的用例 提高用例级别的特性： a. 对架构设计有重要影响的用例，如在领域层中增加多个类的用例或者需要持久化的用例 b. 不需要花费很多努力就可以从中获得重要信息和线索的那些用例 c. 含有开发风险、时间紧迫或功能复杂的用例 d. 涉及到重要技术研究或者新技术和高风险的用例 e. 代表主要的在线业务流程的用例 f. 能产生直接经济效益或者降低成本的用例 -*- 用例分级实施策略-2 依照上述的影响用例级别的特性给用例打分（特性也可能带有权值） -*- 用例的组织 对用例进行分包 让用例图能够更为清晰地表现出系统的业务逻辑关系和层次 对系统进行模块的分割，这将影响到今后的开发和系统的最终表现形式 常见的分包方式 按参与者分包