第2章用例图.ppt

1第2章 用例图 人们在进行软件开发时，无论是采用面向对象方法还是传统方法，首先要做的就是了解需求由于用例图是从用户角度来描述系统功能的，所以在进行需求分析时，使用用例图可以更好描述系统应具备什么功能用例图由开发人员与用户经过多次商讨而共同完成，软件建模的其他部分都是从用例图开始的这些图以每一个参与系统开发的人员都可以理解的方式列举系统的业务需求2本章学习要点： 用例图的组成 理解泛化 理解用例之间的关系 对用例进行描述 绘制用例图32.1 用例图的构成 如 前所言，用例图用于定义系统的功能需求，它描述了系统的参与者与系统提供的用例之间的连接关系这里的参与者可以人，也可以另一个系统用例图仅从参与者使用系统的角度描述系统中的信息图2-1描述了一个学生成绩管理系统的用例图，它是一个实际系统简化后的示例45UML中的用例图描述了一组用例、参与者以及它们之间的关系用例图包括以下3方面内容1）用例（Use Case）（2）参与者（Actor）（3）依赖、泛化以及关联关系672.1.1 系统 系统是用例图一个重要组成部分系统是用于执行某一项功能的，它不单指一个软件系统但就本书的目的而言，我们感兴趣的是计算机软件，系统是为用户执行某类功能的一个或多个软件构件。

系统的边界用来说明用例图应用的范围例如，一台自动售货机应提供售货、供货、提取消售款等功能，这引功能在自动售货机之内的区载起作用，自动售货机之外的情况则不考虑准确定义系统的边界并不总是很容易的，因为有些情况下，严格地划分哪些任务是由系统完成，而哪些是由人工或其他系统完成是很困难的 另外，系统最初的规模应有多大也应该考虑一般的作法是，先识别出系统的基本功能，然后以此为基础定义一个稳定的、精确定义的系统架构，以后再不断地扩充系统功能，逐步完善系统这样做可以避免由于系统太大，需求分析不易明确，从而导致辞浪费大量的开发时间82.1.2 参与者（Actor角色) 参与者是系统外的一个实体，参与者通过向系统输入或者系统要求参与者提供某种信息来进行交互在确定系统的用例时，首要问题就是识别参与者 参与者的概念 参与者用于表示使用系统的对象参与者可以是一个人、一个计算机系统、另一个子系统或另外一种对象例如，一个计算网络系统的参与者可以包括操作员、系统管理员、数据库管理员和普通的用户，也可以有非人类参与者，如网络打印机参与者的特征是其作为外部用户与系统发生交互在系统的实际运作中，一个实际用户可能对应系统的多个参与者。

同样，不同的多个用户也可以只对应于一个参与者，从而代表同一个参与者的不同实例9识别参与者 客户给销售员发来订货， 销售员下班前将当日订货单汇总输入系统 谁是系统的Actor？答案： 销售员 寻呼台系统用户如果预定了天气预报，系统每天定时给他发天气消息；如果当天气温高于35度，还要提醒用户注意防暑 这个叙述里，谁是寻呼台系统的Actor? 用户？气温？时间？答案：用户，气温，时间都是Actor识别参与者参与者使用以下问题有助于发现系统的参与者谁使用系统？谁安装系统、维护系统？谁启动系统、关闭系统？谁从系统中获取信息，谁提供信息给系统？在系统交互中，谁扮演了什么角色？系统会与哪些其他系统相关联？ 2.1.3 用例 用例是一组连续的操作，在用户使用系统来完成某个过程时出现，它是外部可见的系统功能单元通过将这些不同的功能单元进行组合，就构成了对系统总体需求的描述 1、用例的概念 用例是用户期望系统具备的功能，它定义了系统的行为特征，如果没有这些特征，系统就不能被成功地使用例如，程序开发人员使用开发系统来开发软件，则开发系统应具备编译功能以满足程序开发人员的需求13 用例的目标是要定义系统（包括一个子系统或整个系统）的一个行为，但并不显示系统的内部结构。

