第三章 用例图

1、UML- 1 -UML- 1 -第三章第三章 用例图用例图UML- 2 -n 用例建模是UML建模的一部分，它也是UML里最基础的部分； n 用例建模的最主要功能就是用来表达系统的功能性需求或行为；n 用例建模可分为用例图和用例描述； n 用例图是由软件需求分析到最终实现的第一步，它描述人们如何使用一个系统，是外部参与者所能观察到的系统功能的模型图，该图呈现了一些参与者和一些用例，以及它们之间的关系，主要用于对系统、子系统或类的功能行为进行建模，用画图的方法来完成；n 用例描述用来详细描述用例图中每个用例，用文本或图形来实现。UML- 3 -用例图的作用u 用例图展示了用例之间以及用例与参与者

2、之间是怎样相互联系的。用例图对系统、子系统或类的行为进行了可视化，使用户能够理解如何使用这些元素，并使开发者能够实现这些元素。u 用例图主要用来描述用户的功能需求。UML侧重从最终用户的角度来理解软件系统的需求，强调谁在使用系统、系统可以完成哪些功能。用例分析技术已经是一种公认有效的用户需求获取、分析和描述技术。UML- 4 -用例图用例图由如下元素组成：由如下元素组成：参与者参与者(Actor)(Actor)：也称为角色，它代表系统的用户。：也称为角色，它代表系统的用户。系统边界系统边界(System Scope)(System Scope)：它确定系统的范围。：它确定系统的范围。用例用例(

3、Use Case)(Use Case)：它代表系统提供的服务。：它代表系统提供的服务。关系关系(Association)(Association)：关联关系（：关联关系（AssociationAssociation）、）、包含关系（包含关系（IncludeInclude）、扩展关系（）、扩展关系（ExtendExtend）以及）以及泛化关系（泛化关系（GeneralizationGeneralization）。）。UML- 5 -UML- 6 -n 参与者参与者(actor)是指系统以外的、需要使用系统或与系统交互的是指系统以外的、需要使用系统或与系统交互的事物事物, 包括包括: 人、设备、外

4、部系统等人、设备、外部系统等. 其它译名有其它译名有: 活动者、执行活动者、执行者、行动者、角色等；者、行动者、角色等；n 参与者是系统外部的一个实体，参与者只可能存在于参与者是系统外部的一个实体，参与者只可能存在于边界之外边界之外，边界之内的所有人和事物都不是参与者。，边界之内的所有人和事物都不是参与者。UML- 7 -u 从图中可以看出，所有的用例都放置在系统边界内，表明它属于一个系从图中可以看出，所有的用例都放置在系统边界内，表明它属于一个系统。参与者则放在系统边界的外面，表明角色并不属于系统。但是角色负统。参与者则放在系统边界的外面，表明角色并不属于系统。但是角色负责直接（或间接）驱动

5、与之关联的用例的执行。责直接（或间接）驱动与之关联的用例的执行。UML- 8 -n 参与者有三大类：系统用户、与所建造的系统交互的其它系统和一些可以运行的进程。u第一类参与者是真实的人，即用户，命名这类参与者时，应当按照业务命名；u第二类参与者是其它的系统，这类位于程序边界之外的系统也是参与者。u第三类参与者是一些可以运行的进程，如时间。当经过一定的时间触发系统中的某个事件时，时间就成了参与者。UML- 9 -n 怎样识别参与者怎样识别参与者u谁向系统提供信息？u谁从系统获取（使用）信息？u谁管理这个系统？u谁维护这个系统？u系统要使用哪些外部资源？（系统启动打印机、扫描仪）u系统是否和已经存

6、在的系统交互？（跨行转账的外部银行系统、时间到了定时启动系统某功能）UML- 10 -查找参与者时请注意，参与者一定是直接并且主动的向系统发出动作并获得反馈的，否则就不是参与者。下面对机票预订系统进行分情况讨论：情况一：机票购买者通过登录网站购买机票，那么谁是参与者？UML- 11 -情况二：假如机票购买者通过呼叫中心，由人工座席操作订票系统购买机票，那么谁是参与者？UML- 12 -情况三：如果机票购买者通过呼叫中心的自动语音预定机票而不是通过人工座席，那么谁是参与者？UML- 13 -情况四：如果扩大系统边界，让呼叫中心成为机票预定系统的一个子系统，并且假设机票购买者将可以自主选择是通过人

