uml 基础教程 第三章-用例图.ppt

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