UML-2介绍用例

1、5 介绍用例什么是用例建立用例包含用例扩展用例开始用例分析 前面所介绍的图主要涉及的是系统中类的静态视图。我们最终要建立的是能够展示系统和系统中的类如何随时间变化的动态视图。静态视图有助于分析员和客户交流。动态视图，你以后将会看到，它有助于系统分析员与开发小组交流，并且能帮助开发组编制程序。 客户和开发组是系统风险承担入的重要组成部分。然而不应该遗漏另一个同样重要的组成部分用户。不论是静态视图还是动态视图都不能从用户的观点说明系统所具有的行为。理解用户的观点对建立有用的并且易用的系统是十分关键的也就是说，这样的系统能够满足用户需求并且容易使用。5.1 什么是用例 假想你要买一台传真机，当你在办公用品商店选购传真机时，面临着很多选择。如何选购才能使自己最有利呢?你必须不断反问你自己一些问题。究竟我买传真机是要干什么用?我需要传真机具有哪些特征?这台传真机必须具有哪些功能?是不是需要它具有复印功能?是否连接到我的计算机?用传真机是否像用扫描仪一样?我是不是要尽量快地发传真而需要快速拨号功能?它需不需要具有区分外来传真信号和外来电话信号的功能? 当我们慎重的购物时，我们都有过这样的经历。这种

2、经历就是某种形式的用例分析(use case analysis)：我们反问自己究竟将如何使用产品或系统。了解这些需求是非常重要的。 这个过程在系统开发的分析阶段尤为重要。用户对系统的使用方式决定了系统如何设计和构造。 用例是能够帮助分析员和用户确定系统使用情况的UML组件。一组用例就是从用户的角度出发对如何使用系统的描述。 可以认为用例是系统的一组使用场景。每个场景描述了一个事件的序列。每个序列是由一个人、另一个系统、一个硬件设备或者某段时间的流逝所发起。这些发起事件序列的实体叫做参与者(actor)。事件序列的结果是由发起这个序列的参与者或者另一个参与者对系统某种形式的使用所引起的。 正如类图可以以一种好的促进客户以他的观点考察系统的方法一样，用例是一个能促进系统可能的用户以他们自己的观点看待系统的优秀工具。用户并不总是容易清晰的阐明到底他要怎样使用系统。因为传统的系统开发常常是一种缺少前端分析的开发过程，因此当问及用户如何执行系统输入时，他往往不能理解。 避免这种情况的基本思路是让用户参与前期的系统分析与设计。这样做可以使最终的系统尽可能地为用户可用而不仅仅是表现出了设计者的聪明才

3、智而让用户无法理解和使用的一堆计算概念和业务模型。5.2 用例的重要性5.3 举例：饮料自动销售机 假设你现在正着手设计一台饮料自动销售机。为了获得用户的使用观点，你会见了许多可能的用户以了解这些用户将如何与这台机器交互。 饮料自动销售机的主要功能是允许个顾客能够购买罐饮料，很可能用户立刻就能告诉你一些有关的场景(换句话说就是用例)。你可以给这组场景加上一个标签“买饮料”。下面让我们来考察这个用例中每一种可能的场景。记住，在正常的系统开发中，在与用户交谈的过程中就能发现这些场景。5.3.1 用例“买饮料” 这个用例的参与者是买饮料的顾客。顾客将钱插入销售机触发了这个用例的场景被执行。然后他进行选择。如果一切顺利，销售机内还储存有至少一罐被选择的饮料，则销售机会自动弹出一罐这种饮料给顾客。 除了上面的步骤序列，该场景的其他方面也值得考虑。顾客发起“买饮料”这个用例的执行场景需要什么前置条件?最直观的前置条件之一是顾客感到口渴。场景的执行步骤完成后需要什么后置条件?显然最直观的后置条件是顾客有了一罐饮料。 上面的“买饮料”场景是唯一可描述的场景吗?显然我们立即会想到还有其他的场景。顾客所要