每个用例说明一个系统提供给它的使用者的一种服务，即一种对外部可见的使用系统的特定方式它以用户的观点描述用户和系统间交互的完整顺序，以及由系统执行的响应这里的交互只包括系统与参与者之间的通讯，而其内部行为和实现是隐藏的一个系统的全部用例分割和覆盖它的行为，每个用例代表一部分量化了的、有深刻意义的和对用户可用的功能性注意这里的用户包括人、计算机和其他对象14简单说： 用例是对一组序列动作的描述，系统执行这些动作将对用例的参与者产生可以观察的结果 参与者和用例分别描述了“谁来做？”和“做什么？”这两个问题 用例用实线的椭圆表示 识别用例的最好办法就是从分析系统的参与者开始，考虑每个参与者是怎样使用系统根据下面的一些问题来识别用例：参与者希望系统提供什么功能；系统是否存储和检索信息；当系统改变状态时，是否通知参与者；是否存在影响系统的外部事件，是哪个参与者通知系统这些外部事件 2、识别用例 Email客户端（如：outlook express），A在北京发邮件给深圳的B，系统提醒B”你有新邮件”，B收邮件 一个论坛类的应用，用户可以提问，别人来回答，如果有自己问题被解答的话，就给发问者发一份邮件通知。

注意：发邮件这个用例可以是单独的用例，也可以是由回答用例扩展出来的用例如何判断一个用例是否是一个优秀的用例呢？用例是否描述了应该做什么，而不是如何做？用例的描述是否采取了参与者的视点？用例是否对参与者有价值？用例描述的时间流是否是一个完整场景？是否所有的参与者、用例都有相应的关联用例或关联参与者？ 3、用例与事件流 用例描述的是参与者与系统之间的对话，但是这个对话的细节并没有在用例图中表述出来，针对每一个用例我们可以用事件流来描述这一对话的细节内容 事件流可分为：基本事件流 、备选事件流 银行自动取款机(ATM)系统中的“提款”用例可以用事件流表述如下： 提款基本事件流基本流步骤1：用户插入信用卡基本流步骤2：输入密码基本流步骤3：输入提款金额基本流步骤4：提取现金基本流步骤5：退出系统，取回信用卡提款备选事件流 备选流一：用户可以在基本流中的任何一步选择退出， 转至基本流步骤5 备选流二：在基本流步骤1中，用户插入无效信用卡，系统显示错误并退出信用卡，用例结束 备选流三：在基本流步骤中，用户输入错误密码，系统显示错误并提示用户重新输入密码，重新回到基本流步骤2；三次输入密码错误后，信用卡被系统没收，用例结束。

2.1.4 关系 用例与参与者之间的连线称为关系，关系也称为关联或通信关联它表示参与者与用例之间的通信这种通信是双向的，即参与者可以与用例通信，用例也可以与参与者通信下图表示了一个用例图中的关系23关系24用例之间的关系 用例描述的是系统外部可见的行为从原则上来讲，用例之间都是并列的，它们之间并不存在着包含从属关系但是从保证用例模型的可维护性和一致性角度来看，我们可以在用例之间抽象出包含(include)、扩展(extend)和泛化(generalization)这几种关系这几种关系都是从现有的用例中抽取出公共的那部分信息，然后通后过不同的方法来重用这部公共信息，以减少模型维护的工作量 用例之间的关系 泛化关系 包含关系 扩展关系泛化：同一业务目的的不同技术实现包含：提取公共交互，提高复用扩展：“冻结”基用例以保持稳定 *通过关系提高用例复用2.2 泛化 泛化是一种表示UML中项目的继承关系的技术泛化可以应用于参与者和用例来表示其子项从父项继承的功能，而且泛化还表示了父项的每个子项都有略微不同的功能功或目的以确保自己的惟一性272.2.1 泛化用例 相对于参与者而言，用例泛化更易理解。

