2019年业务建模及用例建模.ppt

* -*- 用例关系 include extend 扩展 包含 泛化 -*- 通过关系整理文档 Extend(扩展) 通过扩展用例对基用例增加附加的行为 Include(包含) 基用例中复用被包含用例的行为 提取公共步骤，便于复用 Generalization(泛化) 派生用例继承泛化用例的行为并添加新行为 -*- 用例关系：扩展 扩展：某个用例在特定情况下，包含其他用例(扩展用例)的行为，表示功能被扩展 扩展使用带有extend的虚线表示。此时，箭头由扩展的用例指向原用例，通过扩展点指明在原用例中的扩展位置 -*- 用例关系：包含 包含：表示某个用例中包含了其他用例的行为 包含用带有include的虚线来表示。此时，箭头由原有的用例指向被包含部分的用例 -*- 扩展 VS. 包含-1 包含：由用例A连向用例B，表示用例A中使用了用例B中的行为或功能 包含关系的提出一般是基于用例行为复用的考虑，这也意味着被包含的用例往往被多个基用例引用 扩展：由用例B连向用例A，表示用例A描述了一项基本需求，而用例B则描述了该基本需求的特殊情况，即一种扩展 扩展用例的提出是为了将基用例的一些特殊情况分离出来，在保持基用例本身相对完整的情况下（即一般情况都能处理）来处理这些特殊行为 -*- 用例关系：泛化 泛化：表示子用例继承了父用例 用例间的泛化关系表明子用例继承父用例中定义的所有属性、行为序列和扩展点，并且参与父用例中所有的关系 -*- 用例分包 对用例进行分包 让用例图能够更为清晰地表现出系统的业务逻辑关系和层次 对系统进行模块的分割，这将影响到今后的开发和系统的最终表现形式 常见的分包方式 按参与者分包 按主题分包 按开发团队分包 按发布情况分包 先按主题分包，主题内再按开发团队和发布情况分包 -*- 利用分包机制组织用例模型 -*- 用例分级 用例和迭代开发 迭代开发中开发周期的定义是围绕用例来组织的 一个迭代周期要被指派一个到多个用例，如果完全版本的用例在一个迭代周期中处理起来太复杂的话，那就采用简化版本的用例 迭代周期 迭代周期 迭代周期 用例A -简化版本 用例A -完整版本 用例B 用例C -*- 用例分级实施策略-1 可以使用一个简单的但是有些不精确的分类方法，如将用例划分成高、中、低三个等级 -*- 用例分级原则 用例分级的一个基本原则 高级别用例是那些对系统核心架构影响最大的用例 提高用例级别的特性： a. 对架构设计有重要影响的用例，如在领域层中增加多个类的用例或者需要持久化的用例 b. 不需要花费很多努力就可以从中获得重要信息和线索的那些用例 c. 含有开发风险、时间紧迫或功能复杂的用例 d. 涉及到重要技术研究或者新技术和高风险的用例 e. 代表主要的在线业务流程的用例 f. 能产生直接经济效益或者降低成本的用例 -*- 用例分级实施策略-2 依照上述的影响用例级别的特性给用例打分（特性也可能带有权值） -*- 内容安排 从业务模型获取需求 建立用例模型 编写用例文档 重构用例模型 其它问题 用例建模中常见的问题 用例不是功能分解 用例图不是流程图 用例关系的误用 -*- -*- 何时适用用例建模 用例是从参与者角度捕获系统功能，当系统只有一个或者没有参与者时，显然不是非常有效的 用例捕获功能需求，因此对于系统的非功能需求不是有效 当遇到下述情况时，用例是需求捕获的最好选择 系统由功能需求所主导 系统具有很多类型的用户，系统对他们提供不同的功能 系统具有很多接口 当遇到下述情况时，用例是一个糟糕的选择： 系统由非功能需求所主导（如：google） 系统具有很少的用户 系统具有很少的接口（非内部功能） 如：嵌入式系统、算法复杂但接口少的系统等 * * * * * 注意：该活动图很多细节作了简化，在实际业务建模过程中可以采用分层技术详细描述各业务流程细节 如：在入住、预订之前都需要判定是否有房间，如果没有则直接结束 * * * * * * * * * * * * 附录2-1. UML元语 -*- 用例图元语 返回用例图 -*- 活动图元语 返回活动图 -*- 类图、对象图、包图元语 返回静态结构图 组合结构图元语 -*- 返回组合结构图 -*- 顺序图元语 返回顺序图 -*- 通信图元语 返回通信图 -*- 交互纵览图元语 返回交互纵览图 时间图元语 -*- 返回时间图 -*- 状态机图元语 返回状态机图 -*- 构件图元语 返回构件图 -*- 部署图元语 返回部署图 -*- 外廓图 返回外廓图 -*- 4 构建用例图 用例图：表达参与者与用例关系图形 -*- 内容安排 从业务模型获取需求 建立用例模型 编写用例文档 重构用例模型 其它问题 -*- 撰写用例文档 用例文档：更进一步的精度 需求规格说明书的核心，而用例