吉林大学UML课件3.ppt

UML建模语言及工具 第三章用例建模Use-Case Modeling Review: A Practice of Visual Modeling with UML UML 5类9种图 类 图：类以及类之间的相互关系 对象图：对象以及对象之间相互关系 构件图：构件及其相互依赖关系 部署图：构件在各节点上的部署 顺序图：强调时间顺序的交互图 协作图：强调对象协作的交互图 状态图：类所经历的各种状态 活动图：对工作流建模 用例图：需求捕获，测试依据 学习线路图 本章目录 3.1 前言 3.2 需求 3.3 基于用例的需求分析过程 3.4 用例分析示例 3.1 前言 学习用例建模的必要性 UML的局限性不可避免 解决问题的客观需要 UML的局限性 本章目录 3.1 前言 3.2 需求 3.3 基于用例的需求分析过程 3.4 用例分析示例 3.2 需求 什么是需求 需求理解的难点 需求应对的误区 需求采集的步骤 什么是需求 需求：系统必须满足的条件或具备的能力 理解需求的目的：建造”正确”的系统 Robert Grady软件质量准则“FURPS” 功能性（Functionality） 使用性（Usability） 可靠性（Reliability） 性能（Performance） 可支持性（Supportability） 需求理解的难点 需求：石头问题 我要一块石头… 差不多，但我要小一点的… 很好，不过我要蓝色的… 啊，没有那么小… 咳，还是原来那个好了… 误解 交流障碍 “完整性”问题 需求永远不会稳定 用户意见不统一 认识混淆 “我知道你相信你已经理解了你认为我所说的内容，但是我并不能肯定你已经认识到你所听到的并不是我所想要的。” 需求应对的误区 需求：也需要开发 需求采集的步骤 需求收集包括五个关键步骤 找到可以帮助你理解这个系统的人 倾听这些相关人员的描述，并从他们的角度来理解系统 利用一个容易理解的模型来描述用户希望如何使用这个系统以及为他们提供的什么价值 详细地描述系统和客户以及系统和外部系统之间的交互 重构（refactor）这个详细描述以保证它是可读且易懂的 本章目录 3.1 前言 3.2 需求 3.3 基于用例的需求分析过程 3.4 用例分析示例 3.3 基于用例的需求分析过程 需求问题对策 以用例为中心的需求组织方式 基于用例的需求分析过程 补充需求规约 何时适用用例建模 需求问题对策 以用例为中心的需求组织方式 基于用例的需求分析过程 1. 获取原始需求 2. 开发一个可以理解的需求 2.1 识别参与者 2.2 识别用例 2.3 构建用例图 3. 详细、完整地描述需求 进行用例阐述 4. 重构用例模型 4.1 识别用例间的关系 4.2 对用例进行组织和分包 1. 获取原始需求 学习内容 获取需求的技巧 一个考勤卡应用程序的例子 获取需求的技巧（MSF） 获取需求：考勤卡应用程序 基于用例的需求分析过程 1. 获取原始需求 2. 开发一个可以理解的需求 2.1 识别参与者 2.2 识别用例 2.3 构建用例图 3. 详细、完整地描述需求 进行用例阐述 4. 重构用例模型 4.1 识别用例间的关系 4.2 对用例进行组织和分包 2.1 识别参与者 学习内容 参与者定义 参与者要点 关于识别参与者的思考题 识别参与者思路 参与者的重要性 参与者的泛化 泛化关系的误用 参与者定义 参与者，Actor 关键词：边界 参与者：在系统之外，透过系统边界与系统进行有意义交互的任何事物 参与者要点 系统外 参与者代表在系统边界之外的真实事物，并不是系统的成分 系统边界 参与者透过系统边界直接与系统交互，参与者的确定代表系统边界的确定 有意义的交互 任何事物 人、外系统、外部因素、时间 思考1：识别参与者? 寻呼台系统：用户如果预定了天气预报，系统每天定时给他发天气消息；如果当天气温高于35度，还要提醒用户注意防暑； 思考2：识别参与者? 仪器分析系统 一系列样品溶液在分析仪器上进行测试，实验员把每个样品的数据输入计算机，最后系统对数据进行分析，并给出分析结果. 思考3：识别参与者? 订货系统 客户给销售员发来传真订货，销售员在下班前将当日订货单汇总输入系统. 思考4：识别参与者? 猪圈自动供食供水系统 猪的前蹄触发一个开关系统就供食或供水。 题外话：小人与圣小猪(1) 众所周知，use case 图里的actor 用一个小人表示。但是这个小人极具误导性，往往让初学者（包括客户）理解为一个真实的人。大多数UML 学习者都要花好长一段时间来搞明白小人其实不一定代表的是人，而是很抽象的系统不可控的外部因素，比如说另一个系统。那么为什么不干脆用其它的符号来表示Actor 呢？ 对于最后一个例子，在use case