7、工座席还是自动语音登录网站预订机票，那么谁是参与者？UML- 14 -在对参与者建模的过程中，注意以下几点：（1）参与者表示人和事物与系统发生交互时所扮演的角色，而不是特定的人或特定的事物；（2）每个参与者需要一个具有业务一样的名字；（3）一个人或事物在与系统交互时，可以同时或不同时扮演多个角色。UML- 15 -UML中的中的Actor实际上是一个版型化的类实际上是一个版型化的类, 可以有三种可以有三种表示形式表示形式Icon形式形式Label形式形式Decoration形式形式UML- 16 -Actor之间可以存在一定的关系之间可以存在一定的关系,参与者之间的关系参与者之间的关系一般表现

8、为特殊一般表现为特殊/一般化关系，即，泛化关系。一般化关系，即，泛化关系。UML- 17 -n 定义定义1: 用例是对一个参与者用例是对一个参与者(actor)使用系统的一项功能使用系统的一项功能时所进行的交互过程的一个文字描述序列。时所进行的交互过程的一个文字描述序列。n 定义定义2: 用例是系统、子系统或类和外部参与者交互的用例是系统、子系统或类和外部参与者交互的动作序列的说明动作序列的说明, 包括可选的动作序列和会出现异常的包括可选的动作序列和会出现异常的动作序列动作序列.n 用例是代表系统中各个项目相关人员之间就系统的行用例是代表系统中各个项目相关人员之间就系统的行为所达成的契约为所达

9、成的契约, 软件开发过程是用例驱动的软件开发过程是用例驱动的.UML- 18 -n 用例是一种需求方法学用例是一种需求方法学n 把用例解释为某个参与者把用例解释为某个参与者(actor)要做的一件事，这样的要做的一件事，这样的一件事有以下几个特征：一件事有以下几个特征： 1、这件事是相对独立的；2、这件事的执行结果对参与者来说是可观测的和有意义的；3、这件事必须由一个参与者发起 ；不存在没有参与者的用例，用例不应该自动启动。用例总是由一个参与者发起，并且满足特征二；4、这件事必然是以动宾短语形式出现的 。UML- 19 -n参与者希望系统执行什么任务？n参与者在系统中访问哪些信息？（创建、存储

10、、修改、删除等）n需要将外界的哪些信息提供给系统？n需要将系统的哪个事件告诉参与者？n如何维护系统？UML- 20 -如何判断一个用例是否是一个优秀的用例呢？ 用例是否描述了应该做什么，而不是如何做？ 用例的描述是否采取了参与者的视点？ 用例是否对参与者有价值？ 用例描述的时间流是否是一个完整场景？ 是否所有的参与者、用例都有相应的关联用例或关联参与者？UML- 21 -UML中用例用椭圆表示中用例用椭圆表示, 使用动宾结构或主谓结构命使用动宾结构或主谓结构命名名.例例: 字处理程序中字处理程序中, “置正文为黑置正文为黑体体”和和”创建索引创建索引”都可以是用都可以是用例例.UML- 22

11、-使用用例进行需求分析的特点使用用例进行需求分析的特点:1.用例从使用系统的角度描述系统中的信息用例从使用系统的角度描述系统中的信息.2.用例描述用户提出的一些可见需求用例描述用户提出的一些可见需求, 对应一个具体的用户目标对应一个具体的用户目标.3.用例是对系统行为的描述用例是对系统行为的描述, 属于属于UML的动态建模部分的动态建模部分.使用用例时注意的问题使用用例时注意的问题:1.不要将所有的需求都以用例的形式表示出来不要将所有的需求都以用例的形式表示出来.2.用例只描述系统功能性方面的需求用例只描述系统功能性方面的需求, 它只是全部需求的一部分它只是全部需求的一部分.3.本质上用例分析

12、是功能分解技术本质上用例分析是功能分解技术, 但目前是但目前是OO开发的第一步开发的第一步.4.用例是与实现无关的关于系统功能的描述用例是与实现无关的关于系统功能的描述.UML- 23 -n 用例精度指的是用例所包含的系统服务或功能单元的用例精度指的是用例所包含的系统服务或功能单元的多少。粒度越大，用例包含的功能越多，反之则包含多少。粒度越大，用例包含的功能越多，反之则包含的功能越少。用例粒度确定了用例模型级的复杂度和的功能越少。用例粒度确定了用例模型级的复杂度和用例内部的复杂度。用例内部的复杂度。n 怎样确定用例的粒度？（用例规模的大小）怎样确定用例的粒度？（用例规模的大小）u具体问题具体分

