下载文档原格式
需求中如何画用例图UML用例图用例图主要用来图示化系统的主事件流程，它主要用来描述客户的需求，即用户希望系统具备的完成一定功能的动作，通俗地理解用例就是软件的功能模块，所以是设计系统分析阶段的起点，设计人员根据客户的需求来创建和解释用例图，用来描述软件应具备哪些功能模块以及这些模块之间的调用关系，用例图包含了用例和参与者，用例之间用关联来连接以求把系统的整个结构和功能反映给非技术人员（通常是软件的用户），对应的是软件的结构和功能分解。
用例是从系统外部可见的行为，是系统为某一个或几个参与者（Actor）提供的一段完整的服务。
从原则上来讲，用例之间都是独立、并列的，它们之间并不存在着包含从属关系。
但是为了体现一些用例之间的业务关系，提高可维护性和一致性，用例之间可以抽象出包含(include)、扩展(extend)和泛(generalization)几种关系。
共性：都是从现有的用例中抽取出公共的那部分信息，作为一个单独的用例，然后通后过不同的方法来重用这个公共的用例，以减少模型维护的工作量。
1、包含(include)包含关系：使用包含（Inclusion）用例来封装一组跨越多个用例的相似动作（行为片断），以便多个基（Base）用例复用。
基用例控制与包含用例的关系，以及被包含用例的事件流是否会插入到基用例的事件流中。
基用例可以依赖包含用例执行的结果，但是双方都不能访问对方的属性。
包含关系对典型的应用就是复用，也就是定义中说的情景。
但是有时当某用例的事件流过于复杂时，为了简化用例的描述，我们也可以把某一段事件流抽象成为一个被包含的用例；相反，用例划分太细时，也可以抽象出一个基用例，来包含这些细颗粒的用例。
这种情况类似于在过程设计语言中，将程序的某一段算法封装成一个子过程，然后再从主程序中调用这一子过程。
例如：业务中，总是存在着维护某某信息的功能，如果将它作为一个用例，那新建、编辑以及修改都要在用例详述中描述，过于复杂；如果分成新建用例、编辑用例和删除用例，则划分太细。
⽤例图的画法及含义⽤例图中涉及的关系有：关联、泛化、包含、扩展。
如下表所⽰：a. 关联(Association)表⽰参与者与⽤例之间的通信，任何⼀⽅都可发送或接受消息。
【箭头指向】：指向消息接收⽅b. 泛化(Inheritance)就是通常理解的继承关系，⼦⽤例和⽗⽤例相似，但表现出更特别的⾏为；⼦⽤例将继承⽗⽤例的所有结构、⾏为和关系。
⼦⽤例可以使⽤⽗⽤例的⼀段⾏为，也可以重载它。
⽗⽤例通常是抽象的。
【箭头指向】：指向⽗⽤例c. 包含(Include)包含关系⽤来把⼀个较复杂⽤例所表⽰的功能分解成较⼩的步骤。
【箭头指向】：指向分解出来的功能⽤例d. 扩展(Extend)扩展关系是指⽤例功能的延伸，相当于为基础⽤例提供⼀个附加功能。
【箭头指向】：指向基础⽤例e. 依赖(Dependency)以上4种关系，是UML定义的标准关系。
但VS2010的⽤例模型图中，添加了依赖关系，⽤带箭头的虚线表⽰，表⽰源⽤例依赖于⽬标⽤例。
【箭头指向】：指向被依赖项5. 项⽬(Artifact)⽤例图虽然是⽤来帮助⼈们形象地理解功能需求，但却没多少⼈能够通看懂它。
很多时候跟⽤户交流甚⾄⽤Excel都⽐⽤例图强，VS2010中引⼊了“项⽬”这样⼀个元素，以便让开发⼈员能够在⽤例图中链接⼀个普通⽂档。
⽤依赖关系把某个⽤例依赖到项⽬上：然后把项⽬-》属性的Hyperlink设置到你的⽂档上；这样当你在⽤例图上双击项⽬时，就会打开相关联的⽂档。
6. 注释(Comment)包含(include)、扩展(extend)、泛化(Inheritance) 的区别：条件性：泛化中的⼦⽤例和include中的被包含的⽤例会⽆条件发⽣，⽽extend中的延伸⽤例的发⽣是有条件的；直接性：泛化中的⼦⽤例和extend中的延伸⽤例为参与者提供直接服务，⽽include中被包含的⽤例为参与者提供间接服务。
对extend⽽⾔，延伸⽤例并不包含基础⽤例的内容，基础⽤例也不包含延伸⽤例的内容。
用例图百科名片用例图就是由主角、用例以及它们之间的关系构成的图。
该图说明了用例模型中的关系。
简介用例图（User Case）是被称为参与者的外部用户所能观察到的系统功能的模型图，呈现了一些参与者和一些用例，以及它们之间的关系，主要用于对系统、子系统或类的功能行为进行建模。
用例图展示了用例之间以及同用例参与者之间是怎样相互联系的。
用例图用于对系统、子系统或类的行为进行可视化，使用户能够理解如何使用这些元素，并使开发者能够实现这些元素。
将每个系统中的用户分出工作状态的属性和工作内容，方便建模，防止功能重复和多余的类。
用例图定义了系统的功能需求，它是从系统的外部看系统功能，并不描述系统内部对功能的具体实现。
ps: 提取出“名词”，画用例图构成用例图由参与者（Actor）、用例（Use Case）、系统边界、箭头组成，用画图的方法来完成。
参与者参与者不是特指人，是指系统以外的，在使用系统或与系统交互中所扮演的角色。
因此参与者可以是人，可以是事物，也可以是时间或其他系统等等。
还有一点要注意的是，参与者不是指人或事物本身，而是表示人或事物当时所扮演的角色。
比如小明是图书馆的管理员，他参与图书馆管理系统的交互，这时他既可以作为管理员这个角色参与管理，也可以作为借书者向图书馆借书，在这里小明扮演了两个角色，是两个不同的参与者。
参与者在画图中用简笔人物画来表示，人物下面附上参与者的名称。
用例用例是对包括变量在内的一组动作序列的描述，系统执行这些动作，并产生传递特定参与者的价值的可观察结果。
这是UML对用例的正式定义，对我们初学者可能有点难懂。
我们可以这样去理解，用例是参与者想要系统做的事情。
对于对用例的命名，我们可以给用例取一个简单、描述性的名称，一般为带有动作性的词。
用例在画图中用椭圆来表示，椭圆下面附上用例的名称。
系统边界系统边界是用来表示正在建模系统的边界。
边界内表示系统的组成部分，边界外表示系统外部。
系统边界在画图中方框来表示，同时附上系统的名称，参与者画在边界的外面，用例画在边界里面。
需求中如何画用例图UML用例图用例图主要用来图示化系统的主事件流程，它主要用来描述客户的需求，即用户希望系统具备的完成一定功能的动作，通俗地理解用例就是软件的功能模块，所以是设计系统分析阶段的起点，设计人员根据客户的需求来创建和解释用例图，用来描述软件应具备哪些功能模块以及这些模块之间的调用关系，用例图包含了用例和参与者，用例之间用关联来连接以求把系统的整个结构和功能反映给非技术人员（通常是软件的用户），对应的是软件的结构和功能分解。
用例是从系统外部可见的行为，是系统为某一个或几个参与者（Actor）提供的一段完整的服务。
从原则上来讲，用例之间都是独立、并列的，它们之间并不存在着包含从属关系。
但是为了体现一些用例之间的业务关系，提高可维护性和一致性，用例之间可以抽象出包含(include)、扩展(extend)和泛(generalization)几种关系。
共性：都是从现有的用例中抽取出公共的那部分信息，作为一个单独的用例，然后通后过不同的方法来重用这个公共的用例，以减少模型维护的工作量。
1、包含(include)包含关系：使用包含（Inclusion）用例来封装一组跨越多个用例的相似动作（行为片断），以便多个基（Base）用例复用。
基用例控制与包含用例的关系，以及被包含用例的事件流是否会插入到基用例的事件流中。
基用例可以依赖包含用例执行的结果，但是双方都不能访问对方的属性。
包含关系对典型的应用就是复用，也就是定义中说的情景。
但是有时当某用例的事件流过于复杂时，为了简化用例的描述，我们也可以把某一段事件流抽象成为一个被包含的用例；相反，用例划分太细时，也可以抽象出一个基用例，来包含这些细颗粒的用例。
这种情况类似于在过程设计语言中，将程序的某一段算法封装成一个子过程，然后再从主程序中调用这一子过程。
例如：业务中，总是存在着维护某某信息的功能，如果将它作为一个用例，那新建、编辑以及修改都要在用例详述中描述，过于复杂；如果分成新建用例、编辑用例和删除用例，则划分太细。
UML中的用例(Use Case)概念分析及实例文/登峰2005-02-25在UML中use case似乎最簡單的，用例建模的最主要功能就是用来表达系统的功能性需求或行为，依我的理解用例建模可分为用例图和用例描述。
用例图由参与者（Actor）、用例（Use Case）、系统边界、箭头组成，用画图的方法来完成。
用例描述用来详细描述用例图中每个用例，用文本文档来完成，以及由箭头所组成的各种关系，包括泛化，包含，扩展等。
本文准备向大家介绍以下内容,所有图示均用PowerDesigner所画.◆用况◆参与者◆泛化◆<<use>>◆<<include>>◆<<extend>>◆用例描述１．用况（use case）图１用况图是对一组动作序列（其中包括它的变体）的描述，系统执行该动作为执行此动作的参与者产生一个可观察的结果值。
比如你使用计算器，这里可以把计算器看作为用况，参与者是登峰，登峰按了３＋３（用况执行的序列），计算机器返回一个结果６。
２．参与者(Actor)参与者不是特指人，是指系统以外的，在使用系统或与系统交互中所扮演的角色。
因此参与者可以是人，可以是事物，也可以是时间或其他系统等等。
还有一点要注意的是，参与者不是指人或事物本身，而是表示人或事物当时所扮演的角色。
比如小明是图书馆的管理员，他参与图书馆管理系统的交互，这时他既可以作为管理员这个角色参与管理，也可以作为借书者向图书馆借书，在这里小明扮演了两个角色，是两个不同的参与者。
参与者在画图中用简笔人物画来表示，人物下面附上参与者的名称。
３．泛化泛化和类中的泛化概念是一样的，子用况继承父用况的行为和含义，还可以增加或覆盖父用况的行为;子用况可以出现在任何父用况出现的位置（父和子均有具体的实例）。
下面给出两种图示来说明泛化的概念和含义图２含义继承图３行为继承４．<<user>><<use>>: 其关系非常象一个函数调用或一个子过程以这种方式使用的用例称为抽象用例因为它不能单独存在而必须被其它用例使用，请看下图图４使用<<use>>示例５．<<include>>怎么解释这个定义呢？还是说明一下它的功能吧，<<include>>可以把几个用例的公共步骤分离出来成为一个单独的被包含用例。
用例图的含义及画法用例图(Use Case Diagram)是由软件需求分析到最终实现的第一步，它描述人们如何使用一个系统。
用例视图显示谁是相关的用户、用户希望系统提供什么样的服务，以及用户需要为系统提供的服务，以便使系统的用户更容易理解这些元素的用途，也便于软件开发人员最终实现这些元素。
用例图在各种开发活动中被广泛的应用，但是它最常用来描述系统及子系统。
当用例视图在外部用户出现以前出现时，它捕获到系统、子系统或类的行为。
它将系统功能划分成对参与者（即系统的理想用户）有用的需求。
而交互部分被称作用例。
用例使用系统与一个或者多个参与者之间的一系列消息来描述系统中的交互。
用例图包含六个元素，分别是：参与者(Actor)、用例(Use Case)、关联关系(Association)、包含关系(Include)、扩展关系(Extend)以及泛化关系(Generalization)。
用例图可一个包含注释和约束，还可一个包含包，用于将模型中的元素组合成更大的模块。
有时，可以将用例的实例引入到图中。
用例图模型如下所示，参与者用人形图标来标识，用例用椭圆来表示，连线表示它们之间的关系。
一．参与者（Actor）1．参与者的概念参与者是系统外部的一个实体，它以某种方式参与用例的执行过程。
参与者通过向系统输入或请求系统输入某些事件来触发系统的执行。
参与着由参与用例时所担当的角色来表示。
在UML中，参与者用名字写在下面的人形图标表示。
每个参与者可以参与一个或多个用例。
它通过交换信息与用例发生交互（因此也与用例所在的系统或类发生了交互），而参与者的内部实现与用例是不相关的，可以用一组定义其状态的属性充分的描述参与者。
参与者有三大类：系统用户、与所建造的系统交互的其它系统和一些可以运行的进程。
第一类参与者是真实的人，即用户，是最常见的参与者，几乎存在于每个系统中。
命名这类参与者时，应当按照业务而不是位置命名，因为一个人可能有很多业务。
第二类参与者是其它的系统。
这类位于程序边界之外的系统也是参与者。
第三了参与者是一些可以运行的进程，如时间。
当经过一定的时间触发系统中的某个事件时，时间就成了参与者。
２．确定参与者在获取用例前首先要确定系统的参与者，开发人员可以通过回答以下的问题来寻找系统的参与者。
（1）谁将使用该系统的主要功能。
（2）谁将需要该系统的支持以完成其工作。
（3）谁将需要维护、管理该系统，以及保持该系统处于工作状态。
（4）系统需要处理哪些硬件设备。
（5）与该系统那个交互的是什么系统。
（6）谁或什么系统对本系统产生的结果感兴趣。
在对参与者建模的过程中，开发人员必须要牢记以下几点。
（1）参与者对于系统而言总是外部的，因此它们可以处于人的控制之外。
（2）参与者可以直接或间接的与系统交互，或使用系统提供的服务以完成某件事务。
（3）参与者表示人和事物与系统发生交户时所扮演的角色，而不是特定的人或者特定的事物。
（4）每个参与者需要一个具有业务一样的名字，在建模中不推荐使用类似“新参与者”的名字。
（5）每一个参与者要必须有简短的描述，从业务角度描述参与者是什么。
（6）一个人或事物在与系统发生交互时，可以同时或不同时扮演多个角色。
（7）和类一样，参与者可以具有表示参与者的属性和可以接受的事件，但使用的不频繁。
３．参与者之间的关系因为参与者是类，所以多个参与者之间可以具有与类相同的关系。
在用例视图中，使用了泛化关系来描述多个参与者之间的公共行为。
如果系统中存在几个参与者，它们既扮演自身的角色，同时也扮演更具一般化的角色，那么就用泛化关系来描述它们。
这种情况往往发生在一般角色的行为在参与者超类中描述的场合。
特殊化的参与者继承了该超类的行为，然后在某些方面扩展了此行为。
参与者之间的泛化关系用一个三角箭头来表示，指向扮演一般角色的超类。
这与UML中类之间的返还关系符号相同。
二用例（Use Case）1．用例的概念用例是外部可见的系统功能单元，这些系统功能由系统单元所提供，并通过一系列系统单元与一个或多个参与者之间交换的消息所表达。
用例的用途是，在不揭示系统内部构造的前提下定义连贯的行为。
用例的定义包含它所必须的所有行为——执行用例的主线次序、标准行为的不同变形、一般行为下的所有异常情况及其预期反应。
从用户的角度来看，上述情况很可能是异常情况；从系统的角度来看，它们是必须被描述和处理的附加情况。
更确切地说，用例不是需求或功能的规格说明，但是也展示和体现其所描述的过程中的需求情况。
在UML中，用例用一个椭圆表示。
在模型中，每个用例的执行都独立与其它用例，尽管在执行一个用例时由于用例之间共享对象的原因可能会在用例之间产生隐含的依赖关系。
每个用例都表示一个纵向的功能块，这个功能块的执行会和其它用例的执行混合在一起。
用例的动态执行过程可以用UML的交互来说明，可用用状态图、时序图、协作图或非正式的文字描述来表示。
用例功能的执行通过系统中类之间的协作来实现。
一个类可以参与多个协作，因此也参与了多个用例。
在系统层，用例表示整个系统对外部用户可见的行为。
一个用例就像外部用户可以使用的系统操作。
但是，它不又与操作不同，用例可以在执行过程中持续接受参与者的输入消息。
用例也可以被像子系统和独立类这样的系统小单元所应用。
一个内部用例表示了系统的一部分对其它部分呈现出的行为。
例如，某个类的用例表示了一个连贯的功能块，这个功能块是该类提供给系统内其它有特定作用的类的。
一个类可以有多个用例。
２．识别用例用例图对整个系统建模过程非常重要，在绘制系统用例图前，还有许多工作要做。
系统分析者必须分析系统的参与者和用例，他们分别描述了“谁来做”和“做什么”这两个问题。
识别用例最好的方法就是从分析系统的参与者开始，考虑每一个参与者是如何使用系统的。
使用这种策略的过程中可能会发现新的参与者，这对完善整个系统的建模有很大的帮助。
用例建模的过程是一个迭代和逐步精华的过程，系统分析者首先从用例的名称开始，然后添加用例的细节信息。
这些信息由简短的描述组成，它们被精华成完整的规格说明。
在识别用例的过程中，通过回答以下几个问题，系统分析者可以获得帮助。
（1）特定参与者希望系统提供什么功能。
（2）系统是否存储和检索信息，如果是，由哪个参与者触发。
（3）当系统改变状态时，是否通知参与者。
（4）是否存在影响系统的外部事件。
（5）哪个参与者通知系统这些事件。
３．用例与事件流用例分析处于系统的需求分析阶段，这个阶段应该尽量避免考虑系统实现的细节问题。
但是要实际建立系统，则需要更加具体的细节，这些细节写在事件流文件中。
事件流的目的是为用例的逻辑流程建立文档，这个文档详细描述系统用户的工作和系统本身的工作。
虽说事件流很详细，但其仍然是独立于实现的方法的。
换句话说，事件流描述的是一个系统“做什么”而不是“怎么做”。
事件流通常包括：简要说明、前提条件、主事件流、其它事件流和事后事件流。
（1）简要说明。
每个用例应当有一个相关的说明，描述该用例的作用，说明应当简明扼要，但应包括执行用例的不同类型的用户和通过这个用例要达到的结果。
（2）前提条件。
用例的前提条件列出用例之间必须满足的条件。
例如，前提条件是另一个用例已经执行或用户具有运行当前用例的权限。
但并不是所有用例都有前提条件。
（3）主事件流和其它事件流。
用例的具体细节在主事件流和其它事件流中描述。
事件流是从用户角度描述执行用例的具体步骤，关注系统“做什么”，而不是“怎么做”。
主事件流和其它事件流包括：用例如何开始和结束、用例如何与参与者交互、用例的正常流程（主流程）、用例主事件流（其它事件流）的变体和错误流。
（4）事后条件。
事后条件是用例执行完毕后必须为真的条件。
例如，可以在用例完成之后设置一个标识，这种信息就是事后条件。
与前提条件一样，事后条件可以增加用例次序方面的信息，如果要求一个用例执行完后必须执行另一个用，那么就可以在事后条件中说明这一点。
当然，并不是每个用例中都有事后条件。
三用例间的关系用例除了与参与者发生关系外，还可以具有系统中的多个关系，这些关系包括包含关系、扩展关系和泛化关系。
应用这些关系的目的是为了从系统中抽取出公共行为和其变体。
1．关联关系（Association）关联关系描述参与者与用例之间的关系，它是用于表示类的挂系的关联元类的实例。
在UML中，关联关系用箭头来表示。
关联关系表示参与者与用例之间的通信。
不同的参与者可以访问相同的用例，一般说来它们和该用例的交互是不一样的，如果一样的话，说明它们的角色可能是相同的。
如果两中交互的目的也相同，说明它们的角色是相同的，就可以将它们合并。
２．包含关系（Include）虽然每个用例的实例都是独立的，但是一个用例可以用其它的更简单的用例来描述。
这有点像通过继承父类并增加附加描述来定义一个类。
一个用例可以简单地包含其它用例具有的行为，并把它所包含的用例行为作为自身行为的一部分，这被称作包含关系。
在这种情况下，新用例不是初始用例的一个特殊例子，并且不能被初始用例所代替。
爱UML中，包含关系表示为虚线箭头交<<include>>字样，箭头指向被包含的用例。
包含关系把几个用例的公共步骤分离成一个单独的被包含用例。
被包含用例称作提供者用例，包含用例称作客户用例，提供者用例提供功能给客户使用。
用例间的包含关系允许包含提供者用例的行为到客户用例的事件中。
包含关系使一个用例的功能可以在另一个用例中使用，如下所述。
（1）如果两个以上用例有大量一致的功能，则可以将这个功能分解到另外一个用例中。
其它用例可以和这两个用例建立包含关系。
（2）一个用例的功能太多时，可以用包含关系建模两个小用例。
要使用包含关系，就必须在客户用例中说明提供者用例行为别包含的详细位置。
这一点同功能调用有点类似。
事实上，它们在某种程度上具有相似的语义。
３．扩展关系（Extend）一个用例也可以被定义为基础用例的增量扩展，这被称作扩展关系，扩展关系是把新的行为插入到已有的用例中的方法。
同一个基础用例的几个扩展用例可以在一起应用。
基础用例的扩展增加了原有的语义，此时基础用例而不是扩展用例被作为例子使用。
在UML中，扩展关系表示为虚线箭头加<<extend>>字样，箭头指向被扩展展的用例。
基础用例提供了一组扩展点，在这些新的扩展点中可以添加新的行为，而扩展用例提供了一组插入片片段，这些片段能够被插入到基础用例的扩展点上。
基础用例不必知道扩展用例的任何细节，它仅为其提供扩展点。
事实上，基础用例即使没有扩展用例也是完整的，这点与包含关系有所不同。
一个用例可能有多个扩展点，每个扩展点可以出现多次。
但是一般情况下，基础用例的执行不和涉及到扩展用例，只有特定的条件发生，扩展用例才被执行。