4、购买的饮料销售机中可能没有；顾客投入的钱数不刚好等于购买饮料所需要的钱。应该如何设计饮料销售机来处理这些场景呢? 先看看没有所需的饮料这个场景，它是用例“买饮料”的另一个场景。可以把这个场景看成是用例执行时的一条可选路径。用例是由顾客在销售机中插入钱币所发起的。然后他进行一个选择，销售机中至少要有一罐选择的饮料，如果没有，销售机就给顾客提示一个信息，告诉顾客没有这种品牌的饮料。理想情况下，顾客看到这条消息后台立即选择其他品牌的饮料。销售机必须提供给顾客取回原来的钱的选项。这表示，销售机应给顾客两种选择：让顾客选择另一种饮料并且给顾客提供这种饮料(如果这种饮料还有存货的话)或者让顾客选择退钱。该场景的前置条件是顾客感到口渴，后置条件是顾客得到一罐饮料或者顾客投入的钱被退回。 接着来看看“付款数不正确”这个场景。顾客按照通常的方式发起了这个用例，并进行一个选择。假设这时机器中备有选择的饮料。如果机器中刚好存有适合的零钱，那么机器就会退还零钱井交付饮料。如果机器中没有保存零钱，它将退还钱，并显示一条消息提示用户投入适当的零钱。前置条件和典型场景一样。后置条件是顾客得到一罐饮料和找回零钱或者按

5、原款归还钱。5.3.2 其它用例 我们已经从用户(即顾客)的观点考察了饮料自动销售机。除了这些用户外当然还有其他人加入。供货人负责为自动销售机提供饮料，收款人负责定期收集销售机中的钱。这说明至少还需要建立两个用例：“供货”和“取钱”，这些用例的细节可以通过与供货人和收款人交谈来获得。 考虑“供货”用例。供货者发起这个用例是由于某个时间间隔到期所引起的。供货代表打开销售机(很可能是要打开销售机的锁，但该问题涉及到了具体的系统实现)，拉出销售机前面的架子，在架子上补满各种品牌的饮料。销售代表还要在机器中加零钱，然后他放好销售机的前端架子，并锁好机器。这个用例的前置条件是一个时间间隔的流逝，后置条件是供货者在机器中放置了新的待售饮料。 还有一个“取钱”用例，同样也是因为一段时间间隔的流逝，收款人发起了这个用例。他的前期工作步骤与“供货”一样，也是打开销售机取出销售机前端架子。收款人从机器中取出钱，然后按照“供货”步骤，放回架子锁好机器。这个用例的前置条件也是时间间隔的流通，后置条件是收款人收到了钱。 注意，当导出一个用例时，不必关心怎么实现它。在这个例子里，我们并没有关心饮料销售机的内部细节

6、。我们也不关心机器内的制冷机制是如何工作的，或者钱在机器中是怎么被保存的。我们只是试图查明饮料销售机对使用它的用户来说是什么样子。 最终的目标是要导出一组用例供饮料销售机的设计者和制造者查看。5.4 包含用例 在“供货”和“收款”用例中，也许你会注意一些相同的步骤。两个用例都以打开机器为起始点，以关闭和锁好机器为终止点。能不能消除用例中的重复步骤呢? 可以。方法是从各个步骤序列中抽取出公共步骤形成一个每个用例都要使用的附加用例。可以将“开机”和“拉出饮料架”这两个步骤合并为一个叫做“打开销售机”的用例，将“放回架子”和“锁机器”合并为一个叫做“关闭销售机”的用例。 如上所述，“供货”和“收款”这两个用例都包含了新的用例。这种用例的重用技术被称作包含用例(include a use case)。5.5 扩展用例 除了包含用例这种方式外还有另一种重用用例的方式。有时我们可以通过对已有用例增加一些额外的步骤来建立新的用例。 以“供货”这个用例来说明。在给机器补充新饮料时，供货代表注意到有些品牌的饮料销售的好，有些品牌的饮料销售的不好。在这种情况下，他不是简单的把所有品牌的饮料补充给机器，而是

7、把一些销售情况不太好的饮料取出来，用销售情况好的饮料来代替它们。同时供货代表还要在机器前修改饮料品种的指示牌。 如果我们把上述步骤加入“供货”用例，我们将得到一个新的用例不妨称它为“根据销售情况供货”。这个新用例是对原用例的扩展，这种技术叫做扩展用例(extend a use case)。5.6 开始用例分析 在我们所举的例子中，我们直接跳到用例并集中讨论了几个用例。实际情况并非如此，在进行用例分析之前必须遵循一套规程。 首先从与客户交谈(还要和专家交谈)开始，这样可以分析得出系统的初步类图，这在前面已经有所介绍。这个过程可以让你对系统有个概念性认识并逐步效悉将要使用的术该，可以为你与用户进一步交流打下基础。 与用户(最好是一组用户)交谈时，你要向他们询问他们淮备如何使用系统的所有事情，为你的设计做淮备。根据他们的回答就能得到一组候选用例。下一步，也是很重要的一步，是要简洁准确的描述出这些用例。你还要导出一个参与者列表，这些参与者或者发起了候选用例或者从候选用例中获益。随着这个过程的深入，你会逐渐增强与用户用他们的语言交流的能力。在开发过程中会不断发现新的用例。它们有助于设计系统的用户