13、析。u用例的粒度可大可小，一般一个系统控制在20个左右，但没有严格规定u用例是系统级的、抽象的描述，不是细化的（考虑的是“做什么what”，而不是“怎样做how”）u对复杂的系统可以划分为若干子系统处理UML- 24 -n 实际上，用例粒度的划分依据最标准的方法是一个用例的粒度是否合适，是以该用例是否完成了参与者的某个目的为依据的。UML- 25 -n 对每一个用例都需要详细描述，这些信息包含在用例规约中。用例模型是对每一个用例都需要详细描述，这些信息包含在用例规约中。用例模型是由用例图和每一个用例的详细描述由用例图和每一个用例的详细描述用例规约所组成的。用例规约所组成的。 RUP 中提供中提

14、供了用例规约的模板，每一个用例的用例规约都应该包含以下内容：了用例规约的模板，每一个用例的用例规约都应该包含以下内容： u 简要说明 (Brief Description) 简要介绍该用例的作用和目的。 u 事件流 (Flow of Event) 包括基本流（正常）和备选流（异常），事件流应该表示出所有的场景。 u 用例场景（Use-Case Scenario)：用例的实例，分成功场景和失败场景，描述时要涵盖所有的场景。u 特殊需求 (Special Requirement) 描述与该用例相关的非功能性需求（包括性能、可靠性、可用性和可扩展性等）和设计约束（所使用的操作系统、开发工具等）。 u

15、 前置条件 (Pre-Condition) 执行用例之前系统必须所处的状态。 u 后置条件 (Post-Condition) 用例执行完毕后系统可能处于的一组状态。 n 用例规约基本上是用文本方式来表述的，为了更加清晰地描述事件流，也用例规约基本上是用文本方式来表述的，为了更加清晰地描述事件流，也可以选择使用状态图、活动图或顺序图来辅助说明。也可以使用用户界面可以选择使用状态图、活动图或顺序图来辅助说明。也可以使用用户界面和其他图形描述。和其他图形描述。UML- 26 -3.6 用例之间的关系用例之间的关系关系关系解释解释图图参与者与参与者与用例之间用例之间的关系的关系关联关联表示参与者与用例

16、之间的交互，通信途径。表示参与者与用例之间的交互，通信途径。(关联有时候也用带箭头的实线来表示，这样的表示能关联有时候也用带箭头的实线来表示，这样的表示能够显示地表明发起用例的是参与者。够显示地表明发起用例的是参与者。)用例之间用例之间的关系的关系包含包含箭头指向的用例为被包含的用例，称为包含用例；箭箭头指向的用例为被包含的用例，称为包含用例；箭头出发的用例为基用例。包含用例是必选的，如果缺头出发的用例为基用例。包含用例是必选的，如果缺少包含用例，基用例就不完整；包含用例必须被执行少包含用例，基用例就不完整；包含用例必须被执行，不需要满足某种条件；其执行并不会改变基用例的，不需要满足某种条件；

17、其执行并不会改变基用例的行为。行为。 include扩展扩展箭头指向的用例为被扩展的用例，称为扩展用例；箭箭头指向的用例为被扩展的用例，称为扩展用例；箭头出发的用例为基用例。扩展用例是可选的，如果缺头出发的用例为基用例。扩展用例是可选的，如果缺少扩展用例，不会影响到基用例的完整性；扩展用例少扩展用例，不会影响到基用例的完整性；扩展用例在一定条件下才会执行，并且其执行会改变基用例的在一定条件下才会执行，并且其执行会改变基用例的行为。行为。参与者之参与者之间的关系间的关系泛化泛化发出发出箭头的箭头的事物事物“is a”箭头指向的箭头指向的事物事物。泛化关系是泛化关系是一般和特殊关系，发出箭头的一方代表特殊的一方，一般和特殊关系，发出箭头的一方代表特殊的一方，箭头指向的一方代表一般一方。特殊一方继承了一般箭头指向的一方代表一般一方。特殊一方继承了一般方的特性并