初学UML 之用例图

初学UML之用例图——陈雨章节UML基础知识用例图

概述参与者（Actor）用例（Uesrcase）4种关系用例描述示例2011年2月28日星期一UML基础知识什么是UMLUML（统一建模语言，UnifiedModelingLanguage）是一种定义良好、易于表达、功能强大且普遍适用的可视化建模语言。它融入了软件工程领域的新思想、新方法和新技术。它的作用域不限于支持面向对象的分析与设计，还支持从需求分析开始的软件开发的全过程。

在系统分析阶段，我们一般用UML来画很多图，主要包括用例图、状态图、类图、活动图、序列图、协作图、构建图、配置图等等，要画哪些图要根据具体情况而定。其实简单的理解，UML的作用就是用很多图从静态和动态方面来全面描述我们将要开发的系统。2011年2月28日星期一2011年2月28日星期一UML基础知识UML的构成

2011年2月28日星期一UML基础知识UML中视图的关系

用例视图逻辑视图组件视图配置视图并发视图用例视图是其他视图的核心，它的内容直接驱动其他视图的开发。系统要提供的功能都是在用例视图中描述的，用例视图的修改会对其他视图产生影响。2011年2月28日星期一UML基础知识UML中的9种图

用例图（UesrcaseDiagram）：需求捕获，测试依据类图（ClassDiagram）：类以及类之间的相互关系对象图（ObjiectDiagram）：对象以及对象之间的相互关系状态图（StateDiagram）：对类描述的补充，类所经历的各种状态时序图（SequenceDiagram）：对象之间发送的消息的时间顺序协作图（CollaborationDiagram）：强调对象写作的交互图活动图（ActivityDiagram）：对工作流程建模组件图（ComponentDiagram）：组件及其之间的相互依赖关系配置图（DeploymentDiagram）：系统中硬件的软件的物理结构2011年2月28日星期一UML基础知识UML建模工具IBM的RationalRoseMS的VisioSparxSystems的EnterpriseArchitect（EA）PowerDesigner、trunfunplato…2011年2月28日星期一用例图概述——定义由参与者（Actor）、用例（usercase）以及它们之间的关系构成的用于描述系统功能的动态视图称为用例图。2011年2月28日星期一用例图概述——作用用例图是需求分析中的产物，主要作用是描述参与者（Actor）和用例（UserCase）之间的关系，帮助开发人员可视化得了解系统的功能。借助于用例图、系统用户、系统分析人员、系统设计人员、领域专家能够以可视化的方式对问题进行探讨，减少了大量交流上的障碍，便于对问题达成共识。用例图可视化地表达了系统的需求，具有直观、规范等优点，克服了纯文字性说明的不足。

用例方法是完全从外部来定义系统功能，它把需求和设计完全的分离开来。我们不用关心系统内部是如何完成各种功能的，系统对于我们来说就是一个黑箱子。2011年2月28日星期一用例图概述——构成要素参与者（Actor）用例（UserCase）关系（箭头）注释约束系统边界（也可以是一个“包”）用例描述2011年2月28日星期一用例图参与者（Actor）——概念要在用例上绘制一个参与者，可绘制一个人形符号，参与者的角色名称写在人形符号正下方。要注意的是，参与者不是指人或事物本身，而是表示人或事物当时所扮演的角色。比如小明是图书馆的管理员，他参与图书馆管理系统的交互，这时他既可以作为管理员这个角色参与管理，也可以作为借书者向图书馆借书，在这里小明扮演了两个角色，是两个不同的参与者。参与者有三大类：系统用户、与所建造的系统交互的其他系统、一些可以运行的进程。

每个参与者可以参与一个或多个用例，每个用例也可以有一个或多个参与者。2011年2月28日星期一用例图参与者（Actor）——确定参与者

在获取用例前首先要确定系统的参与者，建模人员可以通过回答以下的问题来寻找系统的参与者。谁将使用该系统的主要功能。谁将需要该系统的支持以完成其工作。谁将需要维护、管理该系统，以及保持该系统处于工作状态。系统需要处理哪些硬件设备。与该系统那个交互的是什么系统。

谁或什么系统对本系统产生的结果感兴趣。2011年2月28日星期一用例图参与者（Actor）——确定参与者在对参与者建模的过程中，建模人员必须要牢记以下几点：参与者对于系统而言总是外部的，因此它们可以处于人的控制之外。参与者可以直接或间接的与系统交互，或使用系统提供的服务以完成某件事务。

参与者表示人和事物与系统发生交户时所扮演的角色，而不是特定的人或者特定的事物。每个参与者需要一个具有业务一样的名字，在建模中不推荐使用类似“新参与者”的名字。每一个参与者要必须有简短的描述，从业务角度描述参与者是什么。

一个人或事物在与系统发生交互时，可以同时或不同时扮演多个角色。和类一样，参与者可以具有表示参与者的属性和可以接受的事件，但使用的不频繁。2011年2月28日星期一用例图参与者（Actor）——参与者之间的关系

因为参与者是类，所以多个参与者之间可以具有与类相同的关系。在用例视图中，使用了泛化关系（也称作继承关系）来描述多个参与者之间的公共行为。如果系统中存在几个参与者，它们既扮演自身的角色，同时也扮演更具一般化的角色，那么就用泛化关系来描述它们。这种情况往往发生在一般角色的行为在参与者超类中描述的场合。特殊化的参与者继承了该超类的行为，然后在某些方面扩展了此行为。参与者之间的泛化关系用一个三角箭头来表示，指向扮演一般角色的超类。2011年2月28日星期一用例图用例（UserCase）——概念

