[计算机软件及应用]UML用例.ppt

用例图 linx166@163.com 讲授内容 场景 具体系统分析 讲解用例分析设计过程 练习用例分析 课外作业与实验巩固 场景 脚本（scenario），情景，剧本 贯穿用例的一条单一路径，显示用例中的某种特殊情况 用例的一个实例 买饮料用例之场景一 场景的前置条件：顾客感到口渴了 顾客投入硬币，选择饮料的种类； 销售机至少存在顾客想要的饮料一瓶； 销售机自动弹出饮料给顾客 场景的后置条件：顾客得到一瓶饮料。 买饮料用例之场景二 场景的前置条件：顾客感到口渴了 顾客投入硬币，然后选择饮料品牌； 销售机中没有该品牌的饮料了，提示顾客是否继续选择其他品牌； 顾客或者选其他品牌，或者选择退钱。 场景二的后置条件是：顾客得到其他品牌的饮料或者顾客投入的硬币被退出。 用例间关系--包含用例（include) 再回头看看“供货”用例的场景： 前置条件：时间的流逝 1 供货人打开销售机； 2 拉开货架，补满各种品牌的饮料； 3 然后放好货架，锁好机器 后置条件：机器中放置了新的待售饮料。 用例间关系--包含用例(include) “取钱”用例的场景 前置条件：时间流逝 1 打开销售机器，取出前端货架； 2 取款人从机器中取出钱 3 放回架子，锁好机器。 后置条件：收款人收到钱。 比较供货和取款两个用例的场景 1 供货人打开销售机； 2 拉开货架，补满各种品牌的饮料； 3 然后放好货架，锁好机器。 1取款人打开销售机器，取出前端货架； 2 从机器中取出钱； 3 放回架子，锁好机器。 这两个用例都以开锁和拉开销售机的门开始，都以关门和上锁结束 用例间关系—扩展关系extend 当饮料机器开发出后，投入运行。分析员观察到这样一个问题。大部分的机器出现“百事”卖的很快，而其他饮料卖的一般。当“百事”卖完后，后来的顾客往往扫兴而去。 如何解决这个问题呢？问题解决的入口在哪里？ 是“供货”用例。在原“供货”的用例中扩展一个新的“供货”用例-----“按销售情况供货”，原“供货”用例是基本用例，新用例是扩展用例。 用例间关系--泛化 泛化关系(generalization) 表示一般和特殊的关系 。子用例继承了父用例的行为和含义，也可以增加新的行为和含义或者重写父用例 包含和扩展 包含关系中，执行基本用例时一定会执行包含用例，如果没有后者它将是不完整的 扩展关系中，执行基本用例时，扩展用例可执行也可不执行 参与者 系统以外的、需要使用系统或与系统交互的东西，包括人、设备、外部系统等。 选课管理系统的分析 目前情况： 学生填单，教务处受理该业务。学生微调选修课程，教务处重复处理该业务。 学生想了解每门课程教师的情况和课程结业的成绩。通过打听、打电话和发短信。 N多的人花N 长时间还做不好该任务。 明确系统的参与者 教务处 学生 教师 关键用例的设计---谈话记录 分析员：这位老师，你希望该系统为你做什么？ 教师：哎，一定要让我把学生成绩发布出去，学生可以通过网络查看成绩。要不，我的电话都打爆了。 分析员：这没问题，还有呢？ 教师：我想知道不来上课学生的详细情况。 分析员：恩，这个嘛，我需要考虑。 关键用例的设计---谈话记录 教师：对了，我的成绩信息要安全，不能随便改动。 分析员：我们会设计登录功能，保证数据安全。请放心吧。 教师：密码忘了咋办，我经常忘东西。 分析员（暗想）：……。 分析员笑着说：我们会提供相应功能。 关键用例的设计---谈话记录 教师：我想了解教务处开出的选修课程的情况。比如：我讲的是“UML”，我想知道我同行的情况，有时我会去听课学习一下。 分析员：好的，没有问题。系统可以帮你。 需求的故事不会讲完 教师（电话）：系统提供查询选修课程的功能了吧？ 分析员：有提供呀！ 教师：我想查其他老师的课程情况，比如：我想查老师本学期开的课程。 分析员：哦，是不是要列出这位老师开出的所有选修课呀。 教师：是的。 课堂训练项目 角色扮演： 学生群：4-5扮演客户； 分析员：2位同学； 谈话记录：1名同学。 参与者 参与者不单单指人 不是指人或事物本身，而是当时所扮演的角色 系统以外的、需要使用系统或与系统交互的东西，包括人、设备、外部系统等。 确定参与者 谁或什么对系统运行产生的结果感兴趣 谁或什么将会改变系统中的数据 谁或什么要从系统中得到信息 谁或什么要与系统交互 用例 系统、子系统或类和外部的参与者交互的动作序列的说明，包括可选的动作序列和会出现异常的动作序列 对一个参与者使用系统的一项功能时所进行的交互过程的一个文字描述序列 与实现无关的关于系统功能的描述 容易进入的误区 1粒度过细，陷入功能分解 2把步骤当用例 3把系统活动当用例 用例的描