uml 基础教程 第三章-用例图.ppt
合集下载
相关主题
- 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
“缺货”的场景
• 另一种“缺货”的场景。“指定品牌的饮料售完”消息 显示在机器上,直到对这台机器补充为止。在这种情况下, 用户不再输入钱了。销售机的客户可能更喜欢第一种场景: 如果顾客已经投了钱,应该让顾客做另外一种选择而不是 要机器退钱。
“付款数不正确”的 场景
• 紧接着让我们来看看“付款数不正确”的这个场景。顾客 按照通常的方式发起了这个用例,并进行了一个选择。假 设这是机器中备有选择的饮料。如果机器中刚好存有适合 的零钱,那么机器就会退还零钱并交付饮料。如果机器中 没有保存零钱,它将退还钱,并显示一条消息提示用户投 入适当的零钱。
3.1 用例图的构成
• 用例图可以用于描述系统的功能性需求和系统功能 的使用环境。
• 用例图可视化地描述了系统外部的使用者(抽象为 参与者)和使用者使用系统时系统为这些使用者提 供的一系列服务(抽象为用例),并清晰地描述了:
参与者和参与者之间的泛化关系; 用例和用例之间的包含关系、泛化关系、扩展关系; 用例和参与者之间的关联关系
第三章 用例图
本章导读
• 知道参与者、用例和关系的概念 • 了解用例的粒度和规约 • 掌握参与者和用例的确定关系
思考学习以下内容
• 什么是用例? • 创建、包含和扩展用例等的思想 • 如何开始一个用例分析? • 如何表示一个用例模型? • 如何可视化用例之间的关系?
• 【用途】:帮助开发团队以一种可视化的方式理解系统的 功能需求。
• 理想情况下,顾客看到这条消息后会立即选择其它品牌 的饮料。销售机也必须提供给顾客取回原来的钱的选项。 这表示,销售机应给顾客两种选择:让顾客选择另一种饮 料并且给顾客提供这种饮料(如果这种饮料还有存货的话) 或者让顾客选择退钱。
该场景的前置条件是顾客感到口渴,后置条件是顾客 得到一罐饮料或者顾客投入的钱被退回。
• 参与者是用例的启动者,参与者处于用例的外部并且 能够初始化一个用例,但它并不是所描述系统的一部分, 它可能是人或其他外界系统。
• 参与者是指存在于系统外部并直接与系统进行交互的人、 系统、子系统或类的外部实体的抽象。 每个参与者都可以参与一个或多个用例,每个用例也可 以有一个或多个参与者。
用一个小人表示:
“供货”用例
• 考虑“供货”用例。供货人发起这个用例是由于某个时间 间隔到期所引起的。供货代表打开销售机拉出销售机前面 的架子,在架子上补满各种品牌的饮料。销售员还要在机 器中加零钱。然后他放好销售机的前端架子,并锁好机器。 这个用例的前置条件是一个时间间隔的流逝,后置条 件是供货人在机器中放置了新的待售饮料。
• 用户对系统的使用方式决定了系统如何设计和构造。用例 是能够帮助分析员和用户确定系统使用情况的UML组件。 一组用例就是从用户的角度出发对如何使用系统的描述。
• 可以认为用例是系统的一组使用场景。 • 用例图的主要要素是参与者、用例和关联。
• 用例图主要用于描述系统的行为及各种功能之间的关系, 是描述参与者(Actor)与用例以及用例与用例之间关系 的图。
• 上面的“买饮料”场景是唯一可描述的场景么?。显然, 我们立即会想到还有其他的场景。顾客所要购买的饮料销 售机中可能没有。顾客投入的钱数不是刚好等于购买饮料 所需要的钱。应该如何设计饮料销售机来处理这些场景呢?
没有所需饮料的场景
• 先看看没有所需的饮料这个场景,它是用例“买饮料” 的另一场景。可以把这个场景看成是用例执行时的一条可 选路径。用例是由顾客在销售机中插入钱币所发起的。然 后客户进行一个选择,销售机中至少要有一罐选择的饮料, 如果没有,销售机就给顾客提示一个信息,告诉顾客没有 这种品牌的饮料。
• 饮料销售机的主要功能是允许一个顾客购买一罐饮料, 很可能用户立刻就能告诉你一些有关的场景(换句话说就 是用例),你可以给这组场景加上一个标签“买饮料”。 下面我们来考察这个用例中每一种可能的场景。
(1)用例“买饮料”
• 这个用例的参与者是买饮料的顾客。顾客将钱插入销售 机触发了这个用例的场景被执行,然后用户进行选择。如 果一切顺利,销售机内至少还存储有一罐被选择的饮料, 则销售机会自动弹出这种饮料给顾客。
• 要用在用例图上显示某个用例:Βιβλιοθήκη Baidu
➢使用人形符号绘制一个参与者;
➢绘制一个椭圆表示用例,将用例的名称放在椭 圆的中心或椭圆下面的中间位置;
➢使用带箭头或不带箭头的线段来描述参与者和 用例之间的关系。
举例:饮料销售机
• 假设你现在正着手设计一台饮料销售机。为了获得用户 的观点,你会见了许多可能的用户以了解这些用户将如何 与这台机器交互。
前置条件和前面场景一样,后置条件是顾客得到一罐 饮料和找回零钱或者按原款归还钱。
• 另一种可能是机器的储备零钱一旦用光,就会在机器 上显示一条小子告诉用户需要投入适当的零钱。直到对这 台机器补充零钱为止,这条消息才会消失。
(2)其他用例
• 已经从用户的观点考察了饮料销售机。除了这些用户外, 当然还有其他人加入。供货人负责为销售机提供饮料,收 款人(可能与供货人是同一个人)负责定期收集销售机中 的钱。这说明至少需要建立两个用例:“供货”和“取 钱”,这些用例细节可以通过与供货人和收款人交谈来获 得。
• 用例图从用户和外部系统的角度,分析和考察系统的行 为,并通过参与者与系统之间的交互关系描述系统对外提 供的功能特性,用例图用于描述系统与外部系统及用户之 间的交互。
• UML的用例图由参与者、用例及它们之间的关系组成, 它的表达方式为:
用例图 = 参与者 + 用例 + 关系
Use Case Diagram = Actor + Use Case + Relationship
“取钱”用例
• 还有一个“取钱”用例,同样也是因为一段时间的流逝, 收款人发起了这个用例。它的前期工作步骤与”供货“一 样,也是打开销售机前端架子。收款人从机器中取出钱, 然后按照”供货“步骤,放回架子锁好机器。 这个用例的前置条件也是时间间隔的流逝,后置条件 是收款人收到了钱。
3.1.1 参与者
• 特别注意:参与者并不仅仅是指一个人,它代表的是 一个集合。也就是说,参与者(角色)是一个群体概念, 代表的是一类能使用某个功能的人或事,不能将角色的名 字表示成角色的某个实例(如,张三)。