用例是对包括变量在内的一组动作序列的描述，系统执行这些动作，并产生传递特定参与者的价值的可观察结果。这是UML对用例的正式定义，对我们初学者可能有点难懂。我们可以这样去理解，用例是参与者想要系统做的事情。对于对用例的命名，我们可以给用例取一个简单、描述性的名称，一般为带有动作性的词。用例在画图中用椭圆来表示，椭圆下面附上用例的名称。2011年2月28日星期一用例图用例（UserCase）——识别用例

任何用例都不能在缺少参与者的情况下独立存在。同样，任何参与者也必须要有与之关联的用例。所以识别用例的最好方法就是从分析系统参与者开始，在这个过程中往往会发现新的参与者。

可以通过以下问题来寻找用例：参与者希望系统能提供什么功能？参与者是否会读取、创建、修改、删除、存储系统的某些信息？如果是的话，参与者又是如何完成这些操作的？参与者是否会将外部的某些时间通知给系统？是否存在影响系统的外部事件？2011年2月28日星期一用例图用例（UserCase）——用例的粒度

用例的粒度指的是用例所包含的系统服务或功能单元的多少。用例的粒度越大，用例包含的功能越多，反之则包含的功能越少。

如果用例的粒度很小，得到的用例数就会太多。反之，如果用例的粒度很大，那么得到的用例数就会很少。

如果用例的数目过多会造成用例模型过大和引入设计困难大大提高。如果用例数目过少会造成用例的粒度太大，不便于进一步的充分分析。2011年2月28日星期一用例图用例（UserCase）——用例的粒度

比如：网站后台管理系统中的会员信息维护用例，管理员需要进行添加会员信息、修改会员信息、删除会员信息等操作。

我们还可以根据具体的操作把它抽象成3个用例，它展示的系统需求和单个用例是完全一样的。2011年2月28日星期一用例图4种关系

用例除了与其参与者发生关联外，还可以具有系统中的多个关系，这些关系包括：包含关系（Include）扩展关系（Extend）泛化关系（Generalization）关联关系（Association）2011年2月28日星期一用例图4种关系——关联关系（Association）

关联关系描述参与者与用例之间的关系，表示参与者和用例之间的通信。不同的参与者可以访问相同的用例，一般来说它们和该用例的交互是不一样的，如果一样的话，说明它们的角色可能是相同的。如果两种交互的目的也相同，说明它们的角色是相同的，就可以将它们合并（参与者之间的泛化关系）。在Rose中关联关系用箭头表示，在EA中用直线表示。2011年2月28日星期一用例图4种关系——包含关系（Include）

包含关系指用例可以简单地包含其他用例具有的行为，并把它所包含的用例行为做为自身行为的一部分。在UML中，包含关系是通过带箭头的虚线线段加<<include>>字样来表示，箭头由基础用例(Base)指向被包含用例(Inclusion)。2011年2月28日星期一用例图4种关系——包含关系（Include）包含关系代表着基础用例会用到被包含用例，具体的讲就是被包含用例的事件流插入到基础用例的事件流中。例如：登录输入验证码如果两个以上用例有大量一致的功能，则可以将这个功能分解到另一个用例中。其他用例可以和这个用例建立包含关系。一个用例的功能太多时，可以用包含关系建模两个小用例。包含关系是UML1.3中的表述，在UML1.1中，同等语义的关系被表述为使用（Uses）。2011年2月28日星期一用例图4种关系——扩展关系（Extend）在一定条件下，把新的行为加入到已有的用例中，获得的新用例叫做扩展用例（Extension），原有的用例叫做基础用例（Base），从扩展用例到基础用例的关系就是扩展关系。

一个基础用例可以拥有一个或者多个扩展用例，这些扩展用例可以一起使用。

在UML中，扩展关系表示为虚线箭头加<<extend>>字样，箭头指向被扩展的用例（即基础用例）。2011年2月28日星期一用例图4种关系——扩展关系（Extend）基础用例不必知道扩展用例的任何细节，它仅为其提供扩展点。事实上，基础用例即使没有扩展用例也是完整的，这点与包含关系有所不同。

一般情况下，基础用例的执行不会涉及到扩展用例，只有特定的条件发生，扩展用例才被执行。例如：拼途网人人登录2011年2月28日星期一用例图4种关系——泛化关系（Generalization）用例的泛化指的是一个父用例可以被特化形成多个子用例，而父用例和子用例之间的关系就是泛化关系。

在用例的泛化关系中，子用例继承了父用例所有的结构、行为和关系，子用例是父用例的一种特殊形式。

在UML中，用例的泛化关系通过一个三角箭头从子用例指向父用例来表示。2011年2月28日星期一用例图4种关系——泛化关系（Generalization）例如：2011年2月28日星期一用例图用例描述

用例图只是简单地用图描述了一下系统，但对于每个用例，我们还需要有详细的说明，这样就可以让别人对这个系统有一个更加详细的了解，这时我们就需要写用例描述。

对于用例描述的内容，一般没有硬性规定的格式，但一些必须或者重要的内容还是必须要写进用例描述里面的。用例描述一般包括：简要描述（说明）、前置（前提）条件、基本事件流、其他事件流、异常事件流、后置（事后）条件等等。2011年2月28日星期一用例图用例描述简要描述对用例的角