第二讲用例图.pptVIP

第二讲 用例图 1.用例图概述 2.系统 3.参与者 4.用例 5.实例－图书管管理系统中的用例图 1.用例图概述 用例图是把应满足用户需求的基本功能聚合起来表示的强大工具。构建用例图是通过开发者与客户（或最终使用者）共同协商完成的，他们要反复讨论需求的规格说明，达成共识，明确系统的基本功能，为以后阶段的工作打下基础。 在用例图中，系统仿佛是实现各种用例的“黑盒子”，我们只关心该系统实现了哪些功能，并不关心内部的具体实现细节。用例图主要应用在工程开发的初期，进行系统需求分析时使用。通过分析描述使开发者在头脑中明确需要开发的系统功能有哪些。 引入用例的主要目的是： 用例图中显示参与者、用例和用例之间的关系。用例图可以包含注释和约束，还可以包含包，用于将模型中的元素组成更大的模块。 用例图如下图所示，参与者用人形图标表示，用例用椭圆符号表示，连线表示它们之间的关系。 在参与者和用例之间存在的关联关系通常被称为通信关联，因为它代表着参与者和用例之间的通信。关联可以是双向导航（从参与者到用例，并从用例到参与者）或单向导航（从参与者到用例，或从用例到参与者）。导航的方向表明了是参与者发起了和用例的通信还是用例发起了和参与者的通信。 2.系统 系统是用例图的一个组成部分，代表的是一部机器或一个商务活动等等，而并不是真正实现的软件系统。系统的边界用来说明构建的用例图的应用范围。 比如，一台自助式售货机(被看作系统)应提供售货、供货、提取销售款等功能，这些功能在自动售货机之内的区域起作用，自动售货机之外的情况不考虑。 3.参与者 （1）参与者的概念 参与者代表与系统交互的任何事物或人，它是指代表某一种特定功能的角色，因此参与者是虚拟的概念，它可以是人，也可以是外部系统或设备。 参与者有三大类：系统用户、与所建造的系统交互的其他系统和一些可以运行的进程。 （2）确定参与者 在获取用例前首先要确定系统的参与者，我们可以通过回答以下的问题来寻找系统的参与者： 在对参与者建模的过程中，应该注意以下几点： 参与者对于系统而言总是外部的，因此它们可以处于人的控制之外。 参与者可以直接或间接地同系统交互，或使用系统提供的服务以完成某件事务。 参与者表示人和事物与系统发生交互时所扮演的角色，而不是特定的人或者特定的事物。 一个人或事物在与系统发生交互时，可以同时或不同时扮演多个角色。 每个参与者需要一个具有业务一样的名字，在建模中不推荐使用类似于“新参与者”的名字。 （3）参与者间的关系 因为参与者是类，所以多个参与者之间可以具有与类之间相同的关系。在用例图中，使用类属关系来描述多个参与者之间的公共行为。 假设一个汽车租赁公司，接受客户的电话预定和网上预定。参与者“客户”描述了参与者“电话客户”和“网上客户”所扮演的一般角色。如果不考虑客户是如何与系统接触的，可以使用一般角色的参与者，即父类；如果强调接触发生的形式，那么用例必须使用实际的参与者，即子类。 4.用例 （1）用例的概念 用例是外部可见的系统功能单元，是对系统行为的动态描述，它可以促进设计人员、开发人员与用户的沟通，理解正确的需求；还可以划分系统与外部实体的界限，是系统设计的起点，是类、对象、操作的来源。 （2）识别用例 识别用例最好的方法就是从分析系统的参与者开始，考虑每个参与者是如何使用系统的。使用这种策略的过程中可能会发现新的参与者，这对完善整个系统的建模有很大的帮助。用例建模的过程就是一个迭代和逐步精化的过程，系统分析者首先从用例的名称开始，然后添加用例的细节信息。这些信息由简短的描述组成，它们被精华成完整的规格说明。 通过回答以下的几个问题识别用例： 特定参与者希望系统提供什么功能。 系统是否存储和检索信息，如果是，由哪个参与者触发。 当系统发生改变时，是否通知参与者。 是否存在影响系统的外部事件。 哪个参与者通知系统这些事件。 用例的粒度 不同的设计者设计的用例的粒度不同。在建立模型时，要注意选取适中的用例粒度，以避免用例数目过多或过少。确定用例的过程是对获取的用例进行提炼和归纳的过程。 （3）用例的描述 一个用例是用一个命名的椭圆来表示，但如果没有对这个用例的具体说明，那么还是不清楚该用例到底会完成什么功能。没有描述的用例就像是一本书的目录，我们只知道该目录的标题，但并不知道该目录的具体内容是什么。 对于每个用例，都可以用事件流来规定用例的行为。用例的事件流是对完成用例规定行为所需要的事件