第05章介绍用例.ppt

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