体系结构椅子第5章.pptVIP

* * 第五章 介绍用例 目前已经学习了类和类之间的关系，现在要将注意力转移到UML建模中的又一重要领域——用例。本章主要讨论下列主题： ● 什么是用例。 ● 建立用例。 ● 包含用例。 ● 扩展用例。 ● 开始用例分析。 前面所介绍的图主要涉及的是系统中类的静态视图。我们最终要建立的是能够展示系统和系统中的类如何随时间变化的动态视图。静态视图有助于分析员和客户交流。动态视图，你以后将会看到，它有助于系统分析员与开发小组交流，并且能帮助开发组编制程序。 客户和开发组是系统风险承担入的重要组成部分。然而不应该遗漏另一个同样重要的组成部分——用户。不论是静态视图还是动态视图都不能从用户的观点说明系统所具有的行为。理解用户的观点对建立有用的 并且易用的系统是十分关键的——也就是说，这样的系统能够满足用户需求并且容易使用。 从用户的观点出发对系统建立模型是用例要完成的任务。在这一章中，你将学习到什么是用例以及用例能做些什么。下一章将学习如何使用UML用例图来可视化表示用例。 5.1 什么是用例 假想你要买一台传真机，当你在办公用品商店选购传真机时，面临着很多选择。如何选购才能使自己最有利呢?你必须不断反问你自己一些问题。究竟我买传真机是要干什么用?我需要传真机具有哪些特征?这台传真机必须具有哪些功能?是不是需要它具有复印功能?是否连接到我的计算机?用传真机是否像用扫描仪一样?我是不是要尽量快地发传真而需要快速拨号功能?它需不需要具有区分外来传真信号和外来电话信号的功能? 当我们慎重的购物时，我们都有过这样的经历。这种经历就是某种形式的用例分析(use case analysis)：我们反问自己究竟将如何使用产品或系统。了解这些需求是非常重要的。 这个过程在系统开发的分析阶段尤为重要。用户对系统的使用方式决定了系统如何设计和构造。 用例是能够帮助分析员和用户确定系统使用情况的UML组件。一组用例就是从用户的角度出发对如何使用系统的描述。 可以认为用例是系统的一组使用场景。每个场景描述了一个事件的序列。每个序列是由一个人、另一个系统、一个硬件设备或者某段时间的流逝所发起。这些发起事件序列的实体叫做参与者(actor)。事件序列的结果是由发起这个序列的参与者或者另一个参与者对系统某种形式的使用所引起的。 5.2 用例的重要性 正如类图可以以一种好的促进客户以他的观点考察系统的方法一样，用例是一个能促进系统可能的用户以他们自己的观点看待系统的优秀工具。用户并不 总是容易清晰的阐明到底他要怎样使用系统。因为传统的系统开发常常是一种缺少前端分析的开发过程，因此当问及用户如何执行系统输入时，他往往不能理解。 避免这种情况的基本思路是让用户参与前期的系统分析与设计。这样做可以使最终的系统尽可能地为用户可用——而不仅仅是表现出了设计者的聪明才智而让用户无法理解和使用的一堆计算概念和业务模型。 5.3 举例：饮料自动销售机 假设你现在正着手设计一台饮料自动销售机。为了获得用户的使用观点，你会见了许多可能的用户以了解这些用户将如何与这台机器交互。 饮料自动销售机的主要功能是允许—个顾客能够购买—罐饮料，很可能用户立刻就能告诉你一些有关的场景(换句话说就是用例)。你可以给这组场景加上一个标签“买饮料”。下面让我们来考察这个用例中每一种可能的场景。记住，在正常的系统开发中，在与用户交谈的过程中就能发现这些场景。 5.3.1 用例“买饮料” 这个用例的参与者是买饮料的顾客。顾客将钱插入销售机触发了这个用例的场景被执行。然后他进行选择。如果一切顺利，销售机内还储存有至少一罐被选择的饮料，则销售机会自动弹出一罐这种饮料给顾客。 除了上面的步骤序列，该场景的其他方面也值得考虑。顾客发起“买饮料”这个用例的执行场景需要什么前置条件?最直观的前置条件之一是顾客感到口渴。场景的执行步骤完成后需要什么后置条件?显然最直观的后置条件是顾客有了一罐饮料。 上面的“买饮料”场景是唯一可描述的场景吗?显然我们立即会想到还有其他的场景。顾客所要购买的饮料销售机中可能没有；顾客投入的钱数不刚好等于购买饮料所需要的钱。应该如何设计饮料销售机来处理这些场景呢? 先看看没有所需的饮料这个场景，它是用例“买饮料”的另一个场景。可以把这个场景看成是用例执行时的一条可选路径。用例是由顾客在销售机中插入钱币所发起的。然后