第06章节UML用例图.pptVIP

* * 第六章 用例图 用例能够帮助分析员从用户的观点收集需求。本章主要学习如何可视化表达前一章中学习的用例概念。将学习下列内容： ● 用例模型的表示法。 ● 用例之间的可视化表示。 ● 理解用例图在开发过程中的任务。 ● 建立和运用用例模型。 可视化允许向用户显示用例，能提供更多的信息。实际生活中用户常常知道的比他们清楚表达出来的要多，用例能够帮助用户解决这个问题。另外，可视化的表达形式允许将用例图和其他种类的图结合起来。 6.1 用例模型的表示法 用例是由参与者发起的，参与者(也许是发起者，但不是必须的)能够从用例的执行中获得有价值的事物。用例模型的图形表示法很直观。用例用一个椭圆形表示，直立人形图标表示参与者。用例的发起参与者在用例图的左侧，接收参与者 在用例图的右侧。参与者的名字放在参与者图标的下方，用例的名字可以放在椭圆形里面也可以放在椭圆形下面。关联线连接参与者和用例，并且表示参与者与用例之间有通信关系。关联线是实线，和类之间的关联线类似。 用例分析的一个好处是它能展现出系统和外部世界之间的边界。参与者是典型地系统外部实体，而用例是典型地属于系统内部。系统的边界用一个矩形(里面写上系统的名字)来代表。系统的用例装入矩形之内。 6.1.1 回顾饮料销售机 在系统中有3个用例，分别是“Buy soda(买饮料)”、“Restock(供货)”和“Collect(收款)”。参与者有Customer (顾客)、Suppliers Representative(供货代表)和Collector (收款人)。下图显示了饮料销售机中的一个UML用例模型。 6.1.2 跟踪场景中的步骤 每个用例是一组场景的集合，而每个场景又是—个步骤序列。但这些步骤在图中并没有表现出来。通常也不用附加注释来说明这些用例。尽管UML并没有禁止不能任用注释来说明用例，但任何图的清晰性是很关键的。对每个用例都附加注释进行说明，则布图就很混乱。那么如何并在哪里记录和跟踪这些场景中的步骤呢? 用例图通常是供客户和开发组参考的设计文档的一部分。每个用例图都有其自身的页。每个用例中的 场景描述通常也至少占一页，在文档中要描述下列内容： ● 发起用例的参与者。 ● 用例的前置条件。 ● 场景中的步骤。 ● 场景完成后的后置条件。 ● 从用例中获益的参与者。 还可以列出场景的假设条件(例如，一次只能有一个顾客使用饮料销售机)和简短的句话的场景描述。 上一章“介绍用例”中还给出了用例“Buy soda”的一些可选的场景。在具体描述中，可以分别列出这些场景，或者把它们作为用例基本场景的扩展来考虑。具体怎么做需要根据客户、用户和你对问题的理解。 要说明一个场景中的步骤，还可以使用UML活动图对场景进行描述(这部分内容将在 “活动图”一章中讨论)。 上一章中的例于还说明用例之间可以两种方式相互关联。一种方式是包含(including)，即在一个用例中重用另一个用例中的步骤。另一种方式叫扩展(extending)，允许对已有用例增加步骤创建一个新的用例。 用例之间的另外两种关系是泛化和分组。和类一样，泛化(generalization)是指一个用例继承了另一个用例。分组(grouping)是一组用例的简单组织方式。 6.2 用例之间的可视化表示 6.2.1 包含 上一章中的“Restock”和“Collect”用例都从开锁和拉开销售机的门开始，都以关门和上锁结束。第1步建立了“Expose the inside(打开销售机)”用例，并且第2步创建了“Unexpose the inside (关闭销售机)”用例。“Restock”和“Collect”两者都包含了这两个新用例。 要表达用例的包含关系，可以使用类之间依赖关系的表示符号——连接两个类之间的虚线，箭头指向被依赖的类。在线上要加一个构造型——用双尖括号扩起来的“include”。下图说明了饮料自动销售机用例模型中包含的关系。 带有包含关系饮料自动销售机模型 记住，被包含的用例不能自己独立存在，只能作为包含它的用例的一部分。 6.2.2 扩展 上一章中曾指出“Restock”用例是另一个用例“Restock according to sales(根据销售情况供货)”的基础。新用例扩展了原来的用例，因为它在原用