8、界面，还能帮助开发者做出编程中的决策，并且用例也是对新构造出的系统进行测试的基础。5.7 小结 用例是用来描述潜在的用户所看到的系统的UML组件。它是一个被称作参与者(可以是个人、个硬件设备、一段时间的流逝或者另一个系统)的实体所发起的场景的集合，用例的执行必须对发起该用例的参与者或者其他参与者产生影响。 用例可以被重用。一种方式(“包含”)是将一个用例中的步骤作为另一个用例的步骤序列的一部分。另一种方式(“扩展”)是通过对现有的用例增加新的步骤来创建新的用例。 与用户会谈是导出用例的最好技术。当导出一个用例时，要注意到发起用例的前置条件和产生影响的后置条件是很重要的。 在和用户会谈之前要先与客户会谈，产生一个候选类的列表。候选类中的基本术语是与用户进行交流的基础。和一组用户会谈是一个好的做法。这种会谈的目标是导出候选用例和可能的参与者列表。 为什么一定要使用用例这个概念呢?询问用户究竟他们想看到一个什么样的系统，然后把他们的描述记录下来，这样做难道不可以吗? 这样做在实际中往往行不通。对于用户的描述，我们必须把这些描述用一种结构组织起来，用例就提供这种组织结构。在记录与用户交谈的结果

9、以及将这些结果用来与客户及开发者交流的时候，这种结构使用起来很方便。 获取用例的难度有多大呢?列举出系统的用例(至少是高层用例)一点也不困难。但在深入研究每个用例并让用户列出每个场景中的步骤时，就会遇到一些困难。当你构造一个系统来代替现有的工作方式时，用户往往对新的步骤很明确，但是经常表达不清楚这些工作步骤。和一组用户而不是一个用户交流是个好主意，因为用户之间的讨论通常能说清楚一个用户难以表达清楚的问题。 怎样获取用例活动者希望系统执行什么任务？活动者在系统中访问哪些信息（创建、存储、修改、删除等）？需要将外界的哪些信息提供给系统？需要将系统的哪个事件告诉活动者？如何维护系统？ 识别参与者的方法 识别参与者的思路，可以从以下几个方面来考虑：（1）谁使用系统的主要功能？（2）谁改变系统的数据？（3）谁从系统获取信息？（4）谁需要系统的支持以完成日常工作任务？（5）谁负责维护、管理并保持系统正常运行？（6）系统需要处理哪些硬设备？（7）系统需要和哪些外部系统交互？（8）谁对系统运行产生的结果感兴趣？（9）有无时间、气温等内部或外部条件？ 6 用例图用例模型的目的用例之间的可视化表示理解用例

10、图在开发过程中的任务建立和运用用例模型定义用例图 用例视图(Use Cases View)从外部用户的角度来描述系统的行为，它将系统功能划分为对用户有意义的事务，这些事务被称为用例，用户被称为执行者，用例视图也就是描述活动者在各个用例中的参与情况，它指导所有的行为视图。 用例图说明的是谁要使用系统以及它们使用该系统可以做些什么用例图和用例的不同 用例简单的描述了用户要求系统所具备的动作. 用例图把用户,用例以及这两者包含在一个系统中,或者一个或多个子系统中用例图中的组件 用例图中包含4个基本组件 系统:是为用户执行某类功能的一个或多个软件构件 参与者:表示使用系统的对象.参与者可以是个人或系统 用例:用例是用户期望系统具备的动作 关系:表示用例和用户的通信关系参与者用例系统关系6.1.1 回顾饮料销售机 让我们来运用前一节中的符号举例。回顾上一章中为饮料销售机开发的一组用例。在系统中有3个用例，分别是“Buy soda(买饮料)”、“Restock(供货)”和“Collect(收款)”。参与者有Customer(顾客)、Suppliers Representative(供货代表)和Co

《UML-2介绍用例》由会员u****w分享，可在线阅读，更多相关《UML-2介绍用例》请在金锄头文库上搜索。