《第06章UML用例图.ppt》由会员分享，可在线阅读，更多相关《第06章UML用例图.ppt（37页珍藏版）》请在三一文库上搜索。
1、第六章 用例图,用例能够帮助分析员从用户的观点收集需求。本章主要学习如何可视化表达前一章中学习的用例概念。将学习下列内容： 用例模型的表示法。 用例之间的可视化表示。 理解用例图在开发过程中的任务。 建立和运用用例模型。,可视化允许向用户显示用例，能提供更多的信息。实际生活中用户常常知道的比他们清楚表达出来的要多，用例能够帮助用户解决这个问题。另外，可视化的表达形式允许将用例图和其他种类的图结合起来。,6.1 用例模型的表示法,用例是由参与者发起的，参与者(也许是发起者，但不是必须的)能够从用例的执行中获得有价值的事物。用例模型的图形表示法很直观。用例用一个椭圆形表示，直立人形图标表示参与者。
2、用例的发起参与者在用例图的左侧，接收参与者,在用例图的右侧。参与者的名字放在参与者图标的下方，用例的名字可以放在椭圆形里面也可以放在椭圆形下面。关联线连接参与者和用例，并且表示参与者与用例之间有通信关系。关联线是实线，和类之间的关联线类似。 用例分析的一个好处是它能展现出系统和外部世界之间的边界。参与者是典型地系统外部实体，而用例是典型地属于系统内部。系统的边界用一个矩形(里面写上系统的名字)来代表。系统的用例装入矩形之内。,6.1.1 回顾饮料销售机 在系统中有3个用例，分别是“Buy soda(买饮料)”、“Restock(供货)”和“Collect(收款)”。参与者有Customer (
3、顾客)、Suppliers Representative(供货代表)和Collector (收款人)。下图显示了饮料销售机中的一个UML用例模型。,6.1.2 跟踪场景中的步骤 每个用例是一组场景的集合，而每个场景又是个步骤序列。但这些步骤在图中并没有表现出来。通常也不用附加注释来说明这些用例。尽管UML并没有禁止不能任用注释来说明用例，但任何图的清晰性是很关键的。对每个用例都附加注释进行说明，则布图就很混乱。那么如何并在哪里记录和跟踪这些场景中的步骤呢? 用例图通常是供客户和开发组参考的设计文档的一部分。每个用例图都有其自身的页。每个用例中的,场景描述通常也至少占一页，在文档中要描述下列内容
4、： 发起用例的参与者。 用例的前置条件。 场景中的步骤。 场景完成后的后置条件。 从用例中获益的参与者。 还可以列出场景的假设条件(例如，一次只能有一个顾客使用饮料销售机)和简短的句话的场景描述。,上一章“介绍用例”中还给出了用例“Buy soda”的一些可选的场景。在具体描述中，可以分别列出这些场景，或者把它们作为用例基本场景的扩展来考虑。具体怎么做需要根据客户、用户和你对问题的理解。 要说明一个场景中的步骤，还可以使用UML活动图对场景进行描述(这部分内容将在 “活动图”一章中讨论)。,上一章中的例于还说明用例之间可以两种方式相互关联。一种方式是包含(including)，即在一个用例中重
5、用另一个用例中的步骤。另一种方式叫扩展(extending)，允许对已有用例增加步骤创建一个新的用例。 用例之间的另外两种关系是泛化和分组。和类一样，泛化(generalization)是指一个用例继承了另一个用例。分组(grouping)是一组用例的简单组织方式。,6.2 用例之间的可视化表示,6.2.1 包含 上一章中的“Restock”和“Collect”用例都从开锁和拉开销售机的门开始，都以关门和上锁结束。第1步建立了“Expose the inside(打开销售机)”用例，并且第2步创建了“Unexpose the inside (关闭销售机)”用例。“Restock”和“Colle
6、ct”两者都包含了这两个新用例。 要表达用例的包含关系，可以使用类之间依赖关系的表示符号连接两个类之间的虚线，箭头指向被依赖的类。在线上要加一个构造型用双尖括号扩起来的“include”。下图说明了饮料自动销售机用例模型中包含的关系。,带有包含关系饮料自动销售机模型,记住，被包含的用例不能自己独立存在，只能作为包含它的用例的一部分。 6.2.2 扩展 上一章中曾指出“Restock”用例是另一个用例“Restock according to sales(根据销售情况供货)”的基础。新用例扩展了原来的用例，因为它在原用例的基础上增加了新的步骤序列，因此原用例被称作基用例(base use cas
7、e)。 扩展只能发生在基用例的序列中某个具体指定点上。这个点叫做扩展点(extension points)。在“Restock”用例中，新步骤发生在供货代表打开机器,准备向机器中补充饮料时。因此在这个例子中，扩展点是“before filling the compartments(补充饮料)”。 与包含关系相似，扩展关系的可视化表达也是用一条依赖线(带箭头的虚线)，线上加一个用双尖括号括起来的“extend”构造型。在基用例中，扩展点出现在用例名的下方。下图示意了“Restock”和“Restock according to sales”用例之间的扩展关系表示法以及“Restock”和“Col
8、lect”之间的包含关系表示法。,Extension Point before filling the compartments,6.2.3 泛化 类可以继承另个类，用例也是如此。在用例继承中，子用例可以从父用例继承行为和含义，还可以增加自己的行为。任何父用例出现的地方子用例也可以出现。 在饮料销售机的例子中，可以想象一个叫做“Buy a cup of soda(买一杯饮料)”的用例。这个用例是从另一个用例“Buy soda”继承而来。在子用例中增加了一些行为，诸如“加冰”、“混合饮料的品牌”。用例之间的泛化关系建模与类之间泛化关系建模方法相同用一条带空心三角形箭头的实线从子用例指向父用例。,
9、参与者之间也像用例一样可能存在泛化关系。供货代表及收款人都可能是供应代理(Suppliers Agent)。如果将供货代表重新命名为Restocker，那么Restocker和Collector(收款人)都是Suppliers Agent的子类。,7.2.4 分组 在一些用例图中，用例的数目可能非常多，这时就需要组织这些用例。这种情况在一个系统包含很多个子系统时就会出现。另一种可能是，当你按顺序和用户会谈，收集系统需求时，每个需求必须用一个单独的用例来表达。这时就需要某种方式来分类这些需求。 最直接的方法是把相关的用例放在一个包中组织起来。一组用例可以出现在一个包中。,6.3 用例图在开发过程
10、中的作用,前面给出用例的表示法。现在回过头看看在开发过程背景中的用例。 开发过程从与客户会谈开始。这些会谈可以产生初步类图，它可作为理解系统领域(也就是要解决的问题的范围)知识的基础。在了解了客户领域的一般术语后，就可以开始准备与用户交谈了。 与用户会谈开始时谈论领域术语，但是要马上转到用户的术语。会谈的初步成果是能够发现一些参与者以及高层用例，这些高层用例概括地描述了,系统的功能需求。这些信息提供了系统边界和范围。 后期与用户的交谈将涉及深层次的需求，产生的成果是详细描述了场景和序列的用例模型。这个结果中还可能发现一些附加的用例，这些用例满足包含和扩展关系。在这个阶段，对问题领域(也就是通过
11、与客户的会谈导出的系统类图)的理解是十分重要的。如果对领域理解不够，那么就可能创建出太多的用例或者太多的用例细节这种情况可能会非常妨碍后期的设计和开发工作。,6.4 运用用例模型：举例,看一个比饮料自动销售机更为复杂的例子。假设你要为一个咨询公司设计一个本地的局域网，那么你首先要估算出这个局域网所具有的功能。怎么开始这项工作呢? 6.4.1 理解领域 首先从与客户的会谈开始，建立一个能够反映咨询公司日常业务的类图。这个类图中可能包括下列类：Consultant(顾问)、Client(客户)、Project(项目)、Proposal(提案)、Data(数据)和Report(报告)。如下图,所示。
12、,6.4.2 理解用户 在掌握业务的领域模型后，下面就将注意力转向用户，因为目标是要使系统具有用户要求那些功能。 在实际中你要和用户面谈，但为了举例方便，这里只根据你对LAN和该业务领域的一般知识进行系统分析，但不管怎样都要记住，在实际的系统分析中，没有什么事情能够替代实际的与人面谈。一组用户可能是顾问(Consultant)，另一组可能是办事员(Clerical Staff)，其他可能的用户包括联合办公人员(corporate Officer)、市场销售员(Marketer)、网络管理员,(Network Administrator)、办公室经理(Office Manager)以及项目经理(
13、Project Manager)。 在这一点上，一个有用的做法是显示出用户之间的泛化层次。,6.4.3 理解用例 这个系统有哪些用例呢?可能会有这些用例：“Provide security levels(提供安全层次)”、“Create a proposal (创建一个提案)”、“Store a proposal(保存一个提案)”、“Use E-mail(使用电子邮件)”、“Perform accounting (清算帐目)”、“Connect to the LAN from outside the LAN(从外部连接到本地局域网)”、“Connect to the Internet(连接到互
14、联网)”、“Share database information(共享数据库信息)”、“Catalog proposals(分类提案)”、“Use prior proposals(使用优先提案)”以及“Share printer(共享打印)”。下图显示了,基于这些信息的高层用例图。这些用例就构成了该局域网系统的功能需求。,6.4.4 进一步深入 详细阐述这些高层用例中的一个，并建立一个用例模型。咨询公司中最重要的一项活动是书写提案。因此检验一下“Create a proposal”这个用例。 与某个顾问面谈，他就能告诉你这个用例中的许多步骤。首先，用例的发起者是一个顾问。顾问要登录到局域网，并
15、作为一个有效用户被验证。然后他使用办公软件套件(包括文字处理软件包、电子表格软件包以及绘图软件包等)来书写提案。在这个过程中，顾问可能要重用一部分以前的提案。咨询公司的,政策要求在一个提案交给客户之前，必须通过一个联合办公人员和两个其他顾问的复审。 为了满足这项政策，顾问要将提案存储在一个中央信息仓库中。可以通过局域网访问这个信息仓库，顾问还要给三个复审者发电子邮件，通知它们提案已经准备好了，并告诉他们提案的存放地点。在收到一些反馈信息并做必要的修改后(还要使用办公软件套件)，顾问将提案打印出来并邮递给客户一份。当所有这些工作完成后，顾问退出局域网系统。这样顾问就完成了一个提案，并且参与者将从
16、这个用例中受益。,在一次面谈中谈到诸如“三个复审者”的政策时，要特别注意做记录。这意味着你正在听的是关于这个公司的业务逻辑公司自身运作的一组规则。一个好的系统分析员能找出很多的业务逻缉。越能够理解客户所在公司的企业文化，就能够更好地理解这个组织的需求。 根据上面描述的顺序，可以清楚地看出某些步骤从一个用例重复到另一个用例这就引出了其他一些前面没有想到过的(可能是被包含的)用例。登录和用户身份验证是许多用例都要包括的两个步骤。因为这个原因，可以新建一个“Verify user(验证用户)”,用例。用例“Create a proposal”包含它。另外两个被包含的用例是“Use office su
17、ite software(使用办公软件套件)”和“Log off the network(退出网络系统)”。 此外，还要考虑到写给新客户的提案与写给现有客户的提案不完全相同。实际上，给新客户的提案中往往还要提供公司的附加信息，而给现有客户的提案中就没必要加进这些信息了，因此，另一个新用例“Create a proposal for a new client”扩展了用例“Create a Proposal”。 下图显示了对用例“Create a proposal”进行上述分析后得到的用例图。,这个例子还说明了一个重要观点：用例分析只是对系统行为的描述，它并不涉及系统的实施。例如局域网的设计问题没
18、有讨论。,6.5 回顾和归纳,现在看看UML的整体结构，因为前面已经学习了UML中的两个重要方面面向对象和用例分析。已经学习了它们的基本概念和表示法，还探讨了一些应用。,6.5.1 结构元素 类、对象、参与者、接口和用例是UML中的5种结构元素。尽管它们之间具有很多差别，但它们都是表达一个模型的物理部件或者概念部件，在这一点上它们是相同的。以后还将遇到其他一些结构元素。 6.5.2 关系 关联、泛化、依赖、聚集、组成和实现是UML中的关系元素(包含和扩展也是依赖)。离开了关系，UML模型图就成了一堆结构元素的杂乱列表。关系连接了这些元素，因此使模型更贴近现实。,6.5.3 分组 包是UML中的唯一分组元素。它允许你将一个模型中的结构元素组织起来。包可以容纳任何种类的结构元素，而且一次可容纳多种结构元素。 6.5.4 注释 注释是UML的解释元素。约束、注解、需求和用来解释说明的图形都可以作为注释被附加到模型当中。 6.5.5 扩展 构造型和约束是UML提供扩展机制的两个组件。,它们允许根据已有元素来创建新的元素，以便更精确方便地对现实世界建立模型。 6.5.6 其它 除了结构元素、关系、分组、注释和扩展以外，UML还有另外一类元素行为元素。这些元素表达模型的某个部分如何随时间经历变化。现在你还没有学到这些元素，但在以后将学习几种行为元素。,