用例泛化是指一个用例（一般为子用例）和另一个用例（父用例）之间的关系，其中的父用例描述了子用例与其他用例共享的特性，而这些用例是有着同一父用例的 泛化将特化用例和一般的用例联系起来即子用例是父用例的特化，子用例除具有父用例的特性外，他还可以有自己的另外特性父用例可以被特化成一个或多个子用例，然后用这些子用例来代表父用例的更多明确的形式图2-7演示一个泛化身份验证用例2829泛化举例（一）： 泛化举例（二）：2.2.2 泛化参与者 与用例一样，也可以对参与者进行泛化泛化后的参与者也在系统中扮演较为具体的角色如图2-12所示，假设图书管理系统中，管理员分为对系统进行维护的管理员和完成借书、还书等日常操作的图书管理员参与者Manager描述了参与者Librarian和Administrator所扮演的一般角色如果不考虑与系统交互时的职责，可以使用一般角色的参与者Manager如果强调管理员的职责，那么用例须使用精确的参与者即子类Librarian和Administrator32332.3 描述用例 用例图描述了参与者和系统特征之间的关系，但是它缺乏描述系统行为的细节所以一般情况下，还会以书面文档的形式对用例进行描述，每个用例应具有一个用例描述。

在UML中对用例的描述并没有硬性规定，但一般情况下用例描述应包括以下几个方面：名称 名称无疑应该表明用户的意图或用例的用途，如上面示例中的“借阅图书”、“归还图书”标识符可选 惟一标识符一个用例，如UC200601这样就可在项目的其他元素（如类模型）中用它来引用这个用例34 参与者可选 与此用例相关的参与者列表尽管这则信息包含在用例本身当中，但在没有用例图时，它有助于增加对该用例的理解 状态可选 指示用例的状态，通常为以下几种之一：进行中、等待审查、通过审查或未通过审查 频率（参与者使用此用例的频率） 前置条件352.4 用例之间的关系 用例描述系统满足需求的方式当细化描述用例操作步骤时，就可以发现有些用例以几种不同的模式或特列在运行，而有些用例在整个执行期间会出现多重流程如果将用例中重要的可选性操作流程从用例中分隔出来，以形成一个新的用例，这对整个系统的好处是显而易见的当分离可重复使用的用例后，用例之间就存在着某种特殊关系包含和扩展在是两个用例紧密相关时，关联用例的两种方法包含关系用于表示用例为执行其功能时需要从其他用例引入功能类似，扩展关系则表示用例的功能可以通过其他用例的功能得到扩充。

362.4.1 包含关系 在对系统进地分析时，通常会发现有些功能在不同的环境下都可以被使用在编写代码时，我们希望编写可重用的构件，这些构件包括诸如可以从其他代码中调用或参考的类库、子过程以及函数在用例图中UML支持同样的做法用例之间的包含关系在UML中的标记符如图2-14所示注意图中虚线箭头是指向被包含用例的37包含举例（一）：包含举例（二）：2.4.2 扩展关系 扩展关系是一种依赖关系,它指定了一个用例可以增强另一个用例的功能扩展关系与包含关系一样，只是将单词include替换成了表示扩展关系的单词extend扩展关系如图所示41扩展举例（一）：扩展举例（二）：2.5 用例建模 为了加深对前面所介绍知识的理解，本节将通过一个实际的系统用例图来说明用例图的创建过程在本节所采用的实例为一个图书馆的图书管理系统绘制用例图一般要经过以下几个步骤： 确定系统涉及的总体信息 确定系统的参与者 确定系统的用例 构造用例模型452.5.1 确定系统涉及的总体信息 图书管理系统是对图书馆中的藏书以及借阅者进行统一管理的系统系统的主要事务包括，图书管理员的书籍借出处理、书籍归还处理和查看借阅者的借阅信息；还有系统管理员对系统的维护，包括对管理员的维护、书籍的维护、借阅者信息的维护等。

在确定了系统的总体信息后就可以分析系统的参与者，并确定系统用例462.5.2 确定系统的参与者 寻找系统的参与者与用例通常是由与潜在用户会见的系统建模人员完成的在某些情况下，该任务还包括与借阅者面对面的访谈，在访谈中可以提出问题，了解他们的需求下面是一个针对图书管理系统的一个业务需求列表，它可以帮助我们创建用例图 系统可供图书管理员使用来完成记录学生借阅图书信息 系统允许用户浏览借阅信息 系统准确记录了图书馆中的所有藏书 系统需要允许图书管理员查询某学生的借阅信息472.5.3 。