UML系统分析与设计 chapter06_plus.pptVIP

Review 用例图定义 由参与者（Actor）、用例（Use Case）以及它们之间的关系构成的用于描述系统功能的动态模型图称为用例图。 参与者 用例 关系 Review 参与者（Actor） Review 用例（Use case） 关系 包含关系误用 某些步骤在多个用例重复出现，且单独形成价值 扩展关系误用 用例粒度 用例的粒度指的是用例所包含的系统服务或功能单元的多少。 用例的粒度越大，用例包含的功能越多，反之则包含的功能越少。 用例粒度 用例粒度 如果用例的粒度很小，得到的用例数就会太多。反之，如果用例的粒度很大，那么得到的用例数就会很少。 如果用例数目过多会造成用例模型过大和引入设计困难大大提高。 如果用例数目过少会造成用例的粒度太大，不便于进一步的充分分析 用例粒度 用例粒度 用例规约 非功能需求(URPS) 可用性（Usability） 可靠性（Reliability） 性能（Performance） 可支持性（Supportability） 设计约束 用Oracle数据库平台，用PB开发… 软件必须符合ISO×××标准 …… 本质上不是需求，只是从商业、行政、技术上的约束 前置、后置条件 前置条件约束在用例开始前系统的状态 把它们看做是看门人，它阻止参与者触发该用例直到满足所有条件 说明在用例触发之前什么必须为真 后置条件约束用例执行后系统的状态 用例执行后什么必须为真 对于有多个事件流的用例，则应该有多个后置条件 词汇表 词汇表 用例规约示例 基于用例的需求分析过程 1. 获取原始需求 2. 开发一个可以理解的需求 2.1 识别参与者 2.2 识别用例 2.3 构建用例图 3 详细、完整地描述需求 进行用例阐述 4 重构用例模型 4.1 识别用例间的关系 4.2 对用例进行组织和分包 基于用例的需求分析过程 1. 获取原始需求 2. 开发一个可以理解的需求 2.1 识别参与者 2.2 识别用例 2.3 构建用例图 3. 详细、完整地描述需求 进行用例阐述 4. 重构用例模型 4.1 识别用例间的关系 4.2 对用例进行组织和分包 1 获取原始需求 获取需求：考勤卡应用程序 基于用例的需求分析过程 1. 获取原始需求 2. 开发一个可以理解的需求 2.1 识别参与者 2.2 识别用例 2.3 构建用例图：确定参与者和用例之间的关系 3. 详细、完整地描述需求 进行用例阐述 4. 重构用例模型 4.1 识别用例间的关系 4.2 对用例进行组织和分包 2.1 识别参与者 谁使用系统的主要功能 谁改变系统的数据 谁从系统获取信息 谁需要系统的支持以完成日常工作任务 谁负责日常维护、管理并保证系统正常运行 系统需要应付（处理）那些硬设备 系统需要和那些外部系统交互 谁（或什么）对系统运行产生的结果（值）感兴趣 时间、气温等内部外部条件 …… 识别参与者：考勤卡系统 参与者的泛化：责任重叠 Generalization – A generalization from an actor A to an actor B indicates that an instance of A can communicate with the same kinds of use-case instances as an instance of B 如系统中经理可以参加雇员的所有用例 泛化关系的误用 2.2 识别用例 关键词：价值 定义 一个用例定义一组用例实例 用例实例是系统执行的一系列动作，这些动作将生成特定参与者可观测的结果值 简单的说：参与者使用系统达到目标 识别用例：考勤卡系统 用例要点 结果值→用例是有意义的目标 系统执行→结果值由系统生成 由参与者观测→业务语言、用户观点 一组用例实例→用例的粒度 2.3 构建用例图 基于用例的需求分析过程 1. 获取原始需求 2. 开发一个可以理解的需求 2.1 识别参与者 2.2 识别用例 2.3 构建用例图 3 详细、完整地描述需求 进行用例阐述 4 重构用例模型 4.1 识别用例间的关系 4.2 对用例进行组织和分包 3 进行用例阐述：写用例规约 用例规约用来描述用例的，不是用例图 基于用例的需求分析过程 1. 获取原始需求 2. 开发一个可以理解的需求 2.1 识别参与者 2.2 识别用例 2.3 构建用例图 3 详细、完整地描述需求 进行用例阐述 4 重构用例模型 4.1 识别用例间的关系 4.2 对用例进行组织和分包 4.1 用例关系 通过关系整理文档 Extend 分离扩展路径 Include 提取公共步骤，便于复用 Generalization 同一业务目的的不同技术实现 4.2 用例进行分类 用例和开发周期 开发周期是围绕用例的需求来组