《体系结构第5章.ppt》由会员分享，可在线阅读，更多相关《体系结构第5章.ppt（23页珍藏版）》请在taowenge.com淘文阁网|工程机械CAD图纸|机械工程制图|CAD装配图下载|SolidWorks_CaTia_CAD_UG_PROE_设计图分享下载上搜索。
1、第五章 介绍用例 目前已经学习了类和类之间的关系，现在要将注意力转移到UML建模中的又一重要领域用例。本章主要讨论下列主题：什么是用例。建立用例。包含用例。扩展用例。开始用例分析。前面所介绍的图主要涉及的是系统中类的静态视图。我们最终要建立的是能够展示系统和系统中的类如何随时间变化的动态视图。静态视图有助于分析员和客户交流。动态视图，你以后将会看到，它有助于系统分析员与开发小组交流，并且能帮助开发组编制程序。客户和开发组是系统风险承担入的重要组成部分。然而不应该遗漏另一个同样重要的组成部分用户。不论是静态视图还是动态视图都不能从用户的观点说明系统所具有的行为。理解用户的观点对建立有用的并且易用
2、的系统是十分关键的也就是说，这样的系统能够满足用户需求并且容易使用。从用户的观点出发对系统建立模型是用例要完成的任务。在这一章中，你将学习到什么是用例以及用例能做些什么。下一章将学习如何使用UML用例图来可视化表示用例。5.1 什么是用例 假想你要买一台传真机，当你在办公用品商店选购传真机时，面临着很多选择。如何选购才能使自己最有利呢?你必须不断反问你自己一些问题。究竟我买传真机是要干什么用?我需要传真机具有哪些特征?这台传真机必须具有哪些功能?是不是需要它具有复印功能?是否连接到我的计算机?用传真机是否像用扫描仪一样?我是不是要尽量快地发传真而需要快速拨号功能?它需不需要具有区分外来传真信号
3、和外来电话信号的功能?当我们慎重的购物时，我们都有过这样的经历。这种经历就是某种形式的用例分析(use case analysis)：我们反问自己究竟将如何使用产品或系统。了解这些需求是非常重要的。这个过程在系统开发的分析阶段尤为重要。用户对系统的使用方式决定了系统如何设计和构造。用例是能够帮助分析员和用户确定系统使用情况的UML组件。一组用例就是从用户的角度出发对如何使用系统的描述。可以认为用例是系统的一组使用场景。每个场景描述了一个事件的序列。每个序列是由一个人、另一个系统、一个硬件设备或者某段时间的流逝所发起。这些发起事件序列的实体叫做参与者(actor)。事件序列的结果是由发起这个序列
4、的参与者或者另一个参与者对系统某种形式的使用所引起的。5.2 用例的重要性 正如类图可以以一种好的促进客户以他的观点考察系统的方法一样，用例是一个能促进系统可能的用户以他们自己的观点看待系统的优秀工具。用户并不总是容易清晰的阐明到底他要怎样使用系统。因为传统的系统开发常常是一种缺少前端分析的开发过程，因此当问及用户如何执行系统输入时，他往往不能理解。避免这种情况的基本思路是让用户参与前期的系统分析与设计。这样做可以使最终的系统尽可能地为用户可用而不仅仅是表现出了设计者的聪明才智而让用户无法理解和使用的一堆计算概念和业务模型。5.3 举例：饮料自动销售机 假设你现在正着手设计一台饮料自动销售机。
5、为了获得用户的使用观点，你会见了许多可能的用户以了解这些用户将如何与这台机器交互。饮料自动销售机的主要功能是允许个顾客能够购买罐饮料，很可能用户立刻就能告诉你一些有关的场景(换句话说就是用例)。你可以给这组场景加上一个标签“买饮料”。下面让我们来考察这个用例中每一种可能的场景。记住，在正常的系统开发中，在与用户交谈的过程中就能发现这些场景。5.3.1 用例“买饮料”这个用例的参与者是买饮料的顾客。顾客将钱插入销售机触发了这个用例的场景被执行。然后他进行选择。如果一切顺利，销售机内还储存有至少一罐被选择的饮料，则销售机会自动弹出一罐这种饮料给顾客。除了上面的步骤序列，该场景的其他方面也值得考虑。
6、顾客发起“买饮料”这个用例的执行场景需要什么前置条件?最直观的前置条件之一是顾客感到口渴。场景的执行步骤完成后需要什么后置条件?显然最直观的后置条件是顾客有了一罐饮料。上面的“买饮料”场景是唯一可描述的场景吗?显然我们立即会想到还有其他的场景。顾客所要购买的饮料销售机中可能没有；顾客投入的钱数不刚好等于购买饮料所需要的钱。应该如何设计饮料销售机来处理这些场景呢?先看看没有所需的饮料这个场景，它是用例“买饮料”的另一个场景。可以把这个场景看成是用例执行时的一条可选路径。用例是由顾客在销售机中插入钱币所发起的。然后他进行一个选择，销售机中至少要有一罐选择的饮料，如果没有，销售机就给顾客提示一个信息
7、，告诉顾客没有这种品牌的饮料。理想情况下，顾客看到这条消息后台立即选择其他品牌的饮料。销售机必须提供给顾客取回原来的钱的选项。这表示，销售机应给顾客两种选择：让顾客选择另一种饮料并且给顾客提供这种饮料(如果这种饮料还有存货的话)或者让顾客选择退钱。该场景的前置条件是顾客感到口渴，后置条件是顾客得到一罐饮料或者顾客投入的钱被退回。接着来看看“付款数不正确”这个场景。顾客按照通常的方式发起了这个用例，并进行一个选择。假设这时机器中备有选择的饮料。如果机器中刚好存有适合的零钱，那么机器就会退还零钱井交付饮料。如果机器中没有保存零钱，它将退还钱，并显示一条消息提示用户投入适当的零钱。前置条件和典型场景
8、一样。后置条件是顾客得到一罐饮料和找回零钱或者按原款归还钱。5.3.2 其它用例 我们已经从用户(即顾客)的观点考察了饮料自动销售机。除了这些用户外当然还有其他人加入。供货人负责为自动销售机提供饮料，收款人负责定期收集销售机中的钱。这说明至少还需要建立两个用例：“供货”和“取钱”，这些用例的细节可以通过与供货人和收款人交谈来获得。考虑“供货”用例。供货者发起这个用例是由于某个时间间隔到期所引起的。供货代表打开销售机(很可能是要打开销售机的锁，但该问题涉及到了具体的系统实现)，拉出销售机前面的架子，在架子上补满各种品牌的饮料。销售代表还要在机器中加零钱，然后他放好销售机的前端架子，并锁好机器。这
9、个用例的前置条件是一个时间间隔的流逝，后置条件是供货者在机器中放置了新的待售饮料。还有一个“取钱”用例，同样也是因为一段时间间隔的流逝，收款人发起了这个用例。他的前期工作步骤与“供货”一样，也是打开销售机取出销售机前端架子。收款人从机器中取出钱，然后按照“供货”步骤，放回架子锁好机器。这个用例的前置条件也是时间间隔的流通，后置条件是收款人收到了钱。注意，当导出一个用例时，不必关心怎么实现它。在这个例子里，我们并没有关心饮料销售机的内部细节。我们也不关心机器内的制冷机制是如何工作的，或者钱在机器中是怎么被保存的。我们只是试图查明饮料销售机对使用它的用户来说是什么样子。最终的目标是要导出一组用例供
10、饮料销售机的设计者和制造者查看。5.4 包含用例 在“供货”和“收款”用例中，也许你会注意一些相同的步骤。两个用例都以打开机器为起始点，以关闭和锁好机器为终止点。能不能消除用例中的重复步骤呢?可以。方法是从各个步骤序列中抽取出公共步骤形成一个每个用例都要使用的附加用例。可以将“开机”和“拉出饮料架”这两个步骤合并为一个叫做“打开销售机”的用例，将“放回架子”和“锁机器”合并为一个叫做“关闭销售机”的用例。如上所述，“供货”和“收款”这两个用例都包含了新的用例。这种用例的重用技术被称作包含用例(include a use case)。5.5 扩展用例 除了包含用例这种方式外还有另一种重用用例的方
11、式。有时我们可以通过对已有用例增加一些额外的步骤来建立新的用例。以“供货”这个用例来说明。在给机器补充新饮料时，供货代表注意到有些品牌的饮料销售的好，有些品牌的饮料销售的不好。在这种情况下，他不是简单的把所有品牌的饮料补充给机器，而是把一些销售情况不太好的饮料取出来，用销售情况好的饮料来代替它们。同时供货代表还要在机器前修改饮料品种的指示牌。如果我们把上述步骤加入“供货”用例，我们将得到一个新的用例不妨称它为“根据销售情况供货”。这个新用例是对原用例的扩展，这种技术叫做扩展用例(extend a use case)。5.6 开始用例分析 在我们所举的例子中，我们直接跳到用例并集中讨论了几个用例
12、。实际情况并非如此，在进行用例分析之前必须遵循一套规程。首先从与客户交谈(还要和专家交谈)开始，这样可以分析得出系统的初步类图，这在前面已经有所介绍。这个过程可以让你对系统有个概念性认识并逐步效悉将要使用的术该，可以为你与用户进一步交流打下基础。与用户(最好是一组用户)交谈时，你要向他们询问他们淮备如何使用系统的所有事情，为你的设计做淮备。根据他们的回答就能得到一组候选用例。下一步，也是很重要的一步，是要简洁准确的描述出这些用例。你还要导出一个参与者列表，这些参与者或者发起了候选用例或者从候选用例中获益。随着这个过程的深入，你会逐渐增强与用户用他们的语言交流的能力。在开发过程中会不断发现新的用
13、例。它们有助于设计系统的用户界面，还能帮助开发者做出编程中的决策，并且用例也是对新构造出的系统进行测试的基础。5.7 小结 用例是用来描述潜在的用户所看到的系统的UML组件。它是一个被称作参与者(可以是个人、个硬件设备、一段时间的流逝或者另一个系统)的实体所发起的场景的集合，用例的执行必须对发起该用例的参与者或者其他参与者产生影响。用例可以被重用。一种方式(“包含”)是将一个用例中的步骤作为另一个用例的步骤序列的一部分。另一种方式(“扩展”)是通过对现有的用例增加新的步骤来创建新的用例。与用户会谈是导出用例的最好技术。当导出一个用例时，要注意到发起用例的前置条件和产生影响的后置条件是很重要的。
14、在和用户会谈之前要先与客户会谈，产生一个候选类的列表。候选类中的基本术语是与用户进行交流的基础。和一组用户会谈是一个好的做法。这种会谈的目标是导出候选用例和可能的参与者列表。为什么一定要使用用例这个概念呢?询问用户究竟他们想看到一个什么样的系统，然后把他们的描述记录下来，这样做难道不可以吗?这样做在实际中往往行不通。对于用户的描述，我们必须把这些描述用一种结构组织起来，用例就提供这种组织结构。在记录与用户交谈的结果以及将这些结果用来与客户及开发者交流的时候，这种结构使用起来很方便。获取用例的难度有多大呢?列举出系统的用例(至少是高层用例)一点也不困难。但在深入研究每个用例并让用户列出每个场景中的步骤时，就会遇到一些困难。当你构造一个系统来代替现有的工作方式时，用户往往对新的步骤很明确，但是经常表达不清楚这些工作步骤。和一组用户而不是一个用户交流是个好主意，因为用户之间的讨论通常能说清楚一个用户难以表达清楚